Jak zbudować program kompetencji AI zgodny z art. 4 AI Act

Co dokładnie mówi art. 4

Przepis jest krótki. Providerzy i deployerzy systemów AI muszą „podejmować środki w celu zapewnienia, w miarę możliwości, wystarczającego poziomu kompetencji AI wśród swojego personelu i innych osób zajmujących się obsługą i korzystaniem z systemów AI w ich imieniu". Środki te muszą uwzględniać wiedzę techniczną tych osób, doświadczenie, wykształcenie i szkolenia, kontekst, w jakim systemy są używane, oraz osoby lub grupy, wobec których systemy są stosowane.

Z tego brzmienia wynikają dwie rzeczy. Po pierwsze, to obowiązek best-effort, skalowany do ryzyka, a nie stały standard. Po drugie, dotyczy ludzi wokół AI, nie samej AI. Zadaniem jest uczynienie tych ludzi na tyle kompetentnymi, by rozsądnie korzystali z systemu i potrafili zauważyć, kiedy coś idzie nie tak.

Same „kompetencje AI" definiuje art. 3(56): umiejętności, wiedza i zrozumienie, które pozwalają providerom, deployerom i osobom dotkniętym skutkami działania AI, biorąc pod uwagę ich odpowiednie prawa i obowiązki, świadomie wdrażać systemy AI oraz zdawać sobie sprawę z możliwości, ryzyk i potencjalnych szkód związanych z AI. Motyw 20 rozwija tę definicję, zaznaczając, że istotne pojęcia różnią się w zależności od kontekstu i mogą obejmować sposób interpretowania wyniku działania systemu AI oraz, dla osób dotkniętych skutkami, sposób, w jaki decyzje wspierane przez AI na nie wpływają.

Kto liczy się jako provider albo deployer

Akt posługuje się czterema rolami operatorów, zdefiniowanymi w art. 3: provider, deployer, importer i dystrybutor. Dla art. 4 liczą się dwie: provider (budujesz system AI albo zlecasz jego zbudowanie i wprowadzasz na rynek pod własną nazwą) oraz deployer (używasz systemu AI pod własnym nadzorem w kontekście zawodowym). Większość organizacji korzystających z narzędzi AI to deployerzy. Jeśli dostrajasz lub istotnie modyfikujesz system albo podpisujesz go własną marką, art. 25 może zamienić cię w providera z cięższymi obowiązkami, które się z tym wiążą, co warto wiedzieć, zanim założysz, że jesteś wyłącznie deployerem.

Kogo muszą objąć szkolenia

Obowiązek obejmuje „personel i inne osoby zajmujące się obsługą i korzystaniem z systemów AI w ich imieniu". Q&A Komisji wprost wskazuje, że „inne osoby" to nie pracownicy, lecz ludzie w szerokim rozumieniu podlegający organizacji: podaje przykłady kontrahenta, dostawcy usług albo klienta. Praktyczny test to pytanie, czy ktoś obsługuje AI w imieniu organizacji, a nie czy jest na liście płac.

To, czy klienci lub osoby dotknięte skutkami działania AI potrzebują kompetencji, zależy od ryzyka. Komisja zaznacza, że w zależności od konkretnego ryzyka warto rozszerzyć kompetencje AI na klientów, odwołując się do wzmianki w art. 3(56) i motywie 20 o osobach dotkniętych skutkami. Dla wewnętrznego narzędzia niskiego ryzyka nie jest to oczekiwane. Przy zastosowaniach wyższego ryzyka staje się bardziej istotne.

Co „wystarczające" znaczy w praktyce

Komisja celowo zapowiedziała, że „nie narzuci ścisłych wymogów" co do tego, co znaczy „wystarczające", ponieważ kompetencje AI to szeroki temat, a technologia zmienia się szybko. Ta elastyczność jest realna, ale Q&A i tak ustala minimalną analizę, którą każdy provider i deployer powinien umieć wykazać. Jako minimum powinieneś:

• Zapewnić ogólne zrozumienie AI w całej organizacji. Czym jest AI, jak działa w prostych słowach, jaka AI jest tu faktycznie używana i jakie są jej możliwości oraz zagrożenia.
• Mieć jasność co do swojej roli. Czy budujesz systemy AI, czy tylko używasz systemów zbudowanych przez innych. To decyduje, jakie dalsze obowiązki cię dotyczą.
• Ocenić ryzyko systemów, które dostarczasz albo wdrażasz. Co muszą wiedzieć osoby korzystające z danego systemu, jakich ryzyk muszą być świadome i czy muszą wiedzieć, jak te ryzyka ograniczać.
• Oprzeć działania z zakresu kompetencji AI na tej analizie. Uwzględnić różnice w wiedzy technicznej, doświadczeniu, wykształceniu i szkoleniach wśród ludzi oraz kontekst i cel, w jakim systemy są używane.

