AI Act w praktyce: obowiązki firm i programistów

Polecenia z tego poradnika zostały uruchomione 7 października 2026 w czystym systemie (Ubuntu 24.04.5 LTS, Node.js 24.21.0, Python 3.12.3). Wyniki pod poleceniami pochodzą z tego uruchomienia.

AI Act wymaga od firmy ustalenia, jaką rolę pełni wobec AI, do czego używa systemu i które przepisy mają zastosowanie. Już stosuje się zakazy określonych praktyk oraz obowiązki przejrzystości, natomiast terminy dla systemów wysokiego ryzyka zostały przesunięte, co pokazuje aktualny harmonogram Komisji Europejskiej. Dlatego zalecam zacząć od spisu zastosowań, sprawdzenia ryzyka i przypisania odpowiedzialności. Firma korzystająca z gotowego narzędzia i firma sprzedająca własny system mogą mieć różne obowiązki.

Stan przepisów sprawdziłem 7 października 2026 r. Poniżej oddzielam wymagania prawne od proponowanych przeze mnie działań technicznych.

W skrócie

• Najpierw ustal rolę firmy i przeznaczenie każdego systemu.
• Korzystaj z harmonogramu uwzględniającego zmiany AI Omnibus.
• Sprawdź zakazy, przejrzystość i kwalifikację wysokiego ryzyka osobno.
• Zalecam powiązać dokumentację z wersjami aplikacji, testami i właścicielem procesu.
• Przy danych osobowych sprawdź również RODO, którego stosowanie zachowuje art. 2 ust. 7.

AI Act: co obowiązuje i od kiedy?

AI Act to rozporządzenie UE 2024/1689 dotyczące sztucznej inteligencji. Nie ma jednej daty rozpoczęcia stosowania wszystkich obowiązków. Dla planowania projektu proponuję poniższe zestawienie oparte na harmonogramie AI Act Service Desk.

AI Omnibus wszedł w życie 27 lipca 2026 r., przesuwając terminy dotyczące wysokiego ryzyka. W planie prac zalecam więc osobno zapisać obowiązki bieżące i przygotowania do kolejnych terminów.

Istnieją także szczególne okresy przejściowe. Według art. 111 dostawcy modeli ogólnego przeznaczenia wprowadzonych na rynek przed 2 sierpnia 2025 r. mają termin do 2 sierpnia 2027 r. Ten sam artykuł przewiduje termin 2 grudnia 2026 r. na dostosowanie do art. 50 ust. 2 systemów generujących treści syntetyczne, które wprowadzono na rynek przed 2 sierpnia 2026 r.

Kto odpowiada: firma, integrator czy programista?

Dostawca i podmiot stosujący

Dostawcą w rozumieniu art. 3 jest podmiot, który rozwija system lub model albo zleca jego rozwój i wprowadza go na rynek lub oddaje system do użytku pod własną nazwą bądź znakiem towarowym. Definicja obejmuje również udostępnienie bezpłatne.

Podmiot stosujący, nazywany też „deployerem”, używa systemu pod swoją kontrolą, poza osobistą działalnością pozazawodową. To również definicja z art. 3. W projekcie zalecam zapisać te role przy konkretnych podmiotach, zamiast posługiwać się wyłącznie etykietami „klient” i „wykonawca”.

Pracownik działający według instrukcji i pod kontrolą firmy nie powinien być traktowany jako odrębny podmiot stosujący, co wyjaśniają wytyczne Komisji dotyczące przejrzystości. Z tych definicji wynika, że samo pisanie kodu nie rozstrzyga roli prawnej programisty.

Kiedy integracja zmienia odpowiedzialność

Art. 25 wskazuje sytuacje przejęcia obowiązków dostawcy systemu wysokiego ryzyka: oznaczenie istniejącego systemu własną marką, istotną modyfikację systemu nadal pozostającego wysokiego ryzyka albo zmianę przeznaczenia powodującą taką kwalifikację. Przy oznaczeniu marką przepis uwzględnia ustalenia umowne dotyczące podziału obowiązków.

