Czy regulator może kontrolować ruchomy cel?

Tak, ale nie przez udawanie, że system adaptacyjny jest obiektem statycznym. Audyt wymaga uchwyconego stanu, ograniczonego roszczenia, dowodów z warunkami...

Czy regulator może kontrolować ruchomy cel?

Audyt może zrobić zdjęcie

Zmienny cel nie wymyka się kontroli. Wymyka się jedynie tej formie kontroli, która zadaje jedno ponadczasowe pytanie i oczekuje jednej ponadczasowej odpowiedzi. To rozróżnienie ma znaczenie. Systemy AI zmieniają się na kilka sposobów jednocześnie. Dostawca wydaje nową wersję modelu. Wdrożeniowiec zmienia prompt lub próg decyzyjny. Korpus do wyszukiwania zyskuje nowy dokument polityki. Reguła tożsamości zmienia to, kto może wywołać narzędzie. Narzędzie zyskuje pole, traci pole albo zaczyna zwracać inne znaczenie pod tą samą nazwą pola. Zespół ludzi zmienia swoją procedurę. Świat dostarczający danych wejściowych zmienia się bez pytania nikogo o zgodę na wydanie.

Żadne z tych zjawisk nie czyni audytu bezcelowym. Czyni przedmiot audytu bardziej precyzyjnym. Pytanie nie brzmi, czy organizacja może udowodnić, że system pozostanie niezmieniony na zawsze. Byłaby to dziwna obietnica nawet dla kalkulatora podłączonego do bazy danych. Pytanie brzmi, czy organizacja może wykazać, jaki system działał w danym momencie, do czego miał służyć, jakie dowody wspierały to użycie, jakie warunki ograniczały te dowody, kto był właścicielem decyzji i jaka późniejsza zmiana powinna spowodować ponowne otwarcie tej decyzji.

Audyt może zrobić zdjęcie. Musi tylko nie nazywać zdjęcia krajobrazem. Prawidłowy zapis identyfikuje stan, który został zbadany, i utrzymuje ścieżkę od tego stanu do następnego. Może wtedy powiedzieć coś użytecznego: ta ocena dotyczyła tego modelu, tych ustawień, tej granicy danych, tych narzędzi, tej polityki, tego przepływu pracy i tej decyzji o wydaniu. Może też powiedzieć coś mniej wygodnego, ale bardziej wartościowego: wniosek nie przeniósł się automatycznie do następnego stanu.

To lepszy punkt wyjścia niż znajomy teatr niezmiennych odznak. Odznaka sugeruje, że ktoś już rozstrzygnął sprawę. Zapis audytu powinien umożliwiać zobaczenie, co zostało rozstrzygnięte, na jakiej podstawie, do jakiego zastosowania i jak długo ta podstawa pozostawała aktualna. Regulator nie potrzebuje zamrożonej organizacji. Regulator potrzebuje organizacji, która potrafi odróżnić zamrożony zapis od działającej usługi, nie traktując żadnego z nich jak mistycznego obiektu.

Europejskie przepisy dotyczące AI już wskazują ten kierunek. W przypadku systemów AI wysokiego ryzyka akt o sztucznej inteligencji wymaga dokumentacji technicznej przed wprowadzeniem systemu do obrotu lub oddaniem go do użytku oraz wymaga jej aktualizowania. Wymaga również automatycznego rejestrowania istotnych zdarzeń przez cały okres życia systemu oraz udokumentowanego systemu monitorowania po wprowadzeniu do obrotu, proporcjonalnego do technologii i ryzyka. To nie są instrukcje, aby wykonać jedno ceremonialne zrzut ekranu. To instrukcje, aby prowadzić ślad dowodowy przez zmianę.

Zmiennym celem jest zwykle system

Kusjące jest opisanie systemu AI jako modelu, a następnie omawianie wersjonowania tak, jakby nowy plik wag modelu był całą historią. To wygodne dla prezentacji i niedokładne dla większości pytań operacyjnych. Model jest ważnym komponentem. Rzadko jest kompletnym obiektem, którego zachowanie wpływa na osobę, przepływ pracy lub zobowiązanie prawne.