To z założenia podejście oparte na ryzyku. Jeśli twoje systemy są wysokiego ryzyka w rozumieniu rozdziału III, Komisja wskazuje, że mogą być potrzebne dodatkowe środki, tak by personel rozumiał, jak sobie z nimi radzić i jak unikać lub ograniczać ich ryzyka. Recepcjonistka, która okazjonalnie korzysta z chatbota, i osoba obsługująca system wspierający decyzje wysokiego ryzyka nie potrzebują tego samego szkolenia, i Akt wcale nie udaje, że potrzebują.

Komisja jasno stwierdza też, że samo wskazanie personelowi instrukcji obsługi narzędzia jest w wielu przypadkach niewystarczające. Art. 4 ma dostarczać szkolenia i wskazówki dopasowane do każdej grupy, co współgra z art. 26, który zobowiązuje deployerów systemów wysokiego ryzyka do zapewnienia, że personel je obsługujący jest kompetentny i przeszkolony w zakresie nadzoru ludzkiego.

Jak zbudować program

Komisja nie narzuca formatu i nie ma domniemania zgodności wynikającego z kopiowania jednego szablonu. Sprawdza się niewielka liczba świadomych kroków, które odzwierciedlają logikę samego Q&A.

1. Zinwentaryzuj używaną AI

Nie da się zaplanować szkolenia dla narzędzi, których nie skatalogowałeś. Zbierz listę systemów AI, z których ludzie faktycznie korzystają, w tym tych konsumenckich, które pojawiły się bez przechodzenia przez zakupy. Dla każdego zanotuj, do czego służy, jakie dane do niego trafiają, i przybliżony poziom ryzyka. Ta inwentaryzacja pełni podwójną rolę: jest wsadem do programu kompetencji AI i fundamentem dla reszty pracy nad AI Act.

2. Sklasyfikuj swoją rolę dla każdego systemu

Dla każdego systemu zdecyduj, czy jesteś deployerem czy, po ewentualnym dostrojeniu lub przebrandowaniu, providerem. To determinuje, jak głębokie muszą być szkolenia i które inne artykuły wchodzą w grę.

3. Pogrupuj ludzi według tego, co muszą wiedzieć

Większość organizacji kończy z niewielką liczbą grup odbiorców. Powszechna i obronna struktura to trzy poziomy:

• Wszyscy · Czego potrzebują: Czym jest AI, gdzie organizacja jej używa, podstawowe ryzyka takie jak halucynacje i wyciek danych, zasady dopuszczalnego użycia i gdzie zadawać pytania · Typowa głębokość: Krótkie, ogólne, cykliczne
• Intensywni lub operacyjni użytkownicy · Czego potrzebują: Konkretne narzędzia, z których korzystają, ograniczenia i tryby awarii tych narzędzi, kiedy nie ufać wynikowi, i ścieżka eskalacji · Typowa głębokość: Dopasowane do roli, praktyczne
• Role nadzorcze i techniczne · Czego potrzebują: Dla systemów wysokiego ryzyka obowiązki nadzoru ludzkiego z art. 26: kompetencja do interwencji, tendencyjność automatyzacji, warunki uchylania wyniku · Typowa głębokość: Głębsze, powiązane z konkretnym systemem

To odzwierciedla własne podejście Komisji, która definiuje pakiety szkoleniowe dla generalistów, menedżerów i specjalistów.

4. Dopasuj głębokość do ryzyka i istniejącej wiedzy

Zróżnicowane poziomy są wyraźnie dopuszczone. Komisja potwierdza, że osoby z wykształceniem lub doświadczeniem w tworzeniu AI mogą zwykle być traktowane jako kompetentne bez dalszych działań, ale tylko jeśli wiedzą to, co muszą wiedzieć o konkretnych systemach i ryzykach organizacji, w tym o aspektach prawnych i etycznych. Istniejąca ekspertyza to przewaga na start, nie automatyczne zwolnienie z obowiązku.

5. Obejmij ryzyka, które faktycznie dają się we znaki

Dla szerokiej populacji najbardziej wartościowa treść to zwykle codzienne tryby awarii. Q&A Komisji podaje bezpośredni przykład: firma, której personel używa ogólnego asystenta takiego jak ChatGPT do pisania lub tłumaczenia tekstu, wciąż musi przestrzegać art. 4, a personel powinien być poinformowany o konkretnych ryzykach, takich jak halucynacje. Dla większości deployerów szkolenie z halucynacji, poufności i wycieku danych, higieny promptów oraz tego, kiedy nie polegać na wyniku, pokrywa to, co się liczy.

6. Odświeżaj program