Przed rozszerzeniem asystenta dokumentowego o ocenianie kandydatów zalecam ponownie sprawdzić klasyfikację i role. W umowie z integratorem proponuję wskazać, kto zatwierdza przeznaczenie, dostarcza dokumentację i obsługuje zmiany.

Jak rozpoznać ryzyko zastosowania?

Zalecam oceniać cały proces: dane wejściowe, wynik modelu i działanie podejmowane na jego podstawie. Nazwa „asystent” jest za mało precyzyjna do takiej oceny.

Najpierw sprawdź praktyki zakazane

Art. 5 zakazuje m.in. określonych szkodliwych praktyk manipulacyjnych, nieukierunkowanego zbierania zdjęć twarzy do baz rozpoznawania twarzy oraz wnioskowania o emocjach w miejscu pracy i instytucjach edukacyjnych. Przy tym ostatnim zakazie przewiduje wyjątek dla zastosowań medycznych lub związanych z bezpieczeństwem.

Przykład do zatrzymania na etapie projektu: ocena emocji pracowników podczas rozmów jako wskaźnik ich zaangażowania. Zalecam sprawdzić ją bezpośrednio względem zakazu, zanim zespół zacznie dobierać model i zbierać dane.

Następnie sprawdź wysokie ryzyko

Załącznik III obejmuje m.in. analizowanie i filtrowanie aplikacji rekrutacyjnych, ocenianie kandydatów oraz ocenę zdolności kredytowej osób fizycznych, z wyjątkiem wykrywania oszustw finansowych. Zawiera też określone zastosowania w edukacji, biometrii i usługach publicznych.

Druga ścieżka dotyczy produktów. Art. 6 ust. 1 wymaga łącznie związku systemu z produktem objętym załącznikiem I oraz obowiązku oceny zgodności tego produktu przez stronę trzecią. Samo umieszczenie AI w urządzeniu nie wystarcza do tej kwalifikacji.

Dla zastosowań z załącznika III art. 6 ust. 3 dopuszcza wyjątki przy braku znaczącego ryzyka szkody i spełnieniu wskazanych warunków, np. wykonywaniu wąskiego zadania proceduralnego. System objęty tym załącznikiem, który profiluje osoby fizyczne, zawsze uznaje się jednak za wysokiego ryzyka.

Zalecam dokumentować uzasadnienie kwalifikacji na konkretnym przykładzie: „narzędzie porządkuje pliki” albo „narzędzie szereguje kandydatów według przewidywanej przydatności”. Przeznaczenie zapisz również w wymaganiach i materiałach sprzedażowych.

Chatboty i generowane treści: przejrzystość

Informacja przy pierwszej interakcji

Art. 50 ust. 1 i 5 wymaga od dostawcy zaprojektowania systemu bezpośrednio rozmawiającego z ludźmi tak, by informował o interakcji z AI, chyba że jest to oczywiste w opisanym przez przepis kontekście. Informacja ma być jasna, rozróżnialna i dostępna najpóźniej przy pierwszej interakcji.

Proponuję prosty komunikat nad polem rozmowy: „Rozmawiasz z asystentem AI. Sprawdź odpowiedź przed podjęciem decyzji”. Druga część jest moim zaleceniem dotyczącym używania narzędzia.

Oznaczenie techniczne i informacja dla odbiorcy

Art. 50 ust. 2 nakłada na dostawców systemów generujących syntetyczny tekst, obraz, dźwięk lub wideo obowiązek zapewnienia oznaczeń odczytywalnych maszynowo i wykrywalności pochodzenia treści. Przewiduje ograniczenia techniczne oraz wyjątki, m.in. dla pomocniczej funkcji standardowej edycji.

