Modellregistret är den nya offentliga anslagstavlan

Ett modellregister kan berätta för allmänheten vad ett system är, vem som står bakom det, var det får användas och vad som har ändrats. Det kan inte...

Modellregistret är den nya offentliga anslagstavlan

The page that starts by admitting it is not magic

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

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

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

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

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

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

A noticeboard is a promise of selection

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

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

Ett modellregister bör besvara samma gränsfråga på vanligt språk. Listar det grundmodeller, utplacerade AI-system, interna experiment, finjusterade avkomlingar, utvärderingspaket eller endast modeller som erbjuds externa användare? Får en ny serveringskonfiguration en ny post, en ny version eller en länkad driftsättningspost? Räknas ett fångat tillstånd av ett adaptivt system som samma modellidentitet? Om registret inte avgör dessa frågor kommer varje läsare att avgöra dem på olika sätt. Så blir en kort lista en lång argumentation.

Urval gör också frånvaro meningsfull. Om omfattningen säger att alla allmänt tillgängliga högrisksystem måste finnas med, är en saknad post ett styrningsproblem. Om omfattningen säger att endast modeller som släppts på en marknad ingår, kan ett internt experiment vara frånvarande avsiktligt. Allmänheten kan inte tolka ett tomt sökresultat utan att veta vilken av dessa två situationer som gäller. Tystnad är inte neutral när registret inte har förklarat sin vokabulär.

Det finns en liten administrativ dygd i att säga detta rakt ut. Register behöver inte låtsas att de vet allt. De behöver berätta för läsaren vad de vet, vad de ansvarar för och vad som ligger utanför ramen. Ett register förtjänar sin auktoritet genom att göra omfattningens gräns explicit, inte genom att dekorera omslaget. Tekniken är nyare. Pappersinstinkten är det inte.

Vad den europeiska regeln faktiskt lägger på bordet

AI-förordningen ger ordet registrering en konkret juridisk form, men inte en enda universell sådan. Artikel 49 kräver att en leverantör eller auktoriserad representant registrerar vissa högrisksystem för AI innan de släpps på marknaden eller tas i bruk. Den kräver också registrering när en leverantör har dragit slutsatsen att ett system inte är högrisk enligt villkoren i artikel 6.3. Offentliga myndigheter och likvärdiga offentliga organ som använder vissa högrisksystem har en egen registreringsskyldighet, inklusive registrering av sin användning.

Samma artikel gör gränsen mellan offentligt och privat explicit. Vissa högrisksystem som används inom brottsbekämpning, migration, asyl och gränsförvaltning registreras i en säker icke-offentlig sektion. Högrisksystem i den andra punkten i bilaga III registreras på nationell nivå. Detta är inte implementeringsdetaljer som kan jämnas ut i en instrumentpanel. De beskriver olika målgrupper, olika risker och olika behörigheter att se posten.

Artikel 71 säger att kommissionen, i samarbete med medlemsstaterna, ska inrätta och underhålla EU-databasen. Informationen som registreras enligt artikel 49 ska vara tillgänglig och offentligt tillgänglig på ett användarvänligt sätt, och bör vara lättnavigerad och maskinläsbar, med undantag för begränsade sektioner. Databasen bör endast innehålla personuppgifter i den utsträckning som är nödvändig. Detta är en användbar definition av offentlig transparens: en post som människor kan hitta och bearbeta, utan att göra posten till ett andra personuppgiftsproblem.

Bilaga VIII är där anslagstavlan blir specifik. För en leverantör som registrerar ett högrisksystem innehåller posten leverantörens identitet och kontaktuppgifter, ett entydigt handelsnamn eller referens, det avsedda syftet, en grundläggande beskrivning av den information som används och driftlogiken, systemets status, relevanta certifikat, medlemsstater där det släpps på marknaden eller tas i bruk, försäkran om överensstämmelse, bruksanvisning och en valfri URL för ytterligare information. Dessa är inte marknadsföringsfält. De är verktyg för identifiering och ansvarsskyldighet.

För en offentlig distributör är informationen annorlunda. Registret innehåller distributörens identitet, den person som lämnar in informationen, webbadressen till leverantörens post samt sammanfattningar av en bedömning av konsekvenser för grundläggande rättigheter och, i förekommande fall, en bedömning av konsekvenser för uppgiftsskydd. Skillnaden är viktig eftersom en modellleverantör och en offentlig myndighet inte känner till samma saker och inte bär samma ansvar. Ett register som slår samman dem till ett enda leverantörskort raderar den plats där ett system möter en institution.

Den rättsliga databasen har därför en skiktad karaktär. Den registrerar en systemidentitet. Den registrerar en leverantör. Den kan registrera en distributör och en användning. Den registrerar status och stödjande försäkringar. Den ersätter inte den tekniska dokumentation, riskhantering, kvalitetssystem eller övervakning efter utsläppande på marknaden som förordningen kräver på andra ställen. Databasen är ett offentligt index över ansvarsbärande fakta. Den är inte hela regelefterlevnadsfilen.

