Registrul de modele este noul avizier public

Un registru de modele poate arăta publicului ce este un sistem, cine îl susține, unde poate fi folosit și ce s-a schimbat. Nu poate transforma o...

Registrul de modele este noul avizier public

Pagina care începe prin a recunoaște că nu este magie

Primul lucru pe care îl face un registru util de modele este să te dezamăgească. Nu spune că un model este sigur. Nu spune că o organizație este competentă. Nu transformă promisiunea unui furnizor într-un fapt, nici o etichetă verde într-un motiv să nu mai pui întrebări. În schimb, îți oferă o evidență delimitată: acesta este obiectul, aceasta este versiunea, acesta este deținătorul, acesta este scopul declarat, aceasta este starea, iar aici este păstrată dovada care susține toate acestea.

Această modestie este începutul încrederii publice. Un registru este un avizier, nu un altar. Un avizier spune unui cartier ce se construiește, cine este responsabil și ce avize au fost înlocuite. Nu certifică calitatea lucrării fiecărei clădiri de pe stradă. Oferă oamenilor un loc de unde să înceapă să caute și o modalitate de a observa când avizul în sine a devenit perimat.

Deschideți Registrul Algoritmilor al guvernului olandez și designul este neobișnuit de sobru. Organismele guvernamentale publică informații despre algoritmii pe care îi folosesc în activitatea lor. Registrul se concentrează pe algoritmii cu impact semnificativ, inclusiv sistemele de inteligență artificială cu risc ridicat, și oferă vizitatorilor o explicație despre modul în care funcționează aceste sisteme. Pagina face și o distincție utilă pe care multe cataloage strălucitoare de AI o evită: un algoritm este un set de reguli și instrucțiuni pe care un computer le urmează pentru a calcula un răspuns, nu o personalitate cu lansare de produs.

Pagina este publică pentru că activitatea este publică. Un cetățean nu are nevoie de un cont privat ca să afle că o autoritate folosește un algoritm, ce spune autoritatea că este scopul acestuia sau unde să adreseze următoarea întrebare. Acest lucru nu face public fiecare detaliu tehnic. Dar face existența sistemului, rolul său declarat și deținătorul instituțional mai greu de ascuns în spatele unui dosar de achiziții.

Registrele de modele devin același tip de obiect civic. Se situează între un catalog tehnic și o evidență publică. Inginerii au nevoie de o identitate stabilă și de o versiune pentru integrare. Operatorii au nevoie de o stare și de un deținător pentru operare. Furnizorii din aval au nevoie de capacități, limite și condiții. Auditorii au nevoie de o pistă care duce înapoi la dovezi. Persoanele afectate au nevoie să știe că un sistem există și cum să conteste ceea ce face. O singură pagină nu poate răspunde la toate aceste întrebări, dar un registru bine proiectat poate îndrepta fiecare cititor către stratul potrivit.

Pericolul este că termenul registru face un document să sune mai complet decât este. O carte de telefon este un registru, dar nu îți poate spune dacă un număr mai funcționează. Un manifest de transport este un registru, dar nu îți poate spune dacă marfa a supraviețuit călătoriei. O evidență de model este un registru, dar nu poate purta întreaga dovadă a performanței, echității, securității, legalității și consecințelor sociale. Întrebarea utilă nu este dacă un model este în registru. Este ce stabilește intrarea, ce lasă deschis și ce poate inspecta un cititor în continuare.

Un avizier este o promisiune de selecție

Un inventar încearcă să numere totul. Un catalog încearcă să te ajute să alegi. Un registru face o promisiune mai formală: aceste intrări aparțin unui domeniu definit, au un deținător, iar informația este menținută conform unei reguli. Promisiunea este despre selecție înainte de a fi despre software. Fără un domeniu declarat, o listă atractivă este doar o colecție de lucruri care s-au întâmplat să fie amintite.

De aceea, fiecare registru are nevoie de o propoziție care să spună ce include și ce exclude în mod deliberat. Baza de date centrală a Actului UE privind IA nu este o listă a fiecărui model care circulă în Europa. Articolul 71 stabilește o bază de date a UE pentru anumite sisteme de IA cu risc ridicat și pentru sistemele înregistrate conform rutelor descrise în Articolul 49. Registrul Algoritmilor olandez nu este o listă a fiecărui calcul făcut într-un birou guvernamental. Se concentrează pe algoritmii cu impact semnificativ, inclusiv sistemele de IA cu risc ridicat. Granița face parte din evidență, nu este o notă de subsol pentru avocați.

Un registru de modele ar trebui să răspundă la aceeași întrebare de graniță în limbaj obișnuit. Listează modele fundaționale, sisteme de IA implementate, experimente interne, descendenți reglați fin, pachete de evaluare sau doar modele oferite utilizatorilor externi? O nouă configurație de servire primește o nouă intrare, o nouă versiune sau o înregistrare de implementare legată? O stare capturată a unui sistem adaptiv contează ca aceeași identitate de model? Dacă registrul nu decide aceste întrebări, fiecare cititor le va decide diferit. Așa se transformă o listă scurtă într-o discuție lungă.

Selecția face și absența semnificativă. Dacă domeniul de aplicare spune că toate sistemele cu risc ridicat accesibile publicului trebuie să apară, o intrare lipsă este o problemă de guvernanță. Dacă domeniul de aplicare spune că sunt incluse doar modelele introduse pe o piață, un experiment intern poate lipsi prin proiectare. Publicul nu poate interpreta un rezultat de căutare gol fără să știe care dintre cele două situații se aplică. Tăcerea nu este neutră atunci când registrul nu și-a explicat vocabularul.