Osobno art. 50 ust. 4 zobowiązuje podmioty stosujące do ujawniania sztucznego pochodzenia deepfake’ów. Dotyczy też tekstów publikowanych dla informowania społeczeństwa o sprawach interesu publicznego; wyjątek obejmuje ludzką weryfikację lub kontrolę redakcyjną połączoną z odpowiedzialnością redakcyjną osoby fizycznej lub prawnej.

Zalecam osobno testować komunikat w interfejsie, zachowanie oznaczeń przy eksporcie i zasady publikacji. Wymaganie techniczne przekaż dostawcy z opisem formatu, w którym aplikacja odbiera i udostępnia wynik.

Co przygotować dla systemu wysokiego ryzyka?

Poniższe obowiązki trzeba odczytywać wraz z właściwym terminem stosowania i przepisami przejściowymi. Zalecam przygotowywać projekt przed tym terminem, szczególnie gdy wymaga zmian w danych lub architekturze.

Obowiązki dostawcy

Art. 16 wymaga m.in. systemu zarządzania jakością, przechowywania dokumentacji, właściwej oceny zgodności przed wprowadzeniem na rynek lub oddaniem do użytku, deklaracji zgodności UE, oznakowania CE oraz wykonania odpowiednich obowiązków rejestracyjnych. Obejmuje też działania naprawcze i wykazywanie zgodności na żądanie organu.

Wymagania dla takich systemów obejmują również zarządzanie ryzykiem, jakość danych, rejestrowanie działania, dokumentację, informacje dla podmiotu stosującego i nadzór człowieka, zgodnie z zestawieniem Komisji.

W przygotowaniach proponuję połączyć wymagania z dowodami:

• ograniczenia zastosowania z instrukcją dla użytkownika;
• ryzyka z testami i decyzjami o zabezpieczeniach;
• wersję aplikacji z konfiguracją modelu i wynikami oceny;
• zgłoszenia błędów z odpowiedzialnością za poprawki.

Art. 15 wymaga odpowiedniej dokładności, odporności i cyberbezpieczeństwa systemów wysokiego ryzyka przez cały cykl życia. Nakazuje też deklarowanie poziomów dokładności i odpowiednich metryk w instrukcji. Zalecam dobierać metryki do zadania, np. badać błędne odrzucenia w procesie kwalifikacji, zamiast raportować jeden ogólny wynik modelu.

Obowiązki firmy stosującej

Art. 26 wymaga używania systemu zgodnie z instrukcją, powierzenia nadzoru osobom z odpowiednimi kompetencjami, szkoleniem i uprawnieniami oraz monitorowania działania. Gdy firma kontroluje dane wejściowe, musi zapewnić ich odpowiedniość i dostateczną reprezentatywność względem przeznaczenia.

Ten sam art. 26 przewiduje przechowywanie automatycznych logów pozostających pod kontrolą podmiotu stosującego przez okres odpowiedni do przeznaczenia, co najmniej sześć miesięcy, chyba że właściwe przepisy stanowią inaczej. Pracodawca ma także uprzednio informować przedstawicieli pracowników i pracowników objętych użyciem systemu wysokiego ryzyka.

Art. 26 ust. 5 określa także obowiązki informowania dostawcy lub dystrybutora i organu nadzoru oraz zawieszenia używania, gdy podmiot stosujący ma podstawy uznać, że użycie zgodne z instrukcją może powodować ryzyko wskazane w art. 79 ust. 1. Zalecam przygotować ścieżkę eskalacji z osobą uprawnioną do zatrzymania systemu.

Dla wskazanych podmiotów, m.in. podmiotów prawa publicznego i określonych zastosowań kredytowych oraz ubezpieczeniowych, art. 27 przewiduje ocenę wpływu na prawa podstawowe. Zalecam ustalić jej zakres osobno od oceny ochrony danych.

Modele ogólnego przeznaczenia i open source