Rozważmy zwykłą ścieżkę wspomagania decyzji, opisaną tutaj jako hipotetyczny przykład, a nie opis rzeczywistego wdrożenia. Użytkownik składa wniosek. Usługa pobiera dokumenty, których może użyć. Model sporządza projekt rekomendacji. Reguła sprawdza, czy wymagane dowody są obecne. Przeszkolony recenzent może zaakceptować, zmienić lub odrzucić rekomendację. Przepływ pracy rejestruje następnie działanie. Zaobserwowany wynik zależy od czegoś więcej niż model. Zależy od wersji źródeł, ustawień wyszukiwania, uprawnień, sformułowań interfejsu, progów, zasad kolejki, uprawnień ludzi i granicy działań.

Jeśli zmieni się korpus źródłowy, model może otrzymać inną podstawę faktyczną bez zmiany choćby jednego parametru. Jeśli zmieni się prompt, model może zostać poproszony o dokonanie innego rodzaju oceny. Jeśli ekran recenzenta przestanie wyświetlać niepewność, nadzór ludzki opisany w pliku ryzyka może przestać być nadzorem, który ludzie faktycznie sprawują. Jeśli integracja zacznie automatycznie stosować rekomendacje, system uzyska nową władzę, nawet jeśli odpowiedź modelu będzie identyczna co do bajtu.

Dlatego rozsądny zapis audytu zaczyna się od zamierzonego celu i granic systemu. Wymogi dotyczące dokumentacji technicznej w załączniku IV do aktu o sztucznej inteligencji obejmują opisy zamierzonego celu, wersji, funkcji monitorowania i kontroli, walidacji i testowania, zarządzania ryzykiem, zmian wprowadzonych w cyklu życia oraz istotnych wskaźników wydajności. Nie chodzi o to, że każdy system potrzebuje katedry papierologii. Chodzi o to, że recenzent nie może ocenić twierdzenia, gdy obiekt, którego twierdzenie dotyczy, po cichu zmienia kształt.

Nazywanie szerszego obiektu systemem nie jest sposobem na to, by praca brzmiała bardziej doniośle. To sposób na uniknięcie błędu kategorialnego. Ewaluacja modelu może odpowiedzieć na pytanie o model. Audyt systemu musi odpowiedzieć na pytanie o system. Pierwsza może ustalić, jak komponent zachowywał się w określonych warunkach. Drugi musi pokazać, jak ten komponent był połączony z ludźmi, danymi, regułami, narzędziami i konsekwencjami. Żadne z nich nie zastępuje drugiego. Wynik modelu nie jest opisem przepływu pracy, podobnie jak dobry test opony nie jest planem trasy.

Co audytor faktycznie próbuje ustalić

Audyt zmieniającego się systemu nie oznacza odtwarzania każdego momentu jego życia w sali konferencyjnej. Oznacza uczynienie konkretnych twierdzeń możliwymi do zbadania. Czy system był używany zgodnie z podanym celem? Czy decyzja o wydaniu była poparta dowodami odpowiednimi do tego celu? Czy organizacja zachowała informacje potrzebne do zbadania spornego wyniku? Czy istotne zmiany uruchamiały ponowną ocenę? Czy monitorowanie uwidaczniało różnicę między niegroźną aktualizacją a istotną zmianą? Czy osoby odpowiedzialne mogły wstrzymać, ograniczyć lub skorygować przebieg, gdy dowody przestały się utrzymywać?

To praktyczne pytania, ponieważ każde z nich ma obserwowalny odpowiednik. Zamierzony cel należy do zapisu. Ewaluacja ma zestaw, konfigurację, populację testową lub granicę wejściową, metodę, wynik i ograniczenie. Decyzja o wydaniu ma właściciela i warunki. Zmiana ma tożsamość, datę, powód i oceniony skutek. Monitorowanie ma nazwane sygnały, progi lub wyzwalacze przeglądu. Ścieżka wstrzymania ma organ i operację. Szczegóły się różnią, ale audytowalność wynika z przekształcania abstrakcyjnych zapewnień w rzeczy, które ktoś inny może zbadać.

Jest tu ważne ograniczenie. Audyt nie dowodzi, że każde przyszłe wyjście będzie poprawne, sprawiedliwe lub nieszkodliwe. Nie może zamienić niepewnego świata w deterministyczny. Może ustalić, czy organizacja formułowała twierdzenia na tyle wąskie, by można je było zbadać, czy zbierała dowody zdolne je potwierdzić i czy zachowała zdolność do ich ponownego rozważenia. To może brzmieć skromnie. To także miejsce, w którym zaczyna się odpowiedzialność.

