Kto odpowiada za system AI po zakończeniu pilotażu

Co traci właściciela, gdy kończy się pilotaż

W trakcie pilotażu mały zespół trzyma wszystko w głowie: dlaczego prompt brzmi tak, a nie inaczej, które sprawy wyłączono i którą wersję modelu testowano. Rules of Machine Learning od Google mówią to samo o cechach danych: wiedzcie, kto utrzymuje każdą z nich, a gdy ta osoba odchodzi, upewnijcie się, że wiedzę ma ktoś inny. Systemy AI mają dodatkowo elementy, które zmieniają się z zewnątrz. Anthropic na przykład wycofuje starsze modele według publikowanego harmonogramu i zapowiada co najmniej 60 dni wyprzedzenia dla modeli udostępnionych publicznie. Ktoś musi przeczytać takie ogłoszenie, przetestować następcę na waszych sprawach i wdrożyć zmianę przed terminem.

Mapa odpowiedzialności dla jednego procesu AI

Poniższe role to przykład dla hipotetycznego agenta sprawdzającego faktury. W waszej organizacji nazwiska będą inne, ale każdy wiersz potrzebuje jednego.

• System jako całość: kierownik działu zobowiązań, odpowiedzialny za wyniki, koszt sprawy i zakres. AWS Generative AI Lens sugeruje jednego właściciela odpowiedzialnego za bieżącą ocenę wydajności.
• Prompty, narzędzia i kod orkiestracji: zespół inżynierski, który prowadzi usługę.
• Wybór i wersje modeli: ten sam zespół, a każdy model jest zapisany w katalogu modeli razem z datami wycofania podanymi przez dostawcę.
• Źródła danych: właściciel każdego systemu źródłowego, który zatwierdza użycie i jest informowany o zmianach schematu.
• Zestaw testowy: właściciel procesu i zespół inżynierski wspólnie, a ekspert dopisuje nowe błędy, gdy się pojawiają.
• Kolejka weryfikacji i poprawki: kierownik zespołu w dziale zobowiązań.
• Uprawnienie do wyłączenia: wskazane osoby po obu stronach. Ramy NIST wymagają, by odpowiedzialność za zastąpienie, odłączenie lub dezaktywację systemu AI była przypisana i zrozumiała.

Kto zatwierdza którą zmianę

• Sformułowania promptu w obecnym zakresie: zespół inżynierski, pod warunkiem że przechodzi zestaw regresji.
• Nowa wersja modelu lub nowy dostawca: inżynierowie proponują, a właściciel procesu zatwierdza po zobaczeniu wyników regresji i kosztu sprawy.
• Progi, które zmieniają liczbę spraw trafiających do człowieka: właściciel procesu, bo zmieniają zarówno godziny weryfikacji, jak i ryzyko.
• Nowe typy spraw lub nowe akcje zapisu: właściciel procesu razem z bezpieczeństwem i właścicielami danych, a przy danych osobowych także z inspektorem ochrony danych.
• Wycofanie systemu: właściciel procesu, z planem wygaszenia. NIST zalicza procedury bezpiecznego wycofywania systemów AI do zarządzania.

Spisana zasada na wypadek spadku jakości

Przykładowa polityka budżetu błędów Google z góry określa, co się dzieje, gdy usługa nie osiąga celu: zmiany inne niż pilne poprawki zostają wstrzymane do czasu poprawy, incydent zużywający więcej niż jedną piątą budżetu kończy się postmortem, a spory trafiają do CTO. System AI zyskuje na takim samym porozumieniu. Hipotetyczna wersja mogłaby brzmieć tak, przy czym zdarzenia krytyczne są traktowane osobno od stopniowego spadku jakości.

1. 1

   Zdarzenia krytyczne

   Nieautoryzowana akcja, ujawnione dane albo błąd, który zasada klasyfikuje jako krytyczny, nie wymagają okresu oczekiwania. Dana akcja lub cały system zostaje natychmiast wyłączony, sprawy trafiają do pełnej weryfikacji przez ludzi i rusza procedura obsługi incydentu.

2. 2

   Wyzwalacz

   Przy niekrytycznym spadku jakości: odsetek błędów w próbce dla dowolnego typu spraw przez dwa kolejne tygodnie przekracza uzgodniony poziom.

3. 3

   Działanie natychmiastowe

   Ten typ spraw wraca do pełnej weryfikacji przez ludzi, a zmiany inne niż poprawki zostają wstrzymane.

4. 4

   Decyzja

   Właściciel procesu na podstawie analizy błędów wybiera między poprawką, węższym zakresem i wyłączeniem tego typu spraw.

5. 5

   Eskalacja

   Jeśli inżynierowie i właściciel procesu się nie zgadzają, wskazany członek kierownictwa decyduje w uzgodnionym terminie.

Gdzie zapisuje się decyzje

AWS Lens opisuje dokument polityki AI jako centralne źródło odpowiedzi na pytania operacyjne dotyczące obciążeń AI i każe utrzymywać go w aktualności. Dla jednego systemu wystarczy jedna strona w repozytorium obok kodu: właściciele, zasady zatwierdzania zmian, zasada jakości, kto może wyłączyć system i jak zostałby wycofany. Ramy NIST wymagają, by role i ścieżki komunikacji były udokumentowane i jasne. Aktualizujcie tę stronę przy każdej zmianie właściciela i sprawdzajcie ją, gdy dochodzi nowy dostawca.

Sygnały ostrzegawcze, że nikt nie korzysta z tej strony: model z listy wycofań dostawcy nadal obsługuje ruch, zestaw testowy się nie zmienia, choć proces się zmienił, zaległości w weryfikacji nikt nie eskaluje, a nikt nie potrafi powiedzieć, kto może wyłączyć system. Gdy przekazujemy system, kod, zestaw testowy, runbooki i monitoring przechodzą razem z tą stroną.

Od pilotażu do produkcjiPlanowanie odejścia od dostawcy AI