AI governance w małej firmie: 1 osoba, 1 rejestr (i jak to ogarnąć bez działu compliance)

W większości MŚP, z którymi rozmawiam o AI, temat governance pojawia się dopiero wtedy, gdy ktoś już wdrożył trzy, cztery automatyzacje i nagle ktoś zadaje pytanie: „a kto właściwie za to odpowiada, jeśli coś pójdzie nie tak?”. Odpowiedzi zwykle nie ma, bo nikt się nad tym nie zastanawiał na starcie. I to jest normalne, bo w firmie bez działu IT i bez compliance nikt nie ma na to etatu ani czasu. Problem w tym, że brak jakiejkolwiek odpowiedzialności to gorsze rozwiązanie niż odpowiedzialność rozłożona po godzinie tygodniowo na jedną osobę.

Nie zaczynałbym więc od pytania „jak zbudować politykę AI zgodną z najlepszymi praktykami korporacyjnymi”, tylko od dużo prostszego: kto w tej firmie w ogóle wie, gdzie AI jest już używane. Bo w praktyce zwykle nikt tego nie wie w 100%, a to jest większe ryzyko niż brak formalnego dokumentu.

Dlaczego kopiowanie modelu dużych firm to zły pomysł

Duże organizacje, zwłaszcza te działające w kilku krajach, powołują AI officerów, komitety etyki AI, procedury oceny ryzyka na wzór tych znanych z RODO. To ma sens przy skali: dziesiątki projektów AI, setki osób, ryzyko regulacyjne liczone w milionach. W firmie zatrudniającej 20 osób, gdzie AI to chatbot na stronie, automatyzacja faktur i asystent do maili, przenoszenie tego modelu jeden do jednego jest marnotrawstwem. Skutek bywa odwrotny do zamierzonego: powstaje dokument PDF, który nikt nie czyta, i który nie ma żadnego związku z tym, co ludzie robią w Make czy w n8n na co dzień.

Widziałem to wielokrotnie: firma zamawia „politykę AI” u prawnika, dostaje 12 stron ogólników, wrzuca do folderu „compliance” i temat uznaje za zamknięty. Tymczasem nikt nie wie, że dział handlowy wkleja dane klientów do publicznego ChatGPT, żeby przyspieszyć pisanie ofert. Dokument istnieje, ryzyko istnieje osobno.

Co naprawdę wynika z AI Act dla małej firmy

AI Act wprowadza konkretne obowiązki governance dla systemów sklasyfikowanych jako wysokiego ryzyka (np. część zastosowań w rekrutacji, ocenie zdolności kredytowej, niektórych systemach medycznych) oraz dla systemów ograniczonego ryzyka, gdzie kluczowa jest transparentność wobec użytkownika, na przykład informacja, że rozmawia z botem. Obowiązki te wchodzą w życie etapami, część od 2025, część od 2026 roku, i większość małych firm w ogóle nie dotyczy systemów wysokiego ryzyka, bo nie robi scoringu kredytowego ani systemów rekrutacyjnych opartych na profilowaniu.

To jednak nie oznacza, że temat firmę omija. Nawet przy zastosowaniach niskiego ryzyka (automatyzacja procesów, chatbot obsługowy, generowanie treści marketingowych) warto już dziś wiedzieć, które z używanych narzędzi mogą w przyszłości wpaść w kategorię wyższego ryzyka i jakie dane przez nie przechodzą. Firma, która nie ma tej wiedzy spisanej, w momencie kontroli albo incydentu (np. wyciek danych klienta przez nieprzemyślaną integrację z zewnętrznym API) nie jest w stanie odpowiedzieć na proste pytanie: co dokładnie się stało i gdzie.

Tu warto zrobić rzecz, którą wielu pomija: sprawdzić, czy w firmie jest już wyznaczony inspektor ochrony danych (IOD) z tytułu RODO. Jeśli tak, to naturalnym rozwiązaniem jest rozszerzenie jego zakresu o AI, bo pytania są bardzo podobne: jakie dane, gdzie trafiają, kto ma dostęp, na jakiej podstawie prawnej. Nie trzeba wymyślać nowej roli od zera, tylko dopisać AI do istniejącego zakresu obowiązków.

Minimalny model, który realnie działa

W Ententrze klientom z sektora MŚP proponujemy model, który mieści się w jednym zdaniu: jedna wyznaczona osoba plus prosty rejestr use case'ów AI. Bez nowego stanowiska, bez komitetu, bez dodatkowego etatu. Ta osoba nie musi być prawnikiem ani specjalistą od AI. Musi mieć czas (realnie: godzinę, dwie tygodniowo na start, potem mniej) i mandat, żeby zadawać innym pytanie „czy zgłosiłeś to do rejestru”.

Kto powinien być tą jedną osobą

Najczęściej sprawdza się ktoś, kto i tak ma przegląd nad procesami operacyjnymi: office manager, osoba odpowiedzialna za wdrożenia narzędzi, czasem sam właściciel przy mniejszych firmach. Zła praktyka to oddanie tego zewnętrznemu freelancerowi bez kontaktu z zespołem na co dzień, bo taka osoba nie dowie się o nowym use case, dopóki ktoś jej sam nie napisze. Dobra praktyka to ktoś, kto siedzi wystarczająco blisko codziennej pracy, żeby usłyszeć, że dział sprzedaży „testuje jakiś nowy asystent do ofert”, zanim ten asystent zacznie przetwarzać dane 200 klientów.