Model ogólnego przeznaczenia może służyć wielu zadaniom. Przy ocenie obowiązków zalecam oddzielić model od aplikacji. FAQ Komisji o modelach GPAI wyjaśnia, że udostępnienie pracownikom licencji na istniejący model nie czyni pracodawcy dostawcą tego modelu. Integrator może natomiast podlegać przepisom dotyczącym własnego systemu.

Obowiązki dostawców modeli obejmują dokumentację, informacje dla dostawców systemów korzystających z modelu, politykę zgodności z prawem autorskim i publiczne podsumowanie treści treningowych, zgodnie z wyjaśnieniami Komisji do art. 53. Dla modeli z ryzykiem systemowym art. 55 dodaje m.in. ewaluację, ograniczanie ryzyk, raportowanie poważnych incydentów i ochronę cyberbezpieczeństwa.

Open source wymaga odrębnego sprawdzenia. Art. 2 ust. 12 wyłącza określone systemy na wolnych i otwartych licencjach, ale zachowuje wyjątki dla wysokiego ryzyka oraz art. 5 i 50. Dla modeli GPAI Komisja opisuje warunkowe zwolnienia z części obowiązków, które nie znoszą obowiązków polityki prawa autorskiego i podsumowania danych treningowych.

Dane, RAG i nadzór nad agentem

Art. 2 ust. 7 zachowuje stosowanie prawa ochrony danych osobowych. Zalecam więc osobno sprawdzić podstawę przetwarzania, odbiorców danych, retencję i dostęp do dokumentów. Przy asystencie firmowym proponuję test: użytkownik bez dostępu do dokumentu nie powinien otrzymać jego treści w odpowiedzi ani w logach.

Przy projektowaniu RAG na firmowych dokumentach zalecam uwzględnić uprawnienia w kryteriach odbioru. W logach proponuję przechowywać informacje potrzebne do odtworzenia zdarzenia, z ograniczeniem kopiowania treści poufnych.

Dla wysokiego ryzyka art. 14 wymaga skutecznego nadzoru człowieka, obejmującego odpowiednio możliwość interpretacji, odrzucenia lub odwrócenia wyniku oraz przerwania działania. W projekcie agenta AI proponuję zatwierdzanie operacji zapisujących dane i osobny mechanizm zatrzymania. Zakres kontroli dobierz do skutków konkretnej operacji.

Jak uporządkować wdrożenie krok po kroku?

Proponuję własny proces organizacyjny. Każdy krok powinien zakończyć się zapisem, który kolejna osoba może sprawdzić.

1. Spisz zastosowania. Uwzględnij zakupy działów, własne integracje i narzędzia programistyczne. Przy każdym wskaż właściciela procesu.
2. Opisz przeznaczenie. Zapisz użytkowników, dane, wynik i decyzję podejmowaną na jego podstawie. Oddziel wyszukiwanie informacji od oceniania ludzi.
3. Przypisz role i przepisy. Sprawdź zakazy, wysokie ryzyko, przejrzystość i ewentualne obowiązki dostawcy modelu. Dodaj uzasadnienie i termin.
4. Zbierz informacje od dostawcy. Poproś o ograniczenia, instrukcję, dokumentację i zasady obsługi zmian. Zapisz brakujące odpowiedzi jako zadania.
5. Przetestuj zabezpieczenia. Proponuję sprawdzić dostęp do danych, błędne odpowiedzi, komunikaty o AI, zatrzymanie działania i obsługę zgłoszenia.
6. Ustal odbiór i ponowną ocenę. Wyznacz osobę zatwierdzającą oraz sytuacje wymagające przeglądu, np. zmianę przeznaczenia lub uprawnień.

Tak proponuję ułożyć przepływ decyzji:

flowchart TD
    A[Spis zastosowań] --> B[Przeznaczenie i role]
    B --> C{Praktyka zakazana?}
    C -->|Tak| D[Wstrzymaj projekt]
    C -->|Nie| E[Ryzyko i przejrzystość]
    E --> F[Dokumentacja i testy]
    F --> G[Odbiór i monitoring]
    G --> B

