albera.pl / Czego wymagać

Wymagania

Czego wymagać od systemu AI i jego dostawcy

Wymagania, które warto wpisać do opisu przedmiotu zamówienia i umowy na system AI. Przy każdym jest uzasadnienie i podpowiedź, jak je sprawdzić w ofercie. Dla zamawiających publicznych i firm

Dlaczego

Co dają Państwu dobre wymagania

To, co Państwo dostaną, ustalają opis przedmiotu zamówienia i umowa. Czego się w nich nie zapisze, tego później nie da się wymagać, a przy AI różnica między dobrym a słabym systemem często wychodzi dopiero po wdrożeniu. Dlatego zebraliśmy w jednym miejscu wymagania, które sprawdzamy w każdym zakupie AI: najpierw co Państwu dają, potem każde z osobna, z uzasadnieniem i sposobem sprawdzenia

System, który rozwiązuje Państwa problem

Wymagania opisane jako zadania i wyniki, sprawdzone testem na Państwa dokumentach, sprawiają, że wygrywa oferta, która działa u Państwa, a nie ta, która najlepiej wypada w prezentacji

Swoboda rozwoju

Zmiana modelu bez przebudowy aplikacji, nowe zastosowania na tym samym rozwiązaniu i rozbudowa przewidziana w umowie od pierwszego dnia

Ochrona danych i pomysłów

Dane, dokumenty i wiedza zespołu zostają pod Państwa kontrolą: nie trenują cudzych modeli, nie trafiają do nieznanych podwykonawców i wiadomo, kto i na jakiej podstawie może do nich sięgnąć

Bez ograniczeń

Bez uzależnienia od jednego dostawcy, jednej chmury czy jednej licencji: eksport danych w otwartych formatach, plan wyjścia i znany z góry koszt zmiany

Spełnione wymagania prawa

AI Act, RODO, ustawa o krajowym systemie cyberbezpieczeństwa i DORA nakładają obowiązki na organizację, która korzysta z AI. Dobre wymagania sprawiają, że dostawca dostarcza wszystko, czego potrzeba, żeby je spełnić i wykazać przy kontroli

Wymagania

45 wymagań w 9 obszarach

Przy każdym wymaganiu piszemy, dlaczego warto je postawić i jak sprawdzić je w ofercie. Proszę wybrać obszar albo wpisać słowo, na przykład „rejestr”, „SLA” czy „eksport”

Obszar 1

Skład systemu i łańcuch dostaw

Zamawiający wie, co kupuje i od kogo zależy działanie systemu

Wymaganie 1.1

Pełny skład systemu w ofercie

Oferta wymienia wszystkie elementy rozwiązania: modele AI z nazwą, wersją i dostawcą, infrastrukturę (chmura albo serwery zamawiającego), miejsce przetwarzania danych oraz podwykonawców i komponenty innych firm

Dlaczego: „Własne oprogramowanie” bywa nakładką na cudzy model i cudzą chmurę, a od tych elementów zależą jakość, koszt i bezpieczeństwo. Prawo zamówień publicznych pozwala żądać wskazania podwykonawców (art. 462 ust. 2), a RODO wymaga zgody administratora na dalsze podmioty przetwarzające (art. 28 ust. 2)
Jak sprawdzić: Schemat architektury i lista komponentów w ofercie, z oświadczeniem, które elementy wykonawca dostarcza sam, a które kupuje

Wymaganie 1.2

Zmiany tylko za zgodą zamawiającego

Zmiana modelu, chmury albo podwykonawcy wymaga wcześniejszego powiadomienia i zgody zamawiającego, poprzedzonej testem jakości

Dlaczego: Ta sama aplikacja na innym modelu odpowiada inaczej, a nowy podwykonawca to nowe ryzyko dla danych
Jak sprawdzić: Postanowienie w projekcie umowy z terminem powiadomienia i obowiązkiem testu przed zmianą

Wymaganie 1.3

Dokumentacja, której potrzebuje zamawiający

Dostawca przekazuje instrukcję oraz informacje o przeznaczeniu, ograniczeniach i dokładności systemu, w języku polskim

Dlaczego: Bez nich organizacja nie spełni własnych obowiązków z AI Act (art. 13 i 26) ani nie przeprowadzi oceny skutków dla ochrony danych i dla praw podstawowych
Jak sprawdzić: Wzór dokumentacji albo jej spis treści dołączony do oferty