Există o mică virtute administrativă în a spune acest lucru clar. Registrele nu trebuie să pretindă că știu totul. Ele trebuie să spună cititorului ce știu, de ce sunt responsabile și ce rămâne în afara cadrului. Un registru își câștigă autoritatea făcând explicită granița domeniului său de aplicare, nu decorând coperta. Tehnologia este mai nouă. Instinctul birocratic nu este.

Ce pune de fapt regula europeană pe masă

Regulamentul privind IA dă cuvântului înregistrare o formă juridică concretă, dar nu una universală. Articolul 49 impune unui furnizor sau reprezentant autorizat să înregistreze anumite sisteme de IA cu risc ridicat înainte de a le introduce pe piață sau de a le pune în funcțiune. Impune, de asemenea, înregistrarea atunci când un furnizor a concluzionat că un sistem nu este cu risc ridicat în condițiile articolului 6 alineatul (3). Autoritățile publice și organismele publice echivalente care implementează anumite sisteme cu risc ridicat au propria obligație de înregistrare, inclusiv înregistrarea utilizării lor.

Același articol face explicită granița public-privat. Anumite sisteme cu risc ridicat utilizate în aplicarea legii, migrație, azil și gestionarea frontierelor sunt înregistrate într-o secțiune securizată, nepublică. Sistemele cu risc ridicat din al doilea punct al anexei III sunt înregistrate la nivel național. Acestea nu sunt detalii de implementare care pot fi rezolvate într-un tablou de bord. Ele descriu audiențe diferite, riscuri diferite și permisiuni diferite de a vedea înregistrarea.

Articolul 71 spune că Comisia, împreună cu statele membre, înființează și menține baza de date a UE. Informațiile înregistrate în temeiul articolului 49 trebuie să fie accesibile și disponibile publicului într-un mod ușor de utilizat și ar trebui să fie ușor de navigat și citibile automat, cu excepții pentru secțiunile restricționate. Baza de date ar trebui să conțină date cu caracter personal doar în măsura necesară. Aceasta este o definiție utilă a transparenței publice: o înregistrare pe care oamenii o pot găsi și procesa, fără a transforma înregistrarea într-o a doua problemă de date cu caracter personal.

Anexa VIII este locul unde panoul de anunțuri devine specific. Pentru un furnizor care înregistrează un sistem cu risc ridicat, înregistrarea include identitatea furnizorului și datele de contact, o denumire comercială sau o referință fără ambiguitate, scopul preconizat, o descriere de bază a informațiilor utilizate și a logicii de funcționare, starea sistemului, certificatele relevante, statele membre în care sistemul este introdus pe piață sau pus în funcțiune, declarația de conformitate, instrucțiunile de utilizare și un URL opțional pentru informații suplimentare. Acestea nu sunt câmpuri de marketing. Sunt instrumente de identificare și responsabilitate.

Pentru un implementator public, informațiile sunt diferite. Înregistrarea include identitatea implementatorului, persoana care depune informațiile, adresa URL a intrării furnizorului și rezumate ale unei evaluări a impactului asupra drepturilor fundamentale și, după caz, ale unei evaluări a impactului asupra protecției datelor. Distincția contează pentru că un furnizor de modele și o autoritate publică nu cunosc aceleași lucruri și nu poartă aceeași responsabilitate. Un registru care le combină într-o singură fișă de furnizor șterge locul în care un sistem întâlnește o instituție.

Baza de date juridică are, prin urmare, un caracter stratificat. Înregistrează o identitate de sistem. Înregistrează un furnizor. Poate înregistra un implementator și o utilizare. Înregistrează statutul și declarațiile justificative. Nu înlocuiește documentația tehnică, gestionarea riscurilor, sistemul de calitate sau monitorizarea post-comercializare pe care Actul le impune în altă parte. Baza de date este un index public al faptelor responsabile. Nu este întregul dosar de conformitate.

Această distincție se pierde ușor pentru că oamenilor le place o singură adresă URL care pare să conțină răspunsul. Legea este mai puțin sentimentală. Creează o suprafață publică, suprafețe restricționate și rute documentare controlate. Suprafața publică trebuie să fie utilizabilă. Suprafața restricționată trebuie să rămână restricționată. Documentația trebuie să rămână disponibilă autorității competente sau furnizorului din aval care are nevoie de ea. Un registru serios este o interfață între aceste obligații, nu o scurtătură care le ocolește.

Un registru devine util când identitatea, statutul și schimbarea sunt conectate. O culoare fără tranziție este doar decor.

Există o altă limită importantă. Prevederile Actului AI privind modelele de uz general nu sunt același lucru cu un catalog public al tuturor modelelor de uz general. Articolul 53 impune furnizorilor să păstreze documentație tehnică, să pună informațiile la dispoziția furnizorilor din aval de sisteme AI, să mențină o politică privind drepturile de autor și să publice un rezumat suficient de detaliat al conținutului de instruire. Orientările Comisiei explică faptul că documentația tehnică este destinată Oficiului AI și autorităților naționale competente, la cerere, în timp ce documentația din aval îi ajută pe integratori să înțeleagă capacitățile și limitările. Doar o parte din acest material aparține unui panou public.

