Cicha praca unijnego aktu o AI: zapisy, nie slogany

Trudna część unijnego aktu o sztucznej inteligencji to nie powtarzanie jego zasad, lecz przełożenie ryzyka, dokumentacji, logowania, nadzoru człowieka i...

Cicha praca unijnego aktu o AI: zapisy, nie slogany

Zapis, który powstaje po decyzji

Jest taki moment po zaakceptowaniu automatycznej rekomendacji, gdy zmienia się kształt pomieszczenia. Ekran wciąż pokazuje wynik. Rozmowa przeszła już do tego, co będzie dalej. Ktoś pyta, która wersja systemu go wygenerowała, jakie informacje były wówczas dostępne, czy operator mógł go odrzucić i która reguła uczyniła trasę dopuszczalną. Te pytania nie są dramatycznym atakiem na technologię. To zwykłe pytania, jakie instytucje zadają, gdy działanie zyskuje konsekwencję.

Wyobraźmy sobie przypadek zbiorczy, celowo bez nazwanej organizacji, systemu czy incydentu. Organ publiczny używa systemu AI wysokiego ryzyka do wsparcia decyzji, która dotyczy osoby. Przeszkolony członek personelu pozostaje odpowiedzialny za decyzję. Model daje wynik, członek personelu go sprawdza i decyzja zostaje podjęta. Później przełożony musi zrozumieć ścieżkę. Sam wynik jest obecny. Decyzja jest obecna. Łańcuch między nimi nie jest. Nie ma jasnego zapisu obowiązujących instrukcji, użytych danych wejściowych, wdrożonej wersji, dostępnej interwencji ani powodu, dla którego człowiek zaakceptował wynik. Nic w tym opisie nie wymaga spektakularnej awarii. Brakujący zapis wystarczy, by przegląd zamienił się w ćwiczenie z rekonstrukcji.

Akt o sztucznej inteligencji Unii Europejskiej jest często omawiany jako katalog zakazów, kategorii i kar. Te części mają znaczenie, ale nie stanowią całego dzieła. Akt opisuje także cichszą infrastrukturę dowodów: zarządzanie ryzykiem, które jest udokumentowane i utrzymywane, praktyki dotyczące danych, które mają pochodzenie i cel, dokumentację techniczną, którą można ocenić, dzienniki rejestrujące istotne zdarzenia, instrukcje mówiące wdrażającemu, jak interpretować system, nadzór człowieka mający realną władzę oraz zapisy pozostające dostępne, gdy później pojawi się pytanie. Prawo wymaga od instytucji, by pamiętała celowo.

To mniej filmowe zadanie niż uruchomienie modelu. To także miejsce, gdzie odpowiedzialność staje się realna. Hasło może głosić, że organizacja bierze odpowiedzialność. Zapis może pokazać, jak odpowiedzialność wyglądała w konkretnym czasie. Może pokazać granicę, niepewność, zatwierdzenie, odmowę, korektę lub nieobecność. Nie może uczynić niezgodnej z prawem decyzji zgodną z prawem przez samo istnienie po fakcie i nie może sam naprawić czyjejś straty. Może uczynić ścieżkę wystarczająco przejrzystą dla środka zaradczego, korekty i lepszej decyzji co do następnej wersji.

Ten artykuł dotyczy tej cichej pracy. Czyta obowiązki dotyczące prowadzenia zapisów i dokumentacji w Akcie o sztucznej inteligencji jako wymogi operacyjne, a nie jako papierologię dołączoną do uruchomienia. Pyta, co zapisy mogą ustalić, czego nie mogą ustalić, jak zapis zyskuje znaczenie z kontekstu, dlaczego kompletność nie jest tym samym co objętość oraz jak organizacja może zbudować rutynę pozostawiającą dowody bez zamieniania każdej ludzkiej interakcji w trwały obiekt nadzoru. Przykłady, które nie pochodzą bezpośrednio z cytowanego źródła, są oznaczone jako proponowane, hipotetyczne lub zbiorcze. Na końcu historii nie czeka żaden zmyślony incydent. Chodzi o to, by go nie potrzebować.

Obowiązki wynikające z aktu nie są osobnymi półkami. Tworzą one ścieżkę od celu i ryzyka do dowodów, nadzoru i środków zaradczych.

Dlaczego cicha praca ma znaczenie

Zapisy łatwo źle zrozumieć, ponieważ występują w niemal każdej organizacji. Wiersz bazy danych, zgłoszenie, wniosek o zmianę, podpisana decyzja, znacznik czasu i wpis w dzienniku zdarzeń wyglądają jak zapisy. Ich sama obecność niewiele mówi. Zapis staje się użyteczny, gdy odpowiada na określone pytanie, dostarczając wystarczającego kontekstu, aby odróżnić to, co się wydarzyło, od tego, co ktoś obecnie uważa, że się wydarzyło. To rozróżnienie jest szczególnie ważne w przypadku sztucznej inteligencji, ponieważ widoczny wynik często ukrywa liczbę przekształceń, które go poprzedziły.

Konwencjonalny system oprogramowania może pozostawiać ślad dobrze znany jego operatorom. Wpływa żądanie, usługa waliduje pola, uruchamia się reguła, zmienia się stan i wychodzi odpowiedź. Systemy AI mogą dodawać wnioskowane kategorie, pobrany kontekst, instrukcje w języku naturalnym, wyniki probabilistyczne, wywołania narzędzi, edycje ludzkie i stan adaptacyjny. Ta dodatkowa elastyczność może być użyteczna. Stwarza też więcej okazji do tego, by fakt stracił swoje pochodzenie albo by instrukcja stała się wiążąca bez uznania jej za taką. Zapis musi zachowywać rozróżnienia, które interfejs jest skłonny zacierać.

Akt o sztucznej inteligencji nie wymaga od organizacji przechowywania każdego bajtu, który kiedykolwiek przeszedł przez model. Jego wymagania są powiązane z celem, ryzykiem, możliwością śledzenia, cyklem życia i kontrolą. To użyteczny punkt wyjścia. Mówi on, że dowody powinny być proporcjonalne do zamierzonego celu i ryzyka, pozostając jednocześnie wystarczająco rygorystyczne dla danej obowiązku. Zapisu dotyczącego sugestii o niskim wpływie nie należy traktować tak, jakby był kompletną dokumentacją decyzji wpływającej na prawa podstawowe. I odwrotnie, ważna decyzja nie może być rozliczalna poprzez zapisanie jednego końcowego zdania i zielonego znacznika.

Cicha praca zaczyna się zatem przed oddaniem systemu do użytku. Ktoś musi określić, do czego system ma służyć, gdzie nie ma działać, którzy ludzie i środowiska są objęte zakresem, jakie dane wejściowe może przyjmować, kto może działać na podstawie wyniku oraz co się dzieje, gdy system jest niepewny lub niedostępny. To nie są tylko pytania projektowe. To warunki, które nadają późniejszym zapisom znaczenie. Bez nich znacznik czasu mówi nam, kiedy coś się wydarzyło, ale nie, czy było to dozwolone, oczekiwane czy wyjątkowe.