Wymaganie 1.4

Licencje na wszystkie elementy

Oferta wskazuje licencje modeli i komponentów i potwierdza, że obejmują zastosowanie i skalę zamawiającego

Dlaczego: Także modele nazywane otwartymi mają warunki licencji, które mogą ograniczać zastosowania albo skalę
Jak sprawdzić: Lista licencji w ofercie z odesłaniem do ich treści

Obszar 2

Dane i jurysdykcja

Suwerenność opisana cechami, a nie pochodzeniem dostawcy

Wymaganie 2.1

Znane miejsce przetwarzania

Oferta wskazuje, gdzie są przetwarzane i przechowywane dane, kopie zapasowe i rejestry zdarzeń, także przy wsparciu technicznym, na przykład tylko w Polsce albo w Europejskim Obszarze Gospodarczym

Dlaczego: Od miejsca przetwarzania zależą obowiązki z RODO przy przekazywaniu danych poza EOG oraz wymagania przepisów branżowych
Jak sprawdzić: Oświadczenie w ofercie i postanowienie w umowie, z obowiązkiem informowania o zmianie

Wymaganie 2.2

Dane nie trenują cudzych modeli

Dane, dokumenty, zapytania i odpowiedzi zamawiającego nie mogą służyć do trenowania ani ulepszania modeli dostawcy i innych klientów, a po zakończeniu umowy są usuwane z potwierdzeniem

Dlaczego: To ochrona tajemnic, pomysłów i danych osobowych: tego, co raz trafiło do trenowania, nie da się wycofać
Jak sprawdzić: Zakaz w umowie i w warunkach usługi modelu, także u podwykonawców

Wymaganie 2.3

Kto może sięgnąć po dane

Dostawca wskazuje, czy on albo jego podwykonawcy podlegają przepisom państw spoza Unii Europejskiej, które mogą nakazać przekazanie danych, i jak postąpi w takim przypadku. Tam, gdzie dane tego wymagają, klucze szyfrowania są w rękach zamawiającego

Dlaczego: O suwerenności decyduje to, kto i na jakiej podstawie może uzyskać dostęp do danych, a nie adres siedziby czy kraj pochodzenia dostawcy
Jak sprawdzić: Oświadczenie w ofercie i opis zarządzania kluczami

Wymaganie 2.4

Uruchomienie u zamawiającego, gdy dane tego wymagają

System można uruchomić na infrastrukturze zamawiającego albo w środowisku bez dostępu do internetu, jeśli wymaga tego rodzaj danych

Dlaczego: Niektóre informacje, na przykład dane szczególnie chronione czy dane infrastruktury krytycznej, nie powinny opuszczać organizacji. Takie wymaganie trzeba uzasadnić w dokumentach zamówienia, bo opis nie może bez potrzeby utrudniać uczciwej konkurencji (art. 99 ust. 4 Pzp)
Jak sprawdzić: Opis wymagań sprzętowych w ofercie i demonstracja działania w takim trybie

Wymaganie 2.5

Wyjście od dostawcy zaplanowane z góry

Umowa przewiduje eksport danych, dokumentów, konfiguracji i zapisanych poleceń w otwartych formatach, pomoc przy przeniesieniu do innego dostawcy i znany z góry koszt wyjścia

Dlaczego: Koszt zmiany dostawcy decyduje o tym, czy organizacja ma jeszcze wybór. To najprostsza ochrona przed uzależnieniem od dostawcy (vendor lock-in)
Jak sprawdzić: Plan wyjścia w ofercie i próbny eksport przy odbiorze

Obszar 3

Jakość po polsku na Państwa dokumentach

Jakość sprawdza się testem, a nie deklaracją

Wymaganie 3.1

Test na pytaniach i dokumentach zamawiającego

Przed wyborem oferty system odpowiada na zbiór pytań przygotowany przez zamawiającego, na jego dokumentach i po polsku

Dlaczego: Ogólne testy i deklaracje nie pokazują, jak model radzi sobie z polszczyzną, terminologią branżową i Państwa dokumentami, a słaba odpowiedź może kosztować więcej niż licencja
Jak sprawdzić: Test opisany w dokumentach zamówienia jako przedmiotowy środek dowodowy (art. 106 Pzp)

Wymaganie 3.2

