Rejestr modeli to nowa publiczna tablica ogłoszeń

Rejestr modeli może pokazać opinii publicznej, czym jest system, kto za nim stoi, gdzie może być używany i co się w nim zmieniło. Nie może jednak zamienić...

Rejestr modeli to nowa publiczna tablica ogłoszeń

The page that starts by admitting it is not magic

The first thing a useful model registry does is disappoint you. It does not say that a model is safe. It does not say that an organisation is competent. It does not turn a supplier's promise into a fact, or a green label into a reason to stop asking questions. It gives you a bounded record instead: this is the thing, this is the version, this is the owner, this is the declared purpose, this is the status, and this is where the supporting evidence is kept.

That modesty is the beginning of public trust. A registry is a noticeboard, not a shrine. A noticeboard tells a neighbourhood what is being built, who is responsible for it and which notices have been replaced. It does not certify the workmanship of every building on the street. It gives people a place to start looking, and a way to notice when the notice itself has gone stale.

Open the Dutch government's Algorithm Register and the design is unusually plain. Government organisations publish information about algorithms they use in their work. The register focuses on impactful algorithms, including high-risk AI systems, and gives visitors an explanation of how those systems work. The page also makes a useful distinction that many glossy AI catalogues avoid: an algorithm is a set of rules and instructions a computer follows to calculate an answer, not a personality with a product launch.

The page is public because the work is public. A citizen does not need a private account to discover that an authority uses an algorithm, what the authority says it is for, or where to ask the next question. That does not make every technical detail public. It does make the existence of the system, its declared role and its institutional owner harder to hide behind a procurement file.

Model registries are becoming the same kind of civic object. They sit between a technical catalogue and a public record. Engineers need a stable identity and a version to integrate. Operators need a status and an owner to run. Downstream providers need capabilities, limits and conditions. Auditors need a trail back to evidence. Affected people need to know that a system exists and how to challenge what it does. One page cannot answer all of those questions, but a well-designed registry can point each reader to the right layer.

The danger is that the word registry makes a document sound more complete than it is. A phone book is a registry, but it cannot tell you whether a number still works. A shipping manifest is a registry, but it cannot tell you whether the cargo survived the voyage. A model record is a registry, but it cannot carry the entire proof of performance, fairness, security, legality and social consequence. The useful question is not whether a model is in the registry. It is what the entry establishes, what it leaves open and what a reader can inspect next.

A noticeboard is a promise of selection

An inventory tries to count everything. A catalogue tries to help you choose. A register makes a more formal promise: these entries belong to a defined scope, they have an owner, and the information is maintained under a rule. The promise is about selection before it is about software. Without a stated scope, an attractive list is only a collection of things that happened to be remembered.

That is why every registry needs a sentence that says what it includes and what it deliberately leaves out. The EU AI Act's central database is not a list of every model circulating in Europe. Article 71 establishes an EU database for specified high-risk AI systems and the systems that are registered under the routes described in Article 49. The Dutch Algorithm Register is not a list of every calculation made in a government office. It focuses on impactful algorithms, including high-risk AI systems. The boundary is part of the record, not a footnote for lawyers.

A model registry should answer the same boundary question in ordinary language. Does it list foundation models, deployed AI systems, internal experiments, fine-tuned descendants, evaluation packages, or only models offered to external users? Does a new serving configuration receive a new entry, a new version or a linked deployment record? Does a captured state of an adaptive system count as the same model identity? If the registry does not decide these questions, every reader will decide them differently. That is how a short list becomes a long argument.

Selection also makes absence meaningful. If the scope says that all publicly accessible high-risk systems must appear, a missing entry is a governance problem. If the scope says that only models placed on a market are included, an internal experiment may be absent by design. The public cannot interpret an empty search result without knowing which of those two situations applies. Silence is not neutral when the register has not explained its vocabulary.

There is a small administrative virtue in saying this plainly. Registries do not need to pretend that they know everything. They need to tell the reader what they know, what they are responsible for and what sits outside the frame. A registry earns its authority by making the boundary of its scope explicit, not by decorating the cover. The technology is newer. The paperwork instinct is not.

What the European rule actually puts on the board

The AI Act gives the word registration a concrete legal shape, but not a single universal one. Article 49 requires a provider or authorised representative to register certain high-risk AI systems before placing them on the market or putting them into service. It also requires registration where a provider has concluded that a system is not high-risk under the conditions of Article 6(3). Public authorities and equivalent public bodies that deploy certain high-risk systems have their own registration duty, including registering their use.

The same article makes the public-private boundary explicit. Certain high-risk systems used in law enforcement, migration, asylum and border control management are registered in a secure non-public section. High-risk systems in the second point of Annex III are registered at national level. These are not implementation details that can be ironed out in a dashboard. They describe different audiences, different risks and different permissions to see the record.

Article 71 says the Commission, working with the Member States, shall set up and maintain the EU database. The information registered under Article 49 is to be accessible and publicly available in a user-friendly manner, and should be easily navigable and machine-readable, with exceptions for restricted sections. The database should contain personal data only as far as necessary. This is a useful definition of public transparency: a record people can find and process, without turning the record into a second personal-data problem.

Annex VIII is where the noticeboard becomes specific. For a provider registering a high-risk system, the record includes the provider's identity and contact details, an unambiguous trade name or reference, the intended purpose, a basic description of the information used and the operating logic, the status of the system, relevant certificates, Member States where it is placed on the market or put into service, the declaration of conformity, instructions for use and an optional URL for further information. These are not marketing fields. They are handles for identification and accountability.

