The model registry is the new public noticeboard

Modelių registras gali visuomenei pasakyti, kas yra sistema, kas už jos stovi, kur ją galima naudoti ir kas pasikeitė. Jis negali tvarkingą įrašą paversti...

The model registry is the new public noticeboard

Puslapis, kuris pradeda prisipažindamas, kad nėra magiškas

Pirmas dalykas, kurį padaro naudingas modelių registras, yra nuvilia jus. Jis nesako, kad modelis yra saugus. Jis nesako, kad organizacija yra kompetentinga. Jis nepaverčia tiekėjo pažado faktu ar žalios etiketės priežastimi nustoti klausti. Vietoj to jis pateikia apibrėžtą įrašą: štai kas tai yra, štai versija, štai savininkas, štai deklaruota paskirtis, štai būsena ir štai kur saugoma pagrindžianti medžiaga.

Tas kuklumas yra visuomenės pasitikėjimo pradžia. Registras yra skelbimų lenta, o ne šventovė. Skelbimų lenta pasako bendruomenei, kas statoma, kas už tai atsakingas ir kurie skelbimai buvo pakeisti. Ji nesertifikuoja kiekvieno pastato gatvėje meistriškumo. Ji suteikia žmonėms vietą, nuo kurios pradėti ieškoti, ir būdą pastebėti, kada pats skelbimas paseno.

Atidarius Nyderlandų vyriausybės algoritmų registrą, dizainas stebėtinai paprastas. Vyriausybės organizacijos skelbia informaciją apie algoritmus, kuriuos naudoja savo darbe. Registras orientuojasi į didelį poveikį turinčius algoritmus, įskaitant didelės rizikos dirbtinio intelekto sistemas, ir lankytojams paaiškina, kaip tos sistemos veikia. Puslapyje taip pat pateikiamas naudingas skirtumas, kurio vengia daugelis blizgių dirbtinio intelekto katalogų: algoritmas yra taisyklių ir instrukcijų rinkinys, kurį kompiuteris vykdo, kad apskaičiuotų atsakymą, o ne asmenybė su produkto pristatymu.

Puslapis yra viešas, nes darbas yra viešas. Piliečiui nereikia privačios paskyros, kad sužinotų, jog institucija naudoja algoritmą, ką institucija teigia juo daranti ar kur užduoti kitą klausimą. Tai nereiškia, kad visos techninės detalės tampa viešos. Tačiau dėl to sistemos egzistavimą, jos deklaruotą vaidmenį ir institucinį savininką tampa sunkiau paslėpti už viešųjų pirkimų bylos.

Modelių registrai tampa tokia pačia pilietine priemone. Jie yra tarp techninio katalogo ir viešojo įrašo. Inžinieriams reikia stabilaus identifikatoriaus ir versijos, kad galėtų integruoti. Operatoriams reikia būsenos ir savininko, kad galėtų vykdyti. Tolesniems paslaugų teikėjams reikia galimybių, apribojimų ir sąlygų. Auditoriams reikia pėdsako, vedančio prie įrodymų. Nukentėjusiems žmonėms reikia žinoti, kad sistema egzistuoja ir kaip ginčyti tai, ką ji daro. Vienas puslapis negali atsakyti į visus šiuos klausimus, tačiau gerai suprojektuotas registras gali nukreipti kiekvieną skaitytoją į tinkamą lygmenį.

Pavojus tas, kad žodis registras dokumentą priverčia skambėti išsamesniu, nei jis yra. Telefonų knyga yra registras, bet ji negali pasakyti, ar numeris vis dar veikia. Krovinio manifestas yra registras, bet jis negali pasakyti, ar krovinys išgyveno kelionę. Modelio įrašas yra registras, bet jis negali talpinti visų veikimo, sąžiningumo, saugumo, teisėtumo ir socialinių pasekmių įrodymų. Naudingas klausimas yra ne tai, ar modelis yra registre. Svarbu tai, ką įrašas nustato, ką palieka atvirą ir ką skaitytojas gali patikrinti toliau.

Skelbimų lenta yra atrankos pažadas

Inventorius bando suskaičiuoti viską. Katalogas bando padėti pasirinkti. Registras duoda oficialesnį pažadą: šie įrašai priklauso apibrėžtai apimčiai, jie turi savininką, o informacija tvarkoma pagal taisyklę. Pažadas pirmiausia susijęs su atranka, o ne su programine įranga. Be aiškiai nurodytos apimties patrauklus sąrašas yra tik atsitiktinai įsimintų dalykų rinkinys.

Štai kodėl kiekvienam registrui reikia sakinio, kuriame būtų pasakyta, ką jis apima ir ko sąmoningai neįtraukia. ES dirbtinio intelekto akto centrinė duomenų bazė nėra kiekvieno Europoje cirkuliuojančio modelio sąrašas. 71 straipsnis įsteigia ES duomenų bazę tam tikroms didelės rizikos dirbtinio intelekto sistemoms ir sistemoms, kurios registruojamos pagal 49 straipsnyje aprašytus maršrutus. Nyderlandų algoritmų registras nėra kiekvieno vyriausybės įstaigoje atlikto skaičiavimo sąrašas. Jis orientuojasi į didelį poveikį turinčius algoritmus, įskaitant didelės rizikos dirbtinio intelekto sistemas. Riba yra įrašo dalis, o ne išnaša teisininkams.

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.

Viešojo diegėjo atveju informacija yra kitokia. Įraše pateikiama diegėjo tapatybė, informaciją teikiantis asmuo, teikėjo įrašo URL adresas ir pagrindinių teisių poveikio vertinimo bei, kai taikoma, duomenų apsaugos poveikio vertinimo santraukos. Šis skirtumas svarbus, nes modelio teikėjas ir valdžios institucija žino ne tuos pačius dalykus ir neturi tos pačios atsakomybės. Registras, sujungiantis juos į vieną tiekėjo kortelę, ištrina vietą, kurioje sistema susitinka su institucija.