Denna skillnad är lätt att förlora eftersom människor gillar en enda webbadress som verkar innehålla svaret. Lagen är mindre sentimental. Den skapar en offentlig yta, begränsade ytor och kontrollerade dokumentationsvägar. Den offentliga ytan måste vara användbar. Den begränsade ytan måste förbli begränsad. Dokumentationen måste förbli tillgänglig för den behöriga myndighet eller nedströmsleverantör som behöver den. Ett seriöst register är ett gränssnitt mellan dessa skyldigheter, inte en genväg förbi dem.

Ett register blir användbart när identitet, status och ändring är kopplade. En färg utan övergång är bara dekoration.

Det finns ytterligare en viktig begränsning. AI-förordningens bestämmelser om allmänna AI-modeller är inte samma sak som en offentlig katalog över alla allmänna modeller. Artikel 53 kräver att leverantörer håller teknisk dokumentation, gör information tillgänglig för nedströmsleverantörer av AI-system, upprätthåller en upphovsrättspolicy och publicerar en tillräckligt detaljerad sammanfattning av träningsinnehåll. Kommissionens vägledning förklarar att den tekniska dokumentationen är avsedd för AI-kontoret och nationella behöriga myndigheter på begäran, medan nedströmsdokumentation hjälper integratörer att förstå kapacitet och begränsningar. Endast en del av detta material hör hemma på en offentlig anslagstavla.

Förordningen kräver också att kommissionen publicerar och upprätthåller en förteckning över allmänna AI-modeller med systemrisk. En förteckning över modeller med systemrisk är en värdefull offentlig signal, men den är inte samma objekt som ett fullständigt modellregister. Den har ett snävare syfte och måste respektera immateriella rättigheter, konfidentiell affärsinformation och affärshemligheter. Att kalla varje förteckning för ett register är ofarligt bara tills någon antar att en förteckning bevisar mer än den gör.

En modell är inte en enda rad

Människor talar om en modell som om den vore en burk på en hylla. Namnet är tryckt på etiketten, versionen är stämplad undertill och innehållet förblir oförändrat tills någon öppnar locket. Den bilden fungerar för en statisk artefakt. Den blir opålitlig när en modell anpassas, finjusteras, paketeras i verktyg, levereras via flera vägar eller ändras under användning.

Ett register behöver minst två identiteter: modellidentiteten och identiteten för det som faktiskt kördes. Den första svarar på vilken modell leverantören avser. Den andra kan identifiera ett fångat tillstånd, ett förseglat distributionspaket, en lokal export eller ett uppspelningspaket. Att koppla samman dem förhindrar två motsatta misstag. En tjänst kan sluta låtsas att varje live-tillstånd har en permanent hash, och en operatör kan sluta låtsas att en paketsammanfattning ensam beskriver hela modellfamiljen.

Versionsnummer är bara användbara när regeln för när de ändras är synlig. En version kan betyda en ny uppsättning inlärda parametrar, en ny begränsningskatalog, en ändring i hämtningen, ett ändrat säkerhetslager eller en väsentlig ändring i leveransavtalet. Om en leverantör använder ett enda nummer för alla dessa blir numret ett artigt sätt att säga att något har ändrats. Ett register bör länka en efterträdare till sin föregångare och ange vilken del av avtalet som har flyttats.

Adaptivt beteende tillför en ytterligare komplikation. Om ett system kan ändras medan det används bör registret ange det. Det är inte ett erkännande av att systemet är okontrollerat. Det är ett erkännande av att ordet version inte kan göra allt arbete. Registret kan behålla en stabil modellidentitet, knyta tidsbundna inspelade tillstånd till den och dokumentera under vilka förhållanden ett tillstånd skapades. Poängen är inte att frysa ett levande system i ett falskt fotografi. Det är att ge varje meningsfullt fotografi ett datum och en ram.

Identitet har också en social aspekt. Ett modellnamn räcker inte när flera juridiska enheter distribuerar liknande artefakter, när en underleverantör ändrar modellen eller när en produkt bäddar in en modell under eget namn. Registret bör göra kedjan synlig: leverantör, distributör där den skiljer sig, driftsättare där det är relevant, samt det system eller den väg där modellen används. En person som påverkas av ett beslut ska inte behöva utföra forensisk arkeologi på en produktlogotyp för att ta reda på vem som kan svara för den.

Status är ett verb, inte en färg

Statusfält visas ofta som märken eftersom märken passar snyggt på kort. Märket är inte statusen. Statusen är ett uttalande om en åtgärd och en tidpunkt. Intern testning betyder en sak när åtkomsten kontrolleras av leverantören. Förhandsversion betyder något annat när inbjudna utomstående kan använda en väg under definierade villkor. På marknaden, i drift, pausad, återkallad och indragen har var och en olika operativa konsekvenser.