Istnieje instytucjonalny powód, by traktować to poważnie. Osoba, która prosi o dowody, często nie jest osobą, która zbudowała system. Właściwy organ, audytor wewnętrzny, osoba, której sprawa dotyczy, lub zespół przejmujący obowiązki mogą zapoznać się z dokumentacją po tym, jak zmienili się pracownicy, dostawcy i modele. Dowody, które mają sens wyłącznie dla ich pierwotnego autora, są kruchą formą odpowiedzialności. Nacisk aktu na jasną dokumentację, zrozumiałe instrukcje i dostęp dla organów jest odpowiedzią na tę kruchość. Traktuje ciągłość jako element zgodności.

Czytaj akt jako ciąg zdarzeń, nie jako hasło

Wymogi dotyczące wysokiego ryzyka zawarte w rozporządzeniu można czytać jako ciąg pytań. Co system ma robić. Jakie ryzyka może stwarzać w tym kontekście. Jakie dane i założenia go wspierają. Jak system został zbudowany i przetestowany. Co musi wiedzieć podmiot wdrażający. Jakie zdarzenia należy rejestrować. Kto może nadzorować, zmieniać lub zatrzymywać system. Co się dzieje, gdy system nie jest zgodny z wymogami lub stwarza ryzyko. Ten ciąg nie jest prostym potokiem oprogramowania. To łańcuch odpowiedzialności, który wraca do początku, gdy zmieniają się dowody.

Artykuł 9 opisuje zarządzanie ryzykiem jako ciągły, iteracyjny proces planowany i prowadzony przez cały cykl życia systemu AI wysokiego ryzyka. Proces ten musi zostać ustanowiony, wdrożony, udokumentowany i utrzymywany. To sformułowanie ma praktyczne konsekwencje. Ocena ryzyka nie jest ceremonialnym dokumentem, który przechodzi na emeryturę w dniu wdrożenia. To zapis żywego procesu, który identyfikuje i ocenia znane oraz możliwe do przewidzenia w uzasadniony sposób ryzyka, uwzględnia informacje z monitorowania po wprowadzeniu do obrotu i przyjmuje ukierunkowane środki. Zapis ten powinien pozwolić późniejszemu czytelnikowi zobaczyć, co wzięto pod uwagę, czego nie można było wyeliminować, co pozostało jako ryzyko szczątkowe i kto zaakceptował takie stanowisko.

Artykuł 10 umieszcza dane i zarządzanie danymi w ramach tej samej dyscypliny. Istotne praktyki obejmują wybory projektowe, pochodzenie danych, operacje przygotowawcze, założenia dotyczące tego, co dane przedstawiają, dostępność i przydatność, możliwe błędy systematyczne, luki w danych oraz środki zastosowane w celu ich rozwiązania. To inne podejście niż stwierdzenie, że zbiór danych był czysty. Czystość to wniosek. Pochodzenie, przygotowanie, założenia i luki to dowody na to, jak osiągnięto wniosek i gdzie może on przestać być wiarygodny. Zapis, który zachowuje wyłącznie etykietę jakości, zapomniał o pytaniach, które nadały jakości znaczenie.

Artykuł 11 wymaga dokumentacji technicznej dla systemu AI wysokiego ryzyka przed wprowadzeniem go do obrotu lub oddaniem do użytku oraz wymaga, aby dokumentacja ta była aktualizowana. Ma ona zapewnić krajowym właściwym organom i jednostkom notyfikowanym informacje potrzebne do oceny zgodności. Istotne nie jest to, aby każdy czytelnik stał się specjalistą od załącznika. Chodzi o to, aby system miał opis samego siebie wystarczająco jasny i wyczerpujący do oceny zewnętrznej. Taki opis potrzebuje wersji, celu i odniesienia do wcześniejszych wersji. Dokument opisujący system, który już nie istnieje, jest archiwum, a nie aktualnym dowodem.

Artykuł 12 czyni następnie samo działanie systemu częścią dowodów. Systemy AI wysokiego ryzyka muszą technicznie umożliwiać automatyczną rejestrację zdarzeń przez cały okres ich użytkowania. Możliwości rejestrowania muszą obejmować zdarzenia istotne dla identyfikacji sytuacji, które mogą stwarzać ryzyko lub istotną modyfikację, ułatwiać monitorowanie po wprowadzeniu do obrotu oraz monitorowanie działania w ramach obowiązków podmiotu wdrażającego. Wymagany poziom możliwości śledzenia jest powiązany z zamierzonym celem. Prawo nie wymaga, aby dziennik był pamiętnikiem z życia ludzi. Wymaga, aby system pozostawił wystarczającą pamięć operacyjną, by można było odpowiedzieć na istotne pytania.

Artykuły 13 i 14 łączą tę pamięć z ludźmi. System wysokiego ryzyka musi być na tyle przejrzysty, aby wdrażający mogli interpretować jego wyniki i właściwie z nich korzystać, a także musi być do niego dołączona instrukcja użytkowania. Nadzór człowieka musi być skuteczny i proporcjonalny do ryzyka, autonomii i kontekstu. Osoby wyznaczone do sprawowania nadzoru muszą być w stanie zrozumieć możliwości i ograniczenia, zauważać anomalie i nieoczekiwane działanie, unikać nadmiernego polegania, interpretować wyniki, odrzucać je lub je unieważniać oraz, w stosownych przypadkach, bezpiecznie przerywać działanie systemu. Te umiejętności nie mogą istnieć wyłącznie na slajdzie szkoleniowym. Rzetelny zapis powinien umożliwiać ustalenie, co człowiek mógł wiedzieć i zrobić w momencie podejmowania decyzji.

Artykuły od 15 do 21 dopełniają łuk od działania do naprawy. Dokładność, odporność i cyberbezpieczeństwo to właściwości całego cyklu życia. Dostawcy muszą utrzymywać system zarządzania jakością, który jest udokumentowany w uporządkowany sposób i obejmuje procedury dotyczące danych, zarządzanie ryzykiem, monitorowanie po wprowadzeniu do obrotu, zgłaszanie incydentów, komunikację, prowadzenie rejestrów oraz ramy odpowiedzialności. Dokumentacja i logi muszą być dostępne przez okresy i do celów określonych w rozporządzeniu. Działania naprawcze i współpraca z właściwymi organami to obowiązki, a nie opcjonalny public relations. Efektem nie jest slogan o godnej zaufania sztucznej inteligencji. Jest to zestaw artefaktów, które pozwalają instytucji wykazać, zbadać, skorygować i wyjaśnić.

Trzy rzeczy, które może zrobić zapis