Miary jakości ustalone z góry

Zamawiający określa, co mierzy: odsetek poprawnych odpowiedzi, odpowiedzi ze wskazanym źródłem, uczciwe „nie wiem” zamiast zmyślenia i czas odpowiedzi

Dlaczego: Tylko zmierzoną jakość da się porównać, odebrać i egzekwować w umowie
Jak sprawdzić: Miary i sposób liczenia w opisie przedmiotu zamówienia

Wymaganie 3.3

Jakość w kryteriach oceny ofert

Wynik testu jakości jest kryterium oceny ofert, obok ceny i kosztu całkowitego

Dlaczego: Zamawiający z sektora finansów publicznych co do zasady nie mogą nadać cenie wagi wyższej niż 60 procent (art. 246 Pzp), a w zakupach AI to jakość decyduje o efekcie
Jak sprawdzić: Kryterium z wagą i opisem punktacji w specyfikacji

Obszar 4

Gotowy produkt i doświadczenie dostawcy

Dowody zamiast obietnic

Wymaganie 4.1

Referencje z wdrożeń produkcyjnych

Wykonawca wykazuje wdrożenia podobnego systemu, które działają w codziennej pracy klientów, a nie tylko pilotaże

Dlaczego: Pilotaż pokazuje, że coś może działać, a wdrożenie produkcyjne, że działa. Warunki udziału muszą być przy tym proporcjonalne do przedmiotu zamówienia (art. 112 ust. 1 Pzp)
Jak sprawdzić: Wykaz wdrożeń z dowodami i kontaktem do klienta

Wymaganie 4.2

Demonstracja na danych zamawiającego

Wykonawca pokazuje działanie systemu na danych i scenariuszach zamawiającego, a nie na przygotowanym pokazie

Dlaczego: Dowodzić, a nie deklarować: to samo zalecają wyroki KIO o zakupach oprogramowania
Jak sprawdzić: Demonstracja według scenariusza z dokumentów zamówienia

Wymaganie 4.3

Osobno to, co działa dziś, i to, co jest w planach

Oferta rozdziela funkcje dostępne dziś w produkcji, funkcje w pilotażu i funkcje planowane, a odbiór obejmuje tylko to, co działa

Dlaczego: Plan rozwoju to nie produkt, a za obietnicę trudno wyegzekwować odpowiedzialność
Jak sprawdzić: Tabela funkcji z oznaczeniem stanu i datą

Wymaganie 4.4

Zespół z doświadczeniem w AI

Oferta wskazuje osoby odpowiedzialne za wdrożenie, ich role i doświadczenie, a zmiana kluczowych osób wymaga zgody zamawiającego

Dlaczego: Wynik wdrożenia AI zależy od ludzi tak samo jak od produktu
Jak sprawdzić: Wykaz osób i postanowienie o zmianie składu zespołu

Obszar 5

Utrzymanie i odpowiedzialność za całość

Darmowy model to nie darmowe utrzymanie

Wymaganie 5.1

Jeden odpowiedzialny za całość

Wykonawca odpowiada za działanie całego rozwiązania, także za komponenty open source i modele innych firm

Dlaczego: Gdy coś przestaje działać, zamawiający nie może szukać winnego wśród kilku dostawców i społeczności projektu
Jak sprawdzić: Postanowienie o odpowiedzialności i wsparciu obejmujące wszystkie komponenty z listy

Wymaganie 5.2

Poprawki bezpieczeństwa i zgłaszanie podatności

Wykonawca dostarcza poprawki bezpieczeństwa w określonym czasie i informuje zamawiającego o podatnościach i incydentach

Dlaczego: Cyber Resilience Act od 11 września 2026 roku wymaga od producentów zgłaszania aktywnie wykorzystywanych podatności, a ustawa o krajowym systemie cyberbezpieczeństwa i DORA obejmują też łańcuch dostaw
Jak sprawdzić: Czasy dostarczenia poprawek w SLA i procedura zgłaszania incydentów

Wymaganie 5.3

Wsparcie przez cały okres umowy

Umowa określa okres wsparcia, aktualizacje modeli i oprogramowania oraz czasy reakcji i naprawy

Dlaczego: System AI starzeje się szybciej niż zwykłe oprogramowanie: zmieniają się modele, przepisy i dane
Jak sprawdzić: Parametry wsparcia w SLA i ceny po okresie podstawowym