Ett användbart register anger vad statusen tillåter och vad den inte tillåter. Om ett system endast är internt bör en läsare inte dra slutsatsen att det är allmänt tillgängligt från en dokumentationssida. Om en extern betaversion är planerad bör datumet märkas som planerat snarare än presenteras som en lansering. Om ett system är indraget bör registret bevara den tidigare identiteten och ange om befintliga driftsättningar får fortsätta, måste upphöra eller håller på att migreras. En status utan giltighetsdatum är ett rykte i uniform.

Statusen bör också ha en ägare. Vem kan flytta en post från intern till extern? Vem kan pausa en väg? Vem kan förklara att ett lanseringsdatum har ändrats? Vilka bevis krävs före övergången? Dessa frågor hör hemma i driftsprocessen, men den offentliga posten bör göra det resulterande beslutet läsbart. Ett register som visar det aktuella märket samtidigt som auktoriteten bakom det döljs är bara en moodboard för styrning.

Illustrativt exempel, inte en verklig notering: en post kan ange att en modell är under kontrollerad utvärdering, att ingen extern väg är öppen, att en inbjudningsbaserad testomgång föreslås vid ett senare datum och att förslaget fortfarande omfattas av en lanseringsgrind. Exemplet namnger ingen organisation, modell eller händelse. Dess syfte är att visa hur en post håller en plan åtskild från ett faktum. Samma disciplin gäller för en indragning, ett kapacitetspåstående eller en certifiering som ännu inte har utfärdats.

Denna åtskillnad skyddar läsare från ett välbekant knep. En framtida avsikt upprepas tillräckligt ofta för att börja låta som historia. Register bör vara platsen där det knepet slutar fungera. Posten kan visa en plan, men planen måste behålla sin etikett. Europa har redan tillräckligt med kalendrar. Ett datum är inte ett faktum bara för att det har placerats i en färgad rektangel.

Registret är inte bevisrummet

En offentlig post bör vara kort nog att läsas och stark nog att vägleda en seriös fråga. Bevisrummet bakom den kan vara betydligt större. Artikel 53 i AI-förordningen om dokumentationsskyldighet illustrerar varför. Leverantörer av allmänna AI-modeller måste upprätta och bevara teknisk dokumentation som täcker utveckling, träning, testning och utvärdering. De måste göra information och dokumentation tillgänglig för nedströmsleverantörer av AI-system så att dessa leverantörer kan förstå kapacitet och begränsningar. De måste publicera en tillräckligt detaljerad sammanfattning av träningsinnehåll och upprätthålla en policy för unionens upphovsrättslagstiftning.

Dessa skyldigheter vänder sig till olika läsare. En behörig myndighet kan behöva den fullständiga tekniska dokumentationen. En nedströmsleverantör behöver integrationsinformation och begränsningar. Allmänheten behöver en tydlig redogörelse för vad modellen är och hur sammanfattningen av träningsinnehåll är avgränsad. En registerpost kan länka samman dessa ytor utan att låtsas att en offentlig sida ska innehålla varje säkerhetskänslig detalj, varje viktfil eller varje testprov med personuppgifter.

Länkar är inte heller bevis genom magi. Ett register som pekar på en utvärderingsrapport bör ange vilken version rapporten täcker, vad utvärderingen mätte och vilka villkor som begränsar resultatet. En länk till en träningssammanfattning bör ange om sammanfattningen täcker förträning, finjustering eller en definierad uppsättning innehållskategorier. En länk till ett certifikat bör visa vem som utfärdat det, vad det certifierar och när det upphör att gälla. Annars är sidan en hylla med oöppnade kuvert.

Samma regel gäller säkerhetspåståenden. Ett register får säga att en riskbedömning finns, att en övervakningsplan är länkad eller att en väg för allvarliga incidenter är publicerad. Det ska inte antyda att förekomsten av ett dokument bevisar att det underliggande systemet är säkert. Dokumentation är ett sätt att granska ett påstående. Den är inte en ersättning för påståendet.

Det är här offentligt skrivande kräver disciplin. En modellkort, transparenssida eller registerpost kan beskriva avsedd användning och kända begränsningar. Den kan inte använda frasen pålitlig som slutsats om inte bevisen och omfattningen gör den slutsatsen försvarbar. Den ärliga meningen är ofta mer användbar: dessa är villkoren vi utvärderade, dessa är begränsningarna vi observerade, och dessa är fallen vi inte påstod oss täcka.

Det nederländska registret visar värdet av en vanlig offentlig lista

