Checklista przed premierą wdrożenia AI: 30 punktów, podpis przed szefem i klientem (PDF do pobrania) 

Wdrożenie AI w firmie ma jeden moment, w którym wszystko się rozstrzyga: premierę. Nie pilot, nie wersję testową. Dzień, w którym asystent wchodzi na produkcję, zaczyna czytać dane firmy i zaczyna odpowiadać klientom. Po tym dniu cofnięcie go jest już o wiele trudniejsze niż powiedzenie „nie teraz".

Dlatego buduję tę checklistę wokół dwóch podpisów. Najpierw podpis przed szefem, czyli zgoda wewnątrz firmy na to, żeby w ogóle zacząć. Potem podpis przed klientem, czyli umowa powierzenia przetwarzania danych, czyli DPA, i klauzule, które musisz mieć w ręku, zanim jakakolwiek dana firmowa pójdzie do modelu językowego. To są 30 punktów, które przechodzę z każdym wdrożeniem, zanim napiszę pierwszą linijkę konfiguracji.

Nie jestem prawnikiem. Poniżej nie ma wzorów umów do podpisania, są punkty kontrolne i liczby, które musisz wiedzieć, żeby świadomie podpisać albo nie podpisać. Umowę powierzenia warto pokazać prawnikowi albo inspektorowi ochrony danych. Reszta to Twoja robota.

Dlaczego checklista ma dwa podpisy, a nie jeden

Bo to są dwa zupełnie różne ryzyka. Podpis przed szefem dotyczy decyzji biznesowej: czy ten proces w ogóle warto automatyzować, kto bierze odpowiedzialność i co się dzieje, gdy model się myli. Podpis przed klientem dotyczy twardych ram prawnych: kto jest administratorem danych, kto procesorem, gdzie fizycznie leżą dane i co się z nimi dzieje, gdy znikniecie z rynku.

Pomylenie tych dwóch rzeczy to najczęstszy błąd, jaki widzę przy mniejszych firmach. Zespół dogaduje automatyzację na poziomie „fajnie, że odpowiada w 2 sekundy”, a nikt nie sprawdził, czy te odpowiedzi powstają na infrastrukturze w Europie, czy za granicą. Z drugiej strony firma miesiąc negocjuje klauzule z klientem, nie odpowiadając na pytanie, co się stanie, gdy asystent wygeneruje błędne dane i nikt tego nie zauważy.

Dobra wiadomość jest taka, że obie listy są krótkie, jeśli trzymać się faktów. Reszta tego artykułu to 30 punktów w sześciu blokach: pięć pierwszych bloków to decyzje wewnętrzne, szósty to umowa.

Blok 1: dowód, że problem jest prawdziwy (punkty 1 do 5)

1. Nazwij proces jednym zdaniem. Nie „automatyzacja obsługi klienta”, tylko „rozliczanie faktur wstecznych”. Proces, którego nie da się opisać w jednym zdaniu, nie da się też zmierzyć.

2. Zmierz, ile czasu zjada dziś. Potrzebujesz liczby sprzed wdrożenia, inaczej nie policzysz efektu. Jeśli nie masz, policz przez tydzień na próbę: godziny pracy przy jednym zadaniu, mnożone przez liczbę zadań. To jedyna miara, o której da się dyskutować bez emocji.

3. Sprawdź, czy problem wart jest automatyzacji. Nie wszystko. Jeśli zadanie jest powtarzalne, policzalne w godzinach i nie wymaga oceny, ma sens. Jeśli wymaga negocjacji i wyczucia, zostaw je ludziom. Nie ma nic gorszego niż zautomatyzowana czynność, która wymaga tyle samo nadzoru co ręczna, tyle że nikt nie potrafi jej poprawić. Pomocne jest zestawienie 20 procesów z czasem i ryzykiem, gdzie warto zacząć, a co odłożyć.

4. Ustal, ile to kosztuje teraz. Godziny, outsourcing, błędy i poprawki po fakcie. Automatyzacja jest wtedy prosta do obrony przed szefem, bo porównujesz z czymś, co już płacisz.

5. Wypisz zakres na piśmie. Co wchodzi, co wychodzi, kiedy przestajemy. Zakres na piśmie jest jedynym dokumentem, który za pół roku ocali projekt przed zdaniem „ja nie wiedziałem, że to miało obejmować księgowość”.

Blok 2: kto, kiedy i kto patrzy w monitor (punkty 6 do 10)

6. Wyznacz jednego właściciela. Jedna osoba, która odpowiada za wynik. Nie zespół, nie „zarząd”, nie dostawca. W małej firmie to często Ty, ale lepiej zapisane z imieniem i nazwiskiem.