Po pierwsze, zapis może ustalić zdarzenie. Może pokazać, że system został uruchomiony, że aktywna była konkretna wersja, że otrzymano dane wejściowe, że zaproponowano wywołanie narzędzia, że zarejestrowano zatwierdzenie przez człowieka, że ukończono działanie lub że zatrzymano system. Dowód zdarzenia to warstwa, którą większość ludzi wyobraża sobie, słysząc słowo log. Ma to znaczenie, ponieważ spornego działania nie można zbadać, jeśli organizacja nie potrafi stwierdzić, czy działanie miało miejsce. Jest to również najmniej kompletna warstwa, jeśli występuje samodzielnie.

Zapis zdarzenia potrzebuje stabilnej tożsamości, odniesienia czasowego, podmiotu działania lub roli odpowiedzialnej, tożsamości systemu lub komponentu oraz wystarczającego stanu, aby uniknąć niejednoznaczności. Dokładne pola zależą od celu i prawa. Znacznik czasu bez podstawy czasowej może być mylący w różnych systemach. Identyfikator użytkownika bez roli niewiele mówi o uprawnieniach. Nazwa modelu bez wersji nie pozwala ustalić, które zachowanie było w zakresie. Zapis może być technicznie autentyczny, a mimo to instytucjonalnie ubogi.

Po drugie, zapis może ustalić podstawę. Może pokazać, który cel, zasada, instrukcja, źródło danych, wersja polityki lub ocena stanowiły podstawę działania. Dowód podstawy zapobiega temu, aby decyzja stała się swobodnie pływającym wynikiem. Nie musi odtwarzać każdego wewnętrznego obliczenia. Musi natomiast wskazać warunki, które nadały wynikowi znaczenie, oraz granice, które ograniczały to, co dana osoba mogła z nim zrobić. Gdy brakuje podstawy, organizacja może wiedzieć, co zrobiła, nie wiedząc, dlaczego miała do tego prawo.

Po trzecie, zapis może ustalić reakcję. Może pokazać, że zauważono anomalię, że operator odrzucił wynik, że eskalowano ryzyko, że zawieszono system, że zastosowano korektę lub że przyjęto i przekazano skargę. Dowód reakcji jest często pomijany, ponieważ zespoły skupiają się na pierwszym wyniku modelu. W praktyce odpowiedzialność przejawia się w tym, co dzieje się po tym, gdy niepewność staje się widoczna. System, który może wytworzyć zapis problemu, ale nie ma zapisu reakcji, zbudował czujnik bez hamulca.

Te trzy funkcje nakładają się na siebie, ale nie należy ich łączyć. Cytowanie źródła może stanowić podstawę bez dowodu, że źródło zostało faktycznie użyte w danym przebiegu. Zatwierdzenie przez człowieka może stanowić odpowiedź bez dowodu, że recenzent widział pełny kontekst. Wersja modelu może stanowić tożsamość bez dowodu, że wersja działała spójnie. Dobre zapisy wprost określają, jakie twierdzenia mogą potwierdzić. Nie pożyczają autorytetu od sąsiednich zapisów i nie nazywają tego układem łańcuchem.

Kompletność to nie liczba bajtów. To zdolność do udzielenia odpowiedzi na pytania, które stwarzają cel systemu i jego konsekwencje.

Czego zapis nie może zrobić

Zapis nie może przekształcić praktyki zakazanej w dozwoloną. Jeśli samo użycie jest niezgodne z prawem, doskonałe logowanie nie stanowi obrony. Dowody mogą ujawnić błędną decyzję, ale nie mogą wstecznie nadać uprawnień, które nigdy nie istniały. Dlatego dokumentacja nigdy nie powinna być przedstawiana jako substytut analizy prawnej, oceny praw podstawowych ani jasnego celu. Pięknie zindeksowane naruszenie nadal jest naruszeniem. Indeks jedynie ułatwia jego znalezienie.

Zapis nie może dowieść, że decyzja była sprawiedliwa tylko dlatego, że pola są wypełnione. Sprawiedliwość nie jest właściwością, która pojawia się, gdy formularz osiąga sto procent. Istotne pytanie brzmi, czy system, dane, przepływ pracy i ludzki osąd traktowały ludzi w sposób respektujący obowiązujące prawa i obowiązki. Zapis może zachować dowody dotyczące tego pytania. Może pokazać, jakie informacje wykorzystano, jaką regułę zastosowano, które wyjątki rozważono i jak rozpatrzono odwołanie. Nie może sam rozstrzygnąć kwestii moralnej i prawnej.

Zapis nie może uczynić słabego wyjaśnienia znaczącym przez dodanie szczegółów technicznych. Osoba, której dotyczy decyzja, może potrzebować jasnego opisu roli, jaką odegrała sztuczna inteligencja, oraz głównych elementów decyzji. Wyrzucanie na tę osobę wewnętrznych identyfikatorów, surowych śladów tokenów czy ekranu pełnego telemetrii maszynowej nie jest automatycznie przejrzystością. Forma dowodów musi odpowiadać pytaniu i odbiorcy. Organy nadzorcze potrzebują ocenialnej dokumentacji. Operatorzy potrzebują użytecznych instrukcji. Osoby, których dotyczy decyzja, potrzebują zrozumiałej ścieżki do jej zrozumienia i zakwestionowania.

Zapis nie może zachować przyszłości. Jest spojrzeniem z konkretnego momentu, powstałym na podstawie informacji i stanu systemu, które istniały wtedy. To ograniczenie nie jest wadą. Jest powodem, aby rejestrować wersje, okresy obowiązywania i niepewność. Jeśli polityka zmieniła się po podjęciu decyzji, zapis nie powinien po cichu prezentować nowej polityki tak, jakby obowiązywała przy dawnej czynności. Jeśli źródło zostało poprawione, wcześniejsze dane wejściowe powinny pozostać możliwe do zidentyfikowania, a poprawka i jej skutek powinny być odnotowane. Czas jest częścią znaczenia, a nie ozdobą po prawej stronie pulpitu nawigacyjnego.

Zapis nie może powiedzieć organizacji tego, czego nie odnotowano. To brzmi oczywiście, ale jest to ważna granica w erze generowanych wyjaśnień. Model można poprosić o opisanie przeszłej decyzji. Powstała proza może być przydatna jako hipoteza lub podsumowanie. Jeśli nie jest oparta na zachowanych dowodach, nie jest wehikułem czasu. Bezpieczniejszą praktyką jest oznaczenie rekonstrukcji jako rekonstrukcji, wskazanie brakujących dowodów i unikanie przedstawiania prawdopodobnego opisu jako zaobserwowanego. Uczciwa niekompletność jest bardziej użyteczna niż kompletna fikcja.

Dzienniki są dowodem, a nie moralnym alibi