Det nederländska algoritmregistret är lärorikt just för att det inte försöker se ut som ett futuristiskt kontrollrum. Det ger offentliga organisationer en offentlig plats att beskriva algoritmer som används i deras arbete. Dess engelska sida varnar för att beskrivningarna har översatts automatiskt och att den nederländska originaltexten är den auktoritativa versionen för beskrivningen. Den lilla noten är en läxa i proveniens. Tillgång är inte detsamma som noggrannhet, och ett översatt gränssnitt ska inte radera källspråket.

Registrets offentliga syfte anges också utan teatraliskt språk. Det fokuserar på algoritmer med stor påverkan, inklusive AI-system med hög risk, och ger besökare insikt i hur de fungerar. Besökaren kan bläddra bland algoritmer, organisationer och mallar. Syftet är inte att erbjuda ett betyg för varje algoritm. Det är att göra användningen av algoritmiska system tillräckligt synlig för att människor, organisationer och medier ska kunna följa, ifrågasätta och granska myndigheters praktik.

Det medföljande nederländska Algoritmekader förvandlar det syftet till ett krav. Det säger att offentliga organ, om inte ett undantag gäller, publicerar algoritmer med stor påverkan och AI-system med hög risk i registret. Det säger också att felaktig eller ofullständig publicering kan göra det svårare för berörda personer och andra intressenter att förstå och utmana användningen av teknik som kan röra deras rättigheter. Transparens är därför inte bara en artighet. Kvaliteten på posten kan påverka kvaliteten på den offentliga kontrollen.

Samma vägledning är noggrann med avgränsningen. Den beskriver registret som ett verktyg inom en bredare uppsättning lagar och krav, och varnar för att ramverket inte är komplett och kan sakna sektorsspecifik lagstiftning. Att en algoritm finns i ett register avgör inte alla juridiska eller etiska frågor. Att den inte finns där bevisar inte att den är ofarlig. En läsare behöver registrets inkluderingsregel och det omgivande ramverket för att tolka posten.

Det är det användbara mönstret för modellregister. En offentlig lista bör vara lätt att hitta, skriven för personer som inte var med på upphandlingsmötet, och kopplad till de dokument som innehåller mer detaljer. Den bör synliggöra osäkerhet snarare än dölja den. Den bör ange när en engelsk beskrivning är maskinöversatt. Den bör förklara vilka system som ingår och vilka som inte gör det. Den bör göra en saknad eller inaktuell post till en synlig styrningsfråga i stället för en privat besvikelse.

Det finns ingen anledning att hitta på en dramatisk händelse för att se varför detta spelar roll. En medborgare som försöker förstå en automatiserad offentlig process har redan en praktisk fråga: används ett system, av vem, för vilket ändamål och med vilken förklaring? Ett register ger den frågan en adress. Svaret kan fortfarande vara ofullständigt. Åtminstone kan institutionen inte låtsas att det inte finns någonstans att fråga.

Offentlig betyder inte naken

Transparens blir kontraproduktiv när den behandlas som en order att publicera allt. Offentliga dokument kan exponera personuppgifter, säkerhetskänslig information, företagshemligheter och attackvägar. De kan också skapa falskt förtroende genom att publicera tekniska fragment som ingen vanlig läsare kan tolka. Gränsen mellan offentligt och privat måste utformas, dokumenteras och ses över, inte improviseras av vilket team som råkar äga innehållshanteringssystemet.

AI-förordningen ger ett juridiskt exempel. Artikel 49.4 placerar vissa system i en säker icke-offentlig sektion och begränsar åtkomsten till kommissionen och de relevanta nationella myndigheterna. Artikel 71 gör information som registrerats enligt artikel 49 offentligt tillgänglig, förutom de begränsade sektionerna, medan information som registrerats enligt artikel 60 endast är tillgänglig för marknadskontrollmyndigheterna och kommissionen, om inte leverantören samtycker till offentlig åtkomst. Offentlighet är därför en regel med undantag, inte en universell standard.

Artikel 53 gör en liknande åtskillnad för allmänna AI-modeller. Leverantörer måste göra teknisk dokumentation tillgänglig för AI-kontoret och nationella behöriga myndigheter på begäran, och de måste tillhandahålla dokumentation om vidare användning till integrerande leverantörer. Skyldigheterna är uttryckligen underställda behovet av att iaktta och skydda immateriella rättigheter, konfidentiell affärsinformation och företagshemligheter. Ett register bör inte tvinga en leverantör att publicera material som lagen säger ska vara kontrollerat. Konfidentialitet bör inte heller bli en artig ursäkt för att undanhålla existensen, syftet eller statusen för ett system som påverkar allmänheten.

Ett praktiskt modellregister kan använda lager. Det offentliga lagret identifierar modellen, leverantören, statusen, det avsedda syftet, de övergripande förmågorna, kända begränsningar, åtkomstvägar, publiceringsvillkor, bevislänkar och ändringshistorik. Ett kontrollerat lager innehåller detaljerad teknisk dokumentation, hotmodeller, begränsat utvärderingsmaterial, incidentdetaljer och annan information som behöriga granskare behöver. Ett privat operativt lager innehåller hemligheter, personuppgifter och intern kontrollinformation som inte bör exponeras alls. Lagren är olika dokument med länkar, inte en sida med en dragspelsmeny märkt transparens.