Różnica między dowodem a językiem zapewnień ma znaczenie. Stwierdzenie, że model został poddany ewaluacji, nie jest jeszcze dowodem użytecznej ewaluacji. To słowo potrzebuje dopełnienia. Wobec jakiego zadania, kryteriów i danych? Z jakim modelem i stanem systemu? W jakich warunkach operacyjnych? Kto sprawdził metodę? Co było poza zakresem? Co sprawiłoby, że wynik stałby się nieaktualny? Bez tych pytań ewaluacja jest jedynie uspokajającą formą czasu przeszłego.

Wcześniejsze wytyczne etyczne Komisji Europejskiej dotyczące godnej zaufania sztucznej inteligencji ujmowały powtarzalność w prostych słowach: eksperyment z zakresu sztucznej inteligencji powinien wykazywać takie samo zachowanie, gdy zostanie powtórzony w tych samych warunkach. To użyteczna definicja, ponieważ zawiera własne ograniczenie. Te same warunki mają realne znaczenie. Powtórzony eksperyment może wykazać, czy udokumentowane twierdzenie jest powtarzalne. Nie może wykazać, że niezmienione zachowanie pojawi się po zmianie źródła danych, polityki lub sposobu wdrożenia. Powtarzalność nie jest zatem obietnicą, że świat stoi w miejscu. To dyscyplina polegająca na precyzyjnym opisaniu tego, co faktycznie się wydarzyło.

Zapisana ocena to punkt w czasie. Audyt staje się trwały, gdy kolejny stan można z nią porównać.

Numer wersji jest konieczny, ale niewystarczający

Numery wersji są przydatne, ponieważ uniemożliwiają zapisowi udawanie, że nazwy wystarczą. Jednak etykieta wersji może również stwarzać fałszywe poczucie bezpieczeństwa. Etykieta taka jak wersja 4.2 może identyfikować wydanie oprogramowania, ale niekoniecznie identyfikuje faktyczny stan ścieżki sztucznej inteligencji. Wartość konfiguracji może znajdować się poza repozytorium modelu. Indeks wyszukiwania może zostać przebudowany na podstawie zmieniających się dokumentów. Flaga funkcji może wybierać inną ścieżkę narzędzia. Silnik polityk może zmienić dozwolone działanie. Usługa może zatem mieć nienagannie sformatowany numer wersji i nadal być trudna do odtworzenia.

Liczy się tożsamość odpowiednia do twierdzenia. Jeśli twierdzenie dotyczy testu porównawczego modelu offline, artefakt modelu, kod wnioskowania, ustawienia parametrów, wersja zbioru danych, definicja metryki i środowisko wykonawcze mogą być niezbędne. Jeśli twierdzenie dotyczy działającej usługi wspomagania decyzji, zapis może dodatkowo wymagać promptu lub szablonu, konfiguracji wyszukiwania, identyfikatorów i świeżości źródeł, stanu uprawnień, schematów narzędzi, wersji polityki, interfejsu recenzenta i reguły przepływu pracy. Pakiet audytowy nie musi zawierać każdego bajtu każdego systemu. Musi zawierać lub wiarygodnie wskazywać elementy, które mogłyby zmienić znaczenie twierdzenia.

Dlatego manifest jest często bardziej pomocny niż archiwum zrzucone na dysk twardy. Manifest określa, które artefakty należą do siebie, ich identyfikatory, odniesienia integralności, relacje i warunki dostępu. Pozwala audytorowi zlokalizować odpowiedni pakiet bez zakładania, że każde źródło można skopiować do nieograniczonego folderu. Niektóre dowody zawierają dane osobowe, informacje wrażliwe pod względem bezpieczeństwa, materiały licencjonowane lub tajemnice handlowe. Możliwość audytu wymaga kontrolowanego dostępu i znaczącej identyfikowalności, a nie obowiązkowego publicznego ujawniania wszystkiego, co sprawia, że system działa.

Załącznik IV przyjmuje podobne, praktyczne podejście. Nie traktuje dokumentacji technicznej jako krótkiego opisu produktu. Wymaga informacji o systemie i jego cyklu życia, w tym zmian wprowadzonych w trakcie rozwoju i po wprowadzeniu do obrotu, funkcji monitorowania i kontroli, procedur i wyników walidacji oraz testów, środków zarządzania ryzykiem oraz opisu wskaźników wydajności. Dokument musi być na tyle jasny, aby właściwe organy krajowe i jednostki notyfikowane mogły ocenić zgodność. Innymi słowy, informacje muszą być zorganizowane pod kątem kontroli, a nie jedynie zgromadzone, ponieważ istniał system przechowywania.

