AI Act dla firm tworzących oprogramowanie z agentami

AI Act (rozporządzenie (UE) 2024/1689) dotyczy firmy, która tylko używa agentów do kodowania, takich jak Claude Code, Codex czy Cursor, głównie przez jeden obowiązek: art. 4 o kompetencjach w zakresie AI, złagodzony, ale nie uchylony przez Digital Omnibus (rozporządzenie (UE) 2026/1744). Obowiązki dotyczące modeli ogólnego przeznaczenia ciążą na dostawcach. Sytuacja zmienia się, gdy produkt sam zawiera system AI.

Przychodzi ankieta zakupowa od klienta z nowym wierszem: „Opisz zgodność z AI Act”. Twoi inżynierowie otwierają większość pull requestów przez agentów, zarząd przeczytał, że Omnibus „odroczył AI Act”, a handlowiec chce do piątku odpowiedzieć „pełna zgodność”. Nikt przy stole nie umie powiedzieć, które artykuły dotyczą was, które Anthropic lub OpenAI, a które tylko wtedy, gdy produkt ma funkcję AI.

Ta strona jest dla CTO, który musi udzielić tej odpowiedzi, i dla członka zarządu, który ma ją podpisać. To inżynierska lektura rozporządzenia, a nie porada prawna: zanim się na niej oprzesz, potwierdź swoją sytuację z prawnikiem.

Co ta strona daje CTO przygotowującemu się do AI Act

Tabelę ról twojej firmy i dostawców oraz oś czasu z datami: co przesunął Digital Omnibus.
Tabelę decyzyjną dla produktu: które funkcje zmieniają obowiązki i od kiedy.
Rejestr kompetencji AI, rejestr systemów AI, test CI blokujący niezarejestrowaną funkcję AI i dwa prompty inwentaryzacyjne.
Typowe błędy w zespołach pracujących z agentami i pięć pytań, które członek zarządu może zadać CTO.

Jakie role z AI Act pełni firma używająca agentów do kodowania?

AI Act przypisuje obowiązki według ról, a nie technologii. Dla firmy programistycznej liczą się cztery role. Definicje są w art. 3 rozporządzenia.

Rola	Definicja w skrócie	Kto ją pełni przy Claude Code, Codex i Cursorze
Podmiot stosujący (deployer)	Wykorzystuje system AI, nad którym sprawuje kontrolę, w działalności zawodowej	Ty, dla każdego agenta, którego inżynierowie używają w pracy
Dostawca systemu AI	Rozwija system AI i wprowadza go do obrotu lub oddaje do użytku pod własną nazwą	Anthropic (Claude Code), OpenAI (Codex), Anysphere (Cursor). Ty, dla każdego systemu AI, który zbudujesz, także wyłącznie na użytek wewnętrzny
Dostawca modelu AI ogólnego przeznaczenia (GPAI)	Rozwija model ogólnego przeznaczenia i wprowadza go do obrotu	Dostawcy modeli: Anthropic dla modeli Claude, OpenAI dla modeli GPT oraz dostawca każdego innego wybranego modelu
Dostawca niższego szczebla (downstream provider)	Włącza model GPAI do własnego systemu AI	Ty, gdy budujesz funkcję produktu lub wewnętrznego agenta na API modelu, np. Claude API, Claude Agent SDK lub Codex SDK

Zespoły najczęściej przeoczają drugi wiersz. Podpięcie Claude API do wewnętrznego bota do code review albo zbudowanie chatbota wsparcia na GPT czyni cię dostawcą tego systemu AI. Użycie Claude Code do napisania zwykłej aplikacji webowej tego nie robi: aplikacja nie jest systemem AI.

Co dotyczy cię dziś, jeśli tylko używasz agentów do kodowania?

Dla firmy, w której agenci piszą, testują i przeglądają kod, a dostarczany produkt nie ma funkcji AI, lista jest krótka.