Rejestrowanie jest atrakcyjne, ponieważ wydaje się obiektywne. Wiersz ze znacznikiem czasu i identyfikatorem systemu wygląda na bardziej neutralny niż notatka człowieka. Nie jest neutralny. Ktoś zdecydował, co rejestrować, co pominąć, które pola zachować, jak je chronić, jak synchronizować czas i kto może przeglądać wynik. Rejestrowanie to decyzja inżynierska o konsekwencjach prawnych i ludzkich. Przepisy aktu o sztucznej inteligencji dotyczące prowadzenia rejestrów uwidaczniają tę decyzję, ale nie eliminują potrzeby starannego jej zaprojektowania.

Pierwszym pytaniem projektowym jest cel. Artykuł 12 wymienia identyfikowalność, identyfikację ryzyka, monitorowanie po wprowadzeniu do obrotu i monitorowanie działania jako powody rejestrowania istotnych zdarzeń. Każdy z tych powodów może wymagać innego widoku. Operator może potrzebować zwięzłego wyjaśnienia odmowy i ścieżki do przełożonego. Specjalista ds. bezpieczeństwa może potrzebować wersji oraz pochodzenia danych wejściowych. Właściwy organ może potrzebować dokumentacji i dzienników wystarczających do oceny zgodności. Inspektor ochrony danych może potrzebować wiedzy, które dane osobowe zawiera dziennik i dlaczego są przechowywane. Jeden niezróżnicowany strumień może być jednocześnie zbyt hałaśliwy dla człowieka i zbyt słaby dla dochodzenia.

Drugie pytanie dotyczy zakresu. Użyteczny dziennik rejestruje zdarzenia istotne dla zamierzonego celu i ryzyka, a nie każdy przypadkowy gest. W przypadku systemu, który jedynie tworzy projekty tekstów wewnętrznych, istotnym zdarzeniem może być wywołanie, zestaw źródeł, wersja modelu, wersja instrukcji, zatwierdzenie przez człowieka i ostateczne przeznaczenie. W przypadku systemu, który może zmienić zewnętrzny zapis, przejścia stanów i potwierdzenia narzędzi stają się niezbędne. W przypadku systemu wspierającego decyzję o dużym wpływie zakres danych wejściowych, wynik, przegląd przez człowieka i ścieżka korekty mają większe znaczenie niż dekoracyjny licznik tokenów. Zapis powinien podążać za konsekwencjami.

Trzecie pytanie dotyczy integralności. Zapis, który można edytować bez wykrycia, może być nadal użyteczny do celów operacyjnych, ale słabiej świadczy o historii. Mechanizmy integralności mogą obejmować ograniczenia dostępu, pamięć masową tylko do zapisu, sumy kontrolne, podpisy, niezależne odniesienia czasowe, kontrolowane poprawki i udokumentowane okresy przechowywania. Odpowiedni mechanizm zależy od ryzyka. Najważniejsze jest określenie, co mechanizm chroni, a czego nie chroni. Dowód naruszenia może wykazać, że zapis został zmieniony. Nie może wykazać, że pierwotny zapis był kompletny ani że zarejestrowane zdarzenie było zgodne z prawem.

The fourth question is privacy. Logs can contain prompts, identifiers, source excerpts, model outputs, tool arguments and human notes. Keeping all of them forever may create a second problem in the name of solving the first. The Regulation itself connects the logging duties to other Union and national law, including data protection. A sensible design separates operational evidence from unnecessary content, limits access, defines retention and supports correction or deletion where required. Minimisation is not an enemy of accountability. It is what keeps accountability from becoming a licence to collect a private biography of every user.

The fifth question is replay. Replay does not always mean rerunning a probabilistic model and expecting the same sentence. It can mean reconstructing the relevant state: the model and policy versions, source references, input classification, instruction set, output, human intervention, tool result and subsequent action. A replay may reveal that exact reproduction is impossible because a remote dependency changed. That result is still evidence if the system says what was preserved, what was not and why. The honest replay boundary is more valuable than a theatrical button labelled reproduce.

Finally, logs need an owner. A field without an owner becomes an orphaned promise. Someone must decide which events are relevant, verify that recording works, monitor failures in the logging path, protect access, test retrieval and retire records according to the stated purpose. The owner may be a team rather than a person, but accountability cannot be delegated to a storage bucket. The bucket does not attend the review meeting. It also has a disappointing grasp of proportionality.

Documentation is a living description

Technical documentation is sometimes treated as the place where an engineering team explains a product to itself. Under the AI Act it has a wider audience. It needs to provide information that a national competent authority or notified body can use to assess compliance. That changes the tone of the document. It should not be an advertisement for the system, and it should not be a private notebook full of references that no one else can follow. It is a controlled description of purpose, design, operation, limits, data, testing and changes.

A living description has a relationship to the system’s identity. It names the provider, intended purpose and relevant versions. It explains how the system interacts with other software and hardware. It describes the components and processes that affect the requirements. It records the tests and validation that support performance claims. It identifies foreseeable conditions that can change behaviour. It states the interfaces and oversight measures a deployer needs. This does not mean the document must expose trade secrets indiscriminately. It means confidentiality cannot become an excuse for having no assessable account.

Versioning is the hinge. A document that changes without a history can hide a change by making the new state look like the old one. A history that records every punctuation edit can bury a substantial change among harmless noise. A useful change record identifies what changed, why it changed, who authorised it, which assessment was repeated, what downstream material must be updated and when the new state became effective. The AI Act refers to substantial modification in several places. An organisation needs a way to notice change before the label becomes a dispute.

Proweniencja dotyczy również założeń. System może opierać się na założeniu dotyczącym populacji reprezentowanej w zbiorze danych, świeżości źródła, znaczenia pola czy kompetencji osoby wdrażającej. Założenia nie są wstydliwymi niedoskonałościami, które należy ukryć w przypisie. Stanowią granice roszczeń systemu. Rejestr, który je wymienia, daje operatorowi szansę rozpoznania, kiedy granica została osiągnięta. Rejestr, który je ukrywa, zachęca do korzystania z systemu poza warunkami, w których jego dowody miały sens.

Dokumentacja powinna czynić niepewność czytelną, nie udając, że każdą niewiadomą można skwantyfikować. Niektóre niepewności mają charakter liczbowy. Inne dotyczą braku pokrycia, nierozwiązanych konfliktów, zmieniającego się prawa, nowatorskich danych wejściowych lub nieprzetestowanej interakcji z innym komponentem. Dobry opis może stwierdzić, że warunek nie został oceniony, że wynik zależy od ludzkiego osądu lub że systemu nie należy używać do określonego celu. Takie stwierdzenia nie są oznaką słabego systemu. Są informacją, która pozwala silnemu systemowi pozostać w granicach swojego upoważnienia.