Teisinė duomenų bazė todėl yra daugiasluoksnė. Joje registruojama sistemos tapatybė. Joje registruojamas teikėjas. Joje gali būti registruojamas diegėjas ir naudojimo atvejis. Joje registruojama būsena ir patvirtinamosios deklaracijos. Ji nepakeičia techninės dokumentacijos, rizikos valdymo, kokybės sistemos ar rinkos priežiūros po pateikimo rinkai, kurių Aktas reikalauja kitur. Duomenų bazė yra viešas atskaitingų faktų indeksas. Ji nėra visas atitikties failas.

Šį skirtumą lengva pamiršti, nes žmonėms patinka vienas URL adresas, kuriame, atrodo, yra atsakymas. Įstatymas yra mažiau sentimentalus. Jis sukuria viešą paviršių, riboto naudojimo paviršius ir kontroliuojamus dokumentacijos kanalus. Viešas paviršius turi būti naudojamas. Riboto naudojimo paviršius turi likti riboto naudojimo. Dokumentacija turi likti prieinama kompetentingai institucijai arba žemutinės grandies teikėjui, kuriam jos reikia. Rimtas registras yra sąsaja tarp šių įsipareigojimų, o ne būdas jų išvengti.

Registras tampa naudingas, kai tapatybė, būsena ir pokytis yra susieti. Spalva be perėjimo yra tik dekoracija.

Yra dar viena svarbi riba. Dirbtinio intelekto akto nuostatos dėl bendros paskirties DI nėra tas pats, kas viešas visų bendros paskirties modelių katalogas. 53 straipsnis reikalauja, kad teikėjai saugotų techninę dokumentaciją, teiktų informaciją žemutinės grandies DI sistemų teikėjams, laikytųsi autorių teisių politikos ir skelbtų pakankamai išsamią mokymo turinio santrauką. Komisijos gairėse paaiškinama, kad techninė dokumentacija skirta DI biurui ir nacionalinėms kompetentingoms institucijoms paprašius, o žemutinės grandies dokumentacija padeda integruotojams suprasti galimybes ir apribojimus. Tik dalis šios medžiagos priklauso viešai skelbiamai informacijai.

Aktas taip pat reikalauja, kad Komisija paskelbtų ir tvarkytų sisteminės rizikos bendros paskirties DI modelių sąrašą. Sisteminės rizikos modelių sąrašas yra vertingas viešas signalas, tačiau jis nėra tas pats objektas kaip išsamus modelių registras. Jis turi siauresnę paskirtį ir turi gerbti intelektinės nuosavybės teises, konfidencialią verslo informaciją ir komercines paslaptis. Vadinti kiekvieną sąrašą registru yra nekenksminga tik tol, kol kas nors nepadaro prielaidos, kad sąrašas įrodo daugiau, nei iš tikrųjų įrodo.

Modelis nėra viena eilutė

Žmonės apie modelį kalba taip, tarsi jis būtų stiklainis lentynoje. Pavadinimas atspausdintas ant etiketės, versija įspausta apačioje, o turinys nesikeičia, kol kas nors neatidaro dangtelio. Toks vaizdinys tinka statiniam artefaktui. Jis tampa nepatikimas, kai modelis yra pritaikomas, tiksliai derinamas, įtraukiamas į įrankius, teikiamas keliais kanalais arba keičiamas naudojimo metu.

Registrui reikia bent dviejų tapatybių: modelio tapatybės ir to, kas iš tikrųjų veikė, tapatybės. Pirmoji atsako į klausimą, kurį modelį turi omenyje teikėjas. Antroji gali identifikuoti užfiksuotą būseną, užantspauduotą diegimo paketą, vietinį eksportą arba atkūrimo rinkinį. Jų susiejimas apsaugo nuo dviejų priešingų klaidų. Paslauga gali nustoti apsimesti, kad kiekviena tiesioginė būsena turi vieną nuolatinį maišos kodą, o operatorius gali nustoti apsimesti, kad paketo maišos kodas vienas apibūdina visą modelių šeimą.

Versijų numeriai naudingi tik tada, kai matoma jų keitimo taisyklė. Versija gali reikšti naują išmoktų parametrų rinkinį, naują apribojimų katalogą, paieškos pakeitimą, pakeistą saugos sluoksnį arba esminį aptarnavimo sutarties pasikeitimą. Jei teikėjas visiems šiems atvejams naudoja vieną numerį, tas numeris tampa mandagiu būdu pasakyti, kad kažkas pasikeitė. Registras turėtų susieti įpėdinį su pirmtaku ir nurodyti, kuri sutarties dalis pasikeitė.

Adaptyvus elgesys prideda dar vieną niuansą. Jei sistema gali keistis naudojimo metu, įrašas turėtų tai nurodyti. Tai nėra pripažinimas, kad sistema yra nevaldoma. Tai pripažinimas, kad žodis versija negali atlikti viso darbo. Registras gali išlaikyti stabilų modelio tapatumą, prie jo pridėti laike apribotas užfiksuotas būsenas ir įrašyti sąlygas, kuriomis būsena buvo sukurta. Tikslas nėra užšaldyti gyvą sistemą klaidingoje nuotraukoje. Tikslas yra suteikti kiekvienai prasmingai nuotraukai datą ir kadrą.