Za tym wszystkim stoi małe, ale kluczowe pytanie projektowe: co musiałoby się zmienić, aby wcześniejsze dowody nie mogły już dłużej potwierdzać obecnego twierdzenia? Odpowiedź wyznacza granicę wersji. Jeśli nowe źródło wyszukiwania zmienia faktyczne podstawy zaleceń, należy je uwzględnić w tożsamości. Jeśli nowy interfejs recenzenta ukrywa ostrzeżenie, należy go uwzględnić w tożsamości. Jeśli kosmetyczna korekta tekstu nie może wpłynąć na oceniane zachowanie, prawdopodobnie należy ją odnotować w historii zmian, ale nie w odcisku oceny. Dobre wersjonowanie to nie maksymalne gromadzenie. To przemyślana trafność.

Uchwyć kontrakt, nie tylko wynik

Wynik jest dowodem czegoś, ale nie zawsze jest dowodem wystarczającym. Zrzut ekranu może pokazać, co pojawiło się na ekranie. Często nie może pokazać, który model go wygenerował, które źródło zostało pobrane, co zwróciło narzędzie, którą regułę zastosowano, które dane wejściowe pominięto ani czy widok ukrył ostrzeżenie. To jeden z powodów, dla których zrzuty ekranu gromadzą się w folderach zgodności z powagą znalezisk archeologicznych, mając przy tym znacznie mniejszą wartość wyjaśniającą.

Uchwycony kontrakt jest bogatszy. Łączy wynik z warunkami, w jakich system miał działać. W przypadku oceny może obejmować dokładny zestaw testów, dane wejściowe lub chronione odniesienie do nich, oczekiwane asercje, konfigurację modelu i usługi, odpowiednie wersje polityk i narzędzi, środowisko wykonawcze, o ile wpływa na wynik, oraz regułę akceptacji. W przypadku działania na żywo może obejmować tożsamość żądania, autoryzowany zakres, zapisy źródeł i wyszukiwania, trasę modelu, wywołania narzędzi, mechanizmy kontrolne, interwencję człowieka i wynikową zmianę stanu. Celem nie jest prowadzenie niekończącego się dziennika. Chodzi o zachowanie wystarczającej ilości istotnych przyczynowo informacji, aby później móc zadać poważne pytanie.

Warto dokonać użytecznego rozróżnienia. Zapis oceny potwierdza twierdzenie dotyczące zdefiniowanego testu lub ćwiczenia. Zapis operacyjny pomaga zrekonstruować konkretne zdarzenie lub decyzję. Zapis wydania wyjaśnia, dlaczego organizacja dopuściła system do określonej trasy. Zapis zmiany wyjaśnia, co później uległo zmianie. Te zapisy nakładają się na siebie, ale nie należy ich mylić. Traktowanie dziennika produkcyjnego jako benchmarku lub benchmarku jako dowodu przepływu pracy w produkcji to skuteczny sposób, aby każdy zapis obciążać ponad jego możliwości.

Przepis dotyczący rejestrowania w AI Act dla systemów wysokiego ryzyka jest podobnie powiązany z celem. Artykuł 12 wymaga automatycznego rejestrowania istotnych zdarzeń przez cały okres istnienia systemu, z możliwościami rejestrowania odpowiednimi do zamierzonego celu. Rozporządzenie odnosi się do możliwości śledzenia działania systemu, monitorowania eksploatacji i monitorowania po wprowadzeniu do obrotu. Nie wymaga bezrefleksyjnego nawyku rejestrowania. Wymaga zapisów, które mają zadanie.

To zdanie, „zapis z zadaniem", jest lepszym przewodnikiem niż ogólne żądanie obserwowalności. Identyfikator modelu może pomóc odróżnić aktualizację. Pochodzenie danych wejściowych może wyjaśnić zaskakującą rekomendację. Wersja reguły może wyjaśnić, dlaczego wynik został zablokowany. Odwołanie recenzenta może wyjaśnić, dlaczego działanie operacyjne różni się od propozycji modelu. Znacznik czasu może ustalić kolejność. Projekt uwzględniający prywatność wciąż pyta, czy każde pole jest konieczne, proporcjonalne, przechowywane przez określony czas i chronione przed samym systemem, który ma kontrolować.

