Jak przygotować firmę na AI Act: kroki dla IT, prawników i właścicieli procesów

Co AI Act realnie zmienia dla firm: kontekst, ryzyko i perspektywa kosztów

Jakie organizacje w praktyce odczują AI Act

AI Act nie jest przepisem wyłącznie dla gigantów technologicznych. Regulacja dotknie większość firm, które:

• dostarczają rozwiązania z elementami sztucznej inteligencji (software house, dostawcy SaaS, integratorzy),
• używają komercyjnych narzędzi AI w procesach biznesowych (HR, marketing, obsługa klienta, produkcja),
• integrują AI w swoich produktach lub usługach jako element większego rozwiązania,
• uczestniczą w łańcuchu dostaw jako podwykonawcy przy wdrożeniach AI dla klientów korporacyjnych.

W praktyce możesz występować w różnych rolach jednocześnie:

• Dostawca – tworzysz system AI lub oferujesz go pod własną marką (od małego modułu rekomendacji po platformę scoringową).
• Użytkownik profesjonalny – korzystasz z AI u siebie w procesach (np. ATS z modułem AI w rekrutacji, scoring kredytowy, analiza dokumentów).
• Integrator – łączysz komponenty AI od różnych dostawców w spójną całość dla klienta.
• Podwykonawca – odpowiadasz za część danych, trening modeli, etapy wdrożenia lub utrzymania.

Od roli zależy zakres obowiązków, ale uniknięcie kontaktu z AI Act „przez przeczekanie” jest mało realne, jeśli firma korzysta z nowoczesnego oprogramowania, usług chmurowych lub rozwija własne narzędzia IT. Nawet jeśli nie dotkną cię pełne wymogi dla systemów wysokiego ryzyka, pojawią się obowiązki transparentności, oceny wpływu i zarządzania ryzykiem.

Nagłówki prasowe a realne obowiązki średniej firmy

W przestrzeni publicznej dominują dwa skrajne obrazy: „AI Act zablokuje innowacje” albo „AI Act to tylko europejska fanaberia, która nas nie dotyczy”. Prawda leży pośrodku. Dla typowej średniej firmy:

• nie będzie konieczne budowanie olbrzymiego działu compliance AI,
• tak – trzeba będzie uporządkować, co gdzie działa na AI i jak wpływa na ludzi,
• tak – pojawią się nowe wymagania przy przetargach i kontraktach z korporacjami,
• tak – części projektów nie da się prowadzić „na gębę” bez dokumentacji ryzyka.

Przy dobrze ułożonym podejściu większość pracy da się włączyć w istniejące procesy (RODO, bezpieczeństwo IT, zarządzanie projektami), zamiast budować wszystko od zera. Największym kosztem jest nie sam obowiązek, ale chaos: brak listy systemów, brak odpowiedzialnych osób, brak decyzji, które projekty przechodzą pełną analizę, a jakie – nie.

Poziomy ryzyka w AI Act i operacyjne skutki dla biznesu

AI Act dzieli systemy na poziomy ryzyka. Z perspektywy firmy kluczowe jest przełożenie ich na konkretne działania, a nie tylko definicje prawne.

Z punktu widzenia kosztów i organizacji pracy najwięcej energii pochłoną systemy wysokiego ryzyka. To wokół nich trzeba zbudować procedury, dokumentację i łańcuch odpowiedzialności. Narzędzia o ograniczonym lub minimalnym ryzyku najczęściej wystarczy objąć lżejszym procesem zgłoszeń i podstawową oceną wpływu.

Powiązania AI Act z RODO, NIS2 i prawem pracy

Zamiast tworzyć dziesiątki nowych dokumentów, rozsądniej jest połączyć AI Act z istniejącymi ramami:

• RODO / DPIA – jeśli system AI przetwarza dane osobowe, można rozszerzyć istniejącą ocenę skutków dla ochrony danych o elementy ryzyka AI (np. bias, nadzór człowieka, wyjaśnialność decyzji).
• NIS2 / bezpieczeństwo IT – kanały incydentów, zarządzanie podatnościami, backupy, kontrola dostępu – większość tego już istnieje i da się po prostu dodać komponent „AI” do aktualnych procedur.
• Prawo pracy – systemy ocen pracowniczych, monitoringu, rekrutacji z AI wymagają dialogu z HR i często z przedstawicielami pracowników. To dobry moment, by połączyć wymogi AI Act z aktualizacją regulaminów pracy i polityk HR.

Kluczowe jest, aby nie pisać wszystkiego od nowa, tylko:

1. Odnaleźć dokumenty i procesy, które już dotykają danych, bezpieczeństwa, oceny ryzyka.
2. Dodać do nich konkretne sekcje dotyczące AI (kryteria klasyfikacji, dodatkowe pytania, odpowiedzialności).
3. Unikać dublowania tych samych zapisów w pięciu różnych politykach.

Koszty wdrożenia a koszty zaniechania

Z perspektywy „budżetowego pragmatyka” najważniejsze pytanie brzmi: co bardziej się opłaca – uporządkowanie tematu czy ryzykowanie?

Przykładowe koszty wdrożenia „minimum”:

• czas 2–4 osób przez kilka tygodni na inwentaryzację systemów AI i ich klasyfikację,
• proste dokumenty: zasady użycia AI, rejestr systemów, uproszczona procedura oceny ryzyka,
• kilka godzin szkoleń wewnętrznych dla kluczowych osób (IT, prawnicy, właściciele procesów),
• ewentualnie jednorazowa konsultacja zewnętrzna przy klasyfikacji najwrażliwszych systemów.

Z drugiej strony stoją koszty zaniechania:

• blokada projektów – duży klient lub grupa kapitałowa wstrzymuje wdrożenie, bo nie spełniasz wymagań dot. AI,
• utrata kontraktów – brak odpowiedzi na pytania o AI Act w zapytaniach ofertowych,
• kary i roszczenia – w skrajnych przypadkach naruszeń przepisów i praw osób, których dotyka działanie AI,
• koszty „gaszenia pożaru” – doraźne naprawianie sytuacji, kiedy coś już poszło nie tak (wizerunek, regulator, klienci).

Celem nie jest idealna zgodność za wszelką cenę, tylko rozsądny poziom kontroli i dokumentacji, który:

• spełni podstawowe wymogi regulatora,
• uspokoi dział prawny klientów,
• nie sparaliżuje bieżącej pracy zespołów biznesowych.

Szybka diagnoza wyjściowa: gdzie w firmie jest AI (także „ukryte”)?

Co faktycznie jest „AI” w rozumieniu AI Act

Nie każdy algorytm czy raport BI to sztuczna inteligencja w rozumieniu AI Act. Pierwszy krok to odróżnienie:

• Klasyczne IT i automatyzacja – reguły if-then, sztywne workflow, raportowanie na bazie prostych zapytań SQL, prosta analityka opisowa.
• Systemy AI – używają metod uczenia maszynowego, sieci neuronowych, generatywnego modelowania, uczenia ze wzmocnieniem, przetwarzania języka naturalnego itp.

Do wstępnej listy wciągaj przede wszystkim:

• narzędzia wykorzystujące machine learning do przewidywania, rekomendacji, klasyfikacji,
• rozwiązania generatywne (tekst, obrazy, kod, audio),
• systemy, które uczą się na danych i modyfikują swoje działanie bez ręcznego kodowania reguł,
• produkty lub moduły oznaczone marketingowo i technicznie jako „AI”, „ML”, „gen AI”.

Jeśli masz wątpliwości, opłaca się na start przyjąć szerszą definicję i dopiero później odfiltrowywać elementy ewidentnie poza zakresem, zamiast liczyć, że zespoły same zgłoszą wszystkie „podejrzane” narzędzia.

Mini-audyt AI w 1–2 tygodnie bez drogich konsultantów

Przy ograniczonym budżecie kluczowe jest zrobienie szybkiej, taniej mapy systemów. W praktyce wystarczą trzy kroki:

1. Stwórz prosty arkusz rejestru (Excel, Google Sheets):
   • Nazwa systemu / narzędzia,
   • Dostawca / właściciel,
   • Dział / proces, w którym jest używany,
   • Cel biznesowy,
   • Rodzaj danych (w tym dane osobowe tak/nie),
   • Wpływ na ludzi (niski/średni/wysoki),
   • Rola firmy (dostawca, użytkownik, integrator, podwykonawca),
   • Szacunkowy poziom ryzyka (do doprecyzowania później).
2. Uruchom kampanię zbierania informacji:
   • krótkie ankiety dla kierowników działów,
   • przegląd zakupów IT, subskrypcji SaaS i umów z dostawcami,
   • pytania do zespołów data science / BI / analitycznych.
3. Zorganizuj 2–3 krótkie warsztaty (online lub na żywo) z kluczowymi działami – wyjaśnij, co traktujesz jako AI i poproś o dopisanie narzędzi.

Z punktu widzenia czasu i energii to kilkanaście godzin pracy rozłożonej na 1–2 tygodnie, a efekt to baza, na której można budować dalsze działania zgodnościowe.

Skąd zebrać dane o AI: nie tylko dział IT

Najwięcej „ukrytej” AI siedzi tam, gdzie IT ma ograniczoną widoczność:

• Zakupy / procurement – licencje SaaS, narzędzia marketingowe, platformy HR, systemy finansowo-księgowe.
• Marketing – analityka kampanii, scoring leadów, narzędzia generatywne do treści i grafik.
• HR – ATS z modułami AI, systemy do oceny pracowników, narzędzia do analizy CV.
• Finanse i ryzyko – modele scoringowe, predykcja płatności, systemy antyfraudowe.
• Obsługa klienta – chatboty, voiceboty, systemy routingu zgłoszeń.
• Produkcja / logistyka – predykcyjne utrzymanie ruchu, optymalizacja tras, planowanie produkcji.
• Shadow IT – konta w narzędziach generatywnych zakładane „na kartę firmową bez wiedzy IT”.

Warto jasno zakomunikować cel: nie chodzi o szukanie winnych, tylko o spisanie tego, co faktycznie działa, żeby później nie blokować wszystkiego prewencyjnie.

Oznaczanie ról: dostawca, użytkownik, integrator, podwykonawca

Przy każdym systemie trzeba odnotować, kim jesteście w łańcuchu odpowiedzialności:

• Dostawca – oferujecie system AI klientowi zewnętrznemu albo innym spółkom w grupie; tutaj obowiązki są najszersze.
• Użytkownik profesjonalny – kupujecie gotowe rozwiązanie i stosujecie je w swoich procesach; musicie zadbać o zgodne użycie, informowanie osób, reagowanie na incydenty.
• Integrator – łączycie komponenty od innych dostawców; część obowiązków dzielicie z nimi, ale to na was spada ryzyko powstałe na styku systemów.
• Podwykonawca – np. annotacja danych, hostowanie modelu, development modułu; kluczowe stają się zapisy umów i zakres odpowiedzialności kontraktowej.

Klasyfikacja systemów według ryzyka: które projekty wymagają najwięcej pracy

Trzy poziomy priorytetu zamiast akademickiej analizy

Pełna analiza ryzyka zgodna z AI Act może być rozbudowana, ale na start wystarczy prosty podział na trzy koszyki:

• Koszyk A – potencjalnie wysokie ryzyko (priorytet 1)
• Koszyk B – ograniczone ryzyko (priorytet 2)
• Koszyk C – minimalne ryzyko / poza zakresem (priorytet 3)

Nie chodzi o to, żeby już teraz idealnie trafić w kategorie z rozporządzenia, tylko o ustawienie kolejki do pracy. Pomyłki można korygować później, ale brak priorytetyzacji zemści się lawiną zadań.

Jak szybko wychwycić systemy z „koszyka A”

Systemy, które realnie mogą być wysokiego ryzyka, da się wyłapać kilkoma pytaniami. Dla każdego narzędzia z rejestru przejdź przez prosty filtr:

1. Czy system podejmuje lub wspiera decyzje o człowieku (rekrutacja, awans, odmowa kredytu, dostęp do świadczeń, ocena wiarygodności, moderacja treści z konsekwencjami dla użytkownika)?
2. Czy działa w obszarach regulowanych (finanse, zdrowie, edukacja, infrastruktura krytyczna, prawo pracy, prawo karne, administracja publiczna)?
3. Czy wynik AI jest automatycznie wykonywany bez realnego, świadomego nadzoru człowieka (tzn. człowiek tylko „klika dalej”, bo system tak powiedział)?
4. Czy używa szczególnych kategorii danych osobowych (zdrowie, poglądy, pochodzenie rasowe/etniczne, dane biometryczne itp.) albo danych wrażliwych biznesowo (tajemnice klientów, know-how, modele ryzyka)?

Jeśli przy większości z tych pytań odpowiedź brzmi „tak”, oznacz system jako kandydat na wysokie ryzyko. Nie trzeba jeszcze przesądzać jego formalnej klasy – ważne, by trafił na początek listy do szczegółowego przeglądu prawnego i technicznego.

Przykłady szybkiej klasyfikacji

Kilka typowych scenariuszy z praktyki:

• ATS z modułem oceny CV – decyzje o zatrudnieniu, często czarne pudełko od dostawcy SaaS. Najczęściej koszyk A.
• Model antyfraudowy w bankowości internetowej – wpływ na dostęp do środków, silnie regulowany sektor. Koszyk A.
• Chatbot wspierający obsługę klienta, który tylko podpowiada konsultantowi odpowiedzi – koszyk B (o ile człowiek realnie weryfikuje odpowiedzi).
• Wejściowy scoring leadów marketingowych (priorytetyzacja kontaktu handlowców) – zwykle koszyk B.
• Narzędzia wewnętrzne do podpowiadania kodu programistom – głównie ryzyka IP i bezpieczeństwa, raczej koszyk B.
• Silnik rekomendacji produktów w e‑commerce – najczęściej koszyk B, chyba że wchodzi w specjalne kategorie (dzieci, produkty regulowane).
• Generator obrazów do prezentacji marketingowych – zazwyczaj koszyk C, o ile nie wchodzi w obszary praw autorskich klientów i nie jest elementem usługi regulowanej.

Minimalna matryca oceny ryzyka „na jedną stronę A4”

Zamiast tworzyć dziesiątki stron formularzy, wystarczy jedna prosta matryca, którą da się wypełnić w 15–30 minut na system. Core:

• Wpływ na osoby fizyczne (brak / pośredni / bezpośredni, z przykładami konsekwencji).
• Skala użycia (kilka osób w dziale / cała firma / klienci zewnętrzni).
• Rodzaj danych (anonimowe, pseudonimizowane, dane osobowe zwykłe, dane wrażliwe).
• Stopień automatyzacji decyzji (tylko rekomendacja / decyzja z nadzorem / pełna automatyzacja).
• Przezroczystość działania (znany model i logika / częściowo znany / „czarna skrzynka” dostawcy).

Każdym polu można przypisać prostą skalę 1–3 i zsumować wynik. Nie chodzi o naukową precyzję, tylko o odhaczenie oczywistych czerwonych flag i ustawienie pracy w kolejności od największego potencjalnego problemu.

Gdzie włączyć prawników i compliance

Przy ograniczonych zasobach prawnych opłaca się podzielić systemy na:

• TOP 10–20% najbardziej ryzykownych – potrzebują pełnej analizy prawnej (AI Act, RODO, prawo pracy, sektorówka).
• Środek stawki – szybki przegląd wzorców umów i polityk, podstawowe wytyczne użycia.
• Reszta – ogólne zasady korzystania z AI i monitorowanie incydentów bez dużego nakładu pracy.