W przypadku publicznego wdrożeniowca informacje są inne. Rejestr obejmuje tożsamość wdrożeniowca, osobę przekazującą informacje, adres URL wpisu dostawcy oraz streszczenia oceny skutków dla praw podstawowych i, w stosownych przypadkach, oceny skutków dla ochrony danych. To rozróżnienie ma znaczenie, ponieważ dostawca modelu i organ publiczny nie wiedzą tego samego i nie ponoszą tej samej odpowiedzialności. Rejestr, który sprowadza ich do jednej karty dostawcy, zaciera miejsce, w którym system styka się z instytucją.

Baza prawna ma zatem charakter warstwowy. Rejestruje tożsamość systemu. Rejestruje dostawcę. Może rejestrować wdrożeniowca i zastosowanie. Rejestruje status i deklaracje uzupełniające. Nie zastępuje dokumentacji technicznej, zarządzania ryzykiem, systemu jakości ani monitorowania po wprowadzeniu do obrotu, których akt wymaga w innych miejscach. Baza danych jest publicznym indeksem faktów podlegających rozliczeniu. Nie jest całym plikiem zgodności.

To rozróżnienie łatwo zatracić, ponieważ ludzie lubią jeden adres URL, który wydaje się zawierać odpowiedź. Prawo jest mniej sentymentalne. Tworzy powierzchnię publiczną, powierzchnie ograniczone i kontrolowane ścieżki dokumentacji. Powierzchnia publiczna musi być użyteczna. Powierzchnia ograniczona musi pozostać ograniczona. Dokumentacja musi pozostać dostępna dla właściwego organu lub dostawcy niższego szczebla, który jej potrzebuje. Poważny rejestr jest interfejsem między tymi obowiązkami, a nie skrótem wokół nich.

Rejestr staje się użyteczny, gdy tożsamość, status i zmiana są ze sobą powiązane. Kolor bez przejścia to tylko dekoracja.

Istnieje jeszcze jedna ważna granica. Przepisy aktu o sztucznej inteligencji dotyczące modeli ogólnego przeznaczenia to nie to samo co publiczny katalog wszystkich modeli ogólnego przeznaczenia. Artykuł 53 wymaga od dostawców prowadzenia dokumentacji technicznej, udostępniania informacji dostawcom systemów AI niższego szczebla, utrzymywania polityki dotyczącej praw autorskich i publikowania wystarczająco szczegółowego streszczenia treści szkoleniowych. Wytyczne Komisji wyjaśniają, że dokumentacja techniczna jest przeznaczona dla Biura ds. AI i krajowych organów właściwych na żądanie, natomiast dokumentacja dla niższego szczebla pomaga integratorom zrozumieć możliwości i ograniczenia. Tylko część tego materiału należy na publiczną tablicę ogłoszeń.

Akt wymaga również od Komisji opublikowania i prowadzenia listy modeli AI ogólnego przeznaczenia stwarzających ryzyko systemowe. Lista modeli stwarzających ryzyko systemowe jest cennym sygnałem publicznym, ale nie jest tym samym co pełny rejestr modeli. Ma węższy cel i musi respektować prawa własności intelektualnej, poufne informacje handlowe i tajemnice przedsiębiorstwa. Nazywanie każdej listy rejestrem jest nieszkodliwe tylko dopóki ktoś nie założy, że lista dowodzi więcej, niż w rzeczywistości dowodzi.

Model to nie pojedyncza linia

Ludzie mówią o modelu tak, jakby był słoikiem na półce. Nazwa jest wydrukowana na etykiecie, wersja jest ostemplowana na spodzie, a zawartość pozostaje niezmieniona, dopóki ktoś nie otworzy wieczka. Ten obraz działa w przypadku statycznego artefaktu. Staje się zawodny, gdy model jest adaptowany, dostrajany, opakowywany w narzędzia, udostępniany kilkoma ścieżkami lub zmieniany podczas użytkowania.

Rejestr potrzebuje co najmniej dwóch tożsamości: tożsamości modelu i tożsamości tego, co faktycznie działało. Pierwsza odpowiada na pytanie, który model ma na myśli dostawca. Druga może identyfikować przechwycony stan, zapieczętowany pakiet wdrożeniowy, lokalny eksport lub pakiet do odtworzenia. Powiązanie ich zapobiega dwóm przeciwstawnym błędom. Usługa może przestać udawać, że każdy stan na żywo ma jeden stały skrót, a operator może przestać udawać, że sam skrót pakietu opisuje całą rodzinę modeli.

Numery wersji są użyteczne tylko wtedy, gdy widoczna jest zasada ich zmiany. Wersja może oznaczać nowy zestaw wyuczonych parametrów, nowy katalog ograniczeń, zmianę w wyszukiwaniu, zmienioną warstwę bezpieczeństwa lub istotną zmianę w umowie świadczenia usług. Jeśli dostawca używa jednego numeru dla wszystkich tych przypadków, numer staje się uprzejmym sposobem powiedzenia, że coś się zmieniło. Rejestr powinien łączyć następcę z poprzednikiem i wskazywać, która część umowy uległa zmianie.

Zachowanie adaptacyjne dodaje kolejną komplikację. Jeśli system może się zmieniać podczas użytkowania, należy to odnotować. Nie jest to przyznanie, że system jest niekontrolowany. To przyznanie, że słowo wersja nie może wykonać całej pracy. Rejestr może zachować stabilną tożsamość modelu, przypisać do niej ograniczone czasowo stany przechwycone i odnotować warunki, w jakich dany stan został utworzony. Nie chodzi o zamrożenie żywego systemu w fałszywym obrazie. Chodzi o nadanie każdemu znaczącemu obrazowi daty i ramy.

Tożsamość ma również wymiar społeczny. Sama nazwa modelu nie wystarczy, gdy kilka podmiotów prawnych dystrybuuje podobne artefakty, gdy dostawca niższego szczebla zmienia model lub gdy produkt osadza model pod własną nazwą. Rejestr powinien uczynić łańcuch widocznym: dostawca, dystrybutor, jeśli jest inny, wdrażający, jeśli ma to znaczenie, oraz system lub ścieżka, w której model jest używany. Osoba, której dotyczy decyzja, nie powinna musieć przeprowadzać kryminalistycznej analizy logo produktu, aby odkryć, kto może za nią odpowiadać.