Powtarzalność ma dwie uczciwe formy

Ludzie często używają słowa „powtarzalny" na określenie wielu różnych rzeczy. To zamieszanie jest zrozumiałe. Zespół może mieć na myśli, że może ponownie uruchomić stałą ewaluację i uzyskać ten sam wynik. Badacz może mieć na myśli, że inny zespół może uruchomić opisaną metodę i sprawdzić wynik. Operator może mieć na myśli, że dochodzenie może odtworzyć stan użyty do konkretnej decyzji. Klient może mieć na myśli, że przepływ pracy zapewnia spójne traktowanie, a nie zmienia się arbitralnie z wtorku na czwartek. To powiązane cele. Nie są one jedną właściwością o wielu obliczach.

Po pierwsze, istnieje powtarzalność zarejestrowanego uruchomienia. Jeśli artefakt, konfiguracja, dane wejściowe, istotny stan i warunki wykonania są utrzymywane stałe, powtórzenie powinno dać udokumentowany wynik w warunkach obiecanych przez system. Niektóre systemy mogą złożyć mocniejsze, deterministyczne oświadczenie dla określonej ścieżki wykonania. Inne opierają się na kontrolowanej losowości, rozproszonej infrastrukturze lub usługach stron trzecich i mogą złożyć tylko węższe oświadczenie. Odpowiedzialny język jest konkretny. Mówi, co jest stałe, co jest mierzone, jaka zmienność pozostaje możliwa i jak przeprowadza się porównanie.

Po drugie, istnieje powtarzalność argumentu ewaluacyjnego. Recenzent musi widzieć, dlaczego zestaw reprezentuje twierdzenie, czy metryka ma określone znaczenie, czy próg akceptacji jest uzasadniony i czy dowody mogą zostać przeniesione do kontekstu operacyjnego. Nie rozwiązuje tego suma kontrolna. Suma kontrolna może ustalić, że plik się nie zmienił. Nie może ustalić, że plik testował właściwe pytanie, że populacja była odpowiednia lub że wynik wspiera decyzję, do której jest dołączony.

Te dwie formy powinny się spotkać. Doskonale powtarzalny test, który mierzy niewłaściwą rzecz, wciąż jest niewłaściwym testem. Wyrafinowany argument dołączony do niepowtarzalnego uruchomienia pozostawia recenzentów niezdolnych do odróżnienia odkrycia od szczęśliwego popołudnia. Użyteczny standard to nie abstrakcyjne żądanie doskonałej powtarzalności. To widoczna zgodność między twierdzeniem, metodą, zarejestrowanymi warunkami, zaobserwowanym wynikiem i zastosowaniem, które organizacja chce dopuścić.

Wytyczne Komisji dotyczące obowiązków dostawców modeli AI ogólnego przeznaczenia również utrzymują ewaluację w związku z dokumentacją i ryzykiem. Opisują one dokumentację techniczną dla organów oraz oddzielne informacje dla dostawców niższego szczebla, w tym możliwości, ograniczenia i informacje o integracji. W przypadku modeli AI ogólnego przeznaczenia stwarzających ryzyko systemowe art. 55 wymaga ewaluacji z wykorzystaniem standaryzowanych protokołów i najnowocześniejszych narzędzi, w tym udokumentowanych testów kontradyktoryjnych w celu identyfikacji i łagodzenia ryzyk systemowych. Ewaluacja, która nie może powiedzieć, co było testowane, w jakich warunkach i z jakimi ograniczeniami, nie staje się bardziej użyteczna przez nazwanie jej standaryzowaną.

Dowody mają termin ważności

Dowody nie wygasają dlatego, że ktoś postanowił być trudny. Wygasają wtedy, gdy warunki, które pozwalały im wspierać dane twierdzenie, zmieniły się na tyle, że tego związku nie można już zakładać. To zwykłe rozumowanie. Test projektu mostu nie obejmuje automatycznie innego materiału. Kontrola bezpieczeństwa żywności nie obejmuje nowego dostawcy siłą optymizmu. Ocena trasy AI nie powinna automatycznie obejmować zmienionego modelu, zmienionej granicy danych, zmienionych uprawnień narzędzi ani zmienionych konsekwencji decyzji.