Tapatumas turi ir socialinį aspektą. Modelio pavadinimo nepakanka, kai kelios teisinės bendrovės platina panašius artefaktus, kai vėlesnis teikėjas pakeičia modelį arba kai produktas įdiegia modelį po savo pavadinimu. Registras turėtų padaryti grandinę matomą: teikėjas, platintojas, jei jis kitoks, diegėjas, jei aktualu, ir sistema ar maršrutas, kuriame modelis naudojamas. Asmuo, kuriam sprendimas turi įtakos, neturėtų atlikti kriminalistinės archeologijos ant produkto logotipo, kad sužinotų, kas už jį atsako.

Būsena yra veiksmažodis, ne spalva

Būsenos laukai dažnai vaizduojami kaip ženkliukai, nes ženkliukai tvarkingai telpa kortelėse. Ženkliukas nėra būsena. Būsena yra teiginys apie veiksmą ir laiką. Vidinis testavimas reiškia viena, kai prieigą kontroliuoja teikėjas. Išankstinis leidimas reiškia ką kita, kai pakviesti pašaliniai asmenys gali naudotis maršrutu pagal apibrėžtas sąlygas. Rinkoje, teikiama, sustabdyta, atšaukta ir atšaukta iš rinkos, kiekviena turi skirtingas veiklos pasekmes.

Naudingas įrašas nurodo, ką būsena leidžia ir ko neleidžia. Jei sistema skirta tik vidiniam naudojimui, skaitytojas neturėtų daryti išvados apie viešą prieinamumą iš dokumentacijos puslapio. Jei planuojamas išorinis beta testas, data turėtų būti pažymėta kaip planuojama, o ne pateikta kaip išleidimas. Jei sistema atšaukta, įrašas turėtų išsaugoti ankstesnį tapatumą ir nurodyti, ar esami diegimai gali tęstis, turi būti sustabdyti ar yra perkeliami. Būsena be įsigaliojimo datos yra gandas, vilkintis uniformą.

Būsena taip pat turėtų turėti savininką. Kas gali perkelti įrašą iš vidinio į išorinį? Kas gali sustabdyti maršrutą? Kas gali paskelbti, kad išleidimo data pasikeitė? Kokie įrodymai reikalingi prieš perėjimą? Šie klausimai priklauso veiklos procesui, tačiau viešas įrašas turėtų padaryti galutinį sprendimą suprantamą. Registras, rodantis dabartinį ženkliuką, bet slepiantis už jo esančią valdžią, yra tik valdymo nuotaikų lenta.

Iliustratyvus pavyzdys, ne tikras sąrašas: įrašas gali nurodyti, kad modelis yra kontroliuojamo vertinimo stadijoje, kad joks išorinis maršrutas nėra atidarytas, kad vėlesnei datai siūlomas tik kvietimų bandomasis etapas ir kad pasiūlymas vis dar priklauso nuo išleidimo vartų. Pavyzdys neįvardija jokios organizacijos, modelio ar įvykio. Jo tikslas yra parodyti, kaip įrašas atskiria planą nuo fakto. Ta pati disciplina taikoma atšaukimui, galimybių teiginiui ar sertifikatui, kuris dar neišduotas.

Šis atskyrimas apsaugo skaitytojus nuo žinomo triuko. Būsimas ketinimas kartojamas pakankamai dažnai, kad pradėtų skambėti kaip istorija. Registrai turėtų būti vieta, kur šis triukas nustoja veikti. Įrašas gali rodyti planą, bet planas turi išlaikyti savo etiketę. Europa jau turi pakankamai kalendorių. Data nėra faktas vien todėl, kad ji įdėta į spalvotą stačiakampį.

Registras nėra įrodymų kambarys

A public entry should be short enough to read and strong enough to orient a serious question. The evidence room behind it can be much larger. The AI Act's Article 53 documentation duties illustrate why. Providers of general-purpose AI models must draw up and keep technical documentation covering development, training, testing and evaluation. They must make information and documentation available to downstream AI-system providers so those providers can understand capabilities and limitations. They must publish a sufficiently detailed summary of training content and maintain a policy for Union copyright law.

Those obligations serve different readers. A competent authority may need the full technical record. A downstream provider needs integration information and limitations. The public needs a clear account of what the model is and how its training-content summary is bounded. A registry entry can link those surfaces without pretending that a public page should contain every security-sensitive detail, every weight file or every personal-data-bearing test sample.

Links are not evidence by magic either. A registry that points to an evaluation report should identify which release the report covers, what the evaluation measured and which conditions limit the result. A link to a training summary should say whether the summary covers pre-training, fine-tuning, or a defined set of content categories. A link to a certificate should show who issued it, what it certifies and when it expires. Otherwise the page is a shelf of unopened envelopes.

The same rule applies to safety claims. A registry may say that a risk assessment exists, that a monitoring plan is linked or that a serious-incident route is published. It should not imply that the existence of a document proves the underlying system is safe. Documentation is a way to inspect a claim. It is not the claim's substitute.

This is where public writing needs discipline. A model card, transparency page or registry entry can describe intended use and known limitations. It cannot use the phrase trustworthy as a conclusion unless the evidence and scope make that conclusion defensible. The honest sentence is often more useful: these are the conditions we evaluated, these are the limits we observed, and these are the cases we did not claim to cover.

The Dutch register shows the value of an ordinary public list

The Dutch Algorithm Register is instructive precisely because it is not trying to look like a futuristic control room. It gives government organisations a public place to describe algorithms used in their work. Its English page warns that descriptions have been automatically translated and that the Dutch original is the authoritative version for the description. That small note is a lesson in provenance. Access is not the same as accuracy, and a translated interface should not erase the source language.

The register's public purpose is also stated without theatrical language. It focuses on impactful algorithms, including high-risk AI systems, and gives visitors insight into how they work. The visitor can browse algorithms, organisations and templates. The object is not to offer a score for each algorithm. It is to make the use of algorithmic systems visible enough for people, organisations and media to follow, question and scrutinise government practice.