Co zawiera dobry rejestr AI

Rejestr, który faktycznie działa, nie ma 40 kolumn. W praktyce wystarczy: nazwa narzędzia lub procesu, do czego służy, jakie dane wchodzą (czy są w nich dane osobowe albo poufne dane biznesowe), gdzie dane trafiają (np. czy narzędzie działa na serwerach w UE czy poza), kto jest właścicielem procesu po stronie firmy, i krótka ocena: niskie, średnie, wysokie ryzyko. Przy średnim i wysokim ryzyku dopisujemy jedno zdanie: co robimy, żeby to ryzyko ograniczyć.

Przykład ilustracyjny: firma handlowa wdraża automatyzację, która czyta przychodzące faktury i wpisuje dane do systemu księgowego. W rejestrze taki wpis wygląda tak: narzędzie do OCR faktur, dane: nazwy kontrahentów, kwoty, NIP-y (bez danych osobowych pracowników), przetwarzanie w chmurze dostawcy zlokalizowanego w UE, właściciel procesu: osoba z księgowości, ryzyko: niskie, uwaga: sprawdzić umowę powierzenia danych z dostawcą. Taki wpis zajmuje trzy minuty, a daje odpowiedź na 90% pytań, które padają przy kontroli albo audycie wewnętrznym. Więcej o tym, jak wygląda takie wdrożenie od strony technicznej, opisujemy przy okazji automatyzacji faktur, bo to jeden z najczęstszych pierwszych use case'ów AI w małych firmach.

Podobnie wygląda to w biurach rachunkowych, które automatyzują część pracy z dokumentami klientów: tam rejestr jest wręcz obowiązkowy, bo dane klientów końcowych są wrażliwe podwójnie, przechodzą przez biuro rachunkowe, a potem trafiają jeszcze do narzędzia AI. Jeśli ktoś wdraża automatyzację procesów w biurze rachunkowym, rejestr use case'ów to pierwszy dokument, który powinien powstać, zanim narzędzie zacznie przetwarzać realne dane klientów.

Jak to wdrożyć w praktyce, bez tworzenia biurokracji

Nie trzeba na to poświęcać miesiąca. Realny harmonogram wygląda mniej więcej tak:

• Tydzień 1: wyznaczenie osoby odpowiedzialnej i krótka rozmowa z każdym działem: „jakich narzędzi AI już używacie, nawet nieformalnie”. Tu zwykle wychodzą niespodzianki, np. że ktoś od pół roku wkleja dane do darmowego narzędzia bez wiedzy zarządu.
• Tydzień 1-2: spisanie wszystkiego do rejestru, nawet jeśli na start jest to pięć, sześć wpisów.
• Tydzień 2: ustalenie jednej zasady na przyszłość: każde nowe narzędzie AI trafia do rejestru przed wdrożeniem produkcyjnym, nie po fakcie. To jedna reguła, nie dwadzieścia.

Kolejny krok to przegląd rejestru raz na kwartał, nie raz w roku. Kwartał jest wystarczająco krótki, żeby złapać nowe narzędzia zanim się zakorzenią, i wystarczająco długi, żeby nie robić z tego codziennego obowiązku administracyjnego.

Gdzie ten model się wywraca

Ten minimalny model ma swoje ograniczenia i uczciwie trzeba je nazwać. Po pierwsze, działa dobrze przy niskim i średnim ryzyku, czyli przy większości zastosowań w MŚP: automatyzacji procesów, obsłudze klienta, marketingu. Jeśli firma faktycznie wchodzi w obszar wysokiego ryzyka w rozumieniu AI Act, np. buduje własny system scoringowy albo wykorzystuje AI w rekrutacji do automatycznego odrzucania kandydatów, jedna osoba z arkuszem to za mało. Tam potrzebna jest konsultacja prawna i dużo bardziej sformalizowany proces oceny ryzyka.

Po drugie, model zawodzi, jeśli wyznaczona osoba nie ma realnego mandatu, żeby wstrzymać wdrożenie. Rejestr bez możliwości powiedzenia „nie, tego jeszcze nie uruchamiamy, dopóki nie sprawdzimy umowy z dostawcą” to tylko lista, nie governance. I po trzecie, jeśli firma rośnie szybko, powyżej 50-70 osób, ten model trzeba rozbudować, np. dodać krótką checklistę oceny ryzyka przed wdrożeniem albo włączyć temat AI do onboardingu nowych pracowników. Minimalny model nie jest docelowy na zawsze, jest punktem startu adekwatnym do skali.

Widać to dobrze przy firmach e-commerce, które wdrażają AI jednocześnie w kilku miejscach: automatyczne odpowiedzi na maile, rekomendacje produktowe, chatboty na stronie. Bez jednego miejsca, gdzie te wdrożenia są spisane, bardzo szybko traci się przegląd nad tym, gdzie właściwie trafiają dane klientów. Przy automatyzacji procesów w e-commerce rejestr use case'ów to jeden z pierwszych elementów, które sprawdzamy przed rozszerzeniem wdrożenia na kolejne procesy.