Zamiast rozciągać prawników na wszystko, lepiej na starcie umówić się, że wchodzą głębiej tylko w koszyk A i wybrane elementy koszyka B, reszta działa na bazie szablonów.

Podział ról: co robi IT, prawnicy i właściciele procesów

Dlaczego sam dział IT nie „udźwignie” AI Act

AI Act dotyka jednocześnie technologii, prawa, procesów i ludzi. Jeśli temat zostanie wrzucony tylko do IT, skończy się albo na blokowaniu narzędzi, albo na „odhaczaniu check-list bez zrozumienia biznesu”. Strategia minimalnego żalu to jasne rozpisanie kto za co odpowiada, jeszcze zanim pojawią się pierwsze zapytania od klientów czy regulatora.

Rola IT: technologia, integracja, bezpieczeństwo

IT nie musi znać każdego przepisu, ale odpowiada za warstwę techniczną i operacyjną. Typowe zadania:

• Prowadzenie rejestru systemów AI – aktualizacja arkusza, weryfikacja dostawców, podstawowe parametry techniczne.
• Ocena wykonalności technicznej wymogów – czy da się dodać logi, wersjonowanie modeli, dodatkowe kontrole dostępu.
• Bezpieczeństwo i ciągłość działania – backupy, monitoring, reagowanie na incydenty techniczne dot. systemów AI.
• Wsparcie przy ocenie nowych narzędzi – szybki screening: skąd biorą dane, jak są trenowane modele, jak wygląda hosting.
• Techniczna strona „human in the loop” – np. wprowadzanie progów, powiadomień, dodatkowych kroków akceptacji.

Z perspektywy kosztowej najważniejsze jest, aby IT nie próbowało budować wszystkiego od zera. Zamiast autorskich rozwiązań compliance lepiej:

• wykorzystać istniejące narzędzia logowania i monitoringu do systemów AI,
• dostosować obecne procedury change managementu do zmian modeli,
• wkomponować AI w już istniejące standardy bezpieczeństwa (np. ISO, NIS2), zamiast tworzyć osobne „wyspy”.

Rola działu prawnego / compliance: ramy, umowy, „czerwone linie”

Prawnicy nie muszą rozumieć architektury modeli, ale powinni zdefiniować granice, w których IT i biznes mogą się swobodnie poruszać. Kluczowe działania:

• Minimalny zestaw dokumentów:
  • polityka korzystania z AI (wewnętrzna),
  • prosty szablon oceny ryzyka AI / check-lista przy nowych projektach,
  • wzorcowe zapisy do umów z dostawcami i klientami (klauzule AI).
• Ustalenie „no go” – krótką listę zastosowań i praktyk, które są zakazane lub wymagają zgody zarządu (np. profilowanie pracowników z użyciem określonych danych).
• Wsparcie przy klasyfikacji systemów z koszyka A – sprawdzenie, czy nie wchodzą w szczególne kategorie wysokiego ryzyka wg AI Act.
• Koordynacja z RODO, prawem pracy, sektorówką – zamiast rozbudowanej teorii: wskazanie kilku kluczowych punktów, których trzeba pilnować przy AI (podstawy prawne, informowanie osób, prawa sprzeciwu, dialog z przedstawicielami pracowników).

Dobrą praktyką jest ustalenie, że prawnicy nie opiniują każdego promptu do ChatGPT, tylko:

• tworzą zasady korzystania,
• uczestniczą w przeglądzie nowych rozwiązań AI o większym ciężarze,
• biorą udział w analizie incydentów.

Rola właścicieli procesów: realny wpływ i „nadzór człowieka”

Właściciel procesu (np. szef sprzedaży, HR, operacji) ma w AI Act bardziej istotną rolę niż się potocznie sądzi, bo to on:

• decyduje, jak i gdzie AI jest wplecione w workflow,
• ustala, kiedy człowiek może / musi „przegłosować” decyzję systemu,
• zna skutki biznesowe błędnych rekomendacji modelu.

Od strony praktycznej właściciele procesów powinni:

• opisać minimalny scenariusz użycia AI (co system robi, jaki jest „plan B” gdy zawiedzie),
• zdefiniować punkty kontrolne – gdzie pracownik ma obowiązek spojrzeć krytycznie na wynik i podjąć ostateczną decyzję,
• przekazać do IT i prawników informacje o skutkach błędów (np. błędne odrzucenie kandydata, niesłuszne zablokowanie konta klienta),
• pilnować szkoleń i komunikacji w swoim zespole – jak korzystać z systemu, czego nie robić, gdzie zgłaszać problemy.

Bez takiego „zakotwiczenia” w procesie AI Act zamieni się w zestaw dokumentów bez realnego przełożenia na praktykę, a odpowiedzialność rozmyje się między działami.

Rola zarządu / właścicieli firmy: decyzje o ryzyku i budżecie

Na koniec i tak ktoś musi podpisać się pod akceptowalnym poziomem ryzyka. Zarząd nie potrzebuje technicznych szczegółów, ale kilku klarownych decyzji:

• Jakie poziomy ryzyka są akceptowalne, a przy jakich wymagane jest „tak” zarządu?
• Jaki jest minimalny budżet czasu na wdrożenie (np. 10–20% czasu wybranych osób przez 2–3 miesiące)?
• Kto ma mandat decyzyjny w sporach między IT, prawnikami a biznesem?
• Jakie są priorytety biznesowe – na których systemach AI firma zarabia lub może zarobić najwięcej, a które można wyłączyć, jeśli będą problemem?

Minimalistyczna, ale jasna decyzja zarządu oszczędza miesiące „przerzucania się” odpowiedzialnością między działami, a przy pierwszym incydencie pomaga pokazać, że firma świadomie zarządza ryzykiem, a nie ignoruje tematu.

Minimalny system zarządzania AI (AI governance) dla firm z ograniczonym budżetem

Prosty szkielet zamiast wielkiego programu transformacji

AI governance nie musi oznaczać komitetów, roadmap na lata i systemów za setki tysięcy. Dla większości firm średniej wielkości w zupełności wystarczy „lekka” struktura, którą da się utrzymać przy regularnej pracy, bez osobnego departamentu AI.

Szkielet może składać się z pięciu elementów:

1. Rejestr systemów AI.
2. Prosta procedura oceny i zatwierdzania nowych zastosowań.
3. Minimalny zestaw zasad użycia i ról.
4. Monitoring incydentów i przeglądy okresowe.
5. Szkolenia „na poziomie podstawowym” dla kluczowych ludzi.

Rejestr systemów AI – utrzymanie zamiast jednorazowego zrywu

Po pierwszej inwentaryzacji problemem staje się utrzymanie aktualności. Zamiast nakładać na wszystkich skomplikowane obowiązki, można przyjąć dwie proste zasady:

• Bez wpisu do rejestru nie kupujemy / nie wdrażamy systemu AI – wpis to jeden z punktów na check-liście przy zakupie oprogramowania lub uruchomieniu projektu.
• Co kwartał krótki przegląd – właściciele procesów dostają przypomnienie: „czy pojawiły się nowe narzędzia AI w twoim obszarze?”.

Technicznie rejestr może pozostać arkuszem w Excelu lub Google Sheets. W małej/średniej firmie wdrażanie do tego dedykowanego systemu GRC często jest przerostem formy nad treścią.

Procedura „nowa AI w firmie” w trzech krokach

Zbyt rozbudowane procedury skończą się tym, że ludzie będą „obchodzić system”. Bardziej opłaca się bardzo prosty proces, który faktycznie jest stosowany:

Trzystopniowy przepływ: zgłoszenie – szybka ocena – decyzja

Prosty schemat wystarczy opisać na jednej stronie i przypiąć tam, gdzie ludzie faktycznie zaglądają (intranet, Teams, Notion). Przykładowy wariant „na start”:

1. Zgłoszenie pomysłu / narzędzia
   • krótki formularz (max 10 pól) dla osoby zgłaszającej – czego dotyczy narzędzie, jakie dane będzie przetwarzać, gdzie w procesie ma działać;
   • automatyczne przypisanie zgłoszenia do IT + działu prawnego + właściciela procesu (np. prostą regułą mailową lub w systemie ticketowym, który już działa w firmie).
2. Szybka ocena ryzyka
   • IT weryfikuje aspekty techniczne, bezpieczeństwo i integrację;
   • prawnik / compliance ocenia kategorię ryzyka wg AI Act, wstępne wymagania dokumentacyjne i prawne;
   • właściciel procesu ocenia skutki biznesowe błędów i określa, czy potrzebny jest „human in the loop”.
3. Decyzja i warunki wdrożenia
   • prosty wynik: „OK” / „OK z warunkami” / „STOP, decyzja zarządu”;
   • jeśli „OK z warunkami”, warunki są konkretne: np. „tylko w pilotażu przez 3 miesiące”, „bez danych klientów”, „wynik zawsze zatwierdza człowiek”.

Całość da się spiąć istniejącym narzędziem (Jira, ServiceNow, Asana, nawet wspólny mailbox) zamiast kupowania „platformy AI governance”. Kluczem jest, by ten proces był najszybszą legalną ścieżką, inaczej i tak wygrają „partyzanckie” wdrożenia.

Minimalny zestaw zasad użycia – trzy poziomy szczegółowości

Zasady korzystania z AI nie muszą mieć 20 stron. Praktyczniej podzielić je na trzy krótkie warstwy, które różne grupy naprawdę przeczytają:

• 1. Jednostronicowe „ABC AI” dla wszystkich – co wolno, czego nie, gdzie są ryzyka. Język prosty, bez żargonu prawniczego. Przykłady: „Nie wgrywamy do publicznych chatbotów danych klientów”, „Decyzje personalne podejmuje człowiek, AI może co najwyżej podpowiadać”.
• 2. Instrukcje dla ról „blisko AI” – właściciele procesów, produktowcy, analitycy. Tu już: jak dokumentować zmiany modeli, jak planować testy, kiedy trzeba zgłosić temat do compliance. 3–5 stron, a nie „biblia”.
• 3. Wytyczne techniczne dla IT / data science – logowanie, wersjonowanie, minimalne kryteria jakości danych, standardy wdrożeń. To może być rozszerzenie istniejących standardów IT.

Zamiast spędzać miesiące na dopieszczaniu pdf-ów lepiej uruchomić prostą wersję, pokazać ludziom na spotkaniu i poprawiać w iteracjach dwa razy do roku.