Actul impune, de asemenea, Comisiei să publice și să mențină o listă a modelelor de uz general cu risc sistemic. O listă a modelelor cu risc sistemic este un semnal public valoros, dar nu este același obiect ca un registru complet de modele. Are un scop mai restrâns și trebuie să respecte drepturile de proprietate intelectuală, informațiile comerciale confidențiale și secretele comerciale. A numi fiecare listă „registru" este inofensiv doar până când cineva presupune că o listă dovedește mai mult decât dovedește.

Un model nu este o singură linie

Oamenii vorbesc despre un model ca și cum ar fi un borcan pe un raft. Numele este tipărit pe etichetă, versiunea este ștanțată dedesubt, iar conținutul rămâne neschimbat până când cineva deschide capacul. Această imagine funcționează pentru un artefact static. Devine nesigură când un model este adaptat, reglat fin, împachetat în instrumente, servit prin mai multe rute sau modificat în timpul utilizării.

Un registru are nevoie de cel puțin două identități: identitatea modelului și identitatea lucrului care a rulat efectiv. Prima răspunde la întrebarea ce model înțelege furnizorul. A doua poate identifica o stare capturată, un pachet de implementare sigilat, un export local sau un pachet de redare. Legarea lor previne două greșeli opuse. Un serviciu poate înceta să pretindă că fiecare stare activă are un singur hash permanent, iar un operator poate înceta să pretindă că un rezumat al pachetului descrie singur întreaga familie de modele.

Version numbers are useful only when their change rule is visible. A version may mean a new set of learned parameters, a new constraint catalogue, a change in retrieval, a changed safety layer or a material change in the serving contract. If a provider uses one number for all of those, the number becomes a polite way of saying that something changed. A registry should link a successor to its predecessor and say which part of the contract moved.

Adaptive behaviour adds another wrinkle. If a system can change while in use, the record should say so. That is not an admission that the system is uncontrolled. It is an admission that the word version cannot do all the work. The registry can keep a stable model identity, attach time-bound captured states to it and record the conditions under which a state was made. The point is not to freeze a living system into a false photograph. It is to give every meaningful photograph a date and a frame.

Identity also has a social edge. A model name is not enough when several legal entities distribute similar artefacts, when a downstream provider changes the model, or when a product embeds a model behind its own name. The registry should make the chain visible: provider, distributor where different, deployer where relevant, and the system or route in which the model is used. A person affected by a decision should not have to perform forensic archaeology on a product logo to discover who can answer for it.

Status is a verb, not a colour

Status fields are often rendered as badges because badges fit neatly on cards. The badge is not the status. The status is a statement about an action and a time. Internal testing means one thing when access is controlled by the provider. Pre-release means something else when invited outsiders can use a route under defined conditions. On the market, in service, suspended, withdrawn and recalled each carry a different operational consequence.

A useful record states what the status permits and what it does not. If a system is internal-only, a reader should not infer public availability from a documentation page. If an external beta is planned, the date should be labelled as planned rather than presented as a release. If a system is withdrawn, the record should preserve the previous identity and say whether existing deployments may continue, must stop or are being migrated. A status without an effective date is a rumour wearing a uniform.

The status should also be owned. Who can move an entry from internal to external? Who can suspend a route? Who can declare a release date changed? Which evidence is required before the transition? Those questions belong in the operating process, but the public entry should make the resulting decision legible. A registry that shows the current badge while hiding the authority behind it is only a mood board for governance.

Illustrative example, not a real listing: a record might say that a model is in controlled evaluation, that no external route is open, that an invite-only trial is proposed for a later date, and that the proposal remains subject to a release gate. The example names no organisation, model or event. Its purpose is to show how a record keeps a plan separate from a fact. The same discipline applies to a withdrawal, a capability claim or a certification that has not yet been issued.

This separation protects readers from a familiar trick. A future intention is repeated often enough that it starts to sound like history. Registries should be the place where that trick stops working. The entry can show a plan, but the plan must keep its label. Europe has enough calendars already. A date is not a fact merely because it has been placed in a coloured rectangle.

The registry is not the evidence room

O intrare publică ar trebui să fie suficient de scurtă pentru a fi citită și suficient de solidă pentru a orienta o întrebare serioasă. Camera cu dovezi din spatele ei poate fi mult mai mare. Obligațiile de documentare din articolul 53 din Regulamentul privind IA ilustrează de ce. Furnizorii de modele de IA cu scop general trebuie să întocmească și să păstreze documentație tehnică care să acopere dezvoltarea, instruirea, testarea și evaluarea. Aceștia trebuie să pună informații și documentație la dispoziția furnizorilor din aval de sisteme de IA, astfel încât aceștia să poată înțelege capacitățile și limitările. Trebuie să publice un rezumat suficient de detaliat al conținutului de instruire și să mențină o politică privind legislația Uniunii în domeniul dreptului de autor.

Aceste obligații deservesc cititori diferiți. O autoritate competentă poate avea nevoie de dosarul tehnic complet. Un furnizor din aval are nevoie de informații de integrare și de limitări. Publicul are nevoie de o relatare clară despre ce este modelul și cum este delimitat rezumatul conținutului de instruire. O intrare în registru poate lega aceste suprafețe fără să pretindă că o pagină publică ar trebui să conțină fiecare detaliu sensibil din punct de vedere al securității, fiecare fișier de ponderi sau fiecare eșantion de test care conține date personale.