Przepis	Czy cię dotyczy?	Od kiedy	Czego wymaga
Art. 4, kompetencje w zakresie AI	Tak, jako podmiotu stosującego	2 lutego 2025 r.; zmieniony przez Omnibus od 27 lipca 2026 r.	Działań na rzecz kompetencji w zakresie AI personelu, który obsługuje lub wykorzystuje systemy AI. Omnibus złagodził art. 4 (źródła wtórne: Gibson Dunn, aiactblog.nl, 2026), ale nadal wymaga on działań na rzecz kompetencji personelu. Zanim zacytujesz zmienione brzmienie, przeczytaj je w EUR-Lex
Art. 5, praktyki zakazane	Tylko jeśli którąś przekroczysz	2 lutego 2025 r.	Istotne tutaj: żadnego systemu AI rozpoznającego emocje pracowników w miejscu pracy, poza względami medycznymi lub bezpieczeństwa. Nie buduj narzędzi do „nastrojów programistów” z głosu, obrazu czy uderzeń w klawiaturę
Art. 50, przejrzystość po stronie podmiotu stosującego	Rzadko	2 sierpnia 2026 r.	Dotyczy rozpoznawania emocji, kategoryzacji biometrycznej, deepfake’ów i tekstów generowanych przez AI publikowanych w celu informowania opinii publicznej o sprawach leżących w interesie publicznym. Kod źródłowy nie jest żadnym z nich
Art. 26, obowiązki podmiotu stosującego system wysokiego ryzyka	Nie, dla agentów do kodowania	systemy z załącznika III od 2 grudnia 2027 r.	Agent do kodowania nie jest zastosowaniem z załącznika III. Wyjątek to ocenianie inżynierów systemem AI, opisane w błędach
Art. 53 i 55, obowiązki GPAI	Nie, wiążą dostawców modeli	2 sierpnia 2025 r.; egzekwowanie przez Komisję od 2 sierpnia 2026 r.	Dokumentacja techniczna, informacje dla dostawców niższego szczebla, polityka praw autorskich, streszczenie danych treningowych oraz obowiązki ryzyka systemowego dla największych modeli

Wynikają z tego dwie rzeczy. Po pierwsze, na gruncie AI Act kod napisany przez agenta nie podlega obowiązkowi oznaczania. Możesz nadal oznaczać zmiany agentów dla routingu code review i audytu, jak w pochodzeniu zmian i routingu ryzyka, ale to decyzja inżynierska. Po drugie, zgodność dostawcy z obowiązkami GPAI nie wypełnia twojego obowiązku z art. 4. Każda rola ma własne obowiązki.

Co zmienił Digital Omnibus, a czego nie?

Omnibus nie odroczył AI Act jako całości. Przesunął terminy dla systemów wysokiego ryzyka, złagodził art. 4 i zostawił resztę harmonogramu bez zmian.

Data	Co obowiązuje	Zmienione przez Omnibus?
2 lutego 2025 r.	Praktyki zakazane (art. 5) i kompetencje w zakresie AI (art. 4)	Art. 4 złagodzony, ale nie uchylony
2 sierpnia 2025 r.	Obowiązki dostawców GPAI; system kar	Nie
27 lipca 2026 r.	Wejście w życie rozporządzenia (UE) 2026/1744	Tak: dodaje zakaz systemów AI generujących intymne obrazy bez zgody lub materiały przedstawiające seksualne wykorzystywanie dzieci (źródła wtórne). W lutym 2025 r. tego zakazu nie było; datę jego stosowania sprawdź w tekście Omnibusa w EUR-Lex
2 sierpnia 2026 r.	Uprawnienia Komisji do egzekwowania wobec dostawców GPAI, w tym kary do 3% światowego obrotu lub 15 mln euro; obowiązki przejrzystości z art. 50	Nie
2 grudnia 2026 r.	Oznaczanie w formacie nadającym się do odczytu maszynowego z art. 50 ust. 2 dla systemów generatywnych wprowadzonych do obrotu przed 2 sierpnia 2026 r.	Tak: okres przejściowy dla systemów już na rynku
2 sierpnia 2027 r.	Modele GPAI wprowadzone do obrotu przed 2 sierpnia 2025 r. muszą spełniać wymogi	Nie
2 grudnia 2027 r.	Obowiązki dla systemów wysokiego ryzyka z załącznika III (zatrudnienie, zdolność kredytowa, edukacja, usługi podstawowe i inne)	Tak: przesunięte z 2 sierpnia 2026 r.
2 sierpnia 2028 r.	Obowiązki dla AI w produktach objętych prawodawstwem sektorowym z załącznika I (wyroby medyczne, maszyny i inne)	Tak: przesunięte z 2 sierpnia 2027 r.

