W czterech poziomach pokazałem, że im wyżej w autonomii, tym ważniejszy staje się nadzór i ślad. To nie jest tylko dobra inżynieria — to dokładnie to, czego żąda AI Act. Wiem, „regulacja” brzmi jak hamulec. Ale pokażę Ci, że jej wymogi mapują się niemal jeden do jednego na deterministyczny szkielet platformy agentowej (ADP) — czyli na to, co i tak musisz zbudować.
AI Act nie jest przeszkodą dla agentów — jest specyfikacją tego, co i tak musi mieć dobra platforma agentowa: nadzór człowieka, logowanie, transparentność i zarządzanie ryzykiem. Im wyższy poziom autonomii, tym mocniejsze wymagane guardrails.
To analiza techniczna, nie porada prawna. Zakres obowiązków AI Act zależy od roli (dostawca, podmiot stosujący), klasy ryzyka i przeznaczenia systemu.
AI Act w pigułce: regulacja oparta na ryzyku
AI Act klasyfikuje systemy AI według ryzyka, a obowiązki rosną wraz z nim:
- Niedopuszczalne — praktyki zakazane (obowiązują od lutego 2025).
- Wysokie ryzyko — np. rekrutacja, scoring kredytowy, egzekwowanie prawa; pełen zestaw obowiązków (zarządzanie ryzykiem, nadzór człowieka, logi, dokumentacja, jakość danych).
- Ograniczone — obowiązki transparentności (użytkownik wie, że ma do czynienia z AI / treścią generowaną).
- Minimalne — większość zastosowań; bez dodatkowych wymogów.
Kalendarz (stan na 2026): obowiązki dla GPAI (modeli ogólnego przeznaczenia) są stosowane od 2 sierpnia 2025, a pełne uprawnienia egzekucyjne AI Office aktywują się 2 sierpnia 2026. Terminy dla systemów wysokiego ryzyka zostały przesunięte (w ramach „Digital Omnibus”, porozumienie z 7 maja 2026, w trakcie formalnego przyjęcia): Annex III (samodzielne) do 2 grudnia 2027, Annex I (wbudowane w produkty) do 2 sierpnia 2028. GPAI obecne na rynku przed 2 sierpnia 2025 mają czas na zgodność do 2 sierpnia 2027.
Dwa różne pytania
Mówiąc o „AI i regulacji”, łatwo pomieszać dwie sprawy:
- Używasz AI do wytwarzania (agenci w pipeline). Tu zwykle nie budujesz systemu wysokiego ryzyka — kluczowe są ład, nadzór i audytowalność procesu.
- Dostarczasz funkcje oparte na AI w produkcie. Tu może wejść reżim wysokiego ryzyka lub obowiązki transparentności wobec użytkowników.
Ten artykuł skupia się na (1) — agentowym SDLC — bo to tam AI Act spotyka się z architekturą platformy. Ale ta sama platforma pomaga też spełnić (2).
Mapowanie wymogów na ścieżki value streamu
Najciekawsze jest to, jak czysto wymogi AI Act odwzorowują się na elementy ADP opisane wcześniej:
| Wymóg AI Act | Element platformy agentowej |
|---|---|
| Nadzór człowieka (human oversight) | poziomy in/on/orchestrator — człowiek w/na pętli, auto-promocja tylko dla low-risk |
| Logowanie i rejestry (record-keeping) | obserwowalność + ślad audytowy, tożsamość nie-ludzka (kto/co zrobił) |
| Transparentność | provenance artefaktów — podpisy (gitsign), jawne pochodzenie zmian |
| Zarządzanie ryzykiem | klasyfikacja ryzyka + policy-as-code jako bramka (OPA, Gatekeeper) |
| Jakość/ład danych | sekrety i dostęp (Security Plane), warstwy semantyczne nad danymi |
| Testy i monitorowanie | walidacja-pętla + ewaluacja/red-teaming (promptfoo), runtime (Falco) |
Innymi słowy: deterministyczny szkielet, który i tak jest potrzebny, by agenci działali bezpiecznie, jest jednocześnie warstwą zgodności z AI Act.
Nadzór jako funkcja poziomu autonomii
Kluczowa intuicja: im mniej człowieka w pętli, tym mocniejsze muszą być automatyczne dowody i granice. AI Act wymaga „odpowiedniego nadzoru człowieka” — a poziomy z czterech poziomów dają temu konkretny kształt:
- na poziomie 1-2 nadzór jest wprost (człowiek akceptuje / weryfikuje zachowanie),
- na poziomie 3 przenosi się na reguły promocji — człowiek projektuje politykę, a nie ogląda każdą zmianę,
- przy autonomii (poziom 4) nadzór to granice i progi ryzyka plus pełny ślad, który pozwala odtworzyć każdą decyzję.
Klasyfikacja ryzyka zmiany staje się więc nie tylko mechanizmem przepustowości, ale i mechanizmem zgodności:
# tylko zmiany low-risk mogą iść bez człowieka; reszta wymaga nadzoru
package eiac.aiact
auto_promote if {
input.change.risk == "low"
input.validation.status == "green"
input.actor.type == "agent"
input.provenance.signed == true # podpisany artefakt (transparentność)
}Reguła łączy trzy wymogi naraz: zarządzanie ryzykiem (klasa), nadzór (co wolno bez człowieka) i transparentność (podpis). Wszystko jako kod, więc audytowalne.
GPAI, open-weight i transparentność
Jeśli używasz modeli, AI Act dokłada wątek transparentności i dokumentacji (zwłaszcza dla GPAI). Tu zazębia się to z Suwerennym AI: lokalna brama modelu daje naturalny punkt, w którym powstaje ślad zapytań i odpowiedzi, a wybór modelu open-weight ułatwia wykazanie lineage (co, na czym, z jakimi danymi). Suwerenność i zgodność z AI Act często prowadzą do tej samej decyzji architektonicznej.
Praktyka: zgodność jako właściwość platformy
Tak jak przy DORA, najmocniejszy wniosek jest ten sam: nie buduj „zgodności z AI Act” jako osobnego procesu obok platformy. Wbuduj ją w platformę — jako polityki, ślad, prowienancję i progi ryzyka, które i tak są potrzebne do bezpiecznej autonomii. Wtedy zgodność jest produktem ubocznym dobrze zaprojektowanego ADP, a nie dodatkowym obciążeniem.
Podsumowanie
AI Act i agentowy SDLC nie są w konflikcie — opisują tę samą rzecz z dwóch stron. Regulacja mówi „musi być nadzór, ślad, transparentność i zarządzanie ryzykiem”; dobra platforma agentowa mówi „bez tego autonomia jest niebezpieczna”. Deterministyczny szkielet ADP jest więc jednocześnie systemem bezpieczeństwa i warstwą zgodności. Im wcześniej go zbudujesz, tym mniej będzie bolał każdy kolejny termin z kalendarza AI Act. Potraktuj tę regulację nie jak biurokrację do odhaczenia, lecz jak listę kontrolną dobrej platformy agentowej — i tak ją odhaczysz przy okazji.