Techniczne przygotowanie firmy do AI Act

Trzy pojęcia wracają w całym tekście. Dostawca to firma, która wprowadza system na rynek pod własną nazwą lub marką. Podmiot stosujący to firma, która korzysta z systemu we własnej działalności. Ta sama firma bywa jedną i drugą stroną — dla różnych systemów.

Trzecie pojęcie to system wysokiego ryzyka. To między innymi system pełniący funkcję bezpieczeństwa w regulowanym produkcie albo wykorzystywany w jednym z obszarów wskazanych w załączniku III do AI Act, np. do rekrutacji pracowników i oceny kandydatów, przy decyzjach o dostępie do ważnych usług lub w niektórych zastosowaniach biometrycznych. O kwalifikacji decydują przeznaczenie systemu i sposób jego wykorzystania, a nie sam zastosowany model.

Przez cały tekst prowadzimy jeden przykład: mała firma usługowa udostępnia na swojej stronie chatbota, który odpowiada klientom na pytania o ofertę i terminy. Chatbot działa na gotowym narzędziu kupionym w abonamencie. Przy każdym kolejnym kroku pokazujemy, co ten przykład oznacza w praktyce. Taki chatbot zasadniczo nie jest systemem wysokiego ryzyka. Inaczej mogłoby być, gdyby podobny system służył do oceny kandydatów w rekrutacji.

AI Act nakłada obowiązki na systemy, ale żeby sprawdzić, czy firma je spełnia, trzeba mieć materiał: opis systemu, ślad jego decyzji i wskazanie, kto za nie odpowiada. Prawnik nie przygotuje go sam, bo nie zna systemu od strony działania. Audytor też nie odtworzy po czasie logów, których nikt wcześniej nie włączył.

W przykładowej firmie z chatbotem ten materiał to kilka prostych ustaleń: z jakiego narzędzia korzysta chatbot, jakie dane klientów przez niego przechodzą, w którym momencie rozmowa trafia do człowieka i czy zapis rozmów jest w ogóle przechowywany dłużej niż kilka dni. To firma powinna zebrać i opisać te informacje — nikt nie zrobi tego za nią.

Dlatego praca techniczna ma sens niezależnie od tego, jak zakończy się kwalifikacja. Jeśli system znajdzie się poza wymaganiami dla wysokiego ryzyka, firma i tak zyskuje spis narzędzi AI, jasne granice decyzyjne i zapis, na podstawie którego da się wyjaśnić, dlaczego model odpowiedział tak, a nie inaczej. Jeśli zostanie objęty tymi wymaganiami, ta sama praca skraca drogę do zgodności, zamiast zaczynać ją od zera.

Role mają tu praktyczne znaczenie, bo obowiązki przejrzystości z art. 50 są rozdzielone między role i rodzaje systemów. Dostawca systemu przeznaczonego do bezpośredniej interakcji z człowiekiem projektuje go tak, aby użytkownik wiedział, że rozmawia z AI — chyba że jest to oczywiste. Osobny obowiązek ma dostawca systemu generującego treści syntetyczne, czyli tekst, obraz, dźwięk lub wideo: zapewnia ich oznaczenie w formacie możliwym do odczytu maszynowego. Podmiot stosujący ujawnia deepfake'i oraz oznacza wygenerowane przez AI teksty publikowane po to, by informować opinię publiczną o sprawach interesu publicznego. Z tego ostatniego obowiązku zwalniają dopiero dwa warunki łącznie: tekst przeszedł weryfikację człowieka lub kontrolę redakcyjną, a osoba lub firma ponosi odpowiedzialność redakcyjną za publikację. Sama korekta językowa albo pobieżne przejrzenie tekstu nie wystarczą.