Istnieje różnica między ograniczeniem a odmową. Ograniczenie wskazuje, gdzie roszczenia systemu stają się niewiarygodne. Odmowa oznacza, że system nie podejmie działania w danym warunku. Obie sytuacje powinny być udokumentowane. Jeśli użytkownik widzi tylko ogólny błąd, organizacja traci szansę wyjaśnienia, czy ograniczenie chroni bezpieczeństwo, prywatność, prawa, jakość czy wydajność. Jasne rejestry odmów wspierają również doskonalenie. Powtarzające się odmowy mogą pokazywać, że przepływ pracy wymaga od systemu zadania, do którego nigdy nie został zaprojektowany.

Nadzór człowieka wymaga wokół siebie dowodów

Przepisy aktu o sztucznej inteligencji dotyczące nadzoru człowieka łatwo streścić, a trudno wdrożyć. Wyznaczenie osoby to nie to samo co umożliwienie nadzoru. Osoba ta potrzebuje kompetencji, szkolenia, uprawnień i wsparcia. Musi rozumieć możliwości i ograniczenia, wykrywać anomalie, unikać błędu automatyzacji, interpretować wyniki oraz decydować o nieużywaniu, nadpisaniu, odwróceniu lub zatrzymaniu systemu. To uprawnienia operacyjne. Osoba formalnie wyznaczona na recenzenta, która nie widzi danych wejściowych, nie może zmienić wyniku ani wstrzymać przepływu pracy, jest świadkiem, a nie nadzorcą.

Rejestry mogą pokazać, czy nadzór miał realną moc. Mogą identyfikować przypisaną rolę, przedstawione informacje, wyświetlone ostrzeżenie lub ograniczenie, działanie podjęte przez recenzenta oraz ostateczne rozstrzygnięcie. Mogą zachować powód nadpisania bez zmuszania osoby do pisania wypracowania za każdym razem. Mogą również pokazać, kiedy system był niedostępny lub kiedy ścieżka przeglądu została ominięta. Brak działania człowieka nie jest automatycznie niewłaściwym postępowaniem. To sygnał do zbadania, czy projekt uczynił działanie możliwym, koniecznym i widocznym.

Rozważmy proponowany wzorzec, a nie zgłoszone zdarzenie. System dostarcza rekomendację i krótki panel dowodowy. Recenzent może zaakceptować, edytować, odrzucić lub eskalować. Interfejs rejestruje wersję systemu, odniesienia do źródeł, stan polityki, rolę recenzenta i rozstrzygnięcie. Jeśli recenzent odrzuca rekomendację, rejestr przechowuje kontrolowany powód i wysyła sprawę do dalszych działań, gdy wzorzec sugeruje powtarzający się defekt. Nie jest to twierdzenie, że wzorzec jest wystarczający dla każdego kontekstu wysokiego ryzyka. Pokazuje, jak interfejs może przekształcić nadzór człowieka z pola wyboru w obserwowalną część decyzji.

Ludzka weryfikacja również wymaga ochrony przed zmęczeniem i presją społeczną. Rejestr pokazujący tysiące zatwierdzeń, ale żadnych znaczących interwencji, może świadczyć o tym, że proces działa prawidłowo, albo że osoba weryfikująca nie ma realnej możliwości zakwestionowania wyników. Same liczby nie rozstrzygają tej kwestii. Użyteczny system monitorowania łączy decyzje z próbkowaniem, ustaleniami dotyczącymi błędów, jakością eskalacji, dostępnym czasem, szkoleniami i konsekwencjami błędnej odpowiedzi. Pomiar powinien oświetlać pracę, a nie tworzyć limit, który uczy ludzi szybszego zatwierdzania.

Nadzór musi obejmować prawo do zatrzymania. Artykuł 14 opisuje interwencję lub przerwanie za pomocą przycisku zatrzymania lub podobnej procedury umożliwiającej systemowi zatrzymanie się w bezpiecznym stanie. Kontrola zatrzymania istniejąca tylko w instrukcji to nie to samo co kontrola, do której upoważniona osoba może sięgnąć pod presją. Rejestr powinien pokazywać, czy zatrzymanie było dostępne, kto mógł z niego skorzystać, jaki stan nastąpił po nim i jak wznowiono proces. System, który można zatrzymać, ale nie potrafi wyjaśnić, co zostało zatrzymane, rozwiązuje tylko połowę problemu.

Ten materiał dowodowy ma też ludzki wymiar. Gdy wynik jest kwestionowany, rejestry mogą chronić zarówno osobę weryfikującą, jak i osobę, której sprawa dotyczy. Mogą pokazać, że weryfikator dostrzegł ograniczenie, postąpił zgodnie z procedurą, eskalował konflikt lub zatrzymał ryzykowne działanie. Nie czyni to każdej decyzji słuszną. Czyni widocznymi warunki, w jakich zapadł osąd. Odpowiedzialność to nie polowanie na najbliższy ludzki ślad. To próba zrozumienia łańcucha decyzji na tyle dobrze, by go ulepszyć.

System jakości stojący za dokumentacją

Artykuł 17 wymaga, aby dostawcy systemów sztucznej inteligencji wysokiego ryzyka wdrożyli system zarządzania jakością i dokumentowali go systematycznie i uporządkowanie poprzez polityki, procedury i instrukcje. Jego lista jest celowo szeroka. Obejmuje zgodność regulacyjną i zarządzanie zmianami, kontrolę projektowania i rozwoju, testowanie i walidację, specyfikacje techniczne, zarządzanie danymi, zarządzanie ryzykiem, monitorowanie po wprowadzeniu na rynek, zgłaszanie poważnych incydentów, komunikację z organami i innymi podmiotami, prowadzenie rejestrów, zarządzanie zasobami oraz ramy odpowiedzialności dla kierownictwa i pracowników.

Czytany jako całość, nie jest to żądanie kolejnego segregatora zgodności. To żądanie, aby organizacja potrafiła powiązać swoje decyzje. Procedura testowa powinna mieć związek z ryzykiem. Proces danych powinien mieć związek z zamierzonym celem. Proces zmian powinien mieć związek z dokumentacją. Proces monitorowania powinien mieć związek z działaniami naprawczymi. Ramy odpowiedzialności powinny mieć związek z ludźmi, którzy faktycznie mogą zmienić system. Jeśli każdy dokument jest prowadzony w izolacji, system jakości staje się archiwum niepowiązanych dobrych intencji.

Użyteczny rejestr jakości odpowiada na cztery praktyczne pytania. Co miało się wydarzyć. Co faktycznie się wydarzyło. Jak zauważono różnicę. Co się zmieniło w rezultacie. Odpowiedź może być rozproszona między rejestrem ryzyka, raportem z testów, rejestrem zmian, raportem o incydencie i decyzją o wydaniu wersji. To dopuszczalne, jeśli powiązania są stabilne i zrozumiałe. Niedopuszczalne jest, gdy weryfikator musi zgadywać, które pliki należą do tego samego stanu systemu lub który wynik testu posłużył do wsparcia konkretnej wersji.