7. Zbierz zgodę ludzi z innych obszarów. Governance sztucznej inteligencji nie działa, jeśli siedzi tylko w IT. Potrzebujesz głosu tych, którzy wiedzą, gdzie są dane, i tych, którzy odpowiadają za zgodność z prawem. Microsoft przy okazji pisał o tym, że skuteczne ramy opierają się na grupie międzyfunkcyjnej wykraczającej dalej poza dział IT, bo bez tej struktury nawet dobrze napisane ramy są trudne do utrzymania.

8. Rozdziel decyzję od nadzoru. Osoba, która podejmuje decyzję o wdrożeniu, i osoba, która nadzoruje wynik, nie powinny być tym samym człowiekiem przy procesach, w których pomyłka kosztuje pieniądze lub zdrowie ludzi.

9. Wpisz nadzór człowieka tam, gdzie są decyzje. Nie „asystent AI pomaga sprzedawcy”, tylko „asystent proponuje, człowiek zatwierdza, system loguje kto zatwierdził”. Różnica jest ogromna i widać ją w logach. Sposoby na to opisałem przy ograniczaniu halucynacji i human in the loop.

10. Zaplanuj szkolenie, nie tylko wdrożenie. Technologia bez ludzi, którzy wiedzą, jak jej używać, daje dokładnie tyle, ile wynika z instrukcji. Kolejność ról i to, kiedy jeszcze nie ruszać, opisałem w modelu dyfuzji wdrożeń w organizacji. Osobno zebrałem 10 zasad korzystania z AI w firmie, które warto mieć w regulaminie.

Blok 3: dane, koszt i plan wyjścia (punkty 11 do 15)

11. Wypisz, jakie dane wychodzą do modelu. Dosłownie, pole po polu. „Asystent odpowiada na pytania o faktury” brzmi niewinnie, dopóki nie policzysz, że do dostawcy modelu lecą pytania, nazwy kontrahentów i dane o płatnościach.

12. Wypisz, które dane nie mogą wyjść. Dane o zdrowiu, dane biometryczne, numery kart, PESEL pracowników. Lista 12 pól, których nie wklejasz do modelu, jest tutaj, ale najważniejsze jest pierwsze zdanie: to decyzja firmy, zapisana przed wdrożeniem, nie intuicja użytkownika w trakcie pracy. Sama lista pól i sposób ich zanonimizowania: 12 pól, których nie wklejasz do modelu.

13. Ustaw klauzulę wyłączenia. Człowiek, który ma podejrzenie, że wyciekł czegoś, czego nie miał, musi wiedzieć, gdzie jest wyłącznik i czy rzeczywiście działa. Wyłącznik sprawdzony raz przy wdrożeniu i nigdy więcej to wyłącznik, którego nie masz.

14. Ustaw limit kosztu z alertem. Model językowy liczy się za każdym zapytaniem, a agent potrafi zapętlić wywołania. Większość platform do zarządzania AI pozwala śledzić wydatki w rozbiciu na model, agenta i przypadek użycia, co pozwala wyłapać nieefektywne przepływy zanim zadziałają rachunkiem. Bez limitu pierwszy miesiąc jest zaskoczeniem.

15. Napisz plan B. Co robisz, jeśli asystent jest wyłączony w środku dnia roboczego, kto to zgłasza, ile trwa powrót do procesu ręcznego. Jeśli odpowiedź brzmi „nie wiemy”, to znaczy, że nie masz planu B.

Blok 4: umowa powierzenia, czyli DPA (punkty 16 do 23)

Tu zaczyna się właściwa odpowiedź na frazę „dpa ai”. Jeżeli Twoje AI przetwarza dane osobowe klienta, jesteś procesorem w jego imieniu. Art. 28 ust. 3 RODO wymienia, co umowa powierzenia musi określać.

16. Sprawdź, czy w ogóle to powierzenie. Umowa powierzenia musi określać przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych, kategorie osób, których dane dotyczą, oraz obowiązki i prawa administratora. Bez tego nie masz umowy powierzenia, tylko plik, w którym są dane klienta.

17. Dopisz obowiązki procesora. Przetwarzanie wyłącznie na udokumentowane polecenie administratora, poufność personelu, stosowanie środków bezpieczeństwa z art. 32 RODO, korzystanie z podwykonawców tylko za zgodą administratora, pomoc w realizacji praw osób, usunięcie lub zwrot danych po zakończeniu współpracy oraz prawo administratora do audytu. Zwróć uwagę na ostatni punkt, bo to on najczęściej kończy się negocjacjami.