Legăturile nu sunt nici ele dovezi prin magie. Un registru care trimite la un raport de evaluare ar trebui să identifice ce versiune acoperă raportul, ce a măsurat evaluarea și ce condiții limitează rezultatul. O legătură către un rezumat al instruirii ar trebui să spună dacă rezumatul acoperă pre-instruirea, reglajul fin sau un set definit de categorii de conținut. O legătură către un certificat ar trebui să arate cine l-a emis, ce certifică și când expiră. Altfel, pagina este un raft cu plicuri nedeschise.

Aceeași regulă se aplică afirmațiilor privind siguranța. Un registru poate spune că există o evaluare a riscurilor, că un plan de monitorizare este legat sau că o rută pentru incidente grave este publicată. Nu ar trebui să sugereze că existența unui document dovedește că sistemul subiacent este sigur. Documentația este o modalitate de a inspecta o afirmație. Nu este substitutul afirmației.

Aici scrierea publică are nevoie de disciplină. O fișă de model, o pagină de transparență sau o intrare în registru pot descrie utilizarea prevăzută și limitările cunoscute. Nu poate folosi expresia demn de încredere ca o concluzie, decât dacă dovezile și domeniul de aplicare fac acea concluzie apărabilă. Propoziția onestă este adesea mai utilă: acestea sunt condițiile pe care le-am evaluat, acestea sunt limitele pe care le-am observat, iar acestea sunt cazurile pe care nu am pretins să le acoperim.

Registrul olandez arată valoarea unei liste publice obișnuite

Registrul olandez al algoritmilor este instructiv tocmai pentru că nu încearcă să arate ca o cameră de control futuristă. Oferă organizațiilor guvernamentale un loc public pentru a descrie algoritmii folosiți în activitatea lor. Pagina sa în engleză avertizează că descrierile au fost traduse automat și că originalul olandez este versiunea autoritară pentru descriere. Acea mică notă este o lecție despre proveniență. Accesul nu este același lucru cu acuratețea, iar o interfață tradusă nu ar trebui să șteargă limba sursă.

Scopul public al registrului este, de asemenea, declarat fără limbaj teatral. Se concentrează pe algoritmi cu impact, inclusiv sisteme de IA cu risc ridicat, și oferă vizitatorilor o perspectivă asupra modului în care funcționează aceștia. Vizitatorul poate răsfoi algoritmi, organizații și șabloane. Scopul nu este de a oferi un scor pentru fiecare algoritm. Este de a face utilizarea sistemelor algoritmice suficient de vizibilă pentru ca oamenii, organizațiile și mass-media să poată urmări, chestiona și examina practica guvernamentală.

Algoritmekader-ul olandez însoțitor transformă acest scop într-o cerință. Acesta spune că, dacă nu se aplică o excepție, organismele publice publică algoritmi cu impact și sisteme de IA cu risc ridicat în registru. De asemenea, spune că publicarea incorectă sau incompletă poate îngreuna înțelegerea și contestarea de către persoanele afectate și alte părți interesate a utilizării tehnologiei care le poate atinge drepturile. Transparența nu este, așadar, doar o curtoazie. Calitatea intrării poate afecta calitatea controlului public.

Aceleași îndrumări sunt atente la sfera de aplicare. Ele descriu registrul ca pe un instrument dintr-un set mai larg de legi și cerințe și avertizează că acest cadru nu este complet și poate să nu includă legislația specifică unui sector. Faptul că un algoritm apare într-un registru nu rezolvă orice întrebare juridică sau etică. Faptul că nu apare nu dovedește că este inofensiv. Pentru a interpreta o intrare, cititorul are nevoie de regula de includere a registrului și de cadrul general în care acesta se integrează.

Acesta este modelul util pentru registrele de modele. O listă publică ar trebui să fie ușor de găsit, scrisă pentru persoane care nu au participat la ședința de achiziții și conectată la documentele care conțin mai multe detalii. Ar trebui să expună incertitudinea, nu să o ascundă. Ar trebui să precizeze când o descriere în engleză este tradusă automat. Ar trebui să explice ce sisteme sunt incluse și care nu. Ar trebui să transforme o intrare lipsă sau neactualizată într-o problemă vizibilă de guvernanță, nu într-o dezamăgire personală.

Nu este nevoie să inventăm un incident dramatic pentru a vedea de ce acest lucru contează. Un cetățean care încearcă să înțeleagă un proces guvernamental automatizat are deja o întrebare practică: este folosit un sistem, de cine, în ce scop și pe baza cărei explicații? Un registru oferă acestei întrebări o adresă. Răspunsul poate fi în continuare incomplet. Cel puțin instituția nu mai poate pretinde că nu există unde să întrebi.

Public nu înseamnă dezgolit

Transparența devine contraproductivă atunci când este tratată ca o poruncă de a publica totul. Documentele publice pot expune date personale, informații sensibile din punct de vedere al securității, detalii proprietare și căi de atac. Ele pot crea, de asemenea, o încredere falsă prin publicarea unor fragmente tehnice pe care niciun cititor obișnuit nu le poate interpreta. Granița dintre public și privat trebuie proiectată, documentată și revizuită, nu improvizată de echipa care se întâmplă să dețină sistemul de gestionare a conținutului.

Regulamentul privind IA oferă un exemplu juridic. Articolul 49 alineatul (4) plasează anumite sisteme într-o secțiune securizată, nepublică, și limitează accesul la Comisie și la autoritățile naționale relevante. Articolul 71 face publice informațiile înregistrate în temeiul articolului 49, cu excepția secțiunilor restricționate, în timp ce informațiile înregistrate în temeiul articolului 60 sunt accesibile doar autorităților de supraveghere a pieței și Comisiei, dacă furnizorul nu își dă acordul pentru accesul public. Publicitatea este, așadar, o regulă cu excepții, nu un implicit universal.