God transparens har en gräns. Den publicerar det människor behöver för att förstå systemet och skyddar det som behöriga granskare måste kontrollera.

Det offentliga lagret bör fortfarande vara specifikt. Det kan säga att en modell är adaptiv under användning utan att avslöja en privat tillståndsrepresentation. Det kan ange att en rutt är inbjudningsbaserad utan att publicera inbjudningstoken. Det kan beskriva utdatamodaliteter och en policy för innehållsmarkering utan att avslöja signeringsnycklar. Det kan säga att en riskbedömning finns och identifiera dess omfattning utan att publicera ett säkerhetsdiagram som skulle göra tjänsten lättare att attackera.

Det kontrollerade lagret behöver sin egen ärlighet. Ett dokument märkt som konfidentiellt är inte automatiskt komplett, aktuellt eller korrekt. Det behöver en ägare, en version, en åtkomstregel och en bevaranderegel. Om ett offentligt register länkar till en kontrollerad post bör länken avslöja dess status och ansvarig rutt även när innehållet är begränsat. Annars ser allmänheten ett svart hål och ombeds kalla det styrning.

Versionshantering är där ett register blir användbart

De flesta registerfel är inte dramatiska. De är små handlingar av glömska. En ny modell ersätter en gammal, men posten redigeras på plats. En policy ändras, men stycket om avsedd användning förblir. En leverantör flyttar en rutt från intern testning till en extern beta, men statusmärket ändras innan ikraftträdandedatumet registreras. En driftsättning dras tillbaka, men den gamla posten försvinner och tar historiken med sig. Nuets ser prydligt ut. Det förflutna blir obesvarat.

En versionshanterad post håller minst fyra datum åtskilda. Innehållsversionen anger vilken posttext och vilka fält som är aktuella. Ikraftträdandedatumet anger när uttalandet gäller. Modell- eller paketversionen anger vilket tekniskt objekt som beskrivs. Verifieringsdatumet anger när någon kontrollerade posten. Dessa datum kan sammanfalla. De behöver inte göra det. Att behandla dem som ett datum är bekvämt och ofta fel.

Tidigare versioner bör förbli sökbara under en lämplig bevaranderegel. Allmänheten behöver inte varje intern redigering, men den behöver veta när ett materiellt syfte, en status, en rutt, en begränsning eller ett ägarskapsuttalande ändrades. En ändringslogg kan säga vad som flyttades utan att avslöja privat information. En maskinläsbar post kan länka den tidigare versionen och ett manifest. En läsbar sida kan förklara konsekvensen i vanligt språk. De två ytorna bör överensstämma.

Versionshantering gör också tillbakadragande meningsfullt. Om en modell dras tillbaka för att en rutt stängs skiljer det sig från en återkallelse för att en allvarlig defekt eller juridisk fråga kräver åtgärd. Om en modell förblir i befintliga privata driftsättningar bör den offentliga posten säga det. Om en efterträdare är kompatibel endast för vissa integrationer bör migrationsgränsen vara synlig. Ett register som tar bort ett namn utan att registrera varför lämnar varje nedströmsläsare att uppfinna en anledning.

Ändringshistorik är särskilt viktig för adaptiva system. Modellidentiteten kan förbli stabil medan fångade tillstånd, begränsningsuppsättningar, hämtningskällor eller utdatakontroller ändras. Registret kan ange vilka ändringar som skapar ett nytt paket, vilka ändringar som kräver en ny utvärdering och vilka ändringar som förblir inom den deklarerade identitetsgränsen. Detta är inte överdriven detalj. Det är skillnaden mellan ett system som kan spelas upp och ett system som bara kan minnas.

Ägare är en del av posten

En modellregisterpost utan ägare är en väderrapport. Den berättar hur himlen såg ut och lämnar dig utan någon att ringa när taket läcker. Rollerna som leverantör och driftsättare är inte desamma, och ingen av rollerna bör tillåtas upplösas i ordet plattform.

Leverantören äger modellidentiteten, utvecklingshistoriken och beslutet om lansering inom sitt ansvarsområde. En driftsättare äger beslutet att använda ett system under sin auktoritet, inklusive det lokala syftet, skyddsåtgärderna, konsekvensbedömningen och operativa kontroller. En nedströmsleverantör kan integrera en generell modell i ett AI-system och bära ansvar som modellleverantören inte kan se. Ett offentligt register bör synliggöra dessa relationer där lagen och risken kräver det.