The accompanying Dutch Algoritmekader turns that purpose into a requirement. It says that, unless an exclusion applies, public bodies publish impactful algorithms and high-risk AI systems in the register. It also says that incorrect or incomplete publication can make it harder for affected people and other stakeholders to understand and challenge the use of technology that may touch their rights. Transparency is therefore not only a courtesy. The quality of the entry can affect the quality of public control.

Šios gairės atsargiai apibrėžia savo taikymo sritį. Jose registras apibūdinamas kaip įrankis platesniame įstatymų ir reikalavimų rinkinyje, įspėjama, kad sistema nėra išsami ir gali neapimti sektoriui skirtų teisės aktų. Tai, kad algoritmas įtrauktas į registrą, neišsprendžia visų teisinių ar etinių klausimų. Tai, kad jo registre nėra, neįrodo, kad jis nekenksmingas. Skaitytojui, norinčiam suprasti įrašą, reikia žinoti registro įtraukimo taisyklę ir visą sistemą.

Būtent toks modelis naudingas modelių registrams. Viešas sąrašas turėtų būti lengvai randamas, parašytas žmonėms, kurie nedalyvavo viešųjų pirkimų posėdyje, ir susietas su išsamesnius duomenis saugančiais įrašais. Jis turėtų atskleisti neapibrėžtumą, o ne jį slėpti. Jame turėtų būti nurodyta, kada angliškas aprašymas yra mašininis vertimas. Jame turėtų būti paaiškinta, kurios sistemos įtrauktos, o kurios ne. Trūkstamas ar pasenęs įrašas turėtų tapti matoma valdymo problema, o ne privačiu nusivylimu.

Nereikia sugalvoti dramatiško įvykio, kad suprastume, kodėl tai svarbu. Pilietis, bandantis suprasti automatizuotą valdžios procesą, jau turi praktinį klausimą: ar sistema naudojama, kas ją naudoja, kokiu tikslu ir pagal kokį paaiškinimą? Registras suteikia šiam klausimui adresą. Atsakymas vis tiek gali būti neišsamus. Bent jau institucija nebegali apsimesti, kad nėra kur klausti.

Viešumas nereiškia atvirumo

Skaidrumas tampa neproduktyvus, kai į jį žiūrima kaip į įsakymą skelbti viską. Vieši įrašai gali atskleisti asmens duomenis, neskelbtiną informaciją, komercines paslaptis ir atakų kelius. Jie taip pat gali sukelti klaidingą pasitikėjimą, kai skelbiami techniniai fragmentai, kurių paprastas skaitytojas negali suprasti. Viešojo ir privačiojo sektorių riba turi būti sukurta, aprašyta ir peržiūrėta, o ne improvizuota tos komandos, kuri atsitiktinai tvarko turinio valdymo sistemą.

AI aktas pateikia teisinį pavyzdį. 49 straipsnio 4 dalis tam tikras sistemas priskiria saugiam neviešam skyriui ir apriboja prieigą Komisijai bei atitinkamoms nacionalinėms institucijoms. 71 straipsnis nustato, kad pagal 49 straipsnį registruota informacija yra viešai prieinama, išskyrus riboto naudojimo skyrius, o pagal 60 straipsnį registruota informacija prieinama tik rinkos priežiūros institucijoms ir Komisijai, nebent teikėjas sutinka su vieša prieiga. Viešumas yra taisyklė su išimtimis, o ne visuotinis numatytasis principas.

53 straipsnis panašų skirtumą nustato bendros paskirties modeliams. Teikėjai privalo pateikti techninę dokumentaciją AI tarnybai ir nacionalinėms kompetentingoms institucijoms paprašius, o integruojantiems teikėjams privalo pateikti tolesnę dokumentaciją. Šios pareigos aiškiai priklauso nuo būtinybės gerbti ir apsaugoti intelektinės nuosavybės teises, konfidencialią verslo informaciją ir komercines paslaptis. Registras neturėtų versti teikėjo skelbti medžiagos, kurią pagal įstatymą reikia kontroliuoti. Konfidencialumas taip pat neturėtų tapti mandagiu pasiteisinimu nuslėpti sistemos, darančios įtaką visuomenei, egzistavimą, paskirtį ar būseną.

Praktinis modelių registras gali naudoti lygmenis. Viešajame lygmenyje nurodomas modelis, teikėjas, būsena, numatyta paskirtis, pagrindinės galimybės, žinomi apribojimai, prieigos būdai, išleidimo sąlygos, įrodymų nuorodos ir pakeitimų istorija. Kontroliuojamame lygmenyje saugoma išsami techninė dokumentacija, grėsmių modeliai, riboto naudojimo vertinimo medžiaga, incidentų duomenys ir kita informacija, kurios reikia įgaliotiems vertintojams. Privačiame veiklos lygmenyje saugomos paslaptys, asmens duomenys ir vidaus kontrolės informacija, kurių apskritai neturėtų būti atskleista. Lygmenys yra atskiri įrašai su nuorodomis, o ne vienas puslapis su skaidrumo akordeonu.

Gera skaidrumo politika turi ribą. Ji skelbia tai, ko žmonėms reikia sistemai suprasti, ir saugo tai, ką turi kontroliuoti įgalioti vertintojai.

Viešoji dalis vis tiek turėtų būti konkreti. Galima pasakyti, kad modelis prisitaiko naudojimo metu, neatskleidžiant privačios būsenos reprezentacijos. Galima nurodyti, kad maršrutas yra tik su kvietimu, neskelbiant kvietimo prieigos raktų. Galima aprašyti išvesties modalumus ir turinio žymėjimo politiką, neatskleidžiant pasirašymo raktų. Galima pasakyti, kad rizikos vertinimas egzistuoja, ir nurodyti jo apimtį, neskelbiant saugumo schemos, kuri palengvintų atakas prieš paslaugą.