Monitoring incydentów: prosty kanał zamiast dużego systemu

AI Act kładzie nacisk na reagowanie na problemy. Nie chodzi tylko o spektakularne awarie, ale też o „miękkie” incydenty: niesprawiedliwe rekomendacje, halucynacje, błędne klasyfikacje. Przy ograniczonym budżecie wystarczy:

• jeden kanał zgłoszeń – np. etykieta „AI-INCYDENT” w systemie ticketów lub dedykowany kanał w Teams / Slacku;
• prosty formularz zgłoszenia – co się stało, w jakim systemie, jaki był potencjalny skutek, czy klient / pracownik został poinformowany;
• lekkie kategoryzowanie – np. „błąd bez wpływu na klienta”, „błąd odczuwalny dla klienta”, „poważny incydent / ryzyko naruszenia prawa”.

Ważniejsze niż perfekcyjny system klasyfikacji jest to, żeby pracownicy wiedzieli, że wolno zgłosić problem i że nie będą za to „karani”. Przez pierwsze miesiące warto wręcz zachęcać do nad-zgłaszania, żeby zbudować obraz typowych problemów.

Przeglądy okresowe: krótko, ale regularnie

Zamiast dużego, raz do roku audytu, bardziej opłaca się krótkie przeglądy co kwartał lub co pół roku. Format „low cost”:

• max 60 minut on-line z udziałem IT, prawnika, 2–3 właścicieli kluczowych procesów;
• omówienie: nowych systemów z rejestru, zgłoszonych incydentów, planowanych zmian w najważniejszych modelach;
• prosta notatka po spotkaniu: 3–5 decyzji, co robimy przez kolejne miesiące (np. wymieniamy dostawcę, dopisujemy warunki do regulaminu, wyłączamy eksperyment pilotażowy).

Taki rytm porządkuje temat bez angażowania dodatkowych etatów. Często udaje się go „podczepić” pod już istniejące komitety (np. bezpieczeństwa informacji, ryzyka operacyjnego), zamiast budować nową strukturę.

Szkolenia „na poziomie podstawowym” – dwie grupy, dwa cele

Najtańsze i najbardziej efektywne podejście to odróżnić dwie grupy odbiorców:

• 1. Użytkownicy końcowi – wszyscy, którzy korzystają z AI w codziennej pracy (np. asystenty pisania, narzędzia do analizy dokumentów).
  • krótka sesja (30–45 min), najlepiej online + nagranie;
  • treść: co wolno, czego nie, przykłady błędów AI, gdzie zgłaszać wątpliwości;
  • kosztowo: wystarczy jedno szkolenie rocznie + onboarding dla nowych osób.
• 2. Osoby odpowiedzialne za AI – właściciele procesów, IT, prawnicy, product ownerzy.
  • 2–3 spotkania po 1,5 h zamiast wielodniowych warsztatów;
  • fokus na: klasyfikację ryzyka, wymagania dokumentacyjne, progi decyzyjne („kiedy idziemy do zarządu”);
  • materiały robocze: checklisty, proste wzory dokumentów – tak, aby po szkoleniu faktycznie było z czego korzystać.

Zewnętrznego trenera opłaca się zaprosić raczej dla drugiej grupy; dla użytkowników końcowych często wystarczy nagrany wewnętrzny webinar z krótkimi slajdami i przykładami z własnej firmy.

„Mały komitet AI” bez pompy i nowych etatów

W wielu firmach temat AI można „przypiąć” do istniejącej struktury. Zamiast powoływać Radę AI z osobnymi regulaminami, da się ustalić:

• że 3–4 osoby (IT, prawnik, przedstawiciel biznesu, czasem HR) są „rdzeniem” odpowiedzialnym za AI governance,
• że spotykają się raz na kwartał (ten sam slot, co przegląd systemów),
• że każdorazowo mogą dokooptować „gościa” – właściciela procesu, którego dotyczy dany temat.

Formalizacja sprowadza się do krótkiej decyzji zarządu czy notatki w protokole: kto wchodzi w skład grupy, jakie ma uprawnienia (np. prawo wstrzymania projektu, jeśli ryzyko jest zbyt wysokie lub brakuje informacji). To zwykle wystarcza, żeby wykazać istnienie mechanizmu nadzoru, bez rozbudowanej biurokracji.

Jak wkomponować AI Act w istniejące standardy (RODO, ISO, NIS2)

Z punktu widzenia czasu i kosztów najrozsądniej jest nie budować osobnego „świata AI”, tylko dopiąć wymagania AI Act do tego, co już funkcjonuje:

• RODO / ochrona danych – w szablonach DPIA / oceny skutków dodać 2–3 pytania o AI (czy system wykorzystuje AI, jaki ma wpływ na prawa osób, jak działa wyjaśnialność decyzji).
• ISO 27001 / bezpieczeństwo informacji – potraktować systemy AI jako kolejny typ systemów informatycznych; dopisać w rejestrze aktywów i procedurach zarządzania zmianą, że modele też podlegają change management.
• NIS2 / cyberbezpieczeństwo – w analizie ryzyka IT dodać kategorię „systemy AI”, oceniając, jak ich awaria wpływa na ciągłość działania i jakie są scenariusze degradacji (np. powrót do prostszych reguł biznesowych).

W praktyce często wystarczy aktualizacja 2–3 istniejących polityk i procedur oraz dopisanie kilku pól do rejestrów. To koszt kilku dni pracy zamiast całego projektu konsultingowego.

Dokumentacja „na poziomie wystarczającym”, a nie doskonałym

Wokół AI Act łatwo popaść w perfekcjonizm. Tymczasem w wielu przypadkach akceptowalna jest dokumentacja „lekka”, ale spójna. Dla systemów z koszyka A (niskie ryzyko) sensowny pakiet minimum wygląda tak:

• karta systemu AI – 1–2 strony: opis funkcji, właściciel, dane wejściowe, główne ryzyka, sposób nadzoru człowieka;
• log zmian – prosty arkusz: co zmieniono, kiedy, kto zatwierdził, czy zrobiono podstawowe testy;
• zapis przeglądów – krótkie notatki z kwartalnych spotkań, gdzie ten system był omawiany.

Dopiero przy systemach z koszyka B lub zbliżających się do wysokiego ryzyka warto wchodzić w pełne procedury testów, metryki jakości, opisy datasetów itd. Wiele firm nieświadomie stosuje „standard wysokiego ryzyka” do każdego chatbota, a potem rezygnuje z dokumentowania, bo jest to zbyt ciężkie.

Niedrogie wsparcie zewnętrzne: kiedy ma sens

Nie każda organizacja musi zatrudniać „Head of AI Governance”. Przy ograniczonym budżecie lepiej wykorzystać zewnętrzne wsparcie punktowo:

• 1–2 dni przeglądu obecnych projektów AI i rejestru – żeby potwierdzić klasyfikację ryzyka i uzupełnić najbardziej rażące braki.
• przygotowanie szablonów (polityka AI, karta systemu, checklista oceny ryzyka) – jednorazowo, potem obsługa wewnętrzna.
• krótkie szkolenie dla „rdzenia AI” – ludzi odpowiedzialnych za procesy, IT i prawo, zamiast masowych szkoleń dla wszystkich.

Takie podejście zwykle jest tańsze niż duży projekt doradczy, a jednocześnie pozwala uniknąć typowych błędów interpretacyjnych na starcie. Resztę można rozwijać samemu, w rytmie kolejnych przeglądów.

Rozsądne tempo wdrożenia: małe kroki zamiast „rewolucji na już”

Przy ograniczonych zasobach kluczowe jest, żeby nie zatrzymać biznesu pod pretekstem AI Act. Lepsza jest sekwencja małych kroków:

1. Miesiąc 1–2: dokończenie rejestru systemów, prosta klasyfikacja A/B, wstępny zestaw zasad użycia i formularz „nowa AI w firmie”.
2. Miesiąc 3–4: pierwsze przeglądy okresowe, dopięcie rejestru do istniejących procesów zakupowych / change management, szkolenie podstawowe dla użytkowników.
3. Miesiąc 5–6: dopracowanie dokumentacji dla 2–3 najważniejszych systemów (tam, gdzie ryzyko lub wpływ biznesowy jest największy), drobne poprawki polityk RODO / bezpieczeństwa.

Takie rozłożenie prac po kilku miesiącach daje już sensowny „mini-system” zarządzania AI, bez potrzeby organizowania osobnego programu transformacyjnego. Jednocześnie pozwala utrzymać zgodność z głównymi wymaganiami AI Act na poziomie adekwatnym do skali firmy.

Najczęściej zadawane pytania (FAQ)

Kogo realnie dotyczy AI Act – czy moja firma też się łapie?

W praktyce AI Act obejmie większość firm, które korzystają z nowoczesnego oprogramowania: dostawców rozwiązań IT z elementami AI, użytkowników narzędzi AI w procesach (np. HR, marketing, obsługa klienta), integratorów oraz podwykonawców pracujących przy projektach z AI dla większych klientów.

Nawet jeśli firma nie tworzy własnych modeli, ale używa ATS z modułem AI, systemu scoringowego albo generatywnego AI w obsłudze klienta, jest w zasięgu regulacji – choć zwykle w uproszczonym zakresie. Pełny, ciężki reżim dotyczy głównie systemów wysokiego ryzyka (np. rekrutacja, kredyty, opieka zdrowotna), ale obowiązki transparentności i podstawowego zarządzania ryzykiem pojawią się u wielu „zwykłych” użytkowników biznesowych.

Od czego zacząć przygotowania do AI Act w średniej firmie?

Najbardziej opłacalny pierwszy krok to krótka inwentaryzacja: gdzie w firmie jest AI, także „ukryte” w narzędziach chmurowych i SaaS. Na start wystarczy prosty rejestr systemów z kolumnami: nazwa, dostawca, dział właścicielski, do czego służy, czy wpływa na ludzi (np. decyzje o zatrudnieniu, dostępie do usług, ocenie pracowników).

Kolejny etap to wstępna klasyfikacja według poziomów ryzyka (zakazane / wysokie / ograniczone / minimalne) i wskazanie kilku systemów „najważniejszych”, którym warto przyjrzeć się głębiej. To można zrobić w 1–2 tygodnie pracy kilku osób (IT, prawnik, właściciele procesów), zamiast od razu zamawiać duży projekt compliance.

Jak odróżnić, co jest AI w rozumieniu AI Act, a co zwykłym oprogramowaniem?

AI Act celuje w systemy, które uczą się na danych i modyfikują swoje działanie bez ręcznego dopisywania reguł. Do AI zaliczają się m.in. modele machine learning do przewidywania, scoringu, rekomendacji, systemy generatywne (tekst, obraz, kod), chatboty oparte na NLP czy moduły, które „trenują się” na danych klientów.

Klasyczne workflow w systemie ERP, proste raporty BI czy reguły „if-then” bez uczenia się na danych zazwyczaj nie wchodzą w zakres. Na etapie mini-audytu lepiej jednak wciągnąć na listę wszystko, co dostawca opisuje jako „AI / ML / genAI”, a dopiero potem odsiewać elementy, które po analizie faktycznie nie spełniają definicji z rozporządzenia.

Jakie są poziomy ryzyka w AI Act i co to oznacza dla mojej firmy operacyjnie?

AI Act dzieli systemy na: zakazane, wysokiego ryzyka, ograniczonego ryzyka i minimalnego ryzyka. Zakazanych po prostu nie wolno używać. Wysokie ryzyko (np. rekrutacja, scoring kredytowy, systemy wpływające na dostęp do usług publicznych) wymagają rozbudowanej dokumentacji, oceny ryzyka, nadzoru człowieka, kontroli jakości danych i logowania działań.

Systemy ograniczonego ryzyka (chatboty, generatywne AI mogące być mylone z człowiekiem) wymagają głównie transparentności i prostszej oceny wpływu. Minimalne ryzyko to zwykle narzędzia wewnętrzne wspierające specjalistów – tu wystarczą dobre praktyki i włączenie ich w istniejące zasady IT/RODO. Z punktu widzenia kosztów to systemy wysokiego ryzyka „pożerają” większość budżetu na wdrożenie, resztę da się często obsłużyć lekkim procesem zgłoszeń i krótką analizą.

Ile realnie kosztuje wdrożenie AI Act w średniej firmie?

Dla firm bez krytycznych systemów wysokiego ryzyka minimum da się zrobić stosunkowo tanio: kilka tygodni pracy 2–4 osób na inwentaryzację i klasyfikację, przygotowanie podstawowych dokumentów (rejestr systemów AI, zasady użycia, prosta procedura oceny ryzyka) oraz kilka godzin szkoleń dla kluczowych ról. Dodatkowo można dokupić ograniczoną konsultację zewnętrzną tylko dla najbardziej wrażliwych zastosowań.

Znacznie droższe są koszty zaniechania: wstrzymane projekty, przegrane przetargi, brak odpowiedzi na pytania o AI Act w RFP, a w skrajnym scenariuszu kary, roszczenia i doraźne „gaszenie pożarów” po incydencie. Z perspektywy budżetu bardziej opłaca się poukładać temat na poziomie rozsądnego minimum niż liczyć na to, że nikt nie zapyta o AI w Twoich procesach.

Jak połączyć AI Act z RODO, NIS2 i obecnymi procedurami, żeby nie mnożyć papierologii?

Najsensowniejsze podejście to dobudowanie elementu „AI” do tego, co już istnieje. Jeśli robisz DPIA pod RODO, dołóż do wzoru kilka pytań o specyfikę AI: bias, nadzór człowieka, wyjaśnialność. W bezpieczeństwie IT i NIS2 można dopisać AI do obecnych procedur incydentów, zarządzania podatnościami, backupów i kontroli dostępu, zamiast tworzyć nowe, równoległe polityki.

Przy systemach kadrowych, rekrutacyjnych czy monitoringu sensowne jest zsynchronizowanie wymogów AI Act z aktualizacją regulaminu pracy i polityk HR. Klucz leży w tym, żeby nie kopiować tych samych zapisów do pięciu dokumentów, tylko jasno pokazać, gdzie i jak AI jest już objęte istniejącymi procesami.

Jak podzielić obowiązki przy AI Act między IT, prawników i właścicieli procesów?

Minimalny, praktyczny podział wygląda zwykle tak: IT odpowiada za listę systemów, aspekty techniczne (architektura, logi, bezpieczeństwo), prawnicy za interpretację przepisów, dokumentację i umowy z dostawcami, a właściciele procesów za opis zastosowania AI, wpływ na ludzi oraz decyzję, czy dany use case jest biznesowo i etycznie akceptowalny.

Dobrze działa prosty model: jedna osoba koordynująca temat AI (niekoniecznie na pełen etat), która zbiera informacje z działów, pilnuje rejestru i prowadzi listę priorytetów. Przy takim ustawieniu nie ma potrzeby budowania od razu „departamentu compliance AI”, a obowiązki w dużej mierze da się wpleść w istniejącą strukturę odpowiedzialności.

Bibliografia i źródła

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). European Union (2024) – Tekst AI Act: definicje systemu AI, poziomy ryzyka, obowiązki podmiotów.
• Proposal for a Regulation laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) – Explanatory Memorandum. European Commission (2021) – Uzasadnienie regulacji, cele, wpływ na przedsiębiorstwa i łańcuch dostaw.
• Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk”. European Data Protection Board (2017) – Wytyczne DPIA; podstawa do łączenia RODO z oceną ryzyka systemów AI.