Dla firmy, która tylko używa agentów do kodowania, Omnibus zmienił jedną istotną rzecz: złagodził art. 4. To nadal obowiązek podejmowania działań na rzecz kompetencji i obowiązuje od lutego 2025 r.

Kiedy budowany produkt zmienia sytuację?

Twoje obowiązki rosną wraz z tym, co dostarczasz, a nie z tym, ile z tego napisali agenci. Używaj tej tabeli na przeglądzie produktowym przy każdej funkcji, która dotyka modelu.

Dostarczasz lub uruchamiasz…	Twoja rola	Co obowiązuje	Od kiedy
Zwykłe oprogramowanie pisane z agentami, bez funkcji AI	Podmiot stosujący agentów do kodowania	Tylko art. 4. Samo oprogramowanie podlega innym przepisom UE: zob. CRA, NIS2 i DORA-EU	Teraz
Wewnętrzny agent na API modelu (bot do code review, agent do triażu, agent do runbooków)	Dostawca i podmiot stosujący tego systemu	Art. 4. Ujawnienie z art. 50 ust. 1 nie jest potrzebne, gdy dla rozsądnie poinformowanej osoby jest oczywiste, że rozmawia z AI; mimo to oznacz bota	Teraz
Chatbot lub asystent rozmawiający z klientami	Dostawca	Art. 50 ust. 1: zaprojektuj go tak, by ludzie wiedzieli, że wchodzą w interakcję z systemem AI	2 sierpnia 2026 r.
Funkcja generująca tekst, obrazy, dźwięk lub wideo	Dostawca	Art. 50 ust. 2: oznaczaj wyniki w formacie nadającym się do odczytu maszynowego, wykrywalne jako sztucznie wygenerowane	2 sierpnia 2026 r.; 2 grudnia 2026 r. dla systemów już na rynku
Funkcja AI w obszarze z załącznika III: rekrutacja i zarządzanie pracownikami, zdolność kredytowa, ocena w edukacji, dostęp do usług podstawowych	Dostawca systemu wysokiego ryzyka	Zarządzanie ryzykiem, zarządzanie danymi, dokumentacja techniczna, rejestrowanie zdarzeń, nadzór człowieka, dokładność i solidność, ocena zgodności, rejestracja	2 grudnia 2027 r.
AI w produkcie objętym prawodawstwem sektorowym z załącznika I, np. w wyrobie medycznym	Dostawca	Obowiązki wysokiego ryzyka w ramach sektorowej procedury oceny zgodności	2 sierpnia 2028 r.
Model, który trenujesz lub modyfikujesz powyżej progu mocy obliczeniowej	Dostawca GPAI	Art. 53 i 55	Już obowiązują
Funkcje AI budowane dla klienta, który sprzedaje je pod własną nazwą	Zwykle dostawcą jest klient; umowa musi to mówić	Jak wyżej, dla strony będącej dostawcą	Dla każdej funkcji

Ostatni wiersz jest ważny dla software house’ów: dostawcą systemu jest ten, kto wprowadza go do obrotu pod własną nazwą, więc umowa wdrożeniowa musi wskazać dostawcę dla każdego systemu AI i przypisać prace związane z art. 50 i dokumentacją. Zob. dostarczanie AI-native w software house’ach i agencjach.

Gdzie w łańcuchu dostawców leży każdy agent do kodowania?

Twoje obowiązki z AI Act są takie same niezależnie od narzędzia. Różni się to, kto jest dostawcą wyżej w łańcuchu, a więc od kogo żądasz dokumentacji. Zapisuj, który model działał, bo dostawca modelu jest dostawcą GPAI.

Anthropic dostarcza zarówno system AI (Claude Code), jak i modele GPAI, na których działa. Domyślny model to Claude Opus 5.5 na kanale wydań latest; aktualne ustawienia domyślne znajdziesz w przeglądzie modeli. Routing przez Amazon Bedrock lub Agent Platform w Google Cloud (dawniej Vertex AI) zmienia stronę umowy i warunki przetwarzania danych, ale nie dostawcę modelu.

Aby przebiegi w CI dało się audytować, przypnij model i zachowaj wynik JSON jako dowód:

# Zadanie CI: przekaż diff na wejście (claude -p startuje w trybie Manual, v2.1.283),
# więc zadanie nie zależy od uprawnień narzędzi; przypnij model i zachowaj wynik JSON jako dowód
mkdir -p evidence
git diff origin/main...HEAD | claude -p --model claude-opus-5-5 --output-format json \
  "Review this diff against docs/ai-register.yaml and list any new AI system" \
  > evidence/claude-review.json

OpenAI dostarcza zarówno system AI (Codex), jak i modele GPAI. GPT-6 Astra to model domyślny w codex-cli 0.157.1; zob. przegląd modeli.

Aby przebiegi w CI dało się audytować, przypnij model i zachowaj strumień zdarzeń JSONL:

# Zadanie CI: przekaż diff na wejście, przypnij model i zachowaj strumień zdarzeń jako dowód
mkdir -p evidence
git diff origin/main...HEAD | codex exec -m gpt-6-astra --json \
  "Review this diff against docs/ai-register.yaml and list any new AI system" \
  > evidence/codex-review.jsonl

Anysphere dostarcza system AI (Cursor). Dostawcą GPAI jest dostawca modelu, który wybiera programista, więc może się on zmieniać między sesjami. W rejestrze zapisz Cursora raz jako system AI, a każdy model dopuszczony polityką zespołu, wraz z jego dostawcą, jako osobnego dostawcę wyżej w łańcuchu; zanim któryś wymienisz, sprawdź przegląd modeli.

Aby przebiegi bez interfejsu dało się audytować, uruchamiaj CLI Cursora w trybie print (-p), zapisz z jego wyniku, który model pracował, i zachowaj ten wynik jako dowód; zob. CI/CD z Cursor CLI.

Jeśli budujesz na API modelu, a nie tylko używasz agenta, art. 53 ust. 1 lit. b zobowiązuje dostawcę GPAI do przekazania dostawcom niższego szczebla informacji potrzebnych do zrozumienia możliwości i ograniczeń modelu. Poproś o nie w procesie zakupowym i dołącz je do wpisu w rejestrze.

Jak spełnić obowiązek kompetencji w zakresie AI i mieć na to dowód?

Art. 4 wymaga działań dopasowanych do ludzi, systemów i ryzyka. Jeden slajd na spotkaniu firmowym to działanie, ale nie dowód, że ktokolwiek obsługujący agenta wie, co ten może zepsuć. Dowodem jest rejestr prowadzony według ról.

Wypisz, kto obsługuje lub wykorzystuje systemy AI. Każdy z licencją na Claude Code, Codex lub Cursora, każdy, kto zatwierdza pull requesty agentów, i każdy, kto konfiguruje agentów, hooki, skills lub serwery MCP.
Określ, co każda rola musi rozumieć. Programiści: prompt injection, sekrety, zmyślone zależności i weryfikacja wyników. Recenzenci i tech leadzi: co bramki dowodzą, a czego nie. Product managerowie: które funkcje są systemami AI w rozumieniu rozporządzenia. Zarząd: tabela ról i oś czasu z tej strony.
Wybierz działanie dla każdej roli. Sesje onboardingowe, zestaw kat, sesje review-to-learn, lektury z krótkim sprawdzianem. Program rozwoju kompetencji służy jednocześnie jako ten rejestr.
Zapisz ukończenie z datą i linkiem do materiału. Przechowuj rejestr tam, gdzie HR lub dział compliance przeczyta go bez pytania inżynierów.
Powtarzaj przy zmianie systemów. Nowy agent, nowy poziom autonomii lub nowa rodzina modeli to wyzwalacz. Wyzwalaczem jest też wpis starszy niż 12 miesięcy.

Przyjmij ten format rejestru bez zmian. To YAML, więc agent może go wygenerować i sprawdzić:

- person: "j.kowalski"
  role: developer
  systems: [claude-code, codex]
  autonomy: "tier 1: reversible local changes"
  measures:
    - name: "Agent onboarding: injection, secrets, dependency checks"
      date: 2026-09-12
      material: "https://wiki.example.com/agents/onboarding"
    - name: "Review-to-learn session: verifying agent PRs"
      date: 2026-09-19
      material: "https://wiki.example.com/agents/review-to-learn"
  next_review: 2027-09-12
  owner: "head-of-engineering"

