Teza
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.
Uwaga
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:
1. **Używasz AI do wytwarzania** (agenci w pipeline). Tu zwykle nie budujesz systemu wysokiego ryzyka — kluczowe są ład, nadzór i audytowalność *procesu*.
2. **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](/katalog/gitsign)), jawne pochodzenie zmian |
| Zarządzanie ryzykiem | klasyfikacja ryzyka + policy-as-code jako bramka ([OPA](/katalog/open-policy-agent), [Gatekeeper](/katalog/gatekeeper)) |
| Jakość/ład danych | sekrety i dostęp (Security Plane), warstwy semantyczne nad danymi |
| Testy i monitorowanie | walidacja-pętla + ewaluacja/red-teaming ([promptfoo](/katalog/promptfoo)), runtime ([Falco](/katalog/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](/blog/cztery-poziomy-agentowego-wytwarzania) 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:
```rego
# 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](/blog/suwerenne-ai-open-weight): 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](/blog/dora-w-praktyce-platformy), 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.