System potrzebuje również sposobu na odnotowanie decyzji o braku zmian. Ryzyko może zostać ocenione i uznane za akceptowalne w udokumentowanych warunkach. Proponowana funkcja może zostać odrzucona z powodu niewystarczających dowodów. Wydanie wersji może poczekać, ponieważ ocena jest niekompletna. To decyzje mające podstawę, a nie puste miejsce w kalendarzu. Ich odnotowanie zapobiega sytuacji, w której późniejszy czytelnik pomyli celowe ograniczenie z przypadkowym pominięciem. Pomaga też zespołowi opierać się presji, by każde nierozwiązane pytanie zamieniać w plan wdrożenia.

Zarządzanie jakością ma wymiar czasowy. Proces, który sprawdzał się w przypadku statycznego modelu, może nie działać, gdy system uczy się po wdrożeniu, zmienia swój indeks wyszukiwania lub otrzymuje nowe narzędzie. Proces, który sprawdza się w przypadku asystenta wewnętrznego, może nie działać, gdy ten sam komponent zostanie zintegrowany z przepływem pracy decyzyjnej. Rejestr powinien zatem wskazywać czynniki wyzwalające przegląd: wersję modelu, źródło danych, cel, populację użytkowników, uprawnienie do narzędzia, wymóg prawny, incydent lub wzorzec w monitorowaniu. Czynnik wyzwalający jest częścią kontroli.

Proporcjonalność również ma tu znaczenie. Rozporządzenie stanowi, że wdrażanie powinno być proporcjonalne do wielkości organizacji dostawcy, przy jednoczesnym zachowaniu rygoru i ochrony niezbędnych do zapewnienia zgodności. Proporcjonalne nie oznacza nieformalne. Mały dostawca może stosować zwarty zestaw dobrze zaprojektowanych rejestrów zamiast odtwarzać machinę dużej instytucji. Nadal musi wiedzieć, kto odpowiada za każdą decyzję, gdzie przechowywane są dowody, jak ocenia się zmiany i w jaki sposób organ może uzyskać potrzebne informacje. Mały rozmiar nie oznacza zwolnienia z obowiązku pamięci.

Przechowywanie to decyzja projektowa

Artykuł 18 wymaga, aby dostawcy udostępniali właściwym organom krajowym określoną dokumentację przez okres kończący się dziesięć lat po wprowadzeniu do obrotu lub oddaniu do użytku systemu AI wysokiego ryzyka. Artykuł 19 dotyczy automatycznie generowanych dzienników i wymaga ich przechowywania, o ile pozostają pod kontrolą dostawcy, przez okres odpowiedni do zamierzonego celu i co najmniej sześć miesięcy, chyba że inne przepisy, w tym przepisy o ochronie danych, stanowią inaczej. Są to wymogi prawne o precyzyjnie określonym zakresie. Nie należy ich bezrefleksyjnie uogólniać na wszystkie rejestry w każdym przepływie pracy związanym z AI.

Praktyczny wniosek jest taki, że przechowywanie musi być zaprojektowane według klasy rejestrów. Dokumentacja techniczna, rejestry systemu jakości, materiały dotyczące zgodności, dzienniki, dane źródłowe, notatki ludzkie, zestawy ewaluacyjne, dowody incydentów i wyjaśnienia publiczne mogą mieć różne cele i okresy przechowywania. Jedno domyślne ustawienie przechowywania to skrót architektoniczny, a nie strategia zarządzania. Może wymazać dowody zbyt wcześnie lub przechowywać wrażliwe materiały długo po osiągnięciu celu. System powinien wiedzieć, którą warstwę przechowuje i dlaczego.

Przechowywanie wymaga również określenia początku i końca. Rejestr, który mówi „przechowywać przez dziesięć lat” bez zdefiniowania zdarzenia, od którego biegnie ten okres, nie jest operacyjnie kompletny. Dziennik przechowywany przez sześć miesięcy bez wskazania, czy okres liczy się od zdarzenia, wydania czy zakończenia cyklu monitorowania, prowadzi do możliwych do uniknięcia nieporozumień. Tekst prawny dostarcza odpowiednich punktów odniesienia dla poszczególnych obowiązków. Organizacja musi odwzorować te punkty na stany systemu i uczynić to odwzorowanie możliwym do sprawdzenia.

Usunięcie rejestru samo w sobie jest zdarzeniem. Jeśli działający prompt zostanie usunięty, ponieważ jego cel się zakończył, system może potrzebować zachować odniesienie wskazujące, że usunięcie nastąpiło i która reguła przechowywania je autoryzowała. Jeśli błąd zostanie poprawiony, oryginalne dowody mogą pozostać dostępne w kontrolowanej historii, zamiast zniknąć bez wyjaśnienia. Jeśli dane osobowe zostaną usunięte, artefakty pochodne i ścieżki dostępu mogą wymagać odrębnej analizy. Rejestr usunięcia nie powinien być mylony z dowodem, że każda kopia zniknęła. Jest dowodem kontrolowanego działania w określonych granicach.

Przechowywanie może również chronić uczenie się instytucjonalne. Przegląd incydentu, który zachowuje tylko ostateczny wniosek, traci warunki, które doprowadziły do problemu. Rejestr ewaluacji, który zachowuje tylko wynik, traci obciążenie pracą, populację, metodę i ograniczenia, które czyniły wynik interpretowalnym. Rejestr korekty, który zachowuje tylko nową wartość, traci fakt, że błędna wartość przeszła przez system. Zatrzymywanie wszystkiego nie jest rozwiązaniem. Zachowanie właściwych dowodów dla danego pytania już tak.

Gdy brakuje dowodów

The most useful record systems are designed for absence. They can say that a source was unavailable, that a field was redacted, that a version identifier was unknown, that a human review did not occur, that a tool acknowledgement failed or that a replay cannot be completed. This is not an invitation to manufacture a tidy placeholder. It is a way to prevent missing evidence from being silently converted into confidence.

Absence has types. Not collected means the system never attempted to preserve the field. Not available means the field existed elsewhere but could not be obtained. Not applicable means the condition did not belong to the workflow. Redacted means the evidence exists but is restricted under a rule. Conflicted means two sources disagree. Unknown means the organisation has not established the answer. These labels are proposed operating vocabulary, not terms mandated by the AI Act. Their value is that they keep different problems from collapsing into one empty cell.

A completeness inspector should therefore ask questions, not count fields. Does the record identify the system state. Does it show the purpose and input scope. Can the source or policy basis be found. Is the human authority visible. Are uncertainty and exclusions named. Can a person correct, appeal, suspend or delete within the applicable boundary. The answers depend on context. A record may be complete for an operational alert and incomplete for an individual decision. Completeness is a relationship between evidence and consequence.