Kontaktuppgifter är inte administrativt utfyllnad. De ger en berörd person en väg att fråga vem som fattade ett beslut, vilken version som användes eller hur en korrigering kan begäras. En generisk brevlåda kan vara lämplig, men den bör leda till en underhållen process. Posten bör också ange om kontakten gäller teknisk support, begäran om rättigheter, incidentrapportering, upphandling eller offentlig ansvarsskyldighet. En inkorg kan inte vara alla institutioner på en gång, trots moderna formulärs bästa ansträngningar.

Ägarskap bör inkludera befogenhet att ändra posten. Om den namngivna ägaren inte kan pausa en rutt, korrigera en status eller publicera ett tillbakadragande, är posten dekorativ. Organisationen kan fortfarande ha en juridisk ägare någon annanstans, men det operativa gapet kvarstår. Ett bra register gör ansvar synligt innan en incident tvingar människor att rita organisationen på en whiteboard.

Utforma ett register som människor faktiskt kan läsa

Den första läsaren av ett modellregister är inte alltid en tillsynsmyndighet eller en ingenjör. Det kan vara en journalist, en upphandlare, en lokal tjänsteman, en forskare, en anställd som ombetts använda systemet, eller en person som försöker förstå varför en automatiserad tjänst rörde deras ärende. Sidan bör besvara den vanliga frågan innan den tar till specialiserad vokabulär.

Börja med identiteten och anledningen till posten. Ange vem som tillhandahåller modellen, vilken version som beskrivs, vilken typ av objekt det är och om det är en modell, ett integrerat AI-system eller en driftsättningspost. Ange om den är intern, tillgänglig för inbjudna användare, på marknaden, pausad eller tillbakadragen. Läsaren ska inte behöva sluta sig till statusen från en nedladdningsknapp.

Visa sedan syftet och gränsen. Ange vad modellen är avsedd att göra, vilka användningsområden som ligger utanför anspråket och vilka beslut den inte är behörig att fatta. Förklara om modellen kan anpassas under användning, om ett fångat tillstånd krävs för repris, och om en nedströmsrutt ändrar villkoren. En kapacitetslista utan syfte är en meny utan kök.

Använd progressiv avslöjande. Toppen av sidan bör vara lugn och läsbar. Djupare sektioner kan exponera maskinposten, utvärderingsmetoder, sammanfattning av träningsinnehåll, juridiska dokument och lanseringsbevis. En allmän läsare kan stanna efter första lagret. En revisor kan fortsätta. En ingenjör kan ladda ner en stabil representation. Att dölja detaljerna är inte enkelhet. Det är bara en långsamt laddad överraskning.

Tillgänglighet är en del av postens trovärdighet. Sidan och maskinrepresentationen bör använda tydliga etiketter, tangentbordsnavigering, användbara rubriker och textalternativ för visualiseringar. Datum bör inte kodas enbart som färg. En röd märkning är inte en status för en läsare som inte kan se rött, och en graf som inte kan läsas utan mus är inte en tillgänglig förklaring. En anslagstavla på torget blir inte offentlig om rampen slutar vid första trappsteget.

Maskinläsbarhet är viktigt av en annan anledning. Det gör att forskare kan jämföra poster, att offentliga organ kan bygga inventeringar, att revisorer kan upptäcka inaktuella register och att ett nedströmsverktyg kan verifiera att sidan och den strukturerade posten avser samma version. Maskinläsbart betyder inte enbart för maskiner. Den mänskliga sidan och maskinposten bör dela identifierare, status, datum och länkar, med en integritetsrelation som kan kontrolleras.

Registerfält är beslut

Varje fält berättar för läsaren vad organisationen anser vara värt att bevara. Ett leverantörsfält säger vem som står bakom modellen. Ett modellnamn och en version säger hur den skiljs från en efterföljare. Ett ruttfält säger var den kan nås. Ett fält för avsett ändamål säger vilket arbete leverantören är beredd att beskriva. Ett begränsningsfält säger var beskrivningen slutar. Schemat är ett styrdokument skrivet i små rektanglar.

Identitetsfält bör vara entydiga och stabila. De kan inkludera en leverantörs juridiska namn, modellnamnet, versionen, en unik referens och länkar till en kanonisk post. Om modellen kan levereras genom flera produkter bör registret skilja modellidentiteten från den integrerande ytan. Om en produkt innehåller flera modeller bör posten inte dölja det faktum bakom produktnamnet.

Statusfält bör inkludera värdet, ikraftträdandedatumet, skälet eller auktoriteten för övergången samt eventuell efterträdare eller föregångare. Ett datum som endast är planerat bör märkas som planerat. En post som inte har verifierats nyligen bör säga det. Läsaren bör kunna avgöra om en modell är tillgänglig, föreslagen, pausad eller historisk utan att tolka ett adjektiv som uppfunnits av ett marknadsföringsteam.