Status to czasownik, nie kolor

Pola statusu są często wyświetlane jako plakietki, ponieważ plakietki dobrze pasują do kart. Plakietka nie jest statusem. Status to stwierdzenie dotyczące działania i czasu. Testy wewnętrzne oznaczają co innego, gdy dostęp jest kontrolowany przez dostawcę. Wersja przedpremierowa oznacza co innego, gdy zaproszeni zewnętrzni użytkownicy mogą korzystać ze ścieżki na określonych warunkach. Na rynku, w użyciu, zawieszony, wycofany i wycofany z obrotu niosą ze sobą różne konsekwencje operacyjne.

Użyteczny zapis określa, na co status pozwala, a na co nie. Jeśli system jest przeznaczony wyłącznie do użytku wewnętrznego, czytelnik nie powinien wnioskować o publicznej dostępności na podstawie strony dokumentacji. Jeśli planowana jest zewnętrzna beta, data powinna być oznaczona jako planowana, a nie przedstawiona jako wydanie. Jeśli system został wycofany, zapis powinien zachować poprzednią tożsamość i określić, czy istniejące wdrożenia mogą być kontynuowane, muszą zostać zatrzymane, czy są migrowane. Status bez daty wejścia w życie to plotka w mundurze.

Status powinien mieć również właściciela. Kto może przenieść wpis z wewnętrznego na zewnętrzny? Kto może zawiesić ścieżkę? Kto może ogłosić zmianę daty wydania? Jakie dowody są wymagane przed przejściem? Te pytania należą do procesu operacyjnego, ale publiczny wpis powinien czynić wynikową decyzję czytelną. Rejestr, który pokazuje aktualną plakietkę, ukrywając stojącą za nią władzę, jest tylko tablicą nastrojów dla zarządzania.

Przykład ilustracyjny, nie prawdziwy wpis: zapis może stwierdzać, że model znajduje się w kontrolowanej ocenie, że żadna zewnętrzna ścieżka nie jest otwarta, że test z zaproszeniami jest proponowany na późniejszy termin oraz że propozycja pozostaje uzależniona od bramki wydawniczej. Przykład nie wymienia żadnej organizacji, modelu ani wydarzenia. Jego celem jest pokazanie, jak zapis oddziela plan od faktu. Ta sama dyscyplina dotyczy wycofania, deklaracji możliwości lub certyfikacji, która nie została jeszcze wydana.

To rozdzielenie chroni czytelników przed znaną sztuczką. Przyszły zamiar jest powtarzany wystarczająco często, że zaczyna brzmieć jak historia. Rejestry powinny być miejscem, w którym ta sztuczka przestaje działać. Wpis może pokazywać plan, ale plan musi zachować swoją etykietę. Europa ma już wystarczająco dużo kalendarzy. Data nie jest faktem tylko dlatego, że została umieszczona w kolorowym prostokącie.

Rejestr nie jest archiwum dowodów

Publiczny wpis powinien być na tyle krótki, żeby dało się go przeczytać, i na tyle treściwy, żeby nadać kierunek poważnemu pytaniu. Pomieszczenie z dowodami za nim może być znacznie większe. Obowiązki dokumentacyjne z artykułu 53 aktu o sztucznej inteligencji pokazują, dlaczego. Dostawcy modeli sztucznej inteligencji ogólnego przeznaczenia muszą sporządzać i przechowywać dokumentację techniczną obejmującą opracowanie, trenowanie, testowanie i ocenę. Muszą udostępniać informacje i dokumentację dostawcom systemów sztucznej inteligencji niższego szczebla, aby ci dostawcy mogli zrozumieć możliwości i ograniczenia. Muszą publikować wystarczająco szczegółowe streszczenie treści wykorzystanych do trenowania oraz utrzymywać politykę zgodną z unijnym prawem autorskim.

Obowiązki te służą różnym czytelnikom. Właściwy organ może potrzebować pełnej dokumentacji technicznej. Dostawca niższego szczebla potrzebuje informacji o integracji i ograniczeniach. Społeczeństwo potrzebuje jasnego opisu tego, czym jest model i jakie są granice streszczenia treści wykorzystanych do trenowania. Wpis w rejestrze może łączyć te płaszczyzny, nie udając, że strona publiczna powinna zawierać każdy szczegół wrażliwy dla bezpieczeństwa, każdy plik wag ani każdą próbkę testową zawierającą dane osobowe.

Linki nie są też dowodem same z siebie. Rejestr, który wskazuje raport z oceny, powinien określać, której wersji dotyczy raport, co było mierzone w ocenie i jakie warunki ograniczają wynik. Link do streszczenia treningu powinien mówić, czy streszczenie obejmuje wstępne trenowanie, dostrajanie czy określony zestaw kategorii treści. Link do certyfikatu powinien pokazywać, kto go wydał, co potwierdza i kiedy wygasa. W przeciwnym razie strona jest półką z nieotwartymi kopertami.

Ta sama zasada dotyczy deklaracji o bezpieczeństwie. Rejestr może mówić, że istnieje ocena ryzyka, że plan monitorowania jest podlinkowany albo że opublikowano ścieżkę zgłaszania poważnych incydentów. Nie powinien sugerować, że istnienie dokumentu dowodzi, iż system u podstaw jest bezpieczny. Dokumentacja to sposób na zbadanie deklaracji. Nie jest jej substytutem.