Kontroliuojama dalis taip pat turi būti sąžininga. Dokumentas, pažymėtas kaip konfidencialus, nėra automatiškai išsamus, aktualus ar teisingas. Jam reikia savininko, versijos, prieigos taisyklės ir saugojimo taisyklės. Jei viešasis registras pateikia nuorodą į kontroliuojamą įrašą, nuoroda turėtų atskleisti jo būseną ir atsakingą maršrutą net tada, kai turinys yra ribojamas. Priešingu atveju visuomenė mato juodąją skylę ir yra prašoma tai vadinti valdymu.

Versijavimas yra tai, kas registrą daro naudingu

Dauguma registro nesėkmių nėra dramatiškos. Tai maži užmaršties veiksmai. Naujas modelis pakeičia senąjį, bet įrašas redaguojamas vietoje. Politika keičiasi, bet pastraipa apie numatytą naudojimą lieka. Teikėjas perkelia maršrutą iš vidinio testavimo į išorinę beta versiją, bet būsenos ženklelis pakeičiamas prieš užfiksuojant įsigaliojimo datą. Diegimas atšaukiamas, bet senasis įrašas išnyksta, pasiimdamas ir istoriją. Dabartis atrodo tvarkinga. Praeitis tampa neatsakoma.

Versijuotas įrašas laiko atskirai bent keturis laikrodžius. Turinio versija nurodo, kuris įrašo tekstas ir laukai yra aktualūs. Įsigaliojimo data nurodo, kada teiginys taikomas. Modelio ar paketo versija nurodo, kuris techninis objektas aprašomas. Patikrinimo data nurodo, kada kažkas patikrino įrašą. Šios datos gali sutapti. Jos neturi sutapti. Laikyti jas viena data yra patogu ir dažnai klaidinga.

Ankstesnės versijos turėtų likti randamos pagal tinkamą saugojimo taisyklę. Visuomenei nereikia kiekvieno vidinio pakeitimo, bet jai reikia žinoti, kada pasikeitė esminis tikslas, būsena, maršrutas, apribojimas ar nuosavybės teiginys. Pakeitimų žurnalas gali pasakyti, kas pasikeitė, neatskleisdamas privačios informacijos. Mašininiu būdu skaitomas įrašas gali susieti ankstesnę versiją ir manifestą. Žmogui skaitomas puslapis gali paaiškinti pasekmes paprasta kalba. Abi sąsajos turėtų sutapti.

Versijavimas taip pat suteikia prasmę atšaukimui. Jei modelis atšaukiamas, nes maršrutas uždarytas, tai skiriasi nuo atšaukimo dėl rimto defekto ar teisinės problemos, reikalaujančios veiksmų. Jei modelis lieka esamuose privačiuose diegimuose, viešasis įrašas turėtų tai nurodyti. Jei įpėdinis yra suderinamas tik su kai kuriomis integracijomis, migracijos riba turėtų būti matoma. Registras, kuris pašalina pavadinimą neužfiksuodamas priežasties, palieka kiekvienam vėlesniam skaitytojui sugalvoti priežastį.

Pakeitimų istorija ypač svarbi prisitaikančioms sistemoms. Modelio tapatybė gali išlikti stabili, kol keičiasi užfiksuotos būsenos, apribojimų rinkiniai, paieškos šaltiniai ar išvesties kontrolės. Registras gali nurodyti, kurie pakeitimai sukuria naują paketą, kuriems pakeitimams reikia naujo vertinimo ir kurie pakeitimai lieka deklaruotos tapatybės ribose. Tai nėra per didelis detalumas. Tai skirtumas tarp sistemos, kurią galima atkurti, ir sistemos, kurią galima tik prisiminti.

Savininkai yra įrašo dalis

A model registry entry without an owner is a weather report. It tells you what the sky looked like and leaves you with no one to call when the roof leaks. Provider and deployer roles are not the same, and neither role should be allowed to dissolve into the word platform.

The provider owns the model identity, the development record and the release decision within its scope. A deployer owns the decision to use a system under its authority, including the local purpose, safeguards, impact assessment and operating controls. A downstream provider may integrate a general-purpose model into an AI system and carry responsibilities that the model provider cannot see. A public registry should expose those relationships where the law and the risk require them.

Contact information is not administrative filler. It gives an affected person a route to ask who made a decision, which version was used or how a correction can be requested. A generic mailbox can be appropriate, but it should lead to a maintained process. The entry should also say whether the contact is for technical support, rights requests, incident reporting, procurement or public accountability. One inbox cannot be every institution at once, despite the best efforts of modern forms.

Ownership should include authority to change the record. If the named owner cannot pause a route, correct a status or publish a withdrawal, the entry is decorative. The organisation may still have a legal owner somewhere else, but the operational gap remains. A good registry makes responsibility visible before an incident forces people to draw the organisation on a whiteboard.

Designing a registry people can actually read

The first reader of a model registry is not always a regulator or an engineer. It may be a journalist, a procurement officer, a local official, a researcher, an employee asked to use the system, or a person trying to understand why an automated service touched their case. The page should answer the common question before it reaches for specialised vocabulary.

Start with the identity and the reason for the entry. Say who provides the model, which version is being described, what kind of object it is and whether it is a model, an integrated AI system or a deployment record. Say whether it is internal, available to invited users, on the market, suspended or withdrawn. The reader should not have to infer the status from a download button.