Wymaganie 5.4

Kod i wiedza dla zamawiającego

Dla elementów tworzonych dla zamawiającego wykonawca przekazuje kod źródłowy albo składa go w depozycie, razem z dokumentacją potrzebną do utrzymania

Dlaczego: Zamawiający nie zostaje bez wyjścia, gdy wykonawca zmieni ofertę albo zniknie z rynku
Jak sprawdzić: Postanowienie o kodzie źródłowym lub depozycie i odbiór dokumentacji

Obszar 6

Warstwa kontroli między ludźmi a modelami

Polityka korzystania z AI egzekwowana przez system, a nie tylko spisana

Wymaganie 6.1

Jeden kontrolowany punkt dostępu

Wszystkie modele i narzędzia AI są dostępne przez jeden punkt z regułami według użytkownika, roli, rodzaju danych, modelu i środowiska, które można sprawdzić przed uruchomieniem

Dlaczego: To koniec AI używanej w cieniu i warunek, żeby polityka korzystania z AI działała naprawdę
Jak sprawdzić: Pokaz konfiguracji reguł i ich testu na przykładowych zapytaniach

Wymaganie 6.2

Ochrona danych przed wysłaniem do modelu

Dane osobowe i poufne (na przykład PESEL, NIP, adresy e-mail) są wykrywane i maskowane, zanim zapytanie opuści sieć zamawiającego. Zamiast maskowania można zapytanie zablokować albo przekazać do decyzji człowieka

Dlaczego: RODO i tajemnice przedsiębiorstwa chroni się przed wysłaniem danych, a nie po incydencie
Jak sprawdzić: Test na zapytaniach z danymi osobowymi w czasie demonstracji

Wymaganie 6.3

Kierowanie zapytań według rodzaju danych

Zapytania z danymi poufnymi trafiają tylko do modeli działających u zamawiającego, a system ma model zapasowy na wypadek awarii

Dlaczego: Organizacja korzysta z najlepszych modeli tam, gdzie wolno, i chroni dane tam, gdzie trzeba, bez ręcznego pilnowania
Jak sprawdzić: Opis reguł kierowania i pokaz przełączenia na model zapasowy

Wymaganie 6.4

Rejestr zdarzeń

Każde wywołanie modelu jest zapisywane (użytkownik, model, koszt, kontekst) w rejestrze zabezpieczonym przed zmianą, z eksportem i możliwością odtworzenia zapytania

Dlaczego: Podmiot stosujący system wysokiego ryzyka przechowuje rejestry zdarzeń co najmniej przez sześć miesięcy (art. 26 ust. 6 AI Act), a rejestr jest też dowodem przy kontroli KRiBSI i audycie
Jak sprawdzić: Pokaz rejestru i przykładowy eksport

Wymaganie 6.5

Ochrona przed atakami na model

System wykrywa próby obejścia zasad modelu (prompt injection, jailbreak) i sprawdza odpowiedzi, zanim trafią do użytkownika

Dlaczego: Model połączony z danymi i narzędziami organizacji staje się nową drogą ataku
Jak sprawdzić: Opis zabezpieczeń i wynik testu na przykładowych atakach

Wymaganie 6.6

Budżety i limity kosztów

Zamawiający ustala budżety na zespół, projekt i model, a system wykrywa nietypowe zużycie

Dlaczego: Rozliczenie za użycie bez limitów to koszt, którego nie da się zaplanować
Jak sprawdzić: Pokaz ustawienia limitu i raportu kosztów

Wymaganie 6.7

Zmiana modelu bez zmiany aplikacji

Model można zmienić w ustawieniach, bez przebudowy aplikacji, po teście nowego modelu na zbiorze zamawiającego

Dlaczego: Rynek modeli zmienia się szybko, a organizacja powinna móc korzystać z lepszych i tańszych modeli bez nowego wdrożenia
Jak sprawdzić: Pokaz zmiany modelu i testu porównawczego

Wymaganie 6.8

Nadzór człowieka i przejrzystość

Kroki krytyczne czekają na zatwierdzenie przez uprawnioną osobę, treści wytworzone przez AI są oznaczane, a uprawnienia agentów do narzędzi są nadawane według użytkownika, roli i zespołu