W tym miejscu potrzebna jest dyscyplina w pisaniu publicznym. Karta modelu, strona przejrzystości czy wpis w rejestrze mogą opisywać zamierzone zastosowanie i znane ograniczenia. Nie mogą używać słowa godny zaufania jako wniosku, chyba że dowody i zakres czynią taki wniosek obronnym. Uczciwe zdanie jest często bardziej użyteczne: to są warunki, które oceniliśmy, to są ograniczenia, które zaobserwowaliśmy, a to są przypadki, których nie twierdzimy, że obejmujemy.

Holenderski rejestr pokazuje wartość zwykłej publicznej listy

Holenderski rejestr algorytmów jest pouczający właśnie dlatego, że nie stara się wyglądać jak futurystyczny pokój kontrolny. Daje organizacjom rządowym publiczne miejsce do opisywania algorytmów wykorzystywanych w ich pracy. Jego angielska strona ostrzega, że opisy zostały przetłumaczone automatycznie i że holenderski oryginał jest wersją autorytatywną dla opisu. Ta drobna notatka to lekcja o pochodzeniu informacji. Dostęp to nie to samo co dokładność, a przetłumaczony interfejs nie powinien wymazywać języka źródłowego.

Publiczny cel rejestru jest również wyrażony bez teatralnego języka. Koncentruje się na algorytmach o istotnym wpływie, w tym na systemach sztucznej inteligencji wysokiego ryzyka, i daje odwiedzającym wgląd w to, jak działają. Odwiedzający mogą przeglądać algorytmy, organizacje i szablony. Celem nie jest oferowanie oceny dla każdego algorytmu. Chodzi o to, aby korzystanie z systemów algorytmicznych było na tyle widoczne, żeby ludzie, organizacje i media mogli śledzić, kwestionować i analizować praktyki rządowe.

Towarzyszący mu holenderski Algoritmekader zamienia ten cel w wymóg. Mówi, że o ile nie ma zastosowania wyłączenie, organy publiczne publikują w rejestrze algorytmy o istotnym wpływie i systemy sztucznej inteligencji wysokiego ryzyka. Mówi również, że nieprawidłowa lub niekompletna publikacja może utrudnić osobom, których to dotyczy, i innym zainteresowanym stronom zrozumienie i kwestionowanie wykorzystania technologii, która może dotykać ich praw. Przejrzystość nie jest więc tylko uprzejmością. Jakość wpisu może wpływać na jakość publicznej kontroli.

Te same wytyczne ostrożnie podchodzą do zakresu. Opisują rejestr jako narzędzie w ramach szerszego zestawu przepisów i wymogów oraz ostrzegają, że ramy nie są kompletne i mogą nie obejmować przepisów sektorowych. Fakt, że algorytm pojawia się w rejestrze, nie rozstrzyga wszystkich kwestii prawnych i etycznych. Fakt, że się w nim nie pojawia, nie dowodzi, że jest nieszkodliwy. Czytelnik potrzebuje zasady włączania do rejestru oraz otaczających ram, aby właściwie zinterpretować wpis.

To jest użyteczny wzorzec dla rejestrów modeli. Publiczna lista powinna być łatwa do znalezienia, napisana dla osób, które nie uczestniczyły w spotkaniu dotyczącym zamówień, i powiązana z dokumentami zawierającymi więcej szczegółów. Powinna ujawniać niepewność, a nie ją ukrywać. Powinna informować, kiedy angielski opis jest tłumaczony maszynowo. Powinna wyjaśniać, które systemy są objęte, a które nie. Powinna sprawiać, że brakujący lub nieaktualny wpis staje się widocznym problemem zarządczym, a nie prywatnym rozczarowaniem.

Nie trzeba wymyślać dramatycznego incydentu, aby zrozumieć, dlaczego to ma znaczenie. Obywatel próbujący zrozumieć zautomatyzowany proces rządowy ma już praktyczne pytanie: czy system jest używany, przez kogo, w jakim celu i na podstawie jakiego wyjaśnienia? Rejestr daje temu pytaniu adres. Odpowiedź może być nadal niekompletna. Przynajmniej instytucja nie może udawać, że nie ma się gdzie zwrócić z pytaniem.

Publiczny nie oznacza obnażony

Transparentność staje się kontrproduktywna, gdy traktuje się ją jako nakaz publikowania wszystkiego. Publiczne rejestry mogą ujawniać dane osobowe, informacje wrażliwe ze względów bezpieczeństwa, szczegóły zastrzeżone i ścieżki ataku. Mogą też tworzyć fałszywe poczucie pewności, publikując fragmenty techniczne, których zwykły czytelnik nie jest w stanie zinterpretować. Granica między tym, co publiczne, a tym, co prywatne, musi być zaprojektowana, udokumentowana i poddawana przeglądowi, a nie improwizowana przez zespół, który akurat zarządza systemem treści.

Akt w sprawie sztucznej inteligencji daje prawny przykład. Art. 49 ust. 4 umieszcza niektóre systemy w bezpiecznej sekcji niepublicznej i ogranicza do niej dostęp Komisji oraz właściwych organów krajowych. Art. 71 udostępnia publicznie informacje zarejestrowane na podstawie art. 49, z wyjątkiem sekcji ograniczonych, natomiast informacje zarejestrowane na podstawie art. 60 są dostępne wyłącznie organom nadzoru rynku i Komisji, chyba że dostawca wyrazi zgodę na publiczny dostęp. Publiczność jest zatem zasadą z wyjątkami, a nie uniwersalnym domyślnym ustawieniem.

Art. 53 wprowadza podobne rozróżnienie dla modeli ogólnego przeznaczenia. Dostawcy muszą udostępniać dokumentację techniczną Biuru ds. AI i właściwym organom krajowym na żądanie oraz przekazywać dokumentację dotyczącą dalszego wykorzystania dostawcom integrującym. Obowiązki te są wyraźnie uzależnione od konieczności przestrzegania i ochrony praw własności intelektualnej, poufnych informacji handlowych i tajemnic przedsiębiorstwa. Rejestr nie powinien zmuszać dostawcy do publikowania materiałów, które zgodnie z prawem powinny być kontrolowane. Poufność nie powinna też stać się grzeczną wymówką do zatajania istnienia, celu lub statusu systemu, który ma wpływ na społeczeństwo.