Articolul 53 face o distincție similară pentru modelele cu scop general. Furnizorii trebuie să pună documentația tehnică la dispoziția Oficiului pentru IA și a autorităților naționale competente, la cerere, și trebuie să furnizeze documentația din aval furnizorilor care integrează modelul. Obligațiile sunt în mod explicit supuse necesității de a respecta și proteja drepturile de proprietate intelectuală, informațiile comerciale confidențiale și secretele comerciale. Un registru nu ar trebui să oblige un furnizor să publice materialul pe care legea spune că ar trebui controlat. Nici confidențialitatea nu ar trebui să devină o scuză politicoasă pentru a ascunde existența, scopul sau statutul unui sistem care afectează publicul.

Un registru practic de modele poate folosi straturi. Stratul public identifică modelul, furnizorul, statutul, scopul preconizat, capacitățile generale, limitele cunoscute, căile de acces, condițiile de lansare, linkurile către dovezi și istoricul modificărilor. Un strat controlat conține documentația tehnică detaliată, modelele de amenințări, materialul de evaluare restricționat, detaliile incidentelor și alte informații de care au nevoie evaluatorii autorizați. Un strat operațional privat conține secrete, date personale și informații de control intern care nu ar trebui expuse deloc. Straturile sunt documente diferite, cu linkuri între ele, nu o singură pagină cu un acordeon etichetat transparență.

Transparența bună are o graniță. Publică ceea ce oamenii au nevoie să înțeleagă despre sistem și protejează ceea ce trebuie să controleze recenzenții autorizați.

Stratul public ar trebui să rămână specific. Poate spune că un model este adaptiv în timpul utilizării, fără să expună o reprezentare privată a stării. Poate afirma că o rută este doar pe invitație, fără să publice tokenuri de invitație. Poate descrie modalitățile de ieșire și o politică de marcare a conținutului, fără să expună chei de semnare. Poate spune că există o evaluare de risc și să identifice domeniul acesteia, fără să publice o diagramă de securitate care ar face serviciul mai ușor de atacat.

Stratul controlat are nevoie de propria onestitate. Un document marcat ca fiind confidențial nu este automat complet, actual sau corect. Are nevoie de un deținător, o versiune, o regulă de acces și o regulă de păstrare. Dacă un registru public trimite la o înregistrare controlată, linkul ar trebui să dezvăluie statutul și ruta responsabilă chiar și atunci când conținutul este restricționat. Altfel, publicul vede o gaură neagră și este invitat să o numească guvernanță.

Versionarea este locul unde un registru devine util

Cele mai multe eșecuri de registru nu sunt dramatice. Sunt mici acte de uitare. Un model nou îl înlocuiește pe cel vechi, dar intrarea este editată pe loc. O politică se schimbă, dar paragraful despre utilizarea prevăzută rămâne. Un furnizor mută o rută de la testare internă la o versiune beta externă, dar insigna de statut se schimbă înainte ca data efectivă să fie înregistrată. O implementare este retrasă, dar intrarea veche dispare, luând istoricul cu ea. Prezentul arată ordonat. Trecutul devine fără răspuns.

O înregistrare versionată ține cel puțin patru date separate. Versiunea de conținut spune care text și câmpuri ale înregistrării sunt actuale. Data efectivă spune când se aplică declarația. Versiunea de model sau pachet spune ce obiect tehnic este descris. Data verificării spune când a verificat cineva înregistrarea. Aceste date pot coincide. Nu trebuie să o facă. Tratarea lor ca o singură dată este convenabilă și adesea greșită.

Versiunile anterioare ar trebui să rămână descoperibile în conformitate cu o regulă de păstrare adecvată. Publicul nu are nevoie de fiecare editare internă, dar trebuie să știe când s-a schimbat un scop material, un statut, o rută, o limitare sau o declarație de proprietate. Un jurnal de modificări poate spune ce s-a mișcat fără să expună informații private. O înregistrare lizibilă de mașină poate lega versiunea anterioară și un manifest. O pagină lizibilă de om poate explica consecința în limbaj obișnuit. Cele două suprafețe ar trebui să fie de acord.

Versionarea face și retragerea semnificativă. Dacă un model este retras pentru că o rută este închisă, aceasta este diferit de o rechemare din cauza unui defect grav sau a unei probleme legale care necesită acțiune. Dacă un model rămâne în implementări private existente, înregistrarea publică ar trebui să spună acest lucru. Dacă un succesor este compatibil doar pentru unele integrări, granița de migrare ar trebui să fie vizibilă. Un registru care elimină un nume fără să înregistreze de ce lasă fiecare cititor din aval să inventeze un motiv.

Istoricul modificărilor este deosebit de important pentru sistemele adaptive. Identitatea modelului poate rămâne stabilă în timp ce stările capturate, seturile de constrângeri, sursele de regăsire sau controalele de ieșire se schimbă. Registrul poate afirma ce schimbări creează un pachet nou, ce schimbări necesită o evaluare nouă și ce schimbări rămân în interiorul graniței de identitate declarate. Acesta nu este un detaliu excesiv. Este diferența dintre un sistem care poate fi redat și un sistem care poate fi doar amintit.

Deținătorii fac parte din înregistrare