Trudna praca polega na ustaleniu, które zmiany mają znaczenie. To kwestia oceny technicznej, analizy ryzyka i zarządzania, a nie pojedynczego procentu zapisanego w polityce. Poprawka zmieniająca kolor przycisku może nie mieć żadnego wpływu na ocenę. Zmiana sprawiająca, że ostrzeżenie jest mniej widoczne, może być istotna, jeśli argument bezpieczeństwa zależy od tego, czy recenzent je zobaczy. Ponowne indeksowanie korpusu źródłowego może być nieszkodliwe dla jednego zadania i krytyczne dla innego. Nowy punkt końcowy modelu może zachować szeroką funkcjonalność, jednocześnie zmieniając opóźnienie, zachowanie odmowy, zakres językowy lub wzorce korzystania z narzędzi, które mają znaczenie dla trasy.

Użyteczna kontrola zmian zaczyna się zatem od pytania o wpływ, a nie od rytuału wydawniczego. Na jakie twierdzenie ta zmiana może wpłynąć? Które założenie narusza? Które dowody były zależne od poprzedniego stanu? Czy ograniczona kontrola odpowiada na pytanie, czy trasa wymaga nowej oceny i decyzji o wydaniu? Kto może podjąć tę decyzję i kto może ją zakwestionować? Odpowiedzi należy zapisać, ponieważ w przeciwnym razie następny recenzent będzie musiał je wywnioskować z tytułów zgłoszeń, przekazów ustnych i nieznacznej zmiany czcionki na pulpicie wydawniczym.

To również moment, w którym monitorowanie staje się częścią dowodów, a nie osobnym hobby obserwacyjnym. Artykuł 72 wymaga, aby dostawcy systemów AI wysokiego ryzyka aktywnie i systematycznie gromadzili, dokumentowali i analizowali istotne dane dotyczące wydajności przez cały okres życia systemu, aby mogli oceniać ciągłą zgodność. Plan monitorowania po wprowadzeniu do obrotu stanowi część dokumentacji technicznej. Monitorowanie nie jest zatem jedynie sposobem na sprawdzenie, czy usługa jest obciążona. To sposób na sprawdzenie, czy warunki stojące za pierwotnym twierdzeniem nadal obowiązują.

Monitorowanie nie sprawia, że każdy wynik jest oczywisty. Wzrost rozbieżności między recenzentami a systemem może mieć wiele przyczyn. Zmiana świeżości źródeł może odzwierciedlać problem z potokiem danych, a nie dryf modelu. Wyższy wskaźnik odmów może oznaczać bezpieczniejszą politykę, uszkodzoną integrację lub nową populację zapytań. Rejestr powinien zachować wystarczająco dużo kontekstu, aby umożliwić ludzkie dochodzenie. Metryki to sygnały. Nie są świadkami.

Dowody są ważne w określonym kontekście. Istotna zmiana rodzi pytanie do przeglądu, a nie lukę wokół przeglądu.

Istotna zmiana wymaga ścieżki decyzyjnej

Pojęcie „istotnej zmiany" bywa traktowane tak, jakby nazywało jakąś oczywistą właściwość. Tak nie jest. Istotna dla kogo, dla jakiego twierdzenia, dla jakiego ryzyka i dla jakiego użytkownika? Odpowiedź musi być na tyle konkretna, żeby można było z niej skorzystać, gdy jest się zmęczonym, spóźnionym i chętnym, by nazwać zmianę drobną. Dobra polityka nie obiecuje, że z góry zaklasyfikuje każdą możliwą aktualizację. Wskazuje czynniki, które decydują o tym, czy ponowna ocena jest potrzebna.

Na te czynniki składają się zwykle: zamierzony cel, osoby, których zmiana dotyczy, uprawnienia przyznane trasie, źródła danych i ich kontrola jakości, architektura modelu lub systemu, zakres oceny, progi decyzyjne, sygnały monitorujące, nadzór człowieka, zabezpieczenia i ścieżki odzyskiwania. Modyfikacja, która zmienia którykolwiek z tych elementów, może być istotna lub nie. Liczy się to, czy może zmienić dowody wymagane dla istniejącego twierdzenia albo ryzyko pozostające po zastosowaniu zabezpieczeń.

