Wdrożenie agenta AI - łańcuch zdarzeń, RASCI i zależności systemowe

Wdrożenie agenta AI: 12 etapów, 13 ról, dziesiątki systemów

Modelowy przebieg wdrożenia agenta z dostępem do systemów wewnętrznych w podmiocie regulowanym. Przy każdym etapie: kto jest rozliczany - A (Accountable), kto wykonuje pracę - R (Responsible) - i od jakich systemów zależy praca.

Kontekst Podmiot regulowany (bank / zakład ubezpieczeń). Agent AI z dostępem do systemów wewnętrznych (np. obsługa klienta wykonująca działania w CRM i systemie centralnym przez API). Po co ten model Wdrożenie agenta AI, który nie tylko odpowiada na pytania, ale samodzielnie wykonuje działania w systemach organizacji, nie jest projektem informatycznym. Jest zmianą w sposobie, w jaki organizacja podejmuje decyzje, kto za nie odpowiada i jak dowodzi tej odpowiedzialności przed klientem, audytorem i nadzorcą. Model porządkuje tę zmianę w trzy warstwy: łańcuch zdarzeń, macierz RASCI i mapę zależności systemowych. Agent to praca wielu funkcji, a nie jednego zespołu - w modelu występuje trzynaście funkcji i żadna z nich nie ma „A” w więcej niż trzech etapach. Odpowiedzialność wędruje wraz z etapem - od biznesu przez AI Officera, ryzyko i CISO, po Komitet AI i z powrotem do biznesu. Agent jest tak bezpieczny, jak najsłabsze z jedenastu ogniw, od których zależy - i każde z nich ma innego właściciela. Łańcuch zdarzeń Inicjacja - czy i w jakim reżimie? - 1, 2 Projektowanie - co, na jakich danych, z kim? - 3, 4, 5, 6 Budowa - jak bezpiecznie? - 7, 8 Walidacja - czy wolno? - 9, 10 Eksploatacja - czy nadal działa? - 11, 12 1. Inicjatywa i rejestracja przypadku użycia Cel Zgłoszenie pomysłu na agenta, opis problemu biznesowego i wstępnego zakresu; wpis do centralnego rejestru inicjatyw AI. Przebieg Biznes zgłasza potrzebę (np. automatyzacja obsługi dyspozycji klienta). AI Governance Officer nadaje identyfikator i otwiera kartę inicjatywy. Wstępna kwalifikacja: czy to w ogóle agent (autonomia, narzędzia, działania w systemach)? Produkty Karta inicjatywy w rejestrze AI · Wstępny opis przypadku użycia i interesariuszy Systemy Rejestr inicjatyw AI / GRC Portal zgłoszeń / backlog RASCI A: Właściciel produktu R: - S: AI Governance Officer C: IT / Architektura, Dane / CDO, Operacje / HITL I: Zarząd / Komitet AI, Zespół AI / ML, IOD / DPO, Compliance, Ryzyko 2. Triage i klasyfikacja regulacyjna Cel Ustalenie reżimu prawnego i istotności: klasyfikacja wg AI Act (zakazane / wysokiego ryzyka / obowiązki przejrzystości), rola organizacji (deployer vs provider), materialność w rozumieniu ryzyka modeli, kwalifikacja usługi ICT wg DORA i outsourcingu. Przebieg Warsztat klasyfikacyjny: AI Officer + Compliance + Ryzyko + IOD + Prawny. Decyzja o ścieżce: uproszczona / standardowa / pełna (high-risk). Ustalenie listy wymaganych ocen (DPIA, FRIA, ocena ryzyka ICT, ocena outsourcingu). Produkty Karta klasyfikacji AI Act i uzasadnienie · Plan zgodności (lista wymaganych ocen i zgód) Systemy Rejestr AI / GRC Rejestr outsourcingu i usług ICT Rejestr czynności przetwarzania RASCI A: AI Governance Officer R: - S: Właściciel produktu C: IOD / DPO, Compliance, Ryzyko, Prawny / Zakupy I: Zarząd / Komitet AI, IT / Architektura, CISO / Bezpieczeństwo, Dane / CDO, Audyt wewn. 3. Projekt rozwiązania i granice autonomii Cel Zdefiniowanie, co agent może, a czego nie może: katalog narzędzi i działań, progi wymagające zatwierdzenia człowieka, zakres danych, KPI i kryteria sukcesu, tryb awaryjny. Przebieg Warsztaty projektowe: proces docelowy, punkty decyzyjne, mapa narzędzi (API), scenariusze nadużyć. Zapis granic autonomii (action policy): działania automatyczne vs. z zatwierdzeniem vs. zakazane. Decyzja architektoniczna (ADR): platforma agentowa, model, sposób integracji. Produkty Dokument koncepcji i action policy · Architektura logiczna i lista integracji · Definicja KPI / KRI Systemy Repozytorium architektury (ADR) Backlog projektu Katalog API / narzędzi RASCI A: Właściciel produktu R: IT / Architektura, Zespół AI / ML S: - C: AI Governance Officer, CISO / Bezpieczeństwo, Dane / CDO, IOD / DPO, Compliance, Ryzyko, Operacje / HITL I: Zarząd / Komitet AI 4. Oceny wpływu i ryzyka Cel Zidentyfikowanie i ocena ryzyk przed budową: DPIA (RODO), FRIA (AI Act, jeśli wymagana), ocena ryzyka modelu i ryzyka operacyjnego, ocena ryzyka ICT i koncentracji (DORA), ryzyko konsumenckie i reputacyjne. Przebieg Ryzyko prowadzi zintegrowaną ocenę; IOD prowadzi DPIA; AI Officer prowadzi FRIA. Określenie środków ograniczających i limitów (np. maks. wartość transakcji bez człowieka). Rejestracja ryzyk rezydualnych i właścicieli działań. Produkty DPIA / FRIA · Karta ryzyka agenta z limitami i KRI · Plan działań ograniczających Systemy System GRC / rejestr ryzyk Narzędzie DPIA Rejestr czynności przetwarzania RASCI A: Ryzyko R: AI Governance Officer, Właściciel produktu, IOD / DPO S: IT / Architektura, Zespół AI / ML, Dane / CDO C: CISO / Bezpieczeństwo, Compliance, Prawny / Zakupy, Operacje / HITL I: Zarząd / Komitet AI, Audyt wewn. 5. Dane i baza wiedzy Cel Zapewnienie, że agent korzysta wyłącznie z dopuszczonych, jakościowych i legalnych danych: mapowanie źródeł, podstawy prawne, klasyfikacja i maskowanie, jakość, retencja, przygotowanie bazy wiedzy (RAG). Przebieg Data stewardzi mapują źródła i nadają klasyfikację; IOD potwierdza podstawy prawne. Zespół AI buduje pipeline wiedzy (indeksowanie, wersjonowanie, kontrola dostępu na poziomie dokumentów). Prawny weryfikuje licencje treści i zasady korzystania z danych dostawcy. Produkty Karta danych agenta (data sheet) · Zasady dostępu i retencji · Zwalidowana baza wiedzy Systemy Hurtownia / data lake Katalog danych i DLP Baza wektorowa / RAG DMS / repozytorium wiedzy RASCI A: Dane / CDO R: Zespół AI / ML S: Właściciel produktu, IT / Architektura, Operacje / HITL C: CISO / Bezpieczeństwo, IOD / DPO, Prawny / Zakupy I: AI Governance Officer, Compliance, Ryzyko 6. Dostawca modelu i umowa Cel Wybór i ocena dostawcy modelu / platformy oraz zawarcie umowy zgodnej z wymogami sektorowymi: due diligence, klauzule DORA (art. 30), outsourcing, przetwarzanie danych, poufność promptów, IP, audyt, SLA, plan wyjścia. Przebieg Zakupy prowadzą RFP / ocenę; Bezpieczeństwo i Architektura oceniają dostawcę technicznie. Prawny negocjuje umowę i DPA; Ryzyko ocenia koncentrację i ryzyko podwykonawców. Wpis do rejestru umów ICT / outsourcingu; ewentualne zawiadomienie nadzorcy. Produkty Raport due diligence dostawcy · Umowa z klauzulami DORA / outsourcingowymi i DPA · Plan wyjścia (exit plan) Systemy System zakupowy / CLM Rejestr umów ICT (DORA) Rejestr dostawców i ocen ryzyka RASCI A: Prawny / Zakupy R: - S: Właściciel produktu C: Zarząd / Komitet AI, AI Governance Officer, IT / Architektura, CISO / Bezpieczeństwo, IOD / DPO, Compliance, Ryzyko I: Zespół AI / ML, Dane / CDO, Audyt wewn. 7. Architektura, tożsamość agenta i bezpieczeństwo Cel Wdrożenie zabezpieczeń technicznych: odrębna tożsamość agenta (non-human identity), minimalne uprawnienia do narzędzi, izolacja, zarządzanie sekretami, guardraile wejścia/wyjścia, pełne logowanie działań, mechanizm natychmiastowego wyłączenia. Przebieg Modelowanie zagrożeń (prompt injection, tool misuse, eksfiltracja) i wymagania bezpieczeństwa. Konfiguracja IAM/PAM, API gateway i polityk narzędzi; integracja logów z SIEM. Przegląd bezpieczeństwa architektury przed testami. Produkty Model zagrożeń i wymagania bezpieczeństwa · Skonfigurowana tożsamość i uprawnienia agenta · Architektura logowania i kill switch Systemy IAM / PAM (tożsamość agenta) API gateway i katalog narzędzi Vault sekretów SIEM / SOC Platforma agentowa / orkiestrator RASCI A: CISO / Bezpieczeństwo R: IT / Architektura, Zespół AI / ML S: Dane / CDO C: AI Governance Officer, Właściciel produktu, IOD / DPO, Ryzyko I: Compliance, Audyt wewn., Operacje / HITL 8. Budowa, testy i red teaming Cel Iteracyjna budowa agenta z ewaluacjami: testy jakości odpowiedzi i działań, testy regresji, testy bezpieczeństwa (red teaming), testy akceptacyjne z użytkownikami, testy procesu eskalacji do człowieka. Przebieg Zespół AI buduje i uruchamia zestawy ewaluacyjne (golden set, scenariusze brzegowe). Bezpieczeństwo prowadzi red teaming; Operacje - testy akceptacyjne; Compliance ocenia scenariusze regulacyjne. Zamrożenie wersji (model, prompty, narzędzia, baza wiedzy) do walidacji. Produkty Raport z ewaluacji i red teamingu · Protokół UAT · Zamrożona wersja kandydująca (release candidate) Systemy Platforma ewaluacji / test harness CI/CD i rejestr wersji Środowisko testowe z danymi syntetycznymi Narzędzia red team RASCI A: Właściciel produktu R: Zespół AI / ML, CISO / Bezpieczeństwo, Operacje / HITL S: IT / Architektura, Dane / CDO C: AI Governance Officer, Compliance, Ryzyko I: IOD / DPO 9. Niezależna walidacja i opinia zgodności Cel Weryfikacja przez drugą linię obrony przed decyzją o wdrożeniu: walidacja modelu/agenta (Ryzyko), opinia zgodności (Compliance), stanowisko IOD, ocena bezpieczeństwa (CISO), kompletność dokumentacji. Przebieg Ryzyko przeprowadza niezależną walidację (metodyka, dane, wyniki, limity). Compliance wydaje opinię zgodności z listą warunków; IOD potwierdza zamknięcie DPIA. AI Officer kompletuje dossier decyzyjne. Produkty Raport walidacji · Opinia zgodności z warunkami · Dossier decyzyjne dla Komitetu AI Systemy System GRC Repozytorium walidacji i dokumentacji (DMS) RASCI A: Ryzyko R: Compliance S: AI Governance Officer, Właściciel produktu, IT / Architektura, Zespół AI / ML, Dane / CDO C: CISO / Bezpieczeństwo, IOD / DPO, Prawny / Zakupy I: Zarząd / Komitet AI, Audyt wewn., Operacje / HITL 10. Decyzja o wdrożeniu i dokumentacja Cel Formalna decyzja Komitetu AI / Zarządu o dopuszczeniu agenta do produkcji wraz z warunkami; wpis do rejestru systemów AI; instrukcje użytkowania, komunikacja i szkolenia (AI literacy, art. 4 AI Act); informacja dla klientów (przejrzystość). Przebieg Komitet AI rozpatruje dossier i podejmuje decyzję (go / go z warunkami / no-go). AI Officer aktualizuje rejestr systemów AI i archiwizuje dokumentację techniczną. Szkolenia dla operatorów i nadzorujących; aktualizacja regulaminów i komunikatów dla klientów. Produkty Decyzja i warunki wdrożenia · Wpis w rejestrze systemów AI · Instrukcja użytkowania i materiały szkoleniowe Systemy Rejestr systemów AI DMS / dokumentacja techniczna Platforma szkoleń (LMS) Intranet / komunikacja RASCI A: Zarząd / Komitet AI R: AI Governance Officer, Właściciel produktu S: IT / Architektura, Zespół AI / ML, Dane / CDO C: CISO / Bezpieczeństwo, IOD / DPO, Compliance, Ryzyko, Prawny / Zakupy I: Audyt wewn., Operacje / HITL 11. Wdrożenie kontrolowane i monitoring Cel Stopniowe uruchomienie (pilot, ograniczona grupa, limity) z ciągłym monitoringiem: jakość i dryf, koszty, bezpieczeństwo, skargi, działania agenta w systemach, skuteczność nadzoru ludzkiego, zarządzanie incydentami (w tym poważnymi wg AI Act i DORA). Przebieg Uruchomienie za feature flag; zespół AI i IT monitorują metryki, SOC monitoruje anomalie. Operatorzy nadzorują i przejmują sprawy eskalowane; skargi trafiają do procesu reklamacyjnego. Incydenty klasyfikowane i raportowane (wewnętrznie, a gdy trzeba - do nadzorcy). Produkty Dashboard KPI / KRI · Raporty z pilotażu i decyzja o skalowaniu · Rejestr incydentów i działań naprawczych Systemy Systemy docelowe (CRM, system centralny, KYC) Obserwowalność / logi działań agenta SIEM / SOC ITSM - incydenty i zmiany Konsola nadzoru HITL Feature flags / kill switch RASCI A: Właściciel produktu R: IT / Architektura, Zespół AI / ML, CISO / Bezpieczeństwo, Operacje / HITL S: AI Governance Officer, Dane / CDO C: IOD / DPO, Compliance, Ryzyko I: Zarząd / Komitet AI, Prawny / Zakupy, Audyt wewn. 12. Przegląd okresowy, zmiany i wycofanie Cel Utrzymanie zgodności w czasie: przeglądy okresowe, ponowna ocena przy istotnej zmianie (nowy model, nowe narzędzia, nowy zakres), audyt wewnętrzny, aktualizacja rejestru, kontrolowane wycofanie agenta i archiwizacja logów. Przebieg Każda istotna zmiana wraca do etapu 2 (re-klasyfikacja) lub 4/9 (ponowna ocena i walidacja). Audyt wewnętrzny ocenia skuteczność kontroli; wnioski wracają do właścicieli. Wycofanie: odebranie uprawnień, wygaszenie integracji, retencja dokumentacji i logów. Produkty Raport z przeglądu okresowego · Rejestr zmian i ponownych ocen · Protokół wycofania Systemy System GRC / rejestr AI ITSM - change management Archiwum logów i dokumentacji RASCI A: AI Governance Officer R: Właściciel produktu, Audyt wewn. S: IT / Architektura, Zespół AI / ML, CISO / Bezpieczeństwo, Dane / CDO C: IOD / DPO, Compliance, Ryzyko, Prawny / Zakupy, Operacje / HITL I: Zarząd / Komitet AI Bramka 1 · etap 2 Klasyfikacja wyznacza ścieżkę: uproszczona, standardowa czy pełna (wysokie ryzyko). Bez niej nie wiadomo, jakie oceny są wymagane. Bramka 2 · etap 10 Decyzja Komitetu AI na podstawie dossier: walidacja + opinia zgodności + stanowisko IOD + ocena bezpieczeństwa. Bramka 3 · etap 12 Każda istotna zmiana wymaga ponownej oceny. Agent bez aktualnej oceny to agent bez zgody. Pętla zmian każda istotna zmiana (nowy model, nowe narzędzie, nowy zakres działań) cofa agenta do etapu 2 (re-klasyfikacja) i 9 (ponowna walidacja). Bez decyzji z etapu 10 nic nie trafia na produkcję. Role Zarząd i Komitet ds. AI (AI Governance Board) | Zarząd / Komitet AI | Nadaje apetyt na ryzyko, zatwierdza strategię AI i podejmuje decyzję o dopuszczeniu agenta do produkcji. Ostateczna odpowiedzialność za zgodność i ryzyko (fit & proper, odpowiedzialność zarządcza). AI Governance Officer / właściciel systemu zarządzania AI | AI Governance Officer | Prowadzi rejestr inicjatyw i systemów AI, klasyfikuje przypadki użycia (AI Act), koordynuje FRIA, kompletuje dossier decyzyjne i nadzoruje cykl życia po wdrożeniu. Właściciel produktu / sponsor biznesowy | Właściciel produktu | Definiuje cel, zakres i granice autonomii agenta, KPI oraz proces biznesowy. Odpowiada za wynik, budżet i za to, że agent działa zgodnie z przeznaczeniem (intended purpose). IT, architektura korporacyjna i platformy | IT / Architektura | Projektuje architekturę integracji (orkiestrator, API gateway, narzędzia), zapewnia środowiska, CI/CD, obserwowalność i zgodność ze standardami ICT. Zespół AI / ML (inżynieria agentów) | Zespół AI / ML | Buduje agenta: prompty systemowe, narzędzia (tools), RAG, guardraile, ewaluacje. Utrzymuje wersjonowanie modeli i pipeline'y, reaguje na incydenty jakościowe. CISO / bezpieczeństwo informacji i SOC | CISO / Bezpieczeństwo | Modeluje zagrożenia (prompt injection, eksfiltracja danych, nadużycie narzędzi), definiuje tożsamość i uprawnienia agenta (NHI, least privilege), prowadzi red teaming i monitoring SOC. Chief Data Officer / data stewardzi | Dane / CDO | Odpowiada za źródła danych i wiedzy: katalog, jakość, klasyfikację, linię pochodzenia, retencję i bazę wiedzy (RAG). Potwierdza, że agent korzysta wyłącznie z danych dopuszczonych. Inspektor Ochrony Danych | IOD / DPO | Opiniuje podstawy prawne i DPIA, minimalizację danych, art. 22 RODO (decyzje zautomatyzowane), retencję logów oraz informację dla klientów i pracowników. Compliance (w tym compliance AI Act i ochrona konsumenta) | Compliance | Mapuje wymogi regulacyjne (AI Act, RODO, DORA, NIS2 / UKSC, CRA, prawo konsumenckie), wydaje opinię zgodności przed wdrożeniem i monitoruje zgodność w eksploatacji. Zarządzanie ryzykiem (ryzyko operacyjne, ryzyko modeli, ryzyko ICT) | Ryzyko | Prowadzi ocenę ryzyka i niezależną walidację modelu/agenta, ustala limity i KRI, integruje agenta z ramami ryzyka operacyjnego i ICT (DORA). Departament prawny i zakupy / zarządzanie dostawcami | Prawny / Zakupy | Negocjuje umowy z dostawcą modelu i platformy (klauzule DORA, outsourcing, IP, odpowiedzialność, audyt, exit), ocenia licencje danych i regulaminy dla klientów. Audyt wewnętrzny (3. linia) | Audyt wewn. | Niezależnie ocenia skuteczność procesu wdrożenia i kontroli po wdrożeniu; nie uczestniczy w projektowaniu, ale jest informowany o kluczowych decyzjach. Operacje biznesowe i użytkownicy (human-in-the-loop) | Operacje / HITL | Dostarczają wiedzę domenową, testują akceptacyjnie, nadzorują działanie agenta (human oversight), przejmują sprawy eskalowane i zgłaszają anomalie oraz skargi. A - Accountable - rozliczany, jedna osoba/funkcja na etap R - Responsible - wykonuje pracę S - Support - wspiera zasobami/wiedzą C - Consulted - konsultowany, opinia obowiązkowa I - Informed - informowany o wyniku Zasada: dokładnie jedno „A” na etap. „AR” oznacza funkcję, która jest jednocześnie rozliczana i wykonuje pracę. Zarząd / Komitet AI jest rozliczany wyłącznie za decyzję o wdrożeniu (etap 10) - nie za wykonanie. Audyt wewnętrzny nie projektuje, tylko ocenia (etap 12). Kto za co odpowiada: macierz RASCI Trzynaście funkcji, dwanaście etapów, sporo do zrobienia. Odpowiedzialność krąży od biznesu (pomysł) przez AI Officera (koordynacja), ryzyko (ocena możliwości wdrożenia), aż do Komitetu AI (decyzja) i dalej do biznesu. Z uwzględnieniem silnej roli IT. Zarząd / Komitet AI | AI Governance Officer | Właściciel produktu | IT / Architektura | Zespół AI / ML | CISO / Bezpieczeństwo | Dane / CDO | IOD / DPO | Compliance | Ryzyko | Prawny / Zakupy | Audyt wewn. | Operacje / HITL 1. Inicjatywa i rejestracja przypadku użycia: I | S | AR | C | I | · | C | I | I | I | · | · | C 2. Triage i klasyfikacja regulacyjna: I | AR | S | I | · | I | I | C | C | C | C | I | · 3. Projekt rozwiązania i granice autonomii: I | C | A | R | R | C | C | C | C | C | · | · | C 4. Oceny wpływu i ryzyka: I | R | R | S | S | C | S | R | C | A | C | I | C 5. Dane i baza wiedzy: · | I | S | S | R | C | AR | C | I | I | C | · | S 6. Dostawca modelu i umowa: C | C | S | C | I | C | I | C | C | C | AR | I | · 7. Architektura, tożsamość agenta i bezpieczeństwo: · | C | C | R | R | A | S | C | I | C | · | I | I 8. Budowa, testy i red teaming: · | C | A | S | R | R | S | I | C | C | · | · | R 9. Niezależna walidacja i opinia zgodności: I | S | S | S | S | C | S | C | R | AR | C | I | I 10. Decyzja o wdrożeniu i dokumentacja: A | R | R | S | S | C | S | C | C | C | C | I | I 11. Wdrożenie kontrolowane i monitoring: I | S | A | R | R | R | S | C | C | C | I | I | R 12. Przegląd okresowy, zmiany i wycofanie: I | A | R | S | S | S | S | C | C | C | C | R | C Łącznie: A · R · S+C 1·0·1 | 2·3·7 | 4·4·5 | 0·3·8 | 0·5·4 | 1·2·7 | 1·1·9 | 0·1·9 | 0·1·8 | 2·1·8 | 1·1·6 | 0·1·0 | 0·2·5 Od czego zależy „sukces” agenta, czyli mapa systemów i ich właścicieli Agent nie działa „sam”. Działa dzięki jedenastu ogniwom, z których każde ma innego właściciela i inne ryzyko. Awaria lub luka w którymkolwiek z nich to awaria agenta. W konsekwencji mamy incydent, którym trzeba zarządzić. AGENT AI obsługa klienta: czyta, decyduje, wykonuje działania w systemach przez narzędzia (API) Model językowy (LLM) - dostawca zewnętrzny Prawny / Zakupy, Ryzyko ICT Koncentracja, zmiana wersji modelu, poufność promptów, dostępność Platforma agentowa / orkiestrator IT / Architektura, Zespół AI Błędna logika planowania, pętle, brak limitów Katalog narzędzi i API gateway IT / Architektura, CISO Nadmierne uprawnienia, wywołania poza zakresem IAM / PAM - tożsamość agenta CISO Współdzielone poświadczenia, brak rozliczalności Systemy docelowe (CRM, system centralny, KYC, płatności) Właściciel produktu, IT Nieodwracalne działania, błędne dyspozycje Baza wiedzy / RAG i hurtownia danych Dane / CDO, IOD Nieaktualna lub nieuprawniona wiedza, wyciek danych Guardraile i filtry wejścia/wyjścia Zespół AI, CISO, Compliance Prompt injection, treści niezgodne Logowanie działań, SIEM / SOC CISO, IT Brak śladu audytowego, niewykryty incydent Monitoring jakości i kosztów (obserwowalność) Zespół AI, Ryzyko Dryf, halucynacje, eksplozja kosztów Konsola nadzoru człowieka (HITL) i kill switch Operacje, Właściciel produktu Pozorny nadzór, brak możliwości szybkiego wyłączenia GRC / rejestr systemów AI, ITSM AI Governance Officer, Compliance Brak aktualnej dokumentacji, niekontrolowane zmiany Każde ogniwo ma właściciela Nazwa pod systemem to funkcja, która odpowiada za jego stan. Agent „dziedziczy” słabości każdego z nich. Linia przerywana = zależność zewnętrzna Dostawca modelu jest poza organizacją: umowa, DORA, plan wyjścia i test zmiany wersji to jedyne narzędzia kontroli. Nadzór musi być realny Konsola HITL i kill switch to nie formalność - bez nich human oversight z AI Act istnieje tylko na papierze. Zależności między etapami a systemami Ten sam system pojawia się w wielu etapach, ale z różnymi właścicielami i w różnych rolach. Rejestr systemów AI (GRC) towarzyszy agentowi od etapu 1 do 12 i jest jedynym miejscem, w którym zbiegają się klasyfikacja, oceny, decyzja i historia zmian. IAM/PAM pojawia się w etapie 7 jako miejsce nadania tożsamości agentowi, a w etapie 12 jako miejsce jej odebrania. Systemy docelowe (CRM, system centralny) występują w etapie 3 jako obiekt projektowania, w etapie 8 jako środowisko testowe i w etapie 11 jako środowisko produkcyjne - za każdym razem z innym poziomem uprawnień. Kotwice regulacyjne Model nie jest analizą prawną, lecz operacyjnym uporządkowaniem obowiązków. W tle występują w szczególności: AI Act (art. 4, 26, 27, 50) RODO (art. 22, 35) DORA (art. 28-30) NIS2 / UKSC CRA ISO/IEC 42001 ISO/IEC 27001 ISO 22301 NIST AI RMF - zakres przykładowy, niepełny AI Act - klasyfikacja ryzyka, obowiązki podmiotu stosującego (art. 26), FRIA (art. 27), przejrzystość (art. 50), kompetencje w zakresie AI (art. 4), poważne incydenty RODO - DPIA (art. 35), decyzje zautomatyzowane (art. 22), minimalizacja i retencja, informacja dla osób DORA - zarządzanie ryzykiem ICT stron trzecich (art. 28-30), rejestr umów ICT, incydenty ICT NIS2 / ustawa o krajowym systemie cyberbezpieczeństwa (UKSC) - środki zarządzania ryzykiem cyberbezpieczeństwa, bezpieczeństwo łańcucha dostaw, zgłaszanie incydentów CRA (Cyber Resilience Act) - wymogi cyberbezpieczeństwa produktów z elementami cyfrowymi, w tym komponentów wykorzystywanych przez agenta ISO/IEC 42001 (system zarządzania AI), ISO/IEC 23894 (ryzyko AI), ISO/IEC 27001 (bezpieczeństwo informacji), ISO 22301 (ciągłość działania), NIST AI RMF - jako ramy operacyjne Powyższa lista ma charakter przykładowy i nie jest wyczerpująca. Pełny katalog wymogów zależy od statusu podmiotu, produktu i klasyfikacji konkretnego przypadku użycia; ustala go etap 2 modelu. Najczęstsze błędy i jak ich uniknąć Brak jednego „A”. Gdy za etap odpowiada „zespół projektowy”, nikt nie odpowiada. Każdy etap ma jedną rozliczaną funkcję - nawet jeśli pracę wykonuje kilka. Klasyfikacja po fakcie. Ocena wg AI Act robiona tuż przed wdrożeniem wymusza kosztowne cofnięcia. Bramka pierwsza musi być na początku. Agent na poświadczeniach człowieka. Współdzielone konto pracownika niszczy rozliczalność. Agent potrzebuje własnej tożsamości i minimalnych uprawnień do konkretnych narzędzi. Nadzór ludzki na papierze. Human oversight istnieje wtedy, gdy operator ma konsolę, czas, kompetencje i realną możliwość zatrzymania agenta. Etap 10 musi to potwierdzić szkoleniem i instrukcją. Walidacja przez twórców. Ten sam zespół nie może budować i niezależnie walidować. Etap 9 należy do drugiej linii. Zmiana bez ponownej oceny. Nowa wersja modelu, nowe narzędzie lub nowe źródło danych bez re-klasyfikacji i walidacji to najczęstsza droga do niezgodności po wdrożeniu. Brak planu wycofania. Agent, którego nie da się wyłączyć w kilka minut (kill switch) i wygasić w kilka tygodni (exit plan), jest ryzykiem koncentracji, a nie usprawnieniem. Lista kontrolna przed decyzją o wdrożeniu Minimalny zestaw dowodów, który powinien znaleźć się w dossier dla Komitetu AI (etap 10): 1. Karta klasyfikacji (AI Act, DORA, outsourcing) z uzasadnieniem i datą. 2. Dokument koncepcji z polityką działań agenta (co automatycznie, co z zatwierdzeniem, co zakazane). 3. DPIA oraz - jeśli wymagana - FRIA, z listą środków ograniczających. 4. Karta ryzyka z limitami, KRI i właścicielami działań. 5. Karta danych: źródła, podstawy prawne, klasyfikacja, retencja. 6. Umowa z dostawcą modelu z klauzulami sektorowymi i planem wyjścia. 7. Model zagrożeń, konfiguracja tożsamości i uprawnień agenta, architektura logowania. 8. Raport z ewaluacji, red teamingu i testów akceptacyjnych dla zamrożonej wersji. 9. Raport niezależnej walidacji i opinia zgodności z warunkami. 10. Instrukcja użytkowania, program szkoleń i komunikat dla klientów. 11. Plan wdrożenia kontrolowanego z kryteriami skalowania, planem wycofania i kill switch. 12. Wpis w rejestrze systemów AI i przypisanie właściciela przeglądów okresowych. Słownik skrótów GRC - governance, risk & compliance (system zarządzania zgodnością i ryzykiem); ICT - technologie informacyjno-komunikacyjne; DORA - rozporządzenie o operacyjnej odporności cyfrowej; NIS2 / UKSC - dyrektywa NIS2 / ustawa o krajowym systemie cyberbezpieczeństwa; CRA - Cyber Resilience Act; ADR - rejestr decyzji architektonicznych; API - interfejs programistyczny; DPIA - ocena skutków dla ochrony danych; FRIA - ocena skutków dla praw podstawowych; DLP - ochrona przed wyciekiem danych; RAG - generowanie wspomagane wyszukiwaniem (baza wiedzy agenta); LLM - duży model językowy; CLM - zarządzanie umowami; IAM/PAM - zarządzanie tożsamością i dostępem uprzywilejowanym; CI/CD - ciągła integracja i wdrażanie; DMS - system zarządzania dokumentami; LMS - platforma szkoleniowa; CRM - system obsługi klienta; KYC - weryfikacja tożsamości klienta; SIEM/SOC - system i zespół monitorowania bezpieczeństwa; ITSM - zarządzanie usługami IT; IOD/DPO - inspektor ochrony danych; HITL - człowiek w pętli decyzyjnej; CISO - szef bezpieczeństwa informacji; CDO - dyrektor ds. danych; AI/ML - sztuczna inteligencja / uczenie maszynowe; RASCI - Responsible, Accountable, Support, Consulted, Informed; KRI - kluczowe wskaźniki ryzyka; KPI - kluczowe wskaźniki efektywności. Autor materiału Michał Nowakowski Legal Architect · AI, Data & Cybersec Pomagam organizacjom rozumieć, wdrażać i skalować AI odpowiedzialnie: governance, dane, zgodność i bezpieczeństwo - od pomysłu po nadzór nad agentem w produkcji. Wdrażasz agenta AI i chcesz, żeby role, bramki i systemy zagrały razem? Porozmawiajmy o Twoim przypadku: klasyfikacja, projekt governance, RASCI, umowa z dostawcą, walidacja i nadzór po wdrożeniu. Odpowiadam osobiście. E-mail - michal@nowakowski.ai Telefon - +48 668 002 336 LinkedIn - linkedin.com/in/mjnowakowski Strona - legalarchitect.pl Napisz przez formularz W czym pomagam Audyt i ramy AI governance Klasyfikacja wg AI Act RASCI, procesy i bramki decyzyjne Umowy z dostawcami AI (DORA) Dane i cyberbezpieczeństwo Szkolenia i AI literacy Materiał przygotowany w oparciu o wiedzę i doświadczenie autora - Michała Nowakowskiego - przy wsparciu modelu Fable 5.1. Wszelkie uwagi i wątpliwości można przekazać na adres: michal@nowakowski.ai. Model ma charakter poglądowy i edukacyjny (podmiot regulowany, agent z dostępem do systemów wewnętrznych); nie stanowi porady prawnej; kotwice regulacyjne wskazano przykładowo i niewyczerpująco.