Missing records should trigger a response that matches the risk. A low-impact missing label may be repaired in the next release. A missing model version for a consequential decision may require the decision to be reviewed or the workflow suspended. A missing log of a state-changing tool call may require investigation outside the model team. The organisation should decide these thresholds before the incident, because deciding them during a heated review usually produces a policy made of adrenaline.

The absence path also needs an owner and a timestamp. If a required record cannot be produced, someone should know who is responsible for investigating, who can decide whether work continues, which evidence is being sought and when the status will be reviewed. That turns a gap into a managed state. It does not make the gap harmless. It prevents the institution from pretending that a missing page is an empty page.

The AI Office and the work of interpretation

The AI Act creates institutions and procedures that help turn the Regulation into practice. The Commission’s AI Office has a role in supervising and enforcing the obligations for general-purpose AI models, while national competent authorities and market surveillance authorities have responsibilities within the broader framework. The AI Act Service Desk provides an explainer for Article 12 that summarises the record-keeping duty and points readers to the official text. Its summary is explicitly non-binding. That distinction is worth preserving.

Guidance can make a rule usable by translating a legal requirement into examples, questions and implementation choices. It cannot replace the Regulation. An organisation should be able to show which claim comes from the binding text, which comes from guidance and which is its own control decision. This source discipline is not academic fussiness. It prevents a helpful example from becoming a fictional obligation and prevents a voluntary practice from being marketed internally as a legal minimum.

Komunikat Komisji „AI@EC” stanowi użyteczny przykład instytucjonalny, nie pretendując do opisu każdego organu publicznego. W styczniu 2024 r. Komisja określiła podejście do własnego rozwoju i wykorzystania sztucznej inteligencji, obejmujące wewnętrzne wytyczne operacyjne, ocenę i klasyfikację opartą na analizie ryzyka, unikanie systemów niezgodnych z wartościami europejskimi lub zagrażających prawom i bezpieczeństwu, a także struktury organizacyjne umożliwiające wypełnianie obowiązków. Nie chodzi o to, że komunikat rozwiązuje kwestię wdrożenia. Chodzi o to, że instytucja przygotowująca się do wykorzystania sztucznej inteligencji musi również przygotować własne zdolności do zarządzania tym wykorzystaniem.

Na te zdolności składają się rejestry, które można przenosić między obszarami. Polityka powinna wskazywać właściciela. Ocena ryzyka powinna wskazywać tożsamość systemu. Opis techniczny powinien wskazywać wydanie. Rejestr szkoleń powinien wskazywać rolę i kompetencje. Sygnał monitorowania powinien wskazywać działanie. Skarga powinna wskazywać ścieżkę postępowania. Gdy te powiązania są jawne, wytyczne można stosować bez tworzenia osobnego uniwersum dokumentacji. Gdy ich brak, każda nowa wytyczna staje się kolejnym dokumentem, który organizacja ma nadzieję, że w jakiś sposób zmieni zachowanie.

Prawo europejskie ma szczególną strukturę instytucjonalną. Obowiązki są rozdzielone między instytucje Unii, państwa członkowskie, organy, dostawców, wdrażających i innych operatorów. Rejestr musi uwidaczniać ten podział, a nie sprowadzać każdego aktora do roli ogólnego właściciela systemu. Pytanie dotyczy nie tylko tego, kto zbudował model. Chodzi też o to, kto go wdrożył, kto kontroluje dane wejściowe, komu powierzono nadzór, kto może zawiesić stosowanie i kto musi współpracować z organem. Nazwy i umowy mają znaczenie, ale liczą się również uprawnienia operacyjne, które rejestr może ujawnić.

Od języka prawnego do codziennej praktyki

Prawo staje się praktyczne, gdy organizacja przekształca każdy obowiązek w niewielką liczbę powtarzalnych procedur. To proponowany wzorzec działania, a nie prawna lista kontrolna. Na etapie przyjęcia sklasyfikuj zamierzony cel, osoby, których dotyczy, kategorie danych, poziom autonomii, narzędzia i organ decyzyjny. Przed wydaniem powiąż tożsamość systemu, wersję, stan instrukcji, źródła danych, testy, ograniczenia, rolę nadzorczą i ścieżkę zatrzymania. Podczas eksploatacji rejestruj istotne zdarzenia, monitoruj ryzyka i uwidaczniaj niepewność. Po zmianie lub incydencie zbadaj, skoryguj, zaktualizuj opis i zdecyduj, czy stosowanie powinno być kontynuowane.

Zwróć uwagę, czego ten wzorzec nie mówi. Nie mówi, że należy gromadzić każdą wiadomość w nieskończoność. Nie mówi, że automatyczny dziennik jest tym samym co wyjaśnienie. Nie mówi, że pulpit nawigacyjny dowodzi bezpieczeństwa. Nie mówi, że nazwisko człowieka w przepływie pracy dowodzi nadzoru. Mówi, że system powinien mieć rejestr warunków, w jakich może działać, oraz zdarzeń, które mogą wykazać, czy te warunki zostały spełnione.

Dobra procedura ma początek i koniec. Rejestr jest tworzony, gdy rozpoczyna się istotny stan, aktualizowany, gdy zmieniają się dowody lub uprawnienia, i zamykany, gdy kończy się cel lub okres przeglądu. Zamknięcie ma znaczenie, ponieważ otwarte rejestry po cichu stają się trwałe. Powinno ono wskazywać, czy system został wydany, odrzucony, zawieszony, zastąpiony, skorygowany czy wycofany. Jeśli rejestr nie może zostać zamknięty, organizacja powinna wiedzieć dlaczego. Nieskończony status tymczasowy to uprzejmy sposób unikania decyzji.

Procedury powinny również odróżniać fakty od interpretacji. Dziennik może odnotować, że model zwrócił wynik. Recenzent może odnotować, że wynik został odrzucony, ponieważ źródło było sprzeczne z polityką. Zespół ds. incydentów może później wywnioskować, że zmiana w mechanizmie wyszukiwania przyczyniła się do konfliktu. Wniosek może być mocny, ale nie jest tym samym rodzajem dowodu co zdarzenie. Oznaczone warstwy czynią późniejsze dochodzenie bardziej rzetelnym. Bez nich każdy wniosek stopniowo twardnieje w fakt, ponieważ nikt nie pamięta, które zdanie zaobserwowano, a które zapisano podczas spotkania.

Własność powinna być widoczna na poziomie pól, gdzie to praktyczne. Dostawca może być właścicielem dokumentacji technicznej. Wdrażający może być właścicielem trafności danych wejściowych i monitorowania operacyjnego. Opiekun danych może być właścicielem praw do źródeł i jakości. Osoba pełniąca rolę nadzoru ludzkiego może być właścicielem decyzji o akceptacji, nadpisaniu lub zatrzymaniu. Funkcja rejestrów może być właścicielem przechowywania i dostępu. Przydział będzie się różnić w zależności od kontekstu i umowy. Rejestr powinien umożliwiać zadanie pytania właściwemu właścicielowi bez wysyłania wiadomości do całej organizacji.