18. Ustal podstawę prawną po stronie klienta. Najczęściej art. 6 ust. 1 lit. b RODO, gdy rozmowa służy obsłudze umowy, albo art. 6 ust. 1 lit. f, czyli prawnie uzasadniony interes. Przy uzasadnionym interesie potrzebny jest test równowagi. Wybór należy do administratora, czyli do klienta, i warto go mieć na piśmie.

19. Wypisz zakaz danych szczególnych kategorii. Art. 9 RODO co do zasady zakazuje przetwarzania danych o zdrowiu, w tym biometrii i danych sądowych. Jeden dobry wzór umowy ma taki zakaz wprost i wymaga pisemnych ustaleń, zanim cokolwiek takiego trafi do usługi.

20. Zapisz obowiązek informowania. Jeśli rozmowę prowadzi asystent AI, użytkownik musi wiedzieć, że rozmawia z maszyną. To nie jest dodatek, to obowiązek informacyjny z art. 13 RODO, a jego złamanie to osobna kategoria kar.

21. Dopisz zobowiązanie do środków z art. 32 RODO. Jedno zdanie w umowie, ale konkretne: jakie środki techniczne i organizacyjne, kto je utrzymuje, kiedy się przegląda. Dalsza część tego artykułu pokazuje, co konkretnie tam wpisać.

22. Poproś o wsparcie w art. 32 do 36 RODO. Chodzi o pomoc przy bezpieczeństwie, zgłaszaniu naruszeń, ocenie skutków dla ochrony danych i konsultacjach. Jeden z badanych wzorów ma dosłownie taki zapis wraz z obowiązkiem przekazywania niezbędnych informacji.

23. Ustal termin usunięcia danych i prawo audytu. Nie „po zakończeniu współpracy”, tylko konkretna liczba dni. Różnice między wzorami są duże i nie powinny dziwić, bo każdy procesor ma inną architekturę backupów.

Do tego dochodzi AI Act, który wszedł w życie 1 sierpnia 2024. Dzieli systemy na cztery poziomy ryzyka, a dla chatbotów zapisuje wprost obowiązek poinformowania użytkownika, że rozmawia z maszyną. Systemy o wysokim ryzyku, na przykład w medycynie, rekrutacji, wymiarze sprawiedliwości czy transporcie, podlegają wymogom takim jak nadzór człowieka i jakość danych treningowych. Za zastosowania o niedopuszczalnym ryzyku, czyli między innymi społeczne punktowanie, grozi kara do 35 milionów euro albo do siedmiu procent rocznego obrotu światowego. Nie to myślę tę karę na straszenie. To argument, żeby wiedzieć, w którą kategorię wchodzi Twój system. Za resztę zgodności z odpowiednimi przepisami, także RODO, odpowiada osobno administrator danych, czyli Twój klient, i to on musi mieć świadomość, w co się zgodził. Pełny rozkład dat i obowiązków zebrałem w kalendarzu obowiązków AI Act po polsku.

Blok 5: środki techniczne, które wpisujesz do DPA (punkty 24 do 27)

Tu ludzie najczęściej kończą na „stosujemy odpowiednie środki techniczne”. To zdanie nie znaczy nic, bo w RODO nie ma definicji odpowiedniości. Poproś o konkret i przenieś do swojej umowy.

24. Szyfrowanie w transmisji i w spoczynku. TLS 1.2 i nowszy na każdym połączeniu, szyfrowanie danych w bazie, szyfrowanie kluczy/master key. Jeden z badanych wzorów podaje szyfrowanie kluczy i danych w bazie algorytmem AES-256-GCM oraz opcjonalne szyfrowanie kluczami klienta, czyli SSE-C. To są liczby, które da się zweryfikować.

25. Hasła. Nie „hashowane”. Konkretnie: bcrypt, 12 rund. W drugim wzorze znalazłem zapis „bcrypt cost większy lub równy 10”, co pokazuje, że nawet dobrzy dostawcy zostawiają w umowie trochę luzu. Większa liczba rund oznacza trudniejsze złamanie hasła, ale też dłuższy czas logowania.

26. Kopie zapasowe i replikacja. Jeden wzór opisuje trzykrotną replikację każdego obiektu na poziomie Ceph oraz snapshoty co 24 godziny z 30-dniową retencją. Dla mniejszego zespołu to często po prostu informacja, gdzie są backupy i kto sprawdza, że są odtwarzalne.

27. Logi, monitoring i testy. Anonimowy log dostępu przez 12 miesięcy, logi administracyjne z retencją 90 dni, detektor anomalii z alarmami 24/7, testy penetracyjne co najmniej raz w roku i przegląd środków technicznych i organizacyjnych również raz w roku. Szczegółową listę zabezpieczeń przed włączeniem narzędzia w zespole masz w checkliście 25 punktów bezpieczeństwa.