Metryka, która dowodzi spełnienia obowiązku: pokrycie kompetencjami, czyli odsetek osób z aktywną licencją na agenta lub uprawnieniem do zatwierdzania zmian agentów, które mają wpis z działaniem z ostatnich 12 miesięcy. Cel to 100%; raportuj co kwartał i traktuj lukę jako problem z dostępem: nie ma wpisu, nie ma licencji.

Rejestruj każdy system AI, którego jesteś dostawcą

Rejestr odpowiada na ankietę klienta, zasila rejestr kompetencji i mówi ci, kiedy funkcja wchodzi w zakres art. 50 lub załącznika III. Prowadź jeden wpis na system AI, także dla wewnętrznych agentów:

- id: support-assistant
  owner: "team-support-platform"
  our_role: provider            # provider (dostawca) | deployer (podmiot stosujący) | downstream-provider
  purpose: "Answers customer questions in the help widget"
  users: external               # internal (wewnętrzni) | external (zewnętrzni)
  upstream_models:
    - vendor: Anthropic
      model: claude-opus-5-5
  art50: ["50(1) disclosure in widget header"]
  annex_iii: none               # albo numer punktu, np. "4(b)"
  personal_data: true           # wymaga też wpisu w rejestrze czynności przetwarzania (RODO)
  reviewed: 2026-09-26
  reviewer: "cto"

Następnie zatrzymaj niezarejestrowaną funkcję AI na etapie pull requesta. Ten krok CI kończy się błędem, gdy zmiana dodaje SDK modelu, ale nie zmienia rejestru. Diff z trzema kropkami wymaga bazy scalania, więc pobierz pełną historię (actions/checkout z fetch-depth: 0 w GitHub Actions); to samo dotyczy przykładów z git diff origin/main...HEAD powyżej:

# Krok CI (GitHub Actions lub dowolny runner), uruchamiany na pull requestach.
# Brak gałęzi bazowej lub bazy scalania to błąd, a nie zielony wynik.
set -euo pipefail
BASE_BRANCH="${GITHUB_BASE_REF:-main}"   # GitHub Actions ustawia tę zmienną na pull requestach
git fetch --no-tags origin "$BASE_BRANCH"
BASE="origin/$BASE_BRANCH"
git rev-parse --verify "$BASE" >/dev/null || { echo "base ref missing"; exit 1; }
# Najpierw zapisz diff: bez bazy scalania git diff zwraca błąd, a set -e zatrzymuje zadanie.
# Manifesty na dowolnej głębokości, więc pakiet w monorepo lub katalog usługi też są objęte.
DIFF=$(git diff "$BASE"...HEAD -- ':(glob)**/package.json' ':(glob)**/pyproject.toml' \
  ':(glob)**/requirements*.txt' ':(glob)**/go.mod')
if printf '%s\n' "$DIFF" | grep -iE '^\+.*(anthropic|openai|claude-agent-sdk|codex-sdk|cursor[-/_]?sdk|google[-/]genai|generative-?ai|langchain|llama[-_]?index|@ai-sdk/|"ai"[[:space:]]*:|mistral|cohere|ollama)'; then
  git diff --name-only "$BASE"...HEAD | grep -qx 'docs/ai-register.yaml' || {
    echo "A model SDK was added. Add or update the entry in docs/ai-register.yaml."; exit 1; }
fi

Wzorzec jest celowo szeroki. Fałszywy alarm kosztuje jeden przegląd rejestru; przeoczony chatbot kosztuje ustalenie naruszenia art. 50. Sprawdza jednak tylko manifesty zależności: model wywoływany bezpośrednio przez HTTP albo przez klienta skopiowanego do repozytorium go nie uruchomi. Do tego służy prompt inwentaryzacyjny poniżej.

Prompty do skopiowania: mapa ekspozycji na AI Act

Uruchom je w Claude Code, Codex lub Cursorze z katalogu głównego repozytorium. We wszystkich narzędziach działają tak samo.

Inventory every place this repository calls a language model or other AI
system at runtime (not the coding agents used to write it). Search
dependency manifests and imports for model SDKs (Anthropic, OpenAI, Claude
Agent SDK, Codex SDK, Cursor SDK, Google GenAI, LangChain, LlamaIndex) and
for HTTP calls to model APIs.