Dlaczego: AI Act wymaga nadzoru człowieka przy systemach wysokiego ryzyka (art. 14 i 26) i przejrzystości wobec osób, które mają kontakt z AI (art. 50)
Jak sprawdzić: Pokaz zatwierdzania kroku i oznaczenia treści

Obszar 7

Stanowisko pracy z AI

Odpowiedź, którą da się sprawdzić, w narzędziach, z których zespół już korzysta

Wymaganie 7.1

Odpowiedzi ze źródłem

Odpowiedzi oparte na dokumentach zamawiającego wskazują konkretny fragment pliku, a pytania bez odpowiedzi trafiają do rejestru luk w wiedzy

Dlaczego: Użytkownik sprawdza odpowiedź w kilka sekund, a organizacja widzi, jakiej wiedzy jej brakuje
Jak sprawdzić: Test na dokumentach zamawiającego z oceną wskazanych źródeł

Wymaganie 7.2

Dostęp według istniejących uprawnień

System korzysta z tożsamości i uprawnień organizacji (na przykład SSO, LDAP, SCIM), więc użytkownik widzi tylko te dokumenty, które widzi dziś

Dlaczego: Bez tego AI staje się skrótem do informacji, do których pracownik nie powinien mieć dostępu
Jak sprawdzić: Test na dwóch kontach z różnymi uprawnieniami

Wymaganie 7.3

Biblioteka zatwierdzonych poleceń

Zespół korzysta ze wspólnych, zatwierdzonych poleceń do typowych zadań i może je ponownie wykorzystać

Dlaczego: Dobre polecenie to wiedza organizacji, która nie powinna zostawać w głowie jednej osoby
Jak sprawdzić: Pokaz biblioteki i sposobu zarządzania nią

Wymaganie 7.4

Porównanie odpowiedzi kilku modeli

Przy ważnych pytaniach użytkownik może uzyskać odpowiedzi kilku modeli i porównać je obok siebie

Dlaczego: Zgodność kilku niezależnych odpowiedzi to prosty sposób weryfikacji, a różnice pokazują, gdzie trzeba sprawdzić źródło
Jak sprawdzić: Pokaz w czasie demonstracji

Wymaganie 7.5

Agenci pod kontrolą

Agenci działają według reguł zapisanych zwykłym językiem, przedstawiają plan do zatwierdzenia, mają limity działań i pełną historię przebiegów

Dlaczego: Automatyzacja bez planu i historii to ryzyko, którego nikt nie nadzoruje
Jak sprawdzić: Pokaz zatwierdzenia planu agenta i historii jego działań

Wymaganie 7.6

Przejrzysta pamięć asystenta

Jeśli asystent zapamiętuje informacje o pracy użytkownika, użytkownik widzi, czego się nauczył, i może to poprawić

Dlaczego: To przejrzystość wobec pracownika i porządek w danych osobowych
Jak sprawdzić: Pokaz podglądu i poprawiania pamięci

Wymaganie 7.7

Ocena odpowiedzi przez użytkowników

Użytkownicy oceniają odpowiedzi, a oceny trafiają do rejestru, z którego korzysta pomiar jakości

Dlaczego: To najtańsze źródło danych o jakości i podstawa SLA na jakość odpowiedzi
Jak sprawdzić: Pokaz oceny i raportu z rejestru

Wymaganie 7.8

Integracja z systemami zamawiającego

System współpracuje z narzędziami, z których organizacja już korzysta, na przykład EZD RP, ePUAP, e-Doręczenia, KSeF czy Microsoft 365

Dlaczego: AI przynosi efekt w codziennej pracy, a nie w osobnym oknie, do którego trzeba przenosić dokumenty
Jak sprawdzić: Lista integracji dostępnych dziś i pokaz jednej z nich

Obszar 8

SLA na jakość odpowiedzi

System dostępny przez cały czas może źle odpowiadać

Wymaganie 8.1

Jakość w umowie o poziomie usług

SLA obejmuje miary jakości odpowiedzi, zbiór testowy uzgodniony z zamawiającym oraz sposób i częstotliwość pomiaru, a nie tylko dostępność

Dlaczego: Dostępność mówi, że system działa, a jakość, że działa dobrze
Jak sprawdzić: Wzór SLA z miarami jakości w dokumentach zamówienia

Wymaganie 8.2

Test po każdej zmianie

Każda zmiana modelu, konfiguracji albo bazy wiedzy przechodzi test na zbiorze testowym, zanim trafi do użytkowników