Then show the purpose and the boundary. State what the model is intended to do, which uses are outside the claim and which decisions it is not authorised to make. Explain whether the model can adapt during use, whether a captured state is required for replay, and whether a downstream route changes the conditions. A capability list without a purpose is a menu without a kitchen.

Use progressive disclosure. The top of the page should be calm and readable. Deeper sections can expose the machine record, evaluation methods, training-content summary, legal documents and release evidence. A public reader can stop after the first layer. An auditor can continue. An engineer can download a stable representation. Hiding the detail is not simplicity. It is just a slow-loading surprise.

Accessibility is part of the record's credibility. The page and machine representation should use clear labels, keyboard navigation, useful headings and text alternatives for visualisations. Dates should not be encoded only as colour. A red badge is not a status for a reader who cannot see red, and a graph that cannot be read without a mouse is not an accessible explanation. A noticeboard in the town square does not become public if the ramp ends at the first step.

Mašininis skaitomumas svarbus dėl kitos priežasties. Jis leidžia tyrėjams palyginti įrašus, viešosioms įstaigoms sudaryti inventorių, auditoriams aptikti pasenusius įrašus, o vėlesnėms priemonėms patikrinti, ar puslapis ir struktūrizuotas įrašas nurodo tą pačią versiją. Mašininis skaitomumas nereiškia, kad įrašas skirtas tik mašinoms. Žmogui skirtas puslapis ir mašininis įrašas turėtų turėti tuos pačius identifikatorius, būseną, datas ir nuorodas, o jų vientisumo ryšys turėtų būti patikrinamas.

Registro laukai yra sprendimai

Kiekvienas laukas skaitytojui parodo, ką organizacija laiko verta išsaugoti. Teikėjo laukas nurodo, kas atsako už modelį. Modelio pavadinimas ir versija nurodo, kaip jį atskirti nuo vėlesnio modelio. Maršruto laukas nurodo, kur modelį galima pasiekti. Paskirties laukas nurodo, kokiam darbui teikėjas yra pasirengęs aprašyti. Apribojimų laukas nurodo, kur baigiasi aprašymas. Schema yra valdymo dokumentas, užrašytas mažais stačiakampiais.

Tapatybės laukai turėtų būti vienareikšmiai ir stabilūs. Juose gali būti teikėjo juridinis pavadinimas, modelio pavadinimas, versija, unikalus identifikatorius ir nuorodos į kanoninį įrašą. Jei modelį galima teikti per kelis produktus, registre reikėtų atskirti modelio tapatybę nuo integravimo sąsajos. Jei produkte yra keli modeliai, įrašas neturėtų to nuslėpti už produkto pavadinimo.

Būsenos laukai turėtų apimti reikšmę, įsigaliojimo datą, perėjimo priežastį arba pagrindą bei ankstesnį ar vėlesnį įrašą. Data, kuri tik planuojama, turėtų būti pažymėta kaip planuojama. Įrašas, kuris neseniai nebuvo patikrintas, turėtų tai nurodyti. Skaitytojas turėtų galėti suprasti, ar modelis yra prieinamas, siūlomas, pristabdytas ar istorinis, nereikėdamas aiškinti rinkodaros komandos sugalvoto būdvardžio.

Paskirties ir apimties laukai turėtų aprašyti darbą taip, kad jį suprastų ne specialistas. Juose turėtų būti įvardyti numatomi naudotojai, kai tai svarbu, įvesties ir išvesties rūšys bei sprendimai ar veiksmai, kuriuos modelis gali padėti atlikti. Juose taip pat turėtų būti nurodytas draudžiamas arba nepalaikomas naudojimas. Modelis, galintis generuoti tekstą, savaime nėra įgaliotas priimti sprendimą dėl tinkamumo, o modelis, galintis klasifikuoti dokumentus, savaime nėra įgaliotas klasifikuoti žmones.

Gebėjimų laukams reikia sąlygų. Modalumai, konteksto apribojimai, įrankių prieiga, kalbų aprėptis, adaptavimosi elgsena ir išvesties žymėjimas yra prasmingi tik susieti su maršrutu ir leidimu. Gebėjimas, kuris egzistuoja vidiniame eksperimente, bet ne išoriniame maršrute, neturėtų būti pateikiamas kaip viena universali funkcija. Registras nėra norų sąrašas.

Duomenų laukai turėtų nurodyti, ką modelis gauna, ką saugo, ko mokosi naudojimo metu ir kas naudojama vertinimui, tiek, kiek galima atskleisti viešai neatskleidžiant asmens ar konfidencialios informacijos. Mokymo turinio santraukos ir teisių politika turėtų būti susietos ten, kur to reikalaujama. Miglota frazė, pavyzdžiui, mokytas įvairiais duomenimis, skaitytojui beveik nieko nepasako ir prašo jo pačiam susikurti palankų aiškinimą.

Vertinimo laukai turėtų įvardyti klausimą, metodą, duomenų ribas, datą, rezultatą ir apribojimus. Įraše nebūtina atkartoti kiekvienos lentelės, tačiau jame neturėtų būti pateikiamas balas be vardiklio arba testas be tikslo. Gera vertinimo nuoroda leidžia skaitytojui pamatyti, ar įrodymai apima numatytą naudojimą, gretimą naudojimą ar tik laboratorines sąlygas.

Priežiūros laukai turėtų įvardyti, kas gali pristabdyti, perimti, peržiūrėti ir tirti sistemą. Jei modelis tik teikia rekomendacijas, nurodykite, koks veiksmas lieka žmogui. Jei maršrutas gali veikti išorines sistemas, nurodykite, kokie leidimai ir užtvaros taikomi. Jei incidentų pranešimams yra skirtas atskiras kanalas, paskelbkite jį. Priežiūra nėra pastraipa apie žmogaus įtraukimą į procesą. Tai žemėlapis, kas ką gali daryti, kai sistema susiduria su neapibrėžtumu.