O intrare de registru de modele fără un deținător este o prognoză meteo. Îți spune cum a fost cerul, dar nu îți lasă pe nimeni de contactat când acoperișul începe să curgă. Rolurile de furnizor și de implementator nu sunt identice, iar niciunul dintre ele nu ar trebui lăsat să se dizolve în cuvântul platformă.

Furnizorul deține identitatea modelului, istoricul dezvoltării și decizia de lansare în sfera sa de competență. Implementatorul deține decizia de a utiliza un sistem sub autoritatea sa, inclusiv scopul local, măsurile de siguranță, evaluarea impactului și controalele operaționale. Un furnizor din aval poate integra un model cu scop general într-un sistem de inteligență artificială și poate prelua responsabilități pe care furnizorul modelului nu le poate vedea. Un registru public ar trebui să expună aceste relații acolo unde legea și riscul o impun.

Informațiile de contact nu sunt un simplu adaos administrativ. Ele oferă unei persoane afectate o cale de a întreba cine a luat o decizie, ce versiune a fost folosită sau cum poate fi solicitată o corecție. O căsuță poștală generică poate fi potrivită, dar ar trebui să ducă la un proces întreținut. Intrarea ar trebui să precizeze și dacă persoana de contact este pentru asistență tehnică, cereri privind drepturile, raportarea incidentelor, achiziții sau responsabilitate publică. O singură căsuță de primire nu poate fi toate instituțiile deodată, oricât de mult s-ar strădui formularele moderne.

Deținerea ar trebui să includă autoritatea de a modifica înregistrarea. Dacă deținătorul numit nu poate suspenda o rută, corecta o stare sau publica o retragere, intrarea este doar decorativă. Organizația poate avea în continuare un deținător legal în altă parte, dar decalajul operațional rămâne. Un registru bun face responsabilitatea vizibilă înainte ca un incident să oblige oamenii să deseneze organizația pe o tablă albă.

Proiectarea unui registru pe care oamenii îl pot citi cu adevărat

Primul cititor al unui registru de modele nu este întotdeauna un regulator sau un inginer. Poate fi un jurnalist, un responsabil cu achizițiile, un oficial local, un cercetător, un angajat căruia i se cere să folosească sistemul sau o persoană care încearcă să înțeleagă de ce un serviciu automatizat i-a atins cazul. Pagina ar trebui să răspundă la întrebarea obișnuită înainte de a apela la vocabular de specialitate.

Începeți cu identitatea și motivul intrării. Spuneți cine furnizează modelul, ce versiune este descrisă, ce tip de obiect este și dacă este un model, un sistem integrat de inteligență artificială sau o înregistrare de implementare. Spuneți dacă este intern, disponibil utilizatorilor invitați, pe piață, suspendat sau retras. Cititorul nu ar trebui să fie nevoit să deducă starea dintr-un buton de descărcare.

Apoi arătați scopul și limita. Precizați ce este menit să facă modelul, ce utilizări sunt în afara declarației și ce decizii nu este autorizat să ia. Explicați dacă modelul se poate adapta în timpul utilizării, dacă o stare capturată este necesară pentru reluare și dacă o rută din aval schimbă condițiile. O listă de capacități fără un scop este un meniu fără bucătărie.

Folosiți dezvăluirea progresivă. Partea de sus a paginii ar trebui să fie calmă și lizibilă. Secțiunile mai profunde pot expune înregistrarea tehnică, metodele de evaluare, rezumatul conținutului de instruire, documentele legale și dovezile de lansare. Un cititor public se poate opri după primul strat. Un auditor poate continua. Un inginer poate descărca o reprezentare stabilă. Ascunderea detaliilor nu este simplitate. Este doar o surpriză care se încarcă lent.

Accesibilitatea face parte din credibilitatea înregistrării. Pagina și reprezentarea tehnică ar trebui să folosească etichete clare, navigare de la tastatură, titluri utile și alternative text pentru vizualizări. Datele nu ar trebui codificate doar prin culoare. O insignă roșie nu este o stare pentru un cititor care nu poate vedea roșu, iar un grafic care nu poate fi citit fără mouse nu este o explicație accesibilă. Un avizier din piața orașului nu devine public dacă rampa se termină la prima treaptă.

Lizibilitatea automată contează dintr-un alt motiv. Le permite cercetătorilor să compare intrările, permite organismelor publice să construiască inventare, le permite auditorilor să detecteze înregistrările vechi și permite unui instrument din aval să verifice că pagina și înregistrarea structurată se referă la aceeași versiune. Lizibil automat nu înseamnă doar pentru mașini. Pagina pentru oameni și înregistrarea pentru mașini ar trebui să împărtășească identificatori, statusuri, date și linkuri, cu o relație de integritate care poate fi verificată.

Câmpurile registrului sunt decizii

Fiecare câmp îi spune cititorului ce crede organizația că merită păstrat. Un câmp de furnizor spune cine stă în spatele modelului. Un nume și o versiune de model spun cum să îl deosebești de un succesor. Un câmp de rută spune unde poate fi accesat. Un câmp de scop intenționat spune ce activitate este pregătit furnizorul să descrie. Un câmp de limitare spune unde se oprește descrierea. Schema este un document de guvernanță scris în dreptunghiuri mici.