Praktyczny rejestr modeli może korzystać z warstw. Warstwa publiczna identyfikuje model, dostawcę, status, zamierzony cel, ogólne możliwości, znane ograniczenia, ścieżki dostępu, warunki udostępnienia, linki do dowodów i historię zmian. Warstwa kontrolowana zawiera szczegółową dokumentację techniczną, modele zagrożeń, ograniczone materiały ewaluacyjne, szczegóły incydentów i inne informacje potrzebne upoważnionym recenzentom. Prywatna warstwa operacyjna zawiera tajemnice, dane osobowe i wewnętrzne informacje kontrolne, które nie powinny być w ogóle ujawniane. Warstwy to różne rejestry z linkami, a nie jedna strona z akordeonem oznaczonym jako transparentność.

Dobra transparentność ma swoją granicę. Publikuje to, co ludzie muszą wiedzieć, aby zrozumieć system, i chroni to, co upoważnieni recenzenci muszą kontrolować.

Warstwa publiczna powinna być mimo wszystko konkretna. Może stwierdzić, że model jest adaptacyjny podczas użytkowania, nie ujawniając prywatnej reprezentacji stanu. Może stwierdzić, że trasa jest dostępna wyłącznie na zaproszenie, nie publikując tokenów zaproszeń. Może opisać modalności wyjściowe i politykę oznaczania treści, nie ujawniając kluczy podpisujących. Może stwierdzić, że ocena ryzyka istnieje, i określić jej zakres, nie publikując diagramu zabezpieczeń, który ułatwiłby atak na usługę.

Warstwa kontrolowana wymaga własnej uczciwości. Dokument oznaczony jako poufny nie jest automatycznie kompletny, aktualny ani poprawny. Potrzebuje właściciela, wersji, reguły dostępu i reguły przechowywania. Jeśli publiczny rejestr prowadzi do kontrolowanego rekordu, odnośnik powinien ujawniać jego status i odpowiedzialną trasę, nawet gdy treść jest ograniczona. W przeciwnym razie opinia publiczna widzi czarną dziurę i ma ją nazywać zarządzaniem.

Wersjonowanie to moment, w którym rejestr staje się użyteczny

Większość awarii rejestrów nie jest dramatyczna. To drobne akty zapominania. Nowy model zastępuje stary, ale wpis jest edytowany w miejscu. Polityka się zmienia, ale akapit o przeznaczeniu pozostaje. Dostawca przenosi trasę z testów wewnętrznych do zewnętrznej wersji beta, ale plakietka statusu zmienia się przed zapisaniem daty wejścia w życie. Wdrożenie jest wycofywane, ale stary wpis znika, zabierając ze sobą historię. Teraźniejszość wygląda schludnie. Przeszłość staje się nieodpowiadalna.

Rekord wersjonowany prowadzi co najmniej cztery oddzielne daty. Wersja treści określa, który tekst i które pola rekordu są aktualne. Data wejścia w życie określa, kiedy oświadczenie ma zastosowanie. Wersja modelu lub pakietu określa, który obiekt techniczny jest opisywany. Data weryfikacji określa, kiedy ktoś sprawdził rekord. Te daty mogą się pokrywać. Nie muszą. Traktowanie ich jako jednej daty jest wygodne i często błędne.

Poprzednie wersje powinny pozostać wykrywalne zgodnie z odpowiednią regułą przechowywania. Opinia publiczna nie potrzebuje każdej wewnętrznej edycji, ale musi wiedzieć, kiedy zmieniło się istotne oświadczenie dotyczące przeznaczenia, statusu, trasy, ograniczeń lub własności. Dziennik zmian może powiedzieć, co się przesunęło, nie ujawniając informacji prywatnych. Rekord czytelny maszynowo może łączyć poprzednią wersję i manifest. Strona czytelna dla człowieka może wyjaśnić konsekwencje w zwykłym języku. Te dwie powierzchnie powinny być zgodne.

Wersjonowanie nadaje też sens wycofaniu. Jeśli model jest wycofywany, ponieważ trasa jest zamknięta, to co innego niż wycofanie z powodu poważnej wady lub kwestii prawnej wymagającej działania. Jeśli model pozostaje w istniejących prywatnych wdrożeniach, publiczny rejestr powinien to stwierdzić. Jeśli następca jest kompatybilny tylko z niektórymi integracjami, granica migracji powinna być widoczna. Rejestr, który usuwa nazwę bez zapisania powodu, pozostawia każdemu odbiorcy dalszej części wymyślenie przyczyny.

Historia zmian jest szczególnie ważna w systemach adaptacyjnych. Tożsamość modelu może pozostać stabilna, podczas gdy przechwycone stany, zestawy ograniczeń, źródła wyszukiwania lub mechanizmy kontroli wyjściowej się zmieniają. Rejestr może stwierdzić, które zmiany tworzą nowy pakiet, które zmiany wymagają nowej oceny, a które pozostają w granicach zadeklarowanej tożsamości. To nie jest nadmierny szczegół. To różnica między systemem, który można odtworzyć, a systemem, który można tylko zapamiętać.

Właściciele są częścią rekordu

Wpis w rejestrze modeli bez właściciela to prognoza pogody. Mówi, jak wyglądało niebo, ale nie daje nikogo, do kogo można zadzwonić, gdy dach przecieka. Role dostawcy i wdrażającego nie są tożsame i żadna z nich nie powinna móc rozpłynąć się w słowie platforma.