Akt w sprawie sztucznej inteligencji nakłada wyraźny obowiązek dotyczący istotnej modyfikacji. Jego dokładne zastosowanie prawne zależy od systemu i zaangażowanych podmiotów, więc nie powinien być sprowadzany do hasła. Wniosek operacyjny jest prostszy i szerszy: organizacja powinna wiedzieć, kiedy zmiana przenosi lub tworzy odpowiedzialność, kiedy dotychczasowa dokumentacja przestaje być wystarczająca oraz kiedy system musi zostać ponownie oceniony, zanim nowe zastosowanie będzie kontynuowane. To mniej ekscytujące niż premiera funkcji. Ale też mniej prawdopodobne, że doprowadzi do trudnej sytuacji, w której wszyscy zgadzają się, że system się zmienił, a nikt nie bierze odpowiedzialności za decyzję.

Ścieżka decyzyjna daje zmianie miejsce, do którego może trafić. Jedna ścieżka może pozwolić na udokumentowane stwierdzenie braku wpływu. Inna może wymagać ukierunkowanej oceny regresji. Kolejna może wymagać szerszego przeglądu ryzyka, zmiany instrukcji użytkowania, zaktualizowanego planu monitorowania lub nowej zgody na wydanie. Najpoważniejsza ścieżka może wymagać, aby trasa pozostała ograniczona lub wstrzymana, dopóki nie będą dostępne dowody. Nie chodzi o to, by każda edycja była kosztowna. Chodzi o to, by ważnej edycji nie dało się ukryć jako rutynowych porządków.

Jest w tym satysfakcjonujący brak romantyzmu. Rejestr zmian może pokazywać stan poprzedni, stan proponowany, twierdzenia, których dotyczy, przejrzane dowody, decyzję, osobę decydującą i warunki po wydaniu. To governance w stroju roboczym. Nigdy nie będzie wyglądać tak efektownie jak pokaz modelu. Ma za to bardziej użyteczną właściwość: pomaga organizacji wytłumaczyć się, gdy pokaz stał się prawdziwą usługą.

Ocena powinna móc zakończyć się niepowodzeniem publicznie, albo przynajmniej w pliku

Ocena staje się performatywna, gdy każdy wynik traktuje się jako wynik wydania. Dojrzały program oceny musi móc stwierdzić, że dowody są niekompletne, że próg nie został osiągnięty, że znane ograniczenie uniemożliwia proponowane zastosowanie albo że twierdzenie wymaga zawężenia. To nie są wstydliwe wyjątki od procesu. To wyniki procesu.

Jest to szczególnie ważne w przypadku systemów adaptacyjnych lub podłączonych zewnętrznie. Zespół może odkryć, że zestaw testów nie odzwierciedla już rzeczywistej populacji wejściowej. Kontrakt narzędzia może stać się zbyt niestabilny, by wspierać twierdzenie o odtwarzalności. Aktualizacja modelu może poprawić jedno zadanie, ale utrudnić nadzór nad chronioną trasą. Sygnał operacyjny może pokazać, że przekazanie od systemu do recenzenta zawodzi przy zwykłym obciążeniu pracą. Właściwa odpowiedź nie musi być dramatycznym wyłączeniem. Może nią być ograniczenie, zmieniony przepływ pracy, dodatkowy test, nowy warunek akceptacji albo decyzja o nierozszerzaniu pierwotnego twierdzenia.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

Istnieje organizacyjna pokusa, aby traktować monitorowanie jako zadanie zespołu operacyjnego, a ewaluację jako zadanie zespołu modeli. Taki podział zawiedzie przy pierwszym istotnym pytaniu dotyczącym aktywnej trasy. Osoba budująca model może wiedzieć, dlaczego wybrano dany test. Operator może wiedzieć, że źródła były nieaktualne. Właściciel polityki może wiedzieć, że zmieniła się reguła decyzyjna. Recenzent może wiedzieć, że interfejs powoduje błąd automatyzacji. Ślad audytowy powinien łączyć ich ustalenia, nie udając, że jedna osoba widzi cały system.

Czy regulator może odtworzyć decyzję?

Czasami odpowiedź powinna brzmieć: tak, w określonym zakresie. Jeśli organizacja twierdzi, że decyzję lub ewaluację można powtórzyć, musi określić, co oznacza powtórzenie. Czy chodzi o ponowne wywołanie modelu z tym samym promptem? Czy o odtworzenie pełnej sekwencji wyszukiwania i narzędzi? Czy o zrekonstruowanie zapisu, który widział recenzent? Czy o weryfikację deterministycznych obliczeń na podstawie zachowanych danych wejściowych? Każde z tych podejść jest użyteczne. Każde ma inne wymagania techniczne i prawne.