Câmpurile de identitate ar trebui să fie lipsite de ambiguitate și stabile. Ele pot include numele legal al furnizorului, numele modelului, versiunea, o referință unică și linkuri către o înregistrare canonică. Dacă modelul poate fi servit prin mai multe produse, registrul ar trebui să distingă identitatea modelului de suprafața de integrare. Dacă un produs conține mai multe modele, intrarea nu ar trebui să ascundă acest fapt în spatele numelui produsului.

Câmpurile de status ar trebui să includă valoarea, data efectivă, motivul sau autoritatea pentru tranziție și orice succesor sau predecesor. O dată care este doar planificată ar trebui etichetată ca planificată. O înregistrare care nu a fost verificată recent ar trebui să spună acest lucru. Cititorul ar trebui să poată spune dacă un model este disponibil, propus, în pauză sau istoric fără să interpreteze un adjectiv inventat de o echipă de marketing.

Câmpurile de scop și de scop intenționat ar trebui să descrie activitatea în termeni pe care un nespecialist îi poate înțelege. Ele ar trebui să numească utilizatorii intenționați acolo unde contează, tipurile de intrări și ieșiri implicate și deciziile sau acțiunile pe care modelul le poate susține. Ele ar trebui să declare și utilizările interzise sau nesuportate. Un model care poate genera text nu este prin aceasta autorizat să scrie o decizie de eligibilitate, iar un model care poate clasifica documente nu este prin aceasta autorizat să clasifice oameni.

Câmpurile de capabilitate au nevoie de condiții. Modalitățile, limitele de context, accesul la instrumente, acoperirea lingvistică, comportamentul de adaptare și marcarea ieșirilor sunt semnificative doar când sunt legate de o rută și de o versiune. O capabilitate care există într-un experiment intern, dar nu și în ruta externă, nu ar trebui prezentată ca o caracteristică universală. Registrul nu este o listă de dorințe.

Câmpurile de date ar trebui să spună ce primește modelul, ce stochează, din ce învață în timpul utilizării și ce este folosit pentru evaluare, la nivelul care poate fi făcut public fără a expune material personal sau confidențial. Rezumatele conținutului de instruire și politicile de drepturi ar trebui legate acolo unde este necesar. O propoziție vagă precum instruit pe date diverse nu îi spune cititorului aproape nimic și îi cere să furnizeze o interpretare flatantă.

Câmpurile de evaluare ar trebui să identifice întrebarea, metoda, granița datelor, data, rezultatul și limitările. Intrarea nu trebuie să reproducă fiecare tabel, dar nu ar trebui să afișeze un scor fără un numitor sau un test fără un scop. Un link bun de evaluare îi permite cititorului să vadă dacă dovezile acoperă utilizarea intenționată, o utilizare învecinată sau doar o condiție de laborator.

Câmpurile de supraveghere ar trebui să identifice cine poate pune în pauză, poate anula, poate revizui și poate investiga sistemul. Dacă un model doar recomandă, spune ce acțiune rămâne la om. Dacă o rută poate acționa asupra sistemelor externe, spune ce permisiuni și porți se aplică. Dacă raportarea incidentelor are o rută dedicată, public-o. Supravegherea nu este un paragraf despre menținerea oamenilor în circuit. Este o hartă a cine poate face ce atunci când sistemul este incert.

Fieldurile de dovezi și integritate ar trebui să conecteze intrarea publică la o înregistrare mașină versionată, un pachet de lansare, o declarație, un pachet de evaluare sau un jurnal de transparență. Un hash poate stabili dacă un fișier s-a schimbat sau nu. Nu poate stabili dacă fișierul a fost veridic, așa că registrul ar trebui să țină separate afirmația și verificarea integrității. Precizia tehnică nu înlocuiește judecata, dar face judecata mai ușor de localizat.

În final, câmpurile de modificare ar trebui să explice istoricul. Ce s-a schimbat, când, de ce, cine a aprobat, ce rute sunt afectate și dacă este necesară o nouă evaluare. Intrarea ar trebui să facă posibil să se răspundă la cea mai obișnuită întrebare din sală: ce este diferit față de înregistrarea pe care am citit-o luna trecută?

Ce poate stabili un registru

Un registru bine întreținut poate stabili că un obiect definit este descris de un furnizor numit sub o anumită versiune de înregistrare. Poate stabili scopul declarat, starea, ruta de acces și proprietarul. Poate stabili ce documente justificative și înregistrări de integritate poate inspecta un cititor și ce informații sunt controlate în mod deliberat. Poate stabili că o modificare a fost publicată și că o înregistrare anterioară rămâne disponibilă conform regulii de păstrare declarate.

Poate stabili, de asemenea, poziția proprie a organizației. Dacă un furnizor spune că un model este pentru sprijinirea deciziilor și nu pentru refuz automat, afirmația este o graniță publică. Dacă un implementator spune că o evaluare a impactului a fost finalizată, afirmația creează o întrebare despre unde poate fi găsit rezumatul sau înregistrarea controlată. Dacă un furnizor marchează o lansare ca fiind planificată, eticheta împiedică planul să se prefacă a fi istoric.

Acestea sunt fapte utile. Ele fac achizițiile mai precise, integrarea mai puțin speculativă și întrebările publice mai ușor de direcționat. Ele fac, de asemenea, dezacordul mai clar. Un cititor poate spune că scopul declarat este prea larg, starea este învechită, limitarea lipsește sau dovezile justificative nu acoperă afirmația. Un registru își merită existența atunci când face posibilă această critică.

Ce nu poate stabili un registru