Ändamåls- och omfattningsfält bör beskriva arbetet i termer som en icke-specialist kan förstå. De bör namnge avsedda användare där det är relevant, vilka typer av indata och utdata som ingår samt de beslut eller åtgärder som modellen kan stödja. De bör också ange förbjudna eller ej stödda användningsområden. En modell som kan generera text är inte därmed bemyndigad att skriva ett beslut om berättigande, och en modell som kan klassificera dokument är inte därmed bemyndigad att klassificera människor.

Kapacitetsfält behöver villkor. Modaliteter, kontextgränser, verktygsåtkomst, språktäckning, anpassningsbeteende och utdatamärkning är meningsfulla endast när de kopplas till en rutt och en release. En kapacitet som finns i ett internt experiment men inte i den externa rutten bör inte presenteras som en universell funktion. Registret är inte en önskelista.

Datafält bör ange vad modellen tar emot, vad den lagrar, vad den lär sig från under användning och vad som används för utvärdering, på den nivå som kan göras offentlig utan att exponera personligt eller konfidentiellt material. Sammanfattningar av träningsinnehåll och policyer för rättigheter bör länkas där så krävs. En vag mening som tränad på mångfaldig data säger läsaren nästan ingenting och ber dem att själva fylla i en smickrande tolkning.

Utvärderingsfält bör identifiera frågan, metoden, datagränsen, datumet, resultatet och begränsningarna. Posten behöver inte återge varje tabell, men den bör inte visa ett resultat utan nämnare eller ett test utan syfte. En bra utvärderingslänk låter läsaren se om bevisen täcker den avsedda användningen, en närliggande användning eller endast en laboratoriemiljö.

Tillsynsfält bör identifiera vem som kan pausa, åsidosätta, granska och undersöka systemet. Om en modell endast rekommenderar, ange vilken åtgärd som förblir hos människan. Om en rutt kan agera på externa system, ange vilka behörigheter och spärrar som gäller. Om incidentrapportering har en särskild rutt, publicera den. Tillsyn är inte ett stycke om att hålla människor i loopen. Det är en karta över vem som kan göra vad när systemet är osäkert.

Bevis- och integritetsfält bör koppla den offentliga posten till en versionshanterad maskinpost, ett releasepaket, en deklaration, ett utvärderingspaket eller en transparenslogg. En hash kan fastställa att en fil har ändrats eller inte har ändrats. Den kan inte fastställa att filen var sanningsenlig, så registret bör hålla påståendet och integritetskontrollen åtskilda. Teknisk precision är ingen ersättning för omdöme, men den gör omdömet lättare att lokalisera.

Slutligen bör ändringsfälten förklara historiken. Vad ändrades, när, varför, vem godkände det, vilka vägar påverkas och om en ny utvärdering behövs. Posten bör göra det möjligt att besvara den mest vanliga frågan i rummet: vad skiljer sig från posten vi läste förra månaden?

Vad ett register kan fastställa

Ett välskött register kan fastställa att ett definierat objekt beskrivs av en namngiven leverantör under en viss postversion. Det kan fastställa det deklarerade syftet, statusen, åtkomstvägen och ägarskapet. Det kan fastställa vilka stöddokument och integritetsposter en läsare kan granska, och vilken information som medvetet kontrolleras. Det kan fastställa att en ändring publicerades och att en tidigare post finns kvar enligt den angivna bevaranderegeln.

Det kan också fastställa organisationens egen ståndpunkt. Om en leverantör säger att en modell är avsedd för beslutsstöd och inte för automatiska avslag, är uttalandet en offentlig gräns. Om en driftsättare säger att en konsekvensbedömning har slutförts, skapar uttalandet en fråga om var sammanfattningen eller den kontrollerade posten finns. Om en leverantör markerar en release som planerad, förhindrar etiketten att planen framstår som historik.

Dessa är användbara fakta. De gör upphandling mer precis, integration mindre spekulativ och offentliga frågor lättare att dirigera. De gör också oenighet skarpare. En läsare kan säga att det deklarerade syftet är för brett, att statusen är inaktuell, att begränsningen saknas eller att stödbevisningen inte täcker påståendet. Ett register förtjänar sin plats när det gör sådan kritik möjlig.

Vad ett register inte kan fastställa

En registerpost kan inte fastställa att en modell är korrekt för varje användare, säker i varje miljö, rättvis för varje grupp eller laglig för varje driftsättning. Det kan inte fastställa att en offentlig myndighet följde rätt förfarande bara för att ett system är listat. Det kan inte visa att en mänsklig granskare förstod ett resultat, att en registrerad person hade ett meningsfullt rättsmedel eller att en incident skulle upptäckas i tid. Dessa slutsatser kräver bevis om systemet i bruk, institutionen som använder det och de människor som påverkas av det.

