Ramy governance agentów AI

1. Zacznij od zasad governance

Model governance powinien rozpoczynać się od niewielkiej liczby spójnych zasad obowiązujących w całym portfelu agentów. Muszą być zrozumiałe dla product ownerów, developerów, risk, compliance i biznesu.

Najważniejsze zasady to identyfikowalna odpowiedzialność, least privilege, proporcjonalne kontrole, odpowiedzialność człowieka, evidence by design oraz kontrola zmian.

• Każdy agent ma określonego business ownera i technical ownera.
• Każdy agent działa w jasno zdefiniowanym celu i zakresie uprawnień.
• Dostęp do systemów, danych i działań opiera się na zasadzie least privilege.
• Nadzór człowieka jest proporcjonalny do potencjalnych skutków błędu.
• Dowody testów i zatwierdzeń są zachowywane i odtwarzalne.
• Istotne zmiany uruchamiają ponowną ocenę.

2. Utrzymuj wiarygodny rejestr agentów

Organizacja nie może skutecznie zarządzać agentami, których nie potrafi zidentyfikować. Rejestr agentów jest więc podstawowym mechanizmem governance.

Rejestr powinien zawierać więcej niż nazwy: musi umożliwiać zrozumienie celu, miejsca działania, dostępów oraz odpowiedzialności.

• Nazwa agenta, wersja i status cyklu życia.
• Cel biznesowy i docelowi użytkownicy.
• Business owner, technical owner i support owner.
• Środowisko Microsoft, solution i lokalizacja wdrożenia.
• Połączone systemy, konektory, narzędzia i kategorie danych.
• Uprawnienia do działań i autorytet transakcyjny.
• Klasyfikacja ryzyka i wymagany poziom zatwierdzenia.
• Model nadzoru człowieka.
• Dowody testowe, status certyfikacji i data ostatniego przeglądu.

3. Klasyfikuj ryzyko przed wdrożeniem

Klasyfikacja ryzyka określa poziom wymaganej governance. Liczy się nie tylko model, ale to, co cały agent może zobaczyć, zdecydować i zrobić.

Agent tylko do odczytu różni się zasadniczo od agenta mogącego zatwierdzać transakcje, komunikować się zewnętrznie, modyfikować rekordy lub uruchamiać dalsze procesy.

CAI Score to ustrukturyzowane podejście ColleagueAI do klasyfikacji ryzyka agentów enterprise. Uwzględnia autonomię, wpływ, wrażliwość danych, dostęp do narzędzi, odwracalność, nadzór i wymagania governance.

4. Oddziel odpowiedzialność biznesową od technicznej

Zespół techniczny może budować i utrzymywać agenta, ale nie powinien być jedynym właścicielem wyniku biznesowego. Funkcja biznesowa korzystająca z agenta pozostaje odpowiedzialna za proces i konsekwencje.

Dojrzały model rozdziela business ownership, technical ownership i governance assurance.

Model odpowiedzialności powinien również jasno określać prawa decyzyjne. Właściciel biznesowy zatwierdza zamierzony cel, akceptowalne rezultaty i istotne zmiany procesu, natomiast właściciel techniczny pozostaje odpowiedzialny za integralność komponentów rozwiązania, konfiguracji i kontroli technicznych. Funkcje governance, ryzyka, bezpieczeństwa lub compliance mogą zapewniać niezależną weryfikację, ale nie powinny zastępować odpowiedzialności biznesowej.

5. Zarządzaj tożsamością, dostępem i uprawnieniami narzędzi

Możliwości agenta są w dużym stopniu określone przez systemy i działania, do których ma dostęp. Konektory, credentials, service identities i uprawnienia należy traktować jako kluczowe kontrole.

Uprawnienia powinny być ograniczone do minimum potrzebnego dla zatwierdzonego use case.

• Używaj dedykowanych tożsamości, jeśli pozwala na to architektura.
• Ogranicz konektory i działania do zatwierdzonych use cases.
• Nie przyznawaj szerokich uprawnień jedynie dla wygody developmentu.
• Rejestruj działania uprzywilejowane w audytowalnych logach.
• Używaj approval gates dla działań nieodwracalnych lub o dużym wpływie.
• Ponownie waliduj uprawnienia po zmianach workflow lub integracji.

6. Zaprojektuj nadzór człowieka bezpośrednio w workflow

Nadzór człowieka nie powinien być ogólnym stwierdzeniem, że człowiek pozostaje odpowiedzialny. Musi jasno określać, gdzie człowiek przegląda, zatwierdza, interweniuje lub zatrzymuje agenta.