Dostawca jest właścicielem tożsamości modelu, historii rozwoju i decyzji o wydaniu w swoim zakresie. Wdrażający jest właścicielem decyzji o użyciu systemu w ramach swojej odpowiedzialności, w tym lokalnego celu, zabezpieczeń, oceny skutków i kontroli operacyjnych. Dostawca niższego szczebla może zintegrować model ogólnego przeznaczenia z systemem AI i ponosić odpowiedzialność, której dostawca modelu nie widzi. Publiczny rejestr powinien ujawniać te relacje tam, gdzie wymagają tego prawo i ryzyko.

Dane kontaktowe to nie administracyjny zapychacz. Dają osobie zainteresowanej drogę do zapytania, kto podjął decyzję, której wersji użyto lub jak można poprosić o korektę. Ogólna skrzynka pocztowa może być właściwa, ale powinna prowadzić do utrzymywanego procesu. Wpis powinien też określać, czy kontakt dotyczy wsparcia technicznego, wniosków o prawa, zgłaszania incydentów, zamówień czy rozliczalności publicznej. Jedna skrzynka nie może być każdą instytucją naraz, mimo najlepszych starań współczesnych formularzy.

Własność powinna obejmować uprawnienie do zmiany rekordu. Jeśli wskazany właściciel nie może wstrzymać trasy, poprawić statusu ani opublikować wycofania, wpis jest dekoracją. Organizacja może mieć właściciela prawnego gdzie indziej, ale luka operacyjna pozostaje. Dobry rejestr czyni odpowiedzialność widoczną, zanim incydent zmusi ludzi do rysowania struktury organizacji na tablicy.

Projektowanie rejestru, który ludzie faktycznie przeczytają

Pierwszym czytelnikiem rejestru modeli nie zawsze jest regulator ani inżynier. Może to być dziennikarz, pracownik zamówień publicznych, lokalny urzędnik, badacz, pracownik poproszony o użycie systemu albo osoba próbująca zrozumieć, dlaczego zautomatyzowana usługa dotknęła jej sprawy. Strona powinna odpowiadać na typowe pytanie, zanim sięgnie po specjalistyczne słownictwo.

Zacznij od tożsamości i powodu wpisu. Podaj, kto dostarcza model, którą wersję opisano, jakiego rodzaju obiekt to jest i czy jest to model, zintegrowany system AI czy rekord wdrożenia. Określ, czy jest wewnętrzny, dostępny dla zaproszonych użytkowników, na rynku, zawieszony czy wycofany. Czytelnik nie powinien musieć wnioskować o statusie z przycisku pobierania.

Następnie pokaż cel i granicę. Określ, do czego model ma służyć, które zastosowania są poza zakresem deklaracji i o jakich decyzjach nie może decydować. Wyjaśnij, czy model może się adaptować podczas użytkowania, czy do odtworzenia wymagany jest zapisany stan oraz czy trasa niższego szczebla zmienia warunki. Lista możliwości bez celu to menu bez kuchni.

Stosuj stopniowe ujawnianie. Górna część strony powinna być spokojna i czytelna. Głębsze sekcje mogą pokazywać rekord maszynowy, metody oceny, streszczenie treści szkoleniowych, dokumenty prawne i dowody wydania. Czytelnik publiczny może zatrzymać się po pierwszej warstwie. Audytor może kontynuować. Inżynier może pobrać stabilną reprezentację. Ukrywanie szczegółów to nie prostota. To po prostu wolno ładująca się niespodzianka.

Dostępność jest częścią wiarygodności rekordu. Strona i reprezentacja maszynowa powinny używać jasnych etykiet, nawigacji klawiaturą, użytecznych nagłówków i tekstowych alternatyw dla wizualizacji. Daty nie powinny być kodowane wyłącznie kolorem. Czerwona plakietka nie jest statusem dla czytelnika, który nie widzi czerwieni, a wykres, którego nie można odczytać bez myszy, nie jest dostępnym wyjaśnieniem. Tablica ogłoszeń na rynku nie staje się publiczna, jeśli podjazd kończy się na pierwszym stopniu.

Machine readability matters for a different reason. It lets researchers compare entries, lets public bodies build inventories, lets auditors detect stale records and lets a downstream tool verify that the page and the structured record refer to the same version. Machine-readable does not mean machine-only. The human page and the machine record should share identifiers, status, dates and links, with an integrity relationship that can be checked.

Registry fields are decisions

Every field tells the reader what the organisation believes is worth preserving. A provider field says who stands behind the model. A model name and version say how to distinguish it from a successor. A route field says where it can be reached. An intended-purpose field says which work the provider is prepared to describe. A limitation field says where the description stops. The schema is a governance document written in small rectangles.

Identity fields should be unambiguous and stable. They can include a provider's legal name, the model name, the version, a unique reference and links to a canonical record. If the model can be served through several products, the registry should distinguish the model identity from the integrating surface. If a product contains several models, the entry should not hide that fact behind the product name.

Status fields should include the value, the effective date, the reason or authority for the transition and any successor or predecessor. A date that is merely planned should be labelled as planned. A record that has not been verified recently should say so. The reader should be able to tell whether a model is available, proposed, paused or historic without interpreting an adjective invented by a marketing team.

Purpose and scope fields should describe the work in terms that a non-specialist can understand. They should name intended users where that matters, the kinds of inputs and outputs involved, and the decisions or actions the model may support. They should also state prohibited or unsupported uses. A model that can generate text is not thereby authorised to write an eligibility decision, and a model that can classify documents is not thereby authorised to classify people.

Capability fields need conditions. Modalities, context limits, tool access, language coverage, adaptation behaviour and output marking are meaningful only when tied to a route and a release. A capability that exists in an internal experiment but not in the external route should not be presented as one universal feature. The registry is not a wish list.

Data fields should say what the model receives, what it stores, what it learns from during use and what is used for evaluation, at the level that can be made public without exposing personal or confidential material. Training-content summaries and rights policies should be linked where required. A vague sentence such as trained on diverse data tells a reader almost nothing and asks them to supply a flattering interpretation.

