Rejestr modeli AI: fundament skutecznego AI governance

Rejestr modeli AI odpowiada na proste, ale często trudne pytanie: jakie systemy AI działają w organizacji, kto za nie odpowiada i na podstawie jakich dowodów zostały dopuszczone. Bez rejestru governance opiera się na ankietach i pamięci pojedynczych zespołów.

Rejestr nie powinien ograniczać się do własnych modeli ML. Obejmuje zewnętrzne API LLM, funkcje AI w SaaS, modele open source, systemy RAG, agentów i automatyzacje wykorzystujące wynik modelu.

Jednostką jest przypadek użycia

Ten sam model może streszczać publiczne teksty albo podejmować decyzje dotyczące klienta. Ryzyko jest inne, dlatego zapisuj model razem z przypadkiem użycia, danymi, odbiorcą i zakresem autonomii.

Minimalny rekord zawiera:

ownera biznesowego i technicznego;
cel, użytkowników i systemy zależne;
dostawcę, model, wersję i region;
kategorie danych wejściowych oraz wyjściowych;
źródła RAG, pamięć i udostępnione narzędzia;
ocenę wpływu i wymagane kontrole;
wyniki ewaluacji, datę akceptacji i termin przeglądu;
plan awaryjny, wycofania i reagowania na incydent.

Automatyczne odkrywanie

Formularz zgłoszeniowy nie wykryje wszystkich wdrożeń. Uzupełnij go analizą wydatków SaaS, logów proxy i DNS, repozytoriów, sekretów CI, katalogu aplikacji OAuth oraz ruchu do API modeli.

Odkrycie nieznanego narzędzia nie oznacza automatycznie naruszenia. Najpierw potwierdź ownera, dane i rzeczywisty sposób użycia. Następnie podejmij decyzję: zatwierdzenie, ograniczenie, migracja albo wyłączenie.

Bramki zależne od ryzyka

Niskiego ryzyka asystent do publicznej dokumentacji nie potrzebuje tego samego procesu co model oceniający klientów. Ustal poziomy i proporcjonalne wymagania.

Dla wysokiego ryzyka wymagaj oceny wpływu, testów jakości i bezpieczeństwa, przeglądu danych, człowieka w pętli, monitoringu, ścieżki odwołania i formalnej akceptacji. Dowody powinny być załącznikami lub linkami w rekordzie, nie deklaracją „przetestowano”.

Wersja modelu jest zmianą

Dostawca może zaktualizować model, filtr, retencję lub region. Rejestr musi odbierać sygnały o zmianach i wymuszać ponowną ewaluację, gdy wpływ przekracza próg.

Przypinaj wersję, jeśli usługa na to pozwala. Zapisuj zestaw testowy oraz wyniki, aby porównać zachowanie. Procedurę testów opisuje ewaluacja LLM.

Cykl życia i wycofanie

Każdy rekord powinien mieć status: pomysł, pilotaż, zatwierdzony, ograniczony, wycofywany lub zamknięty. Nieaktywne klucze, indeksy i dane treningowe trzeba usunąć zgodnie z retencją.

Raz na kwartał weryfikuj ownera, aktywność, umowę, model i kompletność dowodów. Alertuj, gdy przegląd wygasł albo używana wersja straciła wsparcie.

Mierniki programu

Mierz pokrycie wykrytego ruchu AI rekordami, czas od odkrycia do decyzji, udział systemów z aktualną ewaluacją, liczbę wdrożeń bez ownera i czas wycofania. Sama liczba pozycji rośnie wraz z biurokracją; nie dowodzi kontroli ryzyka.

Rejestr modeli jest warstwą łączącą technologię, ryzyko, zakupy, bezpieczeństwo i prawo. Największą wartość daje wtedy, gdy automatycznie reaguje na zmianę i prowadzi do konkretnej decyzji.

Minimalny rekord produkcyjny

Rejestr powinien łączyć wersję modelu z zastosowaniem, właścicielem, dostawcą, źródłami danych, lokalizacją przetwarzania, promptem systemowym, narzędziami, ewaluacją i datą zatwierdzenia. Dla API z nazwą „latest” zapisuj faktyczny identyfikator zwróconej wersji, jeśli dostawca go udostępnia. Bez tego nie da się powtórzyć incydentu ani porównać regresji.

Zmiana modelu, promptu, indeksu RAG lub zestawu narzędzi powinna uruchamiać ocenę wpływu zależną od ryzyka. Stan „wycofany” nie oznacza usunięty: trzeba wskazać retencję logów, kopii, embeddingów i danych treningowych. Rejestr ma zasilać monitoring oraz incident response, a nie być arkuszem aktualizowanym raz w roku.

Źródła: NIST AI RMF, NIST GenAI Profile, OWASP GenAI Data Security.