Evidence and integrity fields should connect the public entry to a versioned machine record, a release package, a declaration, an evaluation bundle or a transparency log. A hash can establish that a file changed or did not change. It cannot establish that the file was truthful, so the registry should keep the claim and the integrity check separate. Technical precision is not a substitute for judgement, but it makes judgement easier to locate.

Finally, change fields should explain the history. What changed, when, why, who approved it, which routes are affected and whether a new evaluation is needed. The entry should make it possible to answer the most ordinary question in the room: what is different from the record we read last month?

What a registry can establish

A well-maintained registry can establish that a defined object is being described by a named provider under a particular record version. It can establish the declared purpose, status, access route and ownership. It can establish which supporting documents and integrity records a reader can inspect, and which information is deliberately controlled. It can establish that a change was published and that a previous record remains available under the stated retention rule.

It can also establish the organisation's own position. If a provider says that a model is for decision support and not for automatic refusal, the statement is a public boundary. If a deployer says that an impact assessment was completed, the statement creates a question about where the summary or controlled record can be found. If a provider marks a release as planned, the label prevents the plan from masquerading as history.

These are useful facts. They make procurement more precise, integration less speculative and public questions easier to route. They also make disagreement sharper. A reader can say that the declared purpose is too broad, the status is stale, the limitation is missing or the supporting evidence does not cover the claim. A registry earns its keep when it makes that criticism possible.

What a registry cannot establish

A registry entry cannot establish that a model is accurate for every user, safe in every environment, fair across every group or lawful for every deployment. It cannot establish that a public authority followed the right procedure merely because a system is listed. It cannot show that a human reviewer understood an output, that a data subject had a meaningful remedy or that an incident would be detected in time. Those conclusions require evidence about the system in use, the institution using it and the people affected by it.

It also cannot establish that a model is independent of its supplier, that a route is sovereign because it is hosted in Europe, or that an open licence makes responsibility disappear. Ownership, jurisdiction, supply chain, operating control and maintenance are separate questions. A registry can expose the names and links needed to ask them. It cannot answer them by typography.

Nor can a registry prove the negative. An absent entry may mean that the object is out of scope, that an exclusion applies, that publication is late or that someone failed to publish. The reader needs a clear coverage statement and a route to report errors. A public noticeboard is only as reliable as the process that notices when a notice is missing.

An illustrative record, not a hidden case study

The following is an illustrative record design, not a report of a real organisation, model or event. It uses no customer, public authority, deployment date or measured result. Its purpose is to show how a reader can move from a public entry to a controlled evidence route without confusing either layer.

  • Tapatybė: teikėjo pavadinimas, modelio pavadinimas, versija ir stabilus mašininis identifikatorius.
  • Būsena: kontroliuojamas vertinimas, nurodant įsigaliojimo datą ir pastabą, kad joks išorinis kelias nėra atviras.
  • Paskirtis: pagalba atliekant dokumentų analizę apmokytiems darbuotojams, o automatiniai išoriniai sprendimai nepatenka į deklaruotą taikymo sritį.
  • Įvestys ir išvestys: atstovaujami modalumai, numatomų šaltinio medžiagų rūšys ir išvesties tipai, kuriuos kelias gali sukurti.
  • Apribojimai: žinomos kalbos, srities, naujumo, saugos ir prieigos ribos, kiekviena susieta su atitinkamu vertinimu ar politika.
  • Priežiūra: vaidmuo, galintis sustabdyti kelią, neaiškių rezultatų peržiūros tvarka ir incidentų kontaktas.
  • Įrodymai: vieša santrauka, versijuotas techninis įrašas įgaliotiems recenzentams ir paskelbtų failų vientisumo manifestas.
  • Pakeitimai: nuoroda į ankstesnį įrašą, teiginys apie tai, kas pasikeitė, ir sąlyga, dėl kurios reikėtų naujo vertinimo.

Nieko tame įraše nėra apie tai, kad modelis yra geras. Jame nurodyta, ką teikėjas yra pasirengęs teigti, kur tas teiginys galioja ir kaip kitas asmuo gali jį patikrinti ar užginčyti. To pakanka skelbimų lentai. To taip pat pakanka, kad daugybė reklaminės kalbos nepatektų į teisinį ar veiklos sprendimą nepastebėta.

Kodėl išankstinio leidimo būsena nusipelno pagarbos

Išankstinis leidimas nėra silpnesnė viešosios versijos forma. Tai kitokia būsena. Vidinis testavimas gali paremti inžinerijos ir saugos darbus, kartu išlaikant kontroliuojamą prieigą. Pakviesta beta versija gali atverti kelią pašaliniams, išlaikant sąlygas, taikymo sritį ir teisę sustabdyti. Viešas leidimas pakeičia, kas gali pasikliauti sistema ir kokios pareigos tenka teikėjui, integruotojams ir diegėjams. Registras turėtų padaryti tuos perėjimus matomus, o ne traktuoti leidimą kaip vieną trimito garsą.

Išankstinio leidimo įrašas vis tiek gali būti naudingas visuomenei. Jame gali būti nurodytas modelis, teikėjas, numatytas kelias, būsena, esami įrodymai ir dar laukiami įrodymai. Jame galima pasakyti, kad data yra suplanuota ir kad prieiga dar neatidaryta. Jame galima paskelbti leidimo vartus, neapsimetant, kad vartai jau praeiti. Tai ypač gera vieta registrui būti nuobodžiam. Nuobodi būsena yra saugesnė nei jaudinantis neaiškumas.