Evaluation fields should identify the question, the method, the data boundary, the date, the result and the limitations. The entry does not need to reproduce every table, but it should not display a score without a denominator or a test without a purpose. A good evaluation link lets a reader see whether the evidence covers the intended use, a neighbouring use or only a laboratory condition.

Oversight fields should identify who can pause, override, review and investigate the system. If a model only recommends, say what action remains with the human. If a route can act on external systems, say which permissions and gates apply. If incident reporting has a dedicated route, publish it. Oversight is not a paragraph about keeping humans in the loop. It is a map of who can do what when the system is uncertain.

Pola dotyczące dowodów i integralności powinny łączyć wpis publiczny z wersjonowanym rekordem maszynowym, pakietem wydawniczym, deklaracją, pakietem ewaluacyjnym lub dziennikiem przejrzystości. Hash może potwierdzić, że plik się zmienił lub nie zmienił. Nie może jednak potwierdzić, że plik był zgodny z prawdą, dlatego rejestr powinien prowadzić osobno zapis twierdzenia i zapis integralności. Precyzja techniczna nie zastąpi osądu, ale ułatwia jego zlokalizowanie.

Na koniec pola zmian powinny wyjaśniać historię. Co się zmieniło, kiedy, dlaczego, kto zatwierdził, których tras dotyczy zmiana i czy potrzebna jest nowa ewaluacja. Wpis powinien umożliwiać odpowiedź na najzwyklejsze pytanie w sali: co różni ten rekord od tego, który czytaliśmy w zeszłym miesiącu?

Co rejestr może ustalić

Dobrze prowadzony rejestr może ustalić, że określony obiekt jest opisywany przez wskazanego dostawcę w ramach konkretnej wersji rekordu. Może ustalić deklarowany cel, status, trasę dostępu i własność. Może ustalić, które dokumenty pomocnicze i zapisy integralności może sprawdzić czytelnik oraz które informacje są celowo kontrolowane. Może ustalić, że zmiana została opublikowana i że poprzedni rekord pozostaje dostępny zgodnie z podaną zasadą przechowywania.

Może też ustalić stanowisko samej organizacji. Jeśli dostawca twierdzi, że model służy do wspomagania decyzji, a nie do automatycznej odmowy, to stwierdzenie stanowi publiczną granicę. Jeśli wdrażający twierdzi, że ocena skutków została zakończona, stwierdzenie to rodzi pytanie o to, gdzie można znaleźć podsumowanie lub kontrolowany zapis. Jeśli dostawca oznacza wydanie jako planowane, etykieta ta uniemożliwia planowi udawanie historii.

To użyteczne fakty. Ułatwiają zakupy, czynią integrację mniej spekulacyjną, a publiczne pytania łatwiejszymi do skierowania. Wyostrzają też spory. Czytelnik może powiedzieć, że deklarowany cel jest zbyt szeroki, status nieaktualny, ograniczenie pominięte lub że dowody pomocnicze nie pokrywają twierdzenia. Rejestr spełnia swoje zadanie, gdy umożliwia taką krytykę.

Czego rejestr nie może ustalić

Wpis w rejestrze nie może ustalić, że model jest dokładny dla każdego użytkownika, bezpieczny w każdym środowisku, sprawiedliwy wobec każdej grupy ani zgodny z prawem w każdym wdrożeniu. Nie może ustalić, że organ publiczny zastosował właściwą procedurę tylko dlatego, że system jest wpisany do rejestru. Nie może wykazać, że człowiek dokonujący przeglądu zrozumiał wynik, że osoba, której dane dotyczą, miała skuteczny środek odwoławczy ani że incydent zostałby wykryty na czas. Te wnioski wymagają dowodów dotyczących systemu w użyciu, instytucji, która go używa, i osób, na które wpływa.

Nie może też ustalić, że model jest niezależny od dostawcy, że trasa jest suwerenna, ponieważ jest hostowana w Europie, ani że otwarta licencja sprawia, iż odpowiedzialność znika. Własność, jurysdykcja, łańcuch dostaw, kontrola operacyjna i utrzymanie to odrębne kwestie. Rejestr może ujawnić nazwy i linki potrzebne do zadania tych pytań. Nie może na nie odpowiedzieć typografią.

Rejestr nie może też udowodnić negatywu. Brak wpisu może oznaczać, że obiekt jest poza zakresem, że ma zastosowanie wyłączenie, że publikacja jest opóźniona lub że ktoś nie opublikował. Czytelnik potrzebuje jasnego oświadczenia o zakresie i drogi zgłaszania błędów. Publiczna tablica ogłoszeń jest tak wiarygodna, jak proces, który zauważa brak ogłoszenia.

Rekord poglądowy, nie ukryte studium przypadku

Poniżej znajduje się poglądowy projekt rekordu, a nie raport o prawdziwej organizacji, modelu lub zdarzeniu. Nie wykorzystuje żadnego klienta, organu publicznego, daty wdrożenia ani zmierzonego wyniku. Jego celem jest pokazanie, jak czytelnik może przejść od wpisu publicznego do kontrolowanej ścieżki dowodowej, bez mylenia obu warstw.

  • Tożsamość: nazwa dostawcy, nazwa modelu, wersja oraz stabilny identyfikator maszynowy.
  • Status: kontrolowana ocena, z datą obowiązywania i adnotacją, że żadna zewnętrzna ścieżka nie jest otwarta.
  • Cel: pomoc w analizie dokumentów dla przeszkolonego personelu, z automatycznymi decyzjami zewnętrznymi poza zadeklarowanym zakresem.
  • Dane wejściowe i wyjściowe: reprezentowane modalności, rodzaje oczekiwanych materiałów źródłowych oraz typy wyników, które ścieżka może wytworzyć.
  • Ograniczenia: znane granice językowe, domenowe, aktualności, bezpieczeństwa i dostępu, każda powiązana z odpowiednią oceną lub polityką.
  • Nadzór: rola, która może wstrzymać ścieżkę, ścieżka przeglądu niepewnych wyników oraz kontakt w sprawie incydentów.
  • Dowody: publiczne podsumowanie, wersjonowany zapis techniczny dla upoważnionych recenzentów oraz manifest integralności opublikowanych plików.
  • Zmiany: link do poprzedniego rekordu, oświadczenie o tym, co się zmieniło, oraz warunek wymagający nowej oceny.