Dlaczego: Zmiany po stronie dostawcy modelu potrafią obniżyć jakość bez żadnego komunikatu
Jak sprawdzić: Procedura zmian i raport z testu przy odbiorze

Wymaganie 8.3

Raport i konsekwencje

Wykonawca co miesiąc raportuje jakość i koszty, a niedotrzymanie progów oznacza obniżenie wynagrodzenia albo plan naprawczy

Dlaczego: Miara bez konsekwencji nie zmienia jakości
Jak sprawdzić: Progi i skutki ich niedotrzymania w umowie

Wymaganie 8.4

Klasyczne parametry usługi

SLA obejmuje też dostępność, czas odpowiedzi systemu oraz czasy reakcji i naprawy

Dlaczego: To podstawa, bez której jakość odpowiedzi nie ma znaczenia
Jak sprawdzić: Parametry i sposób ich pomiaru w SLA

Obszar 9

Etapy, bramki i odbiory

Zamawiający decyduje na każdej bramce i płaci za odebrany wynik

Wymaganie 9.1

Etapy z bramkami decyzyjnymi

Wdrożenie jest podzielone na etapy (na przykład Proof of Concept, pilotaż, produkcja) z kryteriami przejścia, a decyzję o przejściu podejmuje zamawiający

Dlaczego: Ryzyko rośnie z każdym etapem, więc decyzja o kolejnych pieniądzach powinna zapadać na podstawie wyników
Jak sprawdzić: Harmonogram z bramkami i kryteriami w ofercie

Wymaganie 9.2

Odbiór na podstawie miar

Każdy etap jest odbierany na podstawie zmierzonych wyników, a nie prezentacji

Dlaczego: Wrażenie z pokazu nie mówi, jak system działa na prawdziwych danych
Jak sprawdzić: Kryteria odbioru i raport z testów dla każdego etapu

Wymaganie 9.3

Płatność za wynik i prawo do zatrzymania

Wynagrodzenie jest powiązane z odebranymi etapami, a zamawiający może zakończyć projekt po etapie, jeśli wynik nie spełnia kryteriów

Dlaczego: Organizacja płaci za efekt, a nie za czas, i nie finansuje projektu, który się nie sprawdził
Jak sprawdzić: Harmonogram płatności i postanowienia o zakończeniu po etapie

Wymaganie 9.4

Ludzie i kompetencje w planie wdrożenia

Plan obejmuje szkolenia użytkowników, plan adopcji i dokumentację dla zespołów

Dlaczego: Art. 4 AI Act wymaga środków wspierających kompetencje w zakresie AI, a system, z którego nikt nie korzysta, nie przynosi efektu
Jak sprawdzić: Program szkoleń i plan adopcji w ofercie

Wymaganie 9.5

Dowody zgodności od wykonawcy

Wykonawca dostarcza informacje do oceny skutków dla praw podstawowych i dla ochrony danych, wpis do rejestru systemów AI i ślad audytowy decyzji

Dlaczego: Przy kontroli zgodność wykazuje organizacja, która korzysta z AI, a potrzebne materiały ma wykonawca
Jak sprawdzić: Lista dokumentów zgodności z terminem ich przekazania

Jak korzystać

Jak wpisać wymagania do zamówienia

Wybierają Państwo tylko te wymagania, których naprawdę potrzebują, i każde uzasadniają potrzebą albo przepisem, bo opis przedmiotu zamówienia nie może bez potrzeby utrudniać uczciwej konkurencji (art. 99 ust. 4 Pzp)
Opisują Państwo cechy i wyniki, a nie marki ani pochodzenie. Konkretny produkt można wskazać tylko wyjątkowo i zawsze z wyrazami „lub równoważny”
Jakość sprawdzają Państwo testem na własnych danych, a jego wynik wpisują do kryteriów oceny ofert
Wymagania dotyczące zmian modelu, wyjścia od dostawcy i SLA warto zapisać w projektowanych postanowieniach umowy już w dokumentach zamówienia

Pomożemy przełożyć tę listę na Państwa zamówienie: wybrać wymagania, zapisać je w opisie przedmiotu zamówienia i w umowie oraz przygotować test na Państwa danych. Pierwsza rozmowa trwa 30 minut i jest bezpłatna

Umów rozmowę