Firma z naszego przykładu kupuje chatbota w abonamencie, więc informacja o rozmowie z AI należy do jego dostawcy. Po stronie firmy zostaje sprawdzenie, czy narzędzie faktycznie ją wyświetla, i nieusuwanie tego komunikatu — niezależnie od tego, że taki chatbot zasadniczo nie jest systemem wysokiego ryzyka.

Odroczenie pozostałych obowiązków nie jest powodem, żeby czekać. Dokumentacja, logi i opis nadzoru powstają miesiącami, a materiał do nich gromadzi się tylko wtedy, gdy system już go zapisuje. Firma, która włączy rejestrowanie zdarzeń dopiero na wezwanie, nie odtworzy decyzji sprzed roku.

Cztery poniższe elementy to wymagania dla systemów wysokiego ryzyka i w praktyce wyznaczają, czego szuka osoba oceniająca system. Wspólny mianownik jest prosty: to, co zespół pamięta, musi trafić w miejsce, z którego odczyta to po roku ktoś, kogo przy wdrożeniu nie było.

Główna odpowiedzialność za spełnienie tych wymagań spoczywa na dostawcy, czyli na tym, kto system tworzy i wprowadza pod własną marką. Firma, która kupiła gotowy system wysokiego ryzyka, jest podmiotem stosującym i ma obowiązki węższe, opisane w art. 26: musi między innymi stosować system zgodnie z instrukcją, zapewnić wymagany nadzór i zachowywać dostępne jej logi. Dla polskiego rynku to rozróżnienie przesądza o zakresie pracy — według GUS w 2025 roku AI stosowało 8,7% przedsiębiorstw, a najczęstszą drogą był zakup gotowego rozwiązania komercyjnego, nie budowa własnego.

Firma korzystająca z gotowego narzędzia nie przygotowuje więc całej tej dokumentacji sama — powinna uzyskać potrzebne informacje od dostawcy i zapisać jego obowiązki w umowie. Najczęstszy błąd to traktowanie czterech elementów jak osobnych dokumentów. W działającym systemie są ze sobą powiązane: log pokazuje, na jakich danych model zadziałał, opis nadzoru mówi, kto wynik zatwierdził, a dokumentacja tłumaczy, dlaczego system w ogóle podejmuje taką decyzję. Gdy brakuje jednego ogniwa, pozostałe tracą wartość dowodową.

Kolejność ma znaczenie. Inwentaryzacja jest pierwsza, bo nie da się opisać ani ograniczyć systemu, o którym się nie wie. Granice decyzyjne są drugie, bo dopiero one pokazują, co rejestrować. Logi i dokumentacja są trzecie, bo bez tych granic zapisują wszystko albo nic. Przegląd zamyka pętlę, bo opis, który się nie zmienia, przestaje pasować do systemu, który się zmienia.

Nie trzeba od razu uruchamiać osobnego, rozbudowanego projektu — i dobrze, bo zasoby na taki projekt ma niewiele firm: według Barometru AI firmy EFL w pierwszej połowie 2026 tylko 7% polskich MŚP oceniło swoją gotowość do wdrożeń AI jako wysoką, a 43% oceniło własne kompetencje jako niskie. W przykładowej firmie z chatbotem cały ten zestaw to jedna tabela, jedna rozmowa o tym, kiedy chatbot ma przekazać klienta człowiekowi, i jedno ustawienie w panelu dostawcy. Próba opisania z góry wszystkich możliwych scenariuszy zwykle kończy się dokumentem, którego nikt nie aktualizuje.

Te cztery działania to: inwentaryzacja wykorzystywanych narzędzi AI, ustalenie granic decyzyjnych, uruchomienie logów wraz z dokumentacją systemu oraz zaplanowanie okresowego przeglądu. Poniżej każde z nich z osobna, w tej samej kolejności.

Harmonogram AI Act zmieniał się już raz po wejściu rozporządzenia w życie i może zmienić się ponownie. Przed decyzją, która zależy od daty, sprawdź aktualną wersję przepisu u źródła, a nie w artykule — także w tym.