Nic w tym rekordzie nie mówi, że model jest dobry. Mówi, co dostawca jest gotów zadeklarować, gdzie to oświadczenie ma zastosowanie i jak inna osoba może je sprawdzić lub zakwestionować. To wystarczy na tablicę ogłoszeń. To także wystarczy, aby powstrzymać dużą część języka broszurowego przed niezauważonym przedostaniem się do decyzji prawnej lub operacyjnej.

Dlaczego status przedpremierowy zasługuje na szacunek

Status przedpremierowy nie jest słabszą wersją publicznego. To inny stan. Testy wewnętrzne mogą wspierać prace inżynieryjne i bezpieczeństwo, jednocześnie utrzymując kontrolę dostępu. Zaproszona beta może udostępnić ścieżkę osobom z zewnątrz, zachowując warunki, zakres i prawo do zatrzymania. Publiczne wydanie zmienia, kto może polegać na systemie i jakie obowiązki spoczywają na dostawcy, integratorach i wdrożeniowcach. Rejestr powinien czynić te przejścia widocznymi, zamiast traktować wydanie jako pojedynczy dźwięk trąbki.

Rekord przedpremierowy może być nadal użyteczny dla społeczeństwa. Może identyfikować model, dostawcę, zamierzoną ścieżkę, status, istniejące dowody oraz dowody wciąż oczekujące. Może stwierdzić, że data jest planowana i że dostęp nie został otwarty. Może opublikować bramę wydania bez udawania, że brama została przekroczona. To szczególnie dobre miejsce, aby rejestr był nudny. Nudny status jest bezpieczniejszy niż ekscytująca niejednoznaczność.

W Dweve staramy się stosować tę dyscyplinę do naszego własnego publicznego rekordu. W naszym Centrum Zaufania rejestr modeli jest oznaczony jako przedpremierowy i wymienia Dweve Loom 1.0 jako wyłącznie wewnętrzne testy przedpremierowe na dzień 1 sierpnia 2026 r. Odnotowuje, że do tej daty nie miało miejsca żadne zewnętrzne wydanie, i wymienia 1 września 2026 r. jako planowaną datę dostępu do rynku unijnego dla zewnętrznej bety wyłącznie na zaproszenie. Planowana to ważne słowo: wpis nie zamienia planu w wydarzenie.

Nasz publiczny rekord wyjaśnia również, że Loom jest jedynym modelem tam wymienionym, że jest własnościowy, a nie wydany na licencji open-source, oraz że nasze produkty i osobno licencjonowane narzędzia open-source nie są przedstawiane jako dodatkowe modele. Ta granica zapobiega pomyłce między katalogiem produktów a rejestrem modeli. Utrzymuje również publiczne oświadczenie na tyle małe, aby można je było sprawdzić.

To wszystko, co musimy tutaj powiedzieć o Dweve. Rejestr modeli jest użyteczny, gdy czyni nasz własny status wydania mniej pochlebnym, ale bardziej precyzyjnym. Powinien działać tak samo dla każdego innego.

Granica między sferą publiczną a prywatną to decyzja projektowa

The strongest registry is not the one with the most fields. It is the one whose fields have a reason, an owner and a boundary. Public readers need a stable identity, a declared purpose, a truthful status, an accountable organisation, usable links and enough limitations to understand the claim. Authorised reviewers need deeper evidence, controlled technical details and a route to inspect incidents or sensitive tests. Operators need secrets, permissions and runbooks that should not be on the noticeboard at all.

Those layers should agree about the facts that cross the boundary. If the public page says a route is paused, the controlled record should say who paused it and why. If a technical file is superseded, the public entry should not continue to link it as current. If an evaluation is restricted, the public page should still state its scope and status. The boundary should limit access to detail, not create three incompatible versions of reality.

Readers should be able to ask five simple questions and receive five stable answers. What is this object? Who is responsible for it? What may it do? What is its current status? What evidence and remedies exist when the claim is challenged? A registry that answers those questions is already doing institutional work. A registry that cannot answer them should not be rescued by animated badges or a dashboard with twelve filters.

There is an optimistic way to read the European movement towards model and algorithm registers. It is not that a database will solve AI governance. It is that public institutions are building places where claims have names, dates, owners and boundaries. Those are the small components from which larger accountability systems are made.

The noticeboard has to survive change

A model registry is the new public noticeboard only if the notices remain legible after the weather changes. The page must survive a model update, a supplier change, a new deployment, a corrected limitation, a withdrawn route and a difficult question from someone who was not in the room. That means keeping history, labelling plans, linking evidence and saying what the record cannot prove.

The work is less glamorous than a launch page. It is also more durable. A public record that distinguishes model identity from deployment state, status from intention, documentation from proof and public facts from controlled evidence gives people something better than reassurance. It gives them a route through the system.

Good registries do not ask readers to trust a colour, a number or a famous name. They make the claim narrow enough to inspect and the boundary clear enough to challenge. They leave a trail to the people who can answer, the records that can be checked and the decision that can be changed. That is a very old civic idea, wearing a reasonably modern file format.

Put the notice on the board. Put the evidence behind it. Keep the old notice where someone can still read it. Then let the public decide what the record earns.

Sources