For each one, report: file and function, what the feature does, who sees
its output (internal staff or external users), whether it talks to people,
whether it generates text, images, audio or video that leaves the system,
and whether it makes or supports decisions about hiring, worker performance,
credit, education or access to essential services.

Output a YAML list in the format of docs/ai-register.yaml. Mark every field
you are unsure about as "UNSURE" with the evidence you found. Do not guess
a legal classification; flag it for review instead.

Read our onboarding and agent documentation (docs/, CONTRIBUTING.md,
CLAUDE.md, AGENTS.md and any .cursor/rules files). Draft
docs/compliance/ai-literacy-record.yaml entries for four roles: developer,
reviewer or tech lead, product manager, and executive.

For each role, list which existing documents already teach: prompt
injection, secrets handling, hallucinated or typosquatted dependencies,
what our CI gates prove and do not prove, and which of our features are AI
systems. List each topic no document covers as a GAP with a one-line
proposal for the smallest measure that would cover it. Do not invent
completion dates; leave date fields empty.

Traktuj oba wyniki jako szkice. Inwentaryzacja to wynik wyszukiwania, który potwierdza wskazany z nazwiska inżynier, a klasyfikacja to decyzja, którą CTO podpisuje razem z prawnikiem.

Jak udowodnić, że stanowisko wobec AI Act jest nadal aktualne?

Cztery mechanizmy utrzymują stanowisko w mocy mimo kolejnych zmergowanych funkcji, bez czytania każdego diffa:

Mechanizm	Czego dowodzi	Właściciel	Częstotliwość
Test CI rejestru (powyżej)	Żadne SDK modelu nie trafia do kodu bez rejestracji	Zespół platformowy	Każdy pull request
Przegląd rejestru	Pola roli, art. 50 i załącznika III każdego wpisu są nadal poprawne	CTO, z prawnikiem dla każdego `annex_iii` innego niż `none`	Co kwartał i przed każdym uruchomieniem funkcji AI
Pokrycie kompetencjami	Każdy operator agenta ma aktualny wpis	Szef inżynierii (head of engineering)	Co kwartał
Test akceptacyjny art. 50	Ujawnienie jest wyświetlane, a generowane media mają znacznik do odczytu maszynowego	Zespół funkcji	W testach end-to-end funkcji

Przegląd rejestru podpisuje CTO. Przy każdym wpisie z punktem załącznika III podpis wymaga też prawnika oraz planu na obowiązki od 2 grudnia 2027 r.

Co psuje zgodność z AI Act w zespołach pracujących z agentami?

Odczytanie Omnibusa jako „AI Act jest odroczony”. Przesunięto tylko terminy dla systemów wysokiego ryzyka. Art. 4 i art. 5 obowiązują od lutego 2025 r., a art. 50 od sierpnia 2026 r. Naprawa: umieść oś czasu w materiałach dla zarządu i sprostuj wewnętrzny komunikat na piśmie.

Ocenianie poszczególnych inżynierów systemem AI. Indywidualna ocena wydajności, ranking lub przydział zadań wyliczany przez model z telemetrii agentów to zastosowanie z pkt 4 lit. b załącznika III: monitorowanie i ocena wydajności oraz zachowania pracowników. Od 2 grudnia 2027 r. to system wysokiego ryzyka, a już dziś rodzi pytania o RODO i konsultacje z przedstawicielami pracowników. Zwykły dashboard liczący zmergowane pull requesty nie jest systemem AI; model, który ocenia ludzi, jest. Naprawa: mierz zespoły, nie osoby, korzystając z frameworków metryk, i usuń indywidualne ocenianie przez AI, zanim się rozprzestrzeni.

Zespół wypuszcza chatbota zbudowanego przez agenta. Agent dodaje SDK, pisze widżet i nikt nie pyta, czy użytkownicy wiedzą, że rozmawiają z AI. Naprawa: test CI rejestru plus test akceptacyjny art. 50, który nie przechodzi bez ujawnienia.