Odpowiedni model zależy od ryzyka. Niektórzy agenci mogą działać autonomicznie w wąsko ograniczonych zadaniach o niskim ryzyku, podczas gdy inni wymagają zatwierdzenia przed istotnym działaniem.

Kontrola powinna określać moment interwencji, osobę dokonującą przeglądu, informacje dostępne dla tej osoby oraz działania, do których jest uprawniona. Formalny etap zatwierdzania nie wystarcza, jeżeli osoba zatwierdzająca nie jest w stanie zrozumieć lub zatrzymać proponowanego rezultatu. Nadzór człowieka powinien więc być testowany jako rzeczywista kontrola operacyjna, a nie jedynie zapisany w polityce.

7. Testuj agenta jako cały system

Assurance agenta wymaga testowania całego workflow. Ważne są prompt, uprawnienia, wywołania narzędzi, zachowanie przy błędach, przetwarzanie danych, eskalacja, jakość outputu i reakcja na nietypowe dane wejściowe.

Pakiet produkcyjny powinien przechowywać dowody tego, co zostało przetestowane, jakie zachowanie było oczekiwane, jakie istnieją ograniczenia i która wersja przeszła test.

• Testy funkcjonalne i scenariuszowe.
• Testy uprawnień i konektorów.
• Ścieżki błędów i wyjątków.
• Ścieżki zatwierdzania i eskalacji.
• Obsługa danych wrażliwych.
• Kryteria jakości outputu.
• Logging i generowanie dowodów.
• Testy regresji po istotnych zmianach.

8. Traktuj wdrożenie jako kontrolowane przekazanie

Pakietowany agent powinien mieć jasno zdefiniowaną granicę wdrożenia. Dostawca może dostarczyć przetestowaną solution, dokumentację, guidance konfiguracji, dowody governance i instrukcje deploymentu, ale klient kontroluje własny tenant i środowisko operacyjne.

W przypadku produktów ColleagueAI deployment i runtime pozostają w środowisku Microsoft klienta. Konfiguracja specyficzna dla tenantu, integracje, wdrożenie i operation są wykonywane przez klienta lub zatwierdzonego partnera wdrożeniowego.

Kontrolowane przekazanie powinno również dokumentować wymagania wstępne, zmienne środowiskowe, odwołania do połączeń, wymagane role, znane ograniczenia oraz kroki walidacji po imporcie. Dzięki temu klient lub partner wdrożeniowy może odtworzyć przetestowaną konfigurację bez zależności od nieudokumentowanej wiedzy pierwotnego twórcy. Wdrożona wersja powinna pozostać możliwa do powiązania z zatwierdzonym pakietem i materiałem dowodowym.

9. Monitoruj ryzyko operacyjne i istotne zmiany

Zatwierdzenie przed startem nie kończy governance. Zachowanie agenta może się zmienić wraz ze zmianą promptów, modeli, narzędzi, uprawnień, źródeł wiedzy lub systemów połączonych.

Ciągła governance powinna koncentrować się na istotnych zmianach, wyjątkach, incydentach, wzorcach użycia i dowodach, że wdrożona konfiguracja nadal odpowiada zatwierdzonemu projektowi.

Monitoring powinien być powiązany z jasno określonymi wyzwalaczami ponownego przeglądu. Mogą nimi być nowy konektor, szersze uprawnienia, inny model, nowe źródło wiedzy, wzrost liczby obejść, powtarzające się wyjątki lub zmiana procesu biznesowego. Takie sygnały powinny określać, kiedy agent wymaga analizy, działań naprawczych, recertyfikacji lub nowej decyzji governance.

10. Zarządzaj wycofaniem równie rygorystycznie jak uruchomieniem

Nieużywani lub zastąpieni agenci nie powinni zachowywać nieaktywnych dostępów bezterminowo. Wycofanie powinno usuwać uprawnienia, wyłączać integracje, archiwizować dowody i aktualizować rejestr.

Czysty proces wycofania ogranicza attack surface i zapobiega powstawaniu osieroconych zdolności AI.

Wycofanie agenta powinno również zamknąć jego zależności operacyjne i governance. Właściciele powinni potwierdzić wyłączenie zaplanowanych przepływów, unieważnienie odpowiednich poświadczeń usługowych, dostosowanie zależnych integracji oraz zachowanie dowodów zgodnie z obowiązującymi zasadami. Użytkowników należy w razie potrzeby skierować do procesu zastępczego, a w rejestrze zapisać datę wycofania i końcowy status agenta.

Najczęściej zadawane pytania