Specyfikacja jednego rejestru wszystkich agentów AI działających w organizacji: kim jest agent, kto go nadzoruje (owner), do jakich narzędzi/uprawnień ma dostęp, jaki jest jego wyliczony risk score i jaki poziom nadzoru człowieka jest wymagany. Bez takiego rejestru nie da się odpowiedzieć na pytanie audytora „ile macie agentów AI i co każdy z nich może zrobić" — a to pytanie zadaje dziś każdy poważny regulator i partner bankowy.
Rejestr agentów AI jest odpowiednikiem CMDB (Configuration Management Database) dla ludzkich kont i systemów — tylko dla bytów agentowych. Dla każdego agenta zapisujemy: kto go stworzył i kto odpowiada (owner), na jakim modelu działa, do czego ma dostęp (tools/permissions), jak wysokie jest ryzyko (risk score) i jaki poziom nadzoru człowieka obowiązuje. To fundament pod playbooki incydentów AI (prompt injection, agent hijack) i pod Legal Trigger Engine.
Minimalny zestaw pól, jaki musi mieć każdy wpis w rejestrze, żeby odpowiedzieć na pytania audytu bez szukania w kodzie. Wszystkie pola: status ROADMAP (schemat danych, tabela nie istnieje jeszcze w bazie produkcyjnej ipIII).
| Pole | Opis | Przykład |
|---|---|---|
agent_id | Unikalny identyfikator agenta (docelowo DID lub UUID stabilny w czasie). | agent:ip3-legal-trigger-01 |
nazwa / rola | Funkcjonalna nazwa i opis zakresu działania w jednym zdaniu. | „Legal Trigger Drafter — szkicuje powiadomienia do organów" |
owner | Osoba lub zespół odpowiedzialny za agenta; kontakt do eskalacji. | zespół Legal Engine, kontakt wewnętrzny |
model bazowy | Dostawca modelu, wersja/snapshot, tryb (API/self-hosted). | model komercyjny, wersja przypięta w konfiguracji |
tools / permissions | Lista narzędzi i uprawnień: role RBAC, zakres API (read/write/execute), dostęp do danych. | read:incidents, write:draft, brak execute:send |
risk_score | Wynik 0–100 wyliczony ze wzoru niżej; mapowany na priorytet przeglądu. | 62/100 → P1 |
human_oversight | Wymagany poziom nadzoru człowieka (patrz tabela poniżej). | L1 — zatwierdzenie przed wysyłką |
status | Aktywny / zawieszony / w kwarantannie / wycofany. | aktywny |
ostatni_przeglad | Data ostatniej weryfikacji uprawnień i risk score. | data ostatniego review |
Wynik ryzyka agenta to iloczyn wagowy czterech wymiarów, nie pojedyncza liczba „z powietrza". Status: ROADMAP — kalkulator nie jest jeszcze zaimplementowany, poniżej opisana jest logika docelowa.
read-only (niskie) → write (średnie) → execute na systemach krytycznych / środkach (wysokie).
human-in-the-loop na każdą akcję (niskie) → human-on-the-loop z monitoringiem (średnie) → w pełni autonomiczny bez bramki (wysokie).
dane publiczne/syntetyczne (niskie) → dane wewnętrzne (średnie) → dane osobowe/finansowe/klienckie (wysokie).
brak zgłoszeń (niskie) → near-miss odnotowany (średnie) → potwierdzony incydent klasy AI (wysokie), patrz playbooki G/H/I.
Suma ważona czterech wymiarów mapowana jest na priorytet przeglądu: P0 agent z uprawnieniami wykonawczymi na systemach krytycznych i historią incydentu — przegląd natychmiastowy; P1 agent z uprawnieniem zapisu i dostępem do danych wrażliwych — przegląd okresowy skrócony; P2/P3 agenci read-only o niskiej autonomii — przegląd standardowy. To wsparcie decyzji dla właściciela agenta, nie automatyczna decyzja o odcięciu dostępu.
| Poziom | Opis | Kiedy wymagany |
|---|---|---|
| L1 — human-in-the-loop | Człowiek zatwierdza każdą pojedynczą akcję agenta przed jej wykonaniem. | Uprawnienia execute na systemach krytycznych lub środkach; wysyłka do organów/klientów. |
| L2 — human-on-the-loop | Agent działa samodzielnie w zdefiniowanych granicach, człowiek monitoruje i ma kill switch. | Uprawnienia write na danych średniej wrażliwości, niska historia incydentów. |
| L3 — human-out-of-loop + audyt post-hoc | Agent działa autonomicznie, przegląd działań odbywa się po fakcie na próbce/logu. | Wyłącznie read-only, dane publiczne/syntetyczne, brak historii incydentów. |
execute na systemie krytycznym lub z dostępem do środków finansowych nie może mieć poziomu niższego niż L1. Brak wyjątków w specyfikacji — każdy wyjątek wymaga jawnej zgody ownera i wpisu w rejestrze z uzasadnieniem.Rejestr agentów jest punktem wyjścia do triage'u incydentu: jeśli wiemy, który agent, z jakimi uprawnieniami i jakim risk score wziął udział w zdarzeniu, klasyfikacja incydentu jest szybsza i ma dowód, nie zgadywanie.
Wstrzyknięcie instrukcji do modelu/agenta (direct lub indirect przez RAG/dokumenty). → Playbook G
Przejęcie agenta, podszycie pod agenta (fałszywy DID), działanie poza rolą, drift roju. → Playbook H
Agent wywołuje narzędzie poza zadeklarowanym zakresem tools/permissions z rejestru — sygnał do natychmiastowego przeglądu wpisu.
Agent bez odpowiedniego poziomu nadzoru (L2/L3 zamiast wymaganego L1) wykonuje akcję z danymi wrażliwymi. → Playbook E
Agent wykonuje akcję na podstawie nieprawdziwego wyniku modelu (zmyślony fakt, nieistniejący rekord). → Playbook I
Specyfikacja pól i metodyki risk score jako dev-doc — to, co widzisz na tej stronie, jest gotowe jako dokument.
Trwały rekord per agent w PostgreSQL, z historią zmian uprawnień i risk score. Nie zaimplementowane.
Endpointy do rejestracji agenta, aktualizacji uprawnień, odczytu risk score. Nie zaimplementowane.
Automatyczne wyliczenie wyniku z czterech wymiarów opisanych wyżej. Dziś: metodyka opisowa, bez silnika.
Szkielet kontroli scope/RoE istnieje jako komponent pokrewny (PoC). → AI Red-Team — to nie jest jeszcze integracja z rejestrem agentów.
Powiadomienie ownera i eskalacja do kwarantanny po przekroczeniu progu P0/P1. Nie zaimplementowane.
Powiązane: metodyka testowania AI i szkielet RoE → /ai-redteam · playbooki incydentów AI → /playbook-prompt-injection, /playbook-agent-hijack · pełny rejestr znanych ograniczeń → /known-limitations · macierz statusów → /status-matrix.