„Pełna zgodność” w ankiecie klienta albo „dostawca to załatwia”. Ogólna deklaracja zaprasza pytanie uzupełniające, na które nie odpowiesz, a zgodność dostawców z obowiązkami GPAI nie przejmuje twoich obowiązków podmiotu stosującego i dostawcy. Naprawa: odpowiadaj według ról, w podziale na „dostawca” i „my”. Do pierwszej części dołącz dokumentację dostawcy; w drugiej podaj swoją rolę przy każdym systemie, obowiązujące artykuły, podjęte działania i datę ostatniego przeglądu rejestru.

Pięć pytań, które członek zarządu może zadać CTO

Jaką rolę z AI Act pełnimy przy każdym systemie AI, którego używamy lub który dostarczamy, i gdzie to jest zapisane?
Jakie jest dziś pokrycie kompetencjami i co się dzieje z dostępem do agenta, gdy czyjś wpis wygaśnie?
Które z naszych funkcji rozmawiają z ludźmi lub generują media i jak testujemy ujawnienie z art. 50?
Czy cokolwiek, co budujemy lub czego używamy, ocenia, klasyfikuje lub przydziela pracę poszczególnym pracownikom za pomocą AI?
Kiedy prawnik ostatnio przeglądał rejestr i które wpisy czekają na termin 2 grudnia 2027 r. dla systemów wysokiego ryzyka?

Kto nadzoruje AI Act w Polsce?

Każde państwo członkowskie wyznacza własne organy nadzoru rynku. Polska wyznacza organ w ustawie wdrożeniowej; rządowy projekt przewidywał nową Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI). Zanim się na nią powołasz, sprawdź w ISAP, czy ustawa została uchwalona. Dostawców GPAI nadzoruje Urząd ds. AI Komisji Europejskiej, a nie organy krajowe.

Dokąd dalej z regulacjami UE i agentami

CRA, NIS2 i DORA-EU Przepisy UE dla oprogramowania, które piszą twoi agenci: zgłaszanie podatności, SBOM i odporność operacyjna.

Podnoszenie kompetencji zespołu w inżynierii agentowej Program, z którego powstaje rejestr kompetencji w zakresie AI.

Prawo i IP w kodzie pisanym przez agentów Własność, licencje i umowy, których AI Act nie rozstrzyga.

Polityka użycia AI, której inżynierowie będą przestrzegać Miejsce, w którym obowiązek kompetencji i rejestr stają się codziennymi zasadami.

Prywatność danych i polityki firmowe RODO i warunki przetwarzania danych w przepływach agentów.

Raportowanie inżynierii AI do zarządu Tabela ról i oś czasu w sekcji ryzyk materiałów dla zarządu.

Najczęstsze pytania

Czy korzystanie z Claude Code, Codex lub Cursora podlega AI Act?

Tak, jako podmiot stosujący, ale wąsko. Firmę, która tylko używa agentów do kodowania, dotyczy przede wszystkim art. 4 o kompetencjach w zakresie AI, który Digital Omnibus złagodził, ale nie uchylił: nadal trzeba podejmować działania na rzecz kompetencji personelu. Obowiązki dotyczące modeli AI ogólnego przeznaczenia spoczywają na dostawcach modeli.

Czy Digital Omnibus odroczył cały AI Act?

Nie. Rozporządzenie (UE) 2026/1744 przesunęło terminy dla systemów wysokiego ryzyka na 2 grudnia 2027 r. (załącznik III) i 2 sierpnia 2028 r. (załącznik I). Zakazy i kompetencje w zakresie AI obowiązują od 2 lutego 2025 r., a obowiązki przejrzystości z art. 50 od 2 sierpnia 2026 r.

Czy kod napisany przez agenta trzeba oznaczać jako wygenerowany przez AI?

Nie na gruncie AI Act. Art. 50 dotyczy rozmów z systemami AI, syntetycznych mediów, deepfake'ów i części publikowanych tekstów, a nie kodu źródłowego. Oznaczanie zmian agentów nadal warto stosować, ale z powodów inżynierskich: dla code review i audytu.

Kiedy budowany produkt zmienia nasze obowiązki?

Gdy sam produkt zawiera system AI. Chatbot lub generator treści wnosi obowiązki przejrzystości z art. 50; funkcja w obszarze z załącznika III, np. rekrutacja lub ocena zdolności kredytowej, wnosi obowiązki dostawcy systemu wysokiego ryzyka od 2 grudnia 2027 r.