Wiarygodne odtworzenie zaczyna się od zachowanej tożsamości. Recenzent musi wiedzieć, która wersja systemu i konfiguracja obowiązywały, które dane wejściowe i wersje źródeł były dopuszczalne, które polityki i uprawnienia miały zastosowanie, które zależności zewnętrzne odpowiedziały oraz które działania ludzi zmieniły ścieżkę. Niektóre elementy mogą wymagać bezpośredniego przechowywania. Inne można wskazać przez stabilne identyfikatory i odtworzyć za pomocą kontrolowanych systemów. Niedopuszczalne jest nazywanie ćwiczenia możliwym do odtworzenia, gdy zależy ono od wyszukiwania na żywo w sieci, nadpisanej kolumny w bazie danych i ustawienia zapamiętanego na laptopie inżyniera.

Nawet wtedy odtworzenie może odtworzyć zapis, a nie powtórzyć świat. Źródło na żywo może zostać zaktualizowane lub wycofane. Usługa zewnętrzna może się zmienić. Usługa adaptacyjna może gromadzić nowy stan regulowany. Człowiek może podjąć inną decyzję, gdy otrzyma te same informacje. To nie są wady idei odtwarzania. To rozróżnienia, które zapis musi zachować. Odtworzenie może pokazać, co system zrobił w ramach zarejestrowanego kontraktu. Nie twierdzi, że obecny świat jest identyczny z tym kontraktem.

Dlatego zapisy decyzji ludzi powinny znajdować się obok zapisów technicznych, gdy nadzór człowieka jest częścią argumentu o bezpieczeństwie lub prawach. Audyt może potrzebować wiedzieć, że osoba przejrzała rekomendację, jakie informacje miała do dyspozycji, co wybrała i jakie posiadała uprawnienia. Nie musi zamieniać każdego recenzenta w obiekt inwigilacji ani przechowywać nieograniczonych danych osobowych. Musi jednak zawierać wystarczająco dużo informacji, aby ustalić, czy obiecany nadzór faktycznie istniał w badanym zdarzeniu.

Odtwarzanie jest zatem drabiną, a nie przechwałką. Na jednym szczeblu recenzent może zidentyfikować wydanie. Na kolejnym może zbadać dowody. Wyżej może odtworzyć test lub przeanalizować ścieżkę decyzji na żywo. Organizacja powinna określić, który szczebel obsługuje, gdzie są granice i które części wymagają autoryzowanego dostępu. Skromne, możliwe do przetestowania twierdzenie o odtwarzalności jest znacznie mocniejsze niż niejasna zapewnienie, że wszystko można prześledzić.

Audyty potrzebują zapisów, które się ze sobą różnią

Publiczny zapis statusu organizacji, wewnętrzny zapis wydania, raport z ewaluacji, logi operacyjne i rejestr incydentów nie powinny mówić różnych rzeczy o tym samym podstawowym stanie. Nie powinny jednak być też identycznymi dokumentami. Każdy ma inną grupę odbiorców i cel. Zapis publiczny może określać zamierzony cel, status, znane ograniczenia i drogę do dalszych informacji. Plik techniczny może zawierać szczegółową architekturę, dane, testy i mechanizmy kontroli. Zapis operacyjny może zawierać identyfikowalność na poziomie zdarzeń. Plik zmian może wyjaśniać, dlaczego ponownie rozważono wcześniejszy wniosek.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Przede wszystkim to pytanie zmienia rolę zmiany. Zmiana przestaje być wstydliwym tematem, który dokumentacja stara się ukryć. Staje się pełnoprawnym zdarzeniem w modelu dowodowym systemu. Niektóre zmiany będą wymagać niewiele więcej niż wpisu. Niektóre uruchomią test. Niektóre ponownie otworzą decyzję o wydaniu. Zdyscyplinowana organizacja nie myli tych kategorii i nie potrzebuje przyszłego incydentu, aby odkryć, że one istnieją.

Więc tak: regulator może przeprowadzić audyt ruchomego celu. Audyt zaczyna się od odrzucenia fałszywego wyboru między zamrożoną kartą modelu a całkowicie niepoznawalną usługą działającą na żywo. Zarejestruj stan. Sformułuj twierdzenie. Zachowaj warunki. Powiąż dowody z decyzją. Zapisz, co się zmienia. Oceń ponownie, gdy powiązanie przestaje obowiązywać. Cel może się poruszać. Ślad musi pozostać czytelny.

Źródła