O intrare de registru nu poate stabili că un model este precis pentru fiecare utilizator, sigur în fiecare mediu, echitabil pentru fiecare grup sau legal pentru fiecare implementare. Nu poate stabili că o autoritate publică a urmat procedura corectă doar pentru că un sistem este listat. Nu poate arăta că un recenzent uman a înțeles o ieșire, că o persoană vizată a avut o cale de atac semnificativă sau că un incident ar fi detectat la timp. Aceste concluzii necesită dovezi despre sistemul în uz, instituția care îl folosește și persoanele afectate de acesta.

De asemenea, nu poate stabili că un model este independent de furnizorul său, că o rută este suverană pentru că este găzduită în Europa sau că o licență deschisă face responsabilitatea să dispară. Proprietatea, jurisdicția, lanțul de aprovizionare, controlul operațional și întreținerea sunt întrebări separate. Un registru poate expune numele și legăturile necesare pentru a le pune. Nu le poate răspunde prin tipografie.

Nici un registru nu poate dovedi contrariul. O intrare absentă poate însemna că obiectul este în afara domeniului de aplicare, că se aplică o excludere, că publicarea este întârziată sau că cineva nu a publicat. Cititorul are nevoie de o declarație clară de acoperire și de o rută pentru raportarea erorilor. Un panou public este la fel de fiabil ca procesul care observă când lipsește un anunț.

O înregistrare ilustrativă, nu un studiu de caz ascuns

Următoarea este o proiectare de înregistrare ilustrativă, nu un raport despre o organizație, un model sau un eveniment real. Nu folosește niciun client, autoritate publică, dată de implementare sau rezultat măsurat. Scopul său este să arate cum un cititor poate trece de la o intrare publică la o rută de dovezi controlată, fără a confunda cele două niveluri.

  • Identitate: un nume de furnizor, un nume de model, o versiune și un identificator de mașină stabil.
  • Stare: evaluare controlată, cu o dată de intrare în vigoare și o notă că nu există nicio rută externă deschisă.
  • Scop: asistență în analiza documentelor pentru personal instruit, cu decizii externe automate în afara domeniului declarat.
  • Intrări și ieșiri: modalitățile reprezentate, tipurile de material sursă așteptate și tipurile de ieșire pe care ruta le poate produce.
  • Limite: limite cunoscute de limbă, domeniu, actualitate, siguranță și acces, fiecare legată de evaluarea sau politica relevantă.
  • Supraveghere: rolul care poate întrerupe ruta, calea de revizuire pentru rezultate incerte și contactul pentru incidente.
  • Dovezi: un rezumat public, o evidență tehnică versionată pentru recenzori autorizați și un manifest de integritate pentru fișierele publicate.
  • Modificare: un link către evidența anterioară, o declarație a ceea ce s-a schimbat și condiția care ar impune o nouă evaluare.

Nimic din acea evidență nu spune că modelul este bun. Spune ce este pregătit să susțină furnizorul, unde se aplică susținerea și cum poate o altă persoană să o testeze sau să o conteste. Este suficient pentru un panou de anunțuri. Este, de asemenea, suficient pentru a împiedica o mare parte din limbajul de broșură să pătrundă neobservat într-o decizie legală sau operațională.

De ce statutul de pre-lansare merită respect

Pre-lansarea nu este o versiune mai slabă a publicului. Este o stare diferită. Testarea internă poate sprijini activitatea de inginerie și siguranță, menținând în același timp accesul controlat. O versiune beta invitată poate expune o rută persoanelor din afara organizației, păstrând condițiile, domeniul și dreptul de a opri. O lansare publică schimbă cine se poate baza pe sistem și ce obligații revin furnizorului, integratorilor și implementatorilor. Registrul ar trebui să facă aceste tranziții vizibile, în loc să trateze lansarea ca pe o singură notă de trompetă.

O evidență de pre-lansare poate fi totuși utilă publicului. Poate identifica modelul, furnizorul, ruta intenționată, starea, dovezile care există și dovezile care sunt încă în așteptare. Poate spune că o dată este planificată și că accesul nu a fost deschis. Poate publica poarta de lansare fără a pretinde că poarta a fost depășită. Acesta este un loc deosebit de bun pentru un registru să fie plictisitor. O stare plictisitoare este mai sigură decât o ambiguitate interesantă.

La Dweve, încercăm să aplicăm această disciplină propriei noastre evidențe publice. În Trust Centre, registrul de modele este marcat ca pre-lansare și listează Dweve Loom 1.0 ca testare internă exclusivă de pre-lansare începând cu 1 august 2026. Se consemnează că nu a avut loc nicio lansare externă până la acea dată și listează 1 septembrie 2026 ca dată planificată pentru accesul pe piața Uniunii pentru o versiune beta externă doar cu invitație. Planificat este cuvântul important: intrarea nu transformă un plan într-un eveniment.

Evidența noastră publică precizează, de asemenea, că Loom este singurul model listat acolo, că este proprietar, nu lansat sub o licență de model open-source, și că produsele noastre și instrumentele open-source licențiate separat nu sunt prezentate ca modele suplimentare. Această delimitare împiedică un catalog de produse să fie confundat cu un registru de modele. Menține, de asemenea, afirmația publică suficient de restrânsă pentru a fi verificată.

Acesta este tot ce trebuie să spunem despre Dweve aici. Un registru de modele este util atunci când face statutul nostru de lansare mai puțin măgulitor, dar mai precis. Ar trebui să facă același lucru pentru oricine altcineva.

Granița public-privat este o decizie de design

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