„Dweve“ stengiamės taikyti šią discipliną savo viešam įrašui. Mūsų pasitikėjimo centre modelių registras pažymėtas kaip išankstinio leidimo ir nurodo „Dweve Loom 1.0“ kaip vidinį tik išankstinio leidimo testavimą nuo 2026 m. rugpjūčio 1 d. Jame užfiksuota, kad iki tos datos nebuvo jokio išorinio leidimo, ir nurodoma 2026 m. rugsėjo 1 d. kaip planuojama Sąjungos rinkos prieigos data išorinės beta versijos versijai tik pakviestiems asmenims. Žodis „planuojama“ yra svarbus: įrašas nepaverčia plano įvykiu.

Mūsų viešas įrašas taip pat aiškiai nurodo, kad „Loom“ yra vienintelis ten išvardytas modelis, kad jis yra patentuotas, o ne išleistas pagal atvirojo kodo modelio licenciją, ir kad mūsų produktai bei atskirai licencijuojami atvirojo kodo įrankiai nėra pateikiami kaip papildomi modeliai. Ši riba neleidžia produktų katalogo supainioti su modelių registru. Ji taip pat išlaiko viešą teiginį pakankamai mažą, kad jį būtų galima patikrinti.

Tai viskas, ką mums reikia pasakyti apie „Dweve“ čia. Modelių registras yra naudingas, kai jis daro mūsų pačių leidimo būseną mažiau glostančią, bet tikslesnę. Jis turėtų daryti tą patį ir bet kam kitam.

Viešojo ir privačiojo sektoriaus riba yra dizaino sprendimas

Stipriausias registras nėra tas, kuris turi daugiausia laukų. Jis yra tas, kurio laukai turi priežastį, savininką ir ribą. Viešiesiems skaitytojams reikia stabilios tapatybės, aiškiai nurodytos paskirties, teisingos būsenos, atskaitingos organizacijos, veikiančių nuorodų ir pakankamai apribojimų, kad suprastų teiginį. Įgaliotiems vertintojams reikia išsamesnių įrodymų, kontroliuojamų techninių detalių ir galimybės peržiūrėti incidentus ar jautrius testus. Operatoriams reikia slaptažodžių, leidimų ir veiksmų vadovų, kurių neturėtų būti ant skelbimų lentos.

Tie sluoksniai turėtų sutarti dėl faktų, kurie kerta ribą. Jei viešame puslapyje nurodyta, kad maršrutas pristabdytas, kontroliuojamame įraše turėtų būti nurodyta, kas jį pristabdė ir kodėl. Jei techninis failas pakeistas, viešas įrašas neturėtų ir toliau į jį pateikti nuorodos kaip į dabartinį. Jei vertinimas yra ribotas, viešame puslapyje vis tiek turėtų būti nurodyta jo apimtis ir būsena. Riba turėtų apriboti prieigą prie detalių, o ne sukurti tris nesuderinamas realybės versijas.

Skaitytojai turėtų galėti užduoti penkis paprastus klausimus ir gauti penkis stabilius atsakymus. Kas yra šis objektas? Kas už jį atsakingas? Ką jis gali daryti? Kokia dabartinė jo būsena? Kokie įrodymai ir sprendimo būdai egzistuoja, kai teiginys yra užginčijamas? Registras, kuris atsako į šiuos klausimus, jau atlieka institucinį darbą. Registras, kuris negali į juos atsakyti, neturėtų būti gelbėjamas animuotais ženkleliais ar prietaisų skydeliu su dvylika filtrų.

Yra optimistiškas būdas suprasti Europos judėjimą modelių ir algoritmų registrų link. Ne tai, kad duomenų bazė išspręs dirbtinio intelekto valdymą. Tai, kad viešosios institucijos kuria vietas, kuriose teiginiai turi pavadinimus, datas, savininkus ir ribas. Tai mažos sudedamosios dalys, iš kurių kuriamos didesnės atskaitomybės sistemos.

Skelbimų lenta turi išlikti įskaitoma keičiantis sąlygoms

Modelių registras yra naujoji viešoji skelbimų lenta tik tuo atveju, jei skelbimai lieka įskaitomi pasikeitus sąlygoms. Puslapis turi išlikti aktualus po modelio atnaujinimo, tiekėjo pasikeitimo, naujo diegimo, pataisyto apribojimo, atšaukto maršruto ir sudėtingo klausimo iš žmogaus, kuris nedalyvavo posėdyje. Tai reiškia, kad reikia saugoti istoriją, žymėti planus, susieti įrodymus ir nurodyti, ko įrašas negali įrodyti.

Šis darbas mažiau įspūdingas nei pristatymo puslapis. Tačiau jis ir patvaresnis. Viešas įrašas, kuris atskiria modelio tapatybę nuo diegimo būsenos, būseną nuo ketinimo, dokumentaciją nuo įrodymų ir viešus faktus nuo kontroliuojamų įrodymų, suteikia žmonėms kažką geriau nei nuraminimą. Jis suteikia jiems kelią per sistemą.

Gerai veikiantys registrai neprašo skaitytojų pasitikėti spalva, skaičiumi ar garsiu vardu. Jie padaro teiginį pakankamai siaurą, kad jį būtų galima patikrinti, ir ribą pakankamai aiškią, kad ją būtų galima užginčyti. Jie palieka pėdsaką iki žmonių, kurie gali atsakyti, įrašų, kuriuos galima patikrinti, ir sprendimo, kurį galima pakeisti. Tai labai sena pilietinė idėja, dėvinti gana modernų failo formatą.

Pakabinkite skelbimą ant lentos. Padėkite įrodymus už jo. Palikite seną skelbimą ten, kur jį vis dar galima perskaityti. Tada leiskite visuomenei nuspręsti, ko vertas įrašas.

Šaltiniai