Komisja wielokrotnie przedstawia kompetencje AI jako ruchomy cel, bo technologia się rozwija. Jednorazowa sesja w 2025 roku to nie program. Wbuduj w niego cykliczność i aktualizuj treść, gdy wdrażasz istotnie nowe narzędzia lub przypadki użycia.

Co warto zachować jako dowód

Nie ma wymogu certyfikatu. Q&A Komisji wprost mówi: organizacje nie potrzebują certyfikatu i mogą prowadzić wewnętrzną ewidencję szkoleń i innych działań edukacyjnych. Nie ma też obowiązku mierzenia wiedzy pracowników ani narzuconej struktury zarządzania, wymaganego oficera AI, ani narzuconej rady ds. zarządzania AI, by spełnić konkretnie art. 4.

To, co warto mieć w dokumentacji, to obronny ślad pokazujący najlepsze starania:

• Inwentaryzację AI oraz ocenę ryzyka i roli stojącą za projektem szkoleń.
• Same materiały szkoleniowe, według grup odbiorców.
• Zapisy tego, kto co ukończył i kiedy, wraz z cyklem odświeżania.
• Politykę dopuszczalnego użycia i wszelkie wskazówki wydane razem ze szkoleniem.

Powód, dla którego warto to trzymać, jest praktyczny. Egzekwowanie jest proporcjonalne i, jak zaznacza Komisja, sankcja jest bardziej prawdopodobna tam, gdzie istnieje dowód incydentu spowodowanego brakiem odpowiedniego szkolenia. Jasna dokumentacja to twój dowód, że podjąłeś rozsądne środki, zanim cokolwiek poszło źle.

Egzekwowanie i zmiana wynikająca z Digital Omnibus

Art. 4 obowiązuje od 2 lutego 2025 roku, więc obowiązek już działa. Nadzór i egzekwowanie leżą po stronie krajowych organów nadzoru rynku, nie AI Office, a Q&A Komisji stwierdza, że organy te zaczynają nadzorować i egzekwować przepisy od 2 sierpnia 2026 roku. Kary będą przebiegać przez prawo krajowe, które państwa członkowskie miały przyjąć, a każda sankcja musi być proporcjonalna do charakteru i wagi naruszenia oraz tego, czy było ono umyślne czy wynikało z zaniedbania.

Nadchodzi zmiana. W pakiecie Digital Omnibus, przedstawionym 19 listopada 2025 roku, Komisja zaproponowała zmianę art. 4 tak, by obowiązek promowania kompetencji AI i podnoszenia kwalifikacji przeniósł się na państwa członkowskie i Komisję, zamiast pozostawać otwartym obowiązkiem każdej organizacji. Omnibus został przyjęty przez Parlament 16 czerwca 2026 roku i przez Radę 29 czerwca 2026 roku, i wejdzie w życie po publikacji w Dzienniku Urzędowym, wciąż oczekującej na lipiec 2026 roku, więc obecny obowiązek z art. 4 nadal obowiązuje i trzeba go uwzględnić w planach. Komisja jasno zaznaczyła też, że niezależnie od zmiany w art. 4, obowiązek deployerów systemów AI wysokiego ryzyka zapewnienia, że ich personel jest przeszkolony do nadzoru ludzkiego zgodnie z art. 26, pozostaje w mocy. Pragmatyczny wniosek jest taki, że solidny, oparty na ryzyku program kompetencji AI pozostaje właściwym rozwiązaniem niezależnie od tego, jak się to rozstrzygnie.

Źródła

• Article 4: AI literacy, tekst unijnego AI Act i data wejścia w życie (artificialintelligenceact.eu): https://artificialintelligenceact.eu/article/4/ (przepis oraz data wejścia w życie 2 lutego 2025 roku na mocy art. 113(a))
• AI Literacy, Questions & Answers, Komisja Europejska, Shaping Europe's digital future (ostatnia aktualizacja 19 listopada 2025 roku): https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers (definicja, minimum „wystarczającego poziomu", zakres „innych osób", stanowisko w sprawie dowodów i certyfikatów, harmonogram egzekwowania oraz propozycja Digital Omnibus)
• Article 26: Obligations of Deployers of High-Risk AI Systems, unijny AI Act (artificialintelligenceact.eu): https://artificialintelligenceact.eu/article/26/ (obowiązek kompetencji i szkolenia w zakresie nadzoru ludzkiego dla deployerów systemów wysokiego ryzyka)
• Article 3: Definitions, unijny AI Act (artificialintelligenceact.eu): https://artificialintelligenceact.eu/article/3/ (provider, deployer i definicja kompetencji AI z art. 3(56))

Ten przewodnik łączy się z naszymi materiałami o unijnym AI Act jako całości, o budowaniu polityki dopuszczalnego użycia AI oraz o zdobywaniu widoczności użycia AI w całej organizacji, czyli inwentaryzacji, od której zależy każdy program kompetencji AI.