Det kan inte heller fastställa att en modell är oberoende av sin leverantör, att en väg är suverän för att den är värd i Europa, eller att en öppen licens får ansvar att försvinna. Ägarskap, jurisdiktion, leveranskedja, driftkontroll och underhåll är separata frågor. Ett register kan exponera de namn och länkar som behövs för att ställa dem. Det kan inte besvara dem genom typografi.

Inte heller kan ett register bevisa det negativa. En frånvarande post kan betyda att objektet ligger utanför tillämpningsområdet, att ett undantag gäller, att publiceringen är försenad eller att någon misslyckades med att publicera. Läsaren behöver ett tydligt täckningsuttalande och en väg för att rapportera fel. En offentlig anslagstavla är bara så tillförlitlig som den process som uppmärksammar när ett meddelande saknas.

En illustrativ post, inte en dold fallstudie

Följande är en illustrativ postdesign, inte en rapport om en verklig organisation, modell eller händelse. Den använder ingen kund, offentlig myndighet, driftsättningsdatum eller uppmätt resultat. Dess syfte är att visa hur en läsare kan gå från en offentlig post till en kontrollerad bevisväg utan att blanda ihop de två lagren.

  • Identitet: ett leverantörsnamn, ett modellnamn, en version och en stabil maskinidentifierare.
  • Status: kontrollerad utvärdering, med ett ikraftträdandedatum och en notering om att ingen extern väg är öppen.
  • Syfte: stöd vid dokumentanalys för utbildad personal, med automatiska externa beslut utanför den deklarerade omfattningen.
  • Indata och utdata: de representerade modaliteterna, de typer av källmaterial som förväntas och de utdatatyper som vägen kan producera.
  • Begränsningar: kända språk-, domän-, aktualitets-, säkerhets- och åtkomstgränser, var och en kopplad till relevant utvärdering eller policy.
  • Tillsyn: den roll som kan pausa vägen, granskningsvägen för osäkra resultat och kontaktpersonen vid incidenter.
  • Bevis: en offentlig sammanfattning, en versionshanterad teknisk dokumentation för behöriga granskare och ett integritetsmanifest för de publicerade filerna.
  • Ändring: en länk till föregående dokumentation, en redogörelse för vad som ändrats och villkoret som skulle kräva en ny utvärdering.

Ingenting i den dokumentationen säger att modellen är bra. Den säger vad leverantören är beredd att hävda, var påståendet gäller och hur en annan person kan testa eller ifrågasätta det. Det räcker för en anslagstavla. Det räcker också för att hindra en stor mängd broschyrartat språk från att obemärkt ta sig in i ett juridiskt eller operativt beslut.

Varför förhandsstatus förtjänar respekt

Förhandsversion är inte en svagare form av offentlig. Det är ett annat tillstånd. Intern testning kan stödja teknik- och säkerhetsarbete samtidigt som åtkomsten hålls kontrollerad. En inbjuden betaversion kan exponera en väg för utomstående samtidigt som villkor, omfattning och rätten att stoppa bevaras. En offentlig lansering ändrar vem som kan förlita sig på systemet och vilka skyldigheter som åligger leverantören, integratörer och distributörer. Registret bör göra dessa övergångar synliga i stället för att behandla lansering som en enda trumpetstöt.

En förhandsregistrering kan fortfarande vara användbar för allmänheten. Den kan identifiera modellen, leverantören, den avsedda vägen, statusen, de bevis som finns och de bevis som fortfarande väntar. Den kan säga att ett datum är planerat och att åtkomst inte har öppnats. Den kan publicera lanseringsgrinden utan att låtsas att grinden har passerats. Detta är ett särskilt bra tillfälle för ett register att vara tråkigt. Tråkig status är säkrare än spännande otydlighet.

På Dweve försöker vi tillämpa den disciplinen på vår egen offentliga dokumentation. I vårt Trust Centre är modellregistret markerat som förhandsversion och listar Dweve Loom 1.0 som intern förhandstestning endast per den 1 augusti 2026. Det dokumenterar att ingen extern lansering har skett före det datumet och listar den 1 september 2026 som ett planerat datum för marknadsåtkomst inom unionen för en extern betaversion med inbjudan. Planerat är det viktiga ordet: posten förvandlar inte en plan till en händelse.

Vår offentliga dokumentation gör också tydligt att Loom är den enda modellen som listas där, att den är proprietär snarare än utgiven under en öppen källkodslicens för modeller, och att våra produkter och separat licensierade verktyg med öppen källkod inte presenteras som ytterligare modeller. Den gränsen förhindrar att en produktkatalog misstas för ett modellregister. Den håller också det offentliga påståendet tillräckligt litet för att kunna kontrolleras.

Det är allt vi behöver säga om Dweve här. Ett modellregister är användbart när det gör vår egen lanseringsstatus mindre smickrande men mer precis. Det borde göra detsamma för alla andra.

Gränsen mellan offentligt och privat är ett designbeslut

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