Jako początek rejestru proponuję poniższy plik. Utwórz plik docs/ai/systemy.json:

{
  "systemy": [
    {
      "id": "asystent-dokumentow",
      "wlasciciel_procesu": "do wyznaczenia",
      "przeznaczenie": "Wyszukiwanie informacji w dokumentach",
      "rola_firmy": "do oceny",
      "klasyfikacja": "do oceny",
      "uzasadnienie": "",
      "dane": ["dokumenty dostępne użytkownikowi"],
      "dzialania": ["odczyt"],
      "ograniczenia": ["bez oceniania osób"],
      "informacja_o_ai": "Rozmawiasz z asystentem AI.",
      "dowody": [],
      "warunki_ponownej_oceny": [
        "zmiana przeznaczenia",
        "dodanie operacji zapisu"
      ]
    }
  ]
}

Plik powinien pokazać zakres zastosowania oraz miejsca wymagające decyzji. To mój szablon roboczy; przed odbiorem zalecam uzupełnić role, uzasadnienie i dowody, a następnie powiązać wpis z wersją aplikacji.

Kompetencje zespołu: czego uczyć?

Zmieniony art. 4 wymaga działań wspierających rozwój kompetencji AI pracowników i innych osób obsługujących systemy w imieniu firmy. Nakazuje uwzględniać ich wiedzę, doświadczenie i kontekst zastosowania; nie wymaga gwarantowania konkretnego poziomu kompetencji każdej osoby.

Proponuję warsztat na rzeczywistym zadaniu: rozpoznanie błędnej odpowiedzi, sprawdzenie źródła, decyzja o dopuszczalnych danych i zgłoszenie problemu. Dla zespołu programującego z AI dodałbym przegląd uprawnień narzędzia oraz zasady zatwierdzania zmian. Zapisz materiały, uczestników i ustalone reguły.

FAQ

Czy AI Act dotyczy małej firmy?

Tak, zakres art. 2 obejmuje m.in. dostawców i podmioty stosujące w UE, bez ogólnego wyłączenia małych firm. Zalecam dobierać działania do roli i zastosowania, zaczynając od krótkiego rejestru.

Czy korzystanie z gotowego modelu czyni firmę jego dostawcą?

Samo udostępnienie pracownikom licencji na istniejący model nie czyni jej dostawcą modelu, zgodnie z FAQ Komisji. Przy własnej aplikacji zalecam osobno ocenić rolę wobec systemu.

Czy każdy tekst napisany z AI trzeba oznaczać?

Art. 50 ust. 4 wskazuje tekst publikowany dla informowania społeczeństwa o sprawach interesu publicznego oraz przewiduje opisany wyżej wyjątek redakcyjny. Techniczne oznaczanie wyników przez dostawcę to odrębny obowiązek.

Czy wszystkie systemy wysokiego ryzyka trzeba już dostosować?

Aktualny harmonogram wskazuje 2 grudnia 2027 r. dla załącznika III i 2 sierpnia 2028 r. dla właściwych systemów produktowych. Art. 111 określa dodatkowo zasady dla wcześniej wprowadzonych systemów. Zalecam sprawdzać datę konkretnego wdrożenia.

Jakie kary przewiduje AI Act?

Art. 99 przewiduje za naruszenie zakazów maksymalnie 35 mln euro lub 7% światowego rocznego obrotu przedsiębiorstwa z poprzedniego roku finansowego, a za wskazane inne naruszenia, w tym przejrzystości, 15 mln euro lub 3%. Zasadniczo stosuje się wyższy limit; dla MŚP przepis przewiduje niższy. Konkretna kara zależy od okoliczności naruszenia.

Co dalej

Zalecam przejść do przewodnika po integracji AI z systemami firmy i dopisać do planowanej integracji właściciela, przepływ danych oraz warunki odbioru opisane tutaj. Jeśli potrzebujesz pomocy przy połączeniu AI z firmowymi narzędziami, możesz skontaktować się ze mną.