Blok 6: podwykonawcy, retencja, audyt (punkty 28 do 30)

28. Sprawdź, kto jest podwykonawcą AI. To najczęstsza luka w tej części. Lista podwykonawców w umowie powinna obejmować także dostawcę modelu, jeśli dane do niego trafiają. W jednym z badanych DPA znalazłem wprost zapisane, że do dostawcy modelu przesyłane są pytania użytkownika oraz dane firmy potrzebne do udzielenia odpowiedzi, na przykład czas pracy, nieobecności i nadgodziny pracowników, z zaznaczeniem, że dodatek jest opcjonalny i aktywowany świadomie przez klienta. Brzmi to jak drobiazg. W praktyce to trzy kolumny danych osobowych, które bez Twojej wiedzy opuściły firmę.

Upewnij się też, że jest procedura zmiany podwykonawcy. W dwóch badanych wzorach: 30 dni wyprzedzenia, 14 dni na uzasadniony sprzeciw, 30 dni na znalezienie rozwiązania zastępczego, a przy braku porozumienia prawo do rozwiązania umowy ze skutkiem natychmiastowym. W trzecim wzorze sprzeciwu w ogóle nie ma, jest tylko ogólne pozwolenie. Różnica jest po Twojej stronie.

29. Ustal retencję w liczbach. Trzy różne modele z trzech różnych umów, których nie należy sklejać: 30 dni na usunięcie lub zwrot danych plus 6 lat na logi audytu; 120 dni od wygaśnięcia umowy, 60 dni po dezaktywacji konta i kolejne 120 dni szyfrowanych kopii zapasowych; 12 miesięcy na audit log, 5 lat na metadane księgowe i 30 dni karencji przed fizycznym usunięciem. Wybierz model pasujący do Twojej infrastruktury i wpisz go w umowę.

30. Zaplanuj audyt. Nie kto, kiedy i ile, tylko: jaki termin zapowiedzi (w badanych wzorach 14 dni roboczych i maksymalnie 2 dni robocze trwania w jednym, 30 dni zapowiedzi w drugim), jak często (we wszystkich trzech raz w roku), kto ponosi koszt (w jednym koszt ponosi klient, ale przy stwierdzeniu istotnych naruszeń pokrywa go dostawca) i jaki jest limit odpowiedzialności za szkodę. W dwóch wzorach to odpowiednio 3 miesiące opłaty abonamentowej i 12 miesięcy opłat. Własna umowa powinna mieć wyższy limit, nie niższy.

Trzy sygnały, żeby premierę wstrzymać

Kiedy projekt dociera do mnie w tym trybie, to najczęściej znaczy, że coś wcześniej poszło nie tak. Najczęściej widzę trzy rzeczy. Pierwsza: aplikacja działa tylko na komputerze jednej osoby i nie ma wersji z logowaniem, rolami, backupem i monitoringiem. Wjście do firmy to inny poziem odpowiedzialności niż notatnik, który działa u developera na biurku. Druga: nie ma jasnego, jak daleko poszedł plan naprawczy, a więc nie wiadomo, co jest pilne, a co może poczekać. Trzecia: nie wiadomo, które usługi odpadają, jeśli projekt się nie uda. Pięć wdrożeń, które się nie udały, zebrałem w antywzorcach, bo powtarzają się w kółko jak te same trzy błędy.

Dobry news jest taki, że wszystkie trzy sygnały są widoczne przed premierą, a nie po. Właśnie po to ta checklista istnieje.

Zapisz checklistę do PDF i podeślij dalej

Ta lista jest napisana tak, żeby działała jako dokument do wydruku. Otwórz stronę w przeglądarce, użyj drukowania do PDF i zapisz plik. Wydrukuj obie strony w orientacji poziomej, wtedy punkty zmieszczą się w jednej tabeli bez łamania tekstu. Do PDF-a dopisz datę, imię osoby zatwierdzającej i osoby podpisującej umowę, bo bez tych trzech pól dokument nie jest dowodem, tylko notatką.

Drukuję osobno: stronę dla szefa, stronę dla klienta i tę z logiem. W praktyce największy problem nie jest w zapisaniu punktów, tylko w tym, że pierwsza osoba, która powinna przeczytać DPA, odkłada to na później. Daj jej w PDF gotową listę 12 pytań do dostawcy AI, w tym czy podpisuje umowę powierzenia zgodną z art. 28 RODO, gdzie fizycznie leżą dane i czy serwery są w UE, jaka jest retencja nagrań i kim są podprocesorzy. Od strony wewnętrznej masz 12 kroków wdrożenia RODO w firmie, które porządkują to, co musisz mieć, zanim cokolwiek wyśle klientowi.