Testowanie procedury jest tak samo ważne jak jej napisanie. Proponowany mechanizm kontroli powinien być sprawdzony przy użyciu bezpiecznego, wyraźnie oznaczonego scenariusza. Czy zespół może pobrać rejestr według wersji systemu? Czy operator może zobaczyć stan instrukcji użyty przy wydaniu? Czy recenzent może odrzucić wynik i zachować powód? Czy ścieżka zatrzymania pozostawia jasny stan? Czy właściwy organ może otrzymać odpowiednią dokumentację bez szukania po omacku? To są ćwiczenia, a nie zgłoszone incydenty. Ich wyniki powinny być zapisane jako testy, z jasno określonymi ograniczeniami.

Procedura powinna być zaprojektowana na spokojny dzień. Jeśli działa tylko wtedy, gdy specjalista nie śpi, dostawca odpowiada szybko i wszyscy pamiętają historię wdrożeń, to nie jest procedura. To pamięć zbiorowa z umową poziomu usług. Poważny system rejestrów daje zwykłym pracownikom sposób na uzyskanie odpowiedzi na zwykłe pytania, a specjalistom daje głębszą ścieżkę, gdy pytanie staje się istotne. To w spokojny dzień system zasługuje na zaufanie w dniu pełnym zamieszania.

Istnieje pokusa, aby rejestry były piękne. Przejrzysty projekt pomaga ludziom z nich korzystać, ale wizualna estetyka nie jest dowodem. Kolorowy status, ocena dojrzałości lub kompletnie wyglądająca karta mogą ukrywać brakujące pola. Interfejs powinien utrudniać przeoczenie niepewności, nieaktualnych danych i niezweryfikowanych twierdzeń. Powinien wspierać nudne czynności, które utrzymują rejestr w prawdzie: przypięcie wersji, wskazanie źródła, nazwanie roli, oznaczenie ograniczenia, powiązanie korekty i zamknięcie stanu. Dobry projekt daje rejestrowi uchwyty. Nie daje mu mocy, na które nie zapracował.

Krótka uwaga od nas

W Dweve nasze Centrum Zaufania jest zorganizowane wokół tego samego pytania: co inna osoba powinna móc sprawdzić na temat modelu i jego działania. Publiczny indeks łączy tożsamość modelu, treści szkoleniowe, oceny, zarządzanie ryzykiem, monitorowanie po wprowadzeniu do obrotu, incydenty, zarządzanie danymi i dokumentację techniczną. Taki układ nie jest twierdzeniem, że publiczna strona dowodzi zgodności, i nie zastępuje oceny organu. To świadoma próba utrzymania widoczności rejestrów i ich granic. Nasza praca nad Ledger przedstawia podobny argument na poziomie operacyjnym: rejestr powinien zawierać wystarczającą tożsamość i historię, aby późniejszy czytelnik mógł sprawdzić, co się zmieniło. Użyteczny test nie polega na tym, czy strona wygląda uspokajająco. Chodzi o to, czy dowody mówią prawdę o tym, co mogą, a czego nie mogą ustalić.

Rejestry są częścią instytucji

Najgłębszym błędem jest traktowanie wymogów dotyczących rejestrów w AI Act jako podatku od innowacji. Lepiej rozumieć je jako opis tego, czego instytucja potrzebuje, aby korzystać z potężnego, zmieniającego się systemu bez utraty pamięci. Model może szybko wygenerować wynik. Instytucja musi zdecydować, czy wynik należy do decyzji, czy ktoś może go zakwestionować, czy korekta może przejść przez system i czy przyszły czytelnik będzie w stanie zrozumieć ścieżkę.

To dlatego zapisów nie można zostawiać na skraju architektury. Należą one obok danych, instrukcji, wersji modeli, narzędzi, interfejsów, ról ludzkich i środków zaradczych. Zapis jest tkanką łączną, która pozwala tym elementom odpowiadać sobie nawzajem. Zamienia stwierdzenie ryzyka w warunek podlegający przeglądowi. Zamienia źródło w możliwą do prześledzenia podstawę. Zamienia ludzką zgodę w obserwowalny akt. Zamienia korektę w zmianę, którą można sprawdzić. Zamienia brakujące pole w zarządzane pytanie, a nie w pustkę, za którą nikt nie odpowiada.

Ta praca jest cicha, bo wygląda zwyczajnie. Nazwij system. Ustal cel. Zapisz wersję. Zachowaj granicę źródła. Przetestuj dziennik. Daj recenzentowi uprawnienia. Oznacz to, co nieznane. Zachowaj odpowiedź. Wycofaj zapis, gdy cel się skończy. Nic z tego nie ma blasku filmu promocyjnego. Ma za to cenniejszą właściwość: przetrwa zmianę personelu, zmianę modelu, zmianę dostawcy i pytanie kogoś, kogo nie było w pomieszczeniu.

Nadal będą spory co do interpretacji aktu o sztucznej inteligencji, właściwego poziomu szczegółowości i sposobu, w jaki normy przełożą wymogi prawne na praktykę techniczną. Zapis nie eliminuje tych sporów. Czyni je bardziej precyzyjnymi. Organizacja może pokazać, na którym tekście się oparła, jakie przyjęła założenie, jakie miała dowody, który mechanizm kontroli wybrała i gdzie pozostaje jej niepewność. To lepszy punkt wyjścia dla organu nadzoru, współpracownika, osoby, której sprawa dotyczy, i samej organizacji.

Praktyczna lekcja jest prosta. Nie pytaj tylko, czy system sztucznej inteligencji potrafi wyprodukować wynik. Zapytaj, czy instytucja potrafi zapamiętać warunki tego wyniku, pokazać dowody, które miały znaczenie, wskazać organ, który działał, zidentyfikować pozostałą niepewność i sprawić, by korekta mogła się przemieszczać. Jeśli odpowiedź brzmi nie, system może wciąż robić wrażenie pod względem technicznym. Nie jest jeszcze gotowy instytucjonalnie.

Cicha praca unijnego aktu o sztucznej inteligencji nie polega zatem na tym, by technologia brzmiała poważnie. Chodzi o to, by powagę uczynić obserwowalną. Zapis to nie hasła z datownikiem. To ograniczony dowód, stworzony w konkretnym celu, powiązany z odpowiedzialnością i otwarty na korektę. Jeśli buduje się go starannie, organizacja może korzystać ze sztucznej inteligencji bez prośby, by płynność zastępowała pamięć. Jeśli zostawi się go na marginesie, pierwsze trudne pytanie ujawni, że system zachował swój wynik, ale zgubił swoją historię.

Źródła