Firma robi godzinny webinar o generatywnej AI. Pracownicy dowiadują się, że modele halucynują, nie należy wpisywać danych poufnych, a wynik trzeba sprawdzić. Na koniec każdy dostaje certyfikat.
Art. 4 AI Act dotyczy kompetencji osób, które korzystają z systemów AI lub obsługują je w imieniu firmy. W praktyce firma powinna pomóc im zrozumieć używane narzędzia, ich ograniczenia i związane z nimi ryzyko. Zakres takich działań powinien uwzględniać wiedzę i doświadczenie konkretnych osób, sposób używania AI oraz to, na kogo może wpływać działanie systemu.
Czy opisany wyżej webinar wystarczy? Dla części pracowników takie szkolenie może być rozsądnym początkiem. Jeden identyczny materiał nie odpowie jednak na potrzeby developera integrującego model przez API, rekrutera używającego AI przy ocenie kandydatów i pracownika marketingu poprawiającego post.
Po wejściu w życie AI Omnibus obowiązek dotyczący AI literacy pozostał, ale stał się bardziej elastyczny. Firma nadal powinna wspierać kompetencje osób korzystających z AI. Nie musi natomiast gwarantować każdej osobie jednego, ustawowo określonego poziomu wiedzy.
Czego dowiesz się z tego tekstu?
- co AI Omnibus zmienił w art. 4 AI Act;
- czy każde przedsiębiorstwo korzystające z AI potrzebuje szkolenia;
- kogo objąć działaniami AI literacy;
- dlaczego marketing, HR i developerzy potrzebują różnych instrukcji;
- jak dokumentować działania bez obowiązkowych certyfikatów;
- czy firma musi powołać AI Officera albo specjalny komitet.
W skrócie
- AI literacy nadal obowiązuje providerów i deployerów systemów AI.
- Provider to w uproszczeniu dostawca systemu AI, a deployer to organizacja, która używa go w swojej działalności.
- Art. 4 nie narzuca jednego kursu, certyfikatu ani programu identycznego dla wszystkich.
- Zakres działań powinien odpowiadać narzędziom, roli danej osoby, kontekstowi użycia i ryzyku.
- Firma nie musi powoływać AI Officera, ale ktoś powinien odpowiadać za mapę narzędzi, materiały i dokumentację.
- Lista obecności pomaga, lecz nie zastępuje odpowiedzi na pytanie, czego konkretna grupa miała się nauczyć.
Co oznacza AI literacy?
AI literacy, nazywane po polsku kompetencjami w zakresie AI, to umiejętność świadomego korzystania z systemów sztucznej inteligencji. Nie chodzi o to, aby każdy pracownik rozumiał architekturę modelu. Powinien jednak wiedzieć, co narzędzie potrafi, gdzie może się pomylić, jakie dane można do niego wprowadzać i kiedy wynik wymaga kontroli człowieka.
Zakres potrzebnej wiedzy zależy od zadania. Osoba używająca asystenta do poprawienia wiadomości działa w innym kontekście niż developer budujący agenta, który wykonuje operacje na koncie klienta. Jeszcze inne kompetencje są potrzebne rekruterowi korzystającemu z rankingu kandydatów.
AI literacy nie polega na zebraniu certyfikatów. Ma sprawić, że ludzie lepiej rozumieją narzędzie, ryzyko i własną odpowiedzialność.
Co AI Omnibus zmienił w art. 4 AI Act?
AI Omnibus, który wszedł w życie 27 lipca 2026 r., zmienił brzmienie art. 4 AI Act. Providerzy i deployerzy nadal mają podejmować działania wspierające rozwój kompetencji osób używających lub obsługujących systemy AI w ich imieniu.
Przy doborze działań trzeba brać pod uwagę między innymi:
- wiedzę techniczną i doświadczenie tych osób;
- ich wykształcenie i wcześniejsze szkolenia;
- kontekst, w którym system jest używany;
- osoby lub grupy, na które działanie systemu może wpływać.
Nowe brzmienie przepisu nie wymaga zagwarantowania określonego poziomu kompetencji. Nie oznacza to jednak, że temat zniknął. Zmienił się sposób opisania obowiązku, a nie potrzeba świadomego używania AI.
Komisja Europejska wyjaśnia, że nie ma jednego rozwiązania pasującego do wszystkich organizacji. Nie wskazuje też obowiązkowego certyfikatu ani jednego formatu szkolenia.
Czy szkolenie z AI jest obowiązkowe?
Art. 4 nie nakazuje kupienia konkretnego kursu ani przeprowadzenia corocznego webinaru. Firma może łączyć różne działania, jeżeli odpowiadają one realnym sposobom używania AI.
Takimi działaniami mogą być:
- krótkie szkolenie wprowadzające;
- polityka używania AI;
- instrukcje dla zatwierdzonych narzędzi;
- warsztaty dla konkretnych zespołów;
- zasady sprawdzania wyników;
- procedura zgłaszania błędów i incydentów;
- aktualizacje po zmianie modelu, dostawcy albo sposobu użycia;
- konsultacje z osobą odpowiedzialną za AI governance.
AI governance to po prostu zasady zarządzania AI w organizacji: kto zatwierdza narzędzia, jakie zastosowania są dopuszczalne, kto ocenia ryzyko i gdzie zgłasza się problem. W małej firmie ten system może być prosty. Organizacja używająca AI w zatrudnieniu, bezpieczeństwie albo procesie wpływającym na prawa ludzi będzie potrzebowała znacznie więcej.
Kogo objąć działaniami AI literacy?
Działania powinny obejmować pracowników i inne osoby, które obsługują lub używają systemu AI w imieniu providera albo deployera. W zależności od modelu współpracy mogą to być również:
- współpracownicy B2B;
- developerzy i administratorzy;
- pracownicy supportu;
- zewnętrzni moderatorzy;
- osoby zatwierdzające decyzje wspierane przez AI;
- osoby kupujące i konfigurujące narzędzia;
- członkowie zespołu klienta obsługujący dostarczony system.
Nie każda osoba potrzebuje identycznego poziomu wiedzy. Osoba używająca AI do poprawienia stylu wiadomości jest w innej sytuacji niż rekruter pracujący z rankingiem kandydatów. Zakres szkolenia powinien wynikać z tego, co dana osoba rzeczywiście robi.
Najpierw mapa systemów i ról
Trudno zaplanować AI literacy, jeśli firma nie wie, z jakich systemów korzystają zespoły. Pierwszym krokiem powinno być połączenie rejestru narzędzi z mapą ról, procesów i ryzyka.
W praktyce można zacząć od takiego podziału:
- marketing: tworzenie treści, ryzyko halucynacji, praw autorskich i niewłaściwego oznaczenia materiału;
- HR: przygotowanie ogłoszeń i analiza aplikacji, ryzyko dyskryminacji, naruszenia prywatności i automatyzacji decyzji;
- developerzy: integracja API i agentów, ryzyko dotyczące logów, danych wejściowych, bezpieczeństwa i zmian modelu;
- support: generowanie odpowiedzi klientom, ryzyko błędnej informacji lub ujawnienia danych;
- zarząd i zakupy: wybór narzędzi, ryzyko kontraktowe, vendor lock-in i zgodność;
- human oversight: nadzór człowieka, ryzyko bezrefleksyjnego zatwierdzania rekomendacji systemu.
Jeżeli organizacja nie wie, z jakich narzędzi korzystają jej zespoły, warto najpierw uporządkować Shadow AI i podstawy AI governance. Szkolenie o zatwierdzonych rozwiązaniach nie pomoże w pełni, jeśli połowa narzędzi pozostaje poza radarem firmy.
Czego potrzebuje zwykły użytkownik generatywnej AI?
Podstawowy użytkownik nie musi znać architektury transformera. Powinien rozumieć ograniczenia narzędzia, zasady pracy z danymi i konieczność sprawdzenia wyniku przed jego użyciem.
Program podstawowy może wyjaśniać:
- czym jest system AI używany w firmie;
- do jakich celów został zatwierdzony;
- jakich danych nie wolno do niego wprowadzać;
- dlaczego model może podawać fałszywe informacje;
- jak sprawdzać wynik i źródła;
- kiedy poinformować odbiorcę o użyciu AI;
- kiedy decyzję musi podjąć człowiek;
- gdzie zgłosić błąd, incydent lub nowy pomysł na użycie.
Nawet przy prostym użyciu generatora tekstu pracownik powinien wiedzieć, że płynnie brzmiąca odpowiedź może być nieprawdziwa. To praktyczna kompetencja, nie wykład z uczenia maszynowego.
Developer potrzebuje innego programu niż marketing
Osoba integrująca AI z produktem powinna rozumieć nie tylko ograniczenia odpowiedzi, ale też przepływ danych, logowanie, podwykonawców dostawcy, wersjonowanie modelu, testy i bezpieczeństwo.
Zakres dla zespołu technicznego może obejmować:
- architekturę integracji i przepływy danych;
- ograniczenia opisane przez dostawcę;
- filtrowanie danych wejściowych i wyników;
- ochronę promptów, sekretów i kluczy API;
- testy jakości, uprzedzeń i odporności;
- monitoring zmian modelu;
- procedurę wycofania lub zmiany dostawcy;
- logowanie i retencję danych;
- zasady nadzoru człowieka;
- wymagania umów, DPA i regulaminów dostawcy.
Trzeba też ustalić rolę firmy. Organizacja może być tylko użytkownikiem systemu, ale przez własną integrację, istotną modyfikację lub nowe przeznaczenie może wejść w szerszy zakres obowiązków. Ten temat rozwijam w artykule o rolach deployer i provider w AI Act.
Human oversight wymaga realnej kontroli
Human oversight oznacza nadzór człowieka nad działaniem systemu. Nie wystarczy jednak dodać przycisku „zatwierdź”. Osoba nadzorująca powinna umieć rozpoznać ograniczenia systemu, odrzucić jego wynik i w razie potrzeby zatrzymać proces.
Powinna wiedzieć:
- co system rzeczywiście ocenia;
- jakich danych nie bierze pod uwagę;
- jakie błędy pojawiły się podczas testów;
- kiedy wynik może być niewiarygodny;
- jakie są skutki błędnej decyzji;
- jak zgłosić nieprawidłowość;
- jak przerwać lub ominąć automatyzację;
- kto podejmuje ostateczną decyzję.
Jeżeli pracownik mechanicznie akceptuje każdą rekomendację, człowiek jest obecny tylko formalnie. W systemach wysokiego ryzyka dodatkowe wymagania mogą wynikać z przepisów dotyczących nadzoru człowieka i obowiązków deployera. Ogólny webinar o generatywnej AI będzie tu zbyt płytki.
Czy firma potrzebuje AI Officera?
AI Act nie wymaga powołania AI Officera ani specjalnego komitetu wyłącznie po to, aby wykonać art. 4. Firma powinna jednak przypisać odpowiedzialność za mapę narzędzi, aktualizację materiałów i dokumentowanie działań.
Taką rolę może pełnić:
- osoba odpowiedzialna za compliance;
- IOD, jeżeli zakres nie prowadzi do konfliktu ról;
- security lub IT manager;
- product owner;
- zespół łączący prawo, HR, bezpieczeństwo i technologię.
Nie chodzi o stworzenie nowego stanowiska z efektownym tytułem. Ktoś powinien jednak zauważyć, że szkolenie nadal opisuje narzędzie wycofane pół roku wcześniej. W praktyce AI literacy warto połączyć z onboardingiem, bezpieczeństwem informacji, RODO, zarządzaniem dostawcami i reagowaniem na incydenty.
Jak udokumentować AI literacy?
Komisja nie wymaga certyfikatu. Organizacja może prowadzić wewnętrzną ewidencję szkoleń, instrukcji i innych działań. Dokumentacja powinna pozwalać odtworzyć, dlaczego wybrano dany zakres i kogo nim objęto.
Warto zachować:
- mapę systemów i sposobów użycia;
- podział grup użytkowników;
- krótką ocenę ryzyka;
- materiały szkoleniowe i instrukcje;
- datę oraz listę osób objętych działaniem;
- pytania i problemy zgłoszone przez uczestników;
- decyzje o aktualizacji materiałów;
- dowody przekazania zasad współpracownikom zewnętrznym;
- informacje o incydentach, które wpłynęły na zakres szkoleń.
Lista obecności jest przydatna, ale nie pokaże, dlaczego rekruter i developer otrzymali dokładnie ten sam program. Dokumentacja ma odzwierciedlać sposób myślenia organizacji, a nie tylko fakt odbycia spotkania.
Kazus modelowy: jedno szkolenie dla całego SaaS-u
Polski SaaS zatrudnia 45 osób. Marketing używa generatora tekstów, support korzysta z AI do proponowania odpowiedzi, a zespół techniczny wdrożył agenta analizującego zgłoszenia klientów. Firma przeprowadza jedno szkolenie o bezpiecznym promptowaniu.
Dwa miesiące później:
- marketing publikuje niezweryfikowaną informację wygenerowaną przez model;
- support kopiuje do narzędzia zgłoszenie zawierające dane osobowe;
- developer nie wie, że dostawca zmienił zasady retencji logów;
- pracownik zatwierdza błędne działanie agenta, bo zakłada, że system widzi całą historię klienta.
Firma może pokazać certyfikaty. Nie potrafi jednak wskazać, jakie ryzyko przypisała poszczególnym rolom ani jakie instrukcje obowiązywały w konkretnym procesie.
Lepszy model obejmowałby:
- wspólny moduł podstawowy;
- krótkie instrukcje dla marketingu i supportu;
- warsztat techniczny dla developerów;
- procedurę eskalacji wyniku agenta;
- aktualizację materiałów po zmianie dostawcy;
- zapis działań w rejestrze AI governance.
Łączny czas nie musi być znacznie dłuższy. Różnica polega na tym, że właściwa wiedza trafia do właściwych osób.
Plan AI literacy dla MŚP
Mała lub średnia firma może zacząć od dziesięciu kroków:
- zidentyfikować używane systemy i funkcje AI;
- ustalić, gdzie firma jest providerem, a gdzie deployerem;
- wskazać osoby korzystające z systemów;
- ocenić ryzyko poszczególnych zastosowań;
- podzielić odbiorców na praktyczne grupy;
- przygotować wspólny moduł podstawowy;
- dodać instrukcje zależne od roli i narzędzia;
- określić zasady zgłaszania pytań oraz incydentów;
- zapisać wykonane działania;
- wracać do materiałów po zmianie modelu, procesu albo prawa.
Dobry program AI literacy nie musi być rozbudowany. Musi odpowiadać temu, jak firma rzeczywiście korzysta z AI.
AI literacy ma zmieniać zachowanie
Celem art. 4 nie jest nauczenie całej firmy teorii uczenia maszynowego. Chodzi o to, aby osoby używające AI rozumiały narzędzie, jego ograniczenia, ryzyko i własną odpowiedzialność.
Po AI Omnibus organizacje mają większą elastyczność. Warto wykorzystać ją do dopasowania działań do realnych procesów, zamiast szukać jednego uniwersalnego webinaru. Certyfikat może potwierdzić udział w szkoleniu. Nie potwierdzi sam z siebie, że pracownik umie bezpiecznie użyć konkretnego systemu.
Wdrażasz AI w produkcie albo w firmie?
Pomagam firmom SaaS i software house’om korzystającym ze wsparcia prawnika IT uporządkować AI governance, role, instrukcje, dokumentację i umowy z dostawcami. Zakres można dopasować do rzeczywistych narzędzi i ryzyka, bez budowania niepotrzebnej biurokracji.