Das Modell-Registry ist das neue öffentliche Schwarze Brett.

Ein Modellregister kann der Öffentlichkeit zeigen, was ein System ist, wer dahintersteht, wo es eingesetzt werden darf und was sich geändert hat. Es kann...

Das Modell-Registry ist das neue öffentliche Schwarze Brett.

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.

Ein Modellregister sollte dieselbe Abgrenzungsfrage in einfacher Sprache beantworten. Führt es Foundation-Modelle, eingesetzte KI-Systeme, interne Experimente, feinabgestimmte Nachfolger, Evaluationspakete oder nur Modelle auf, die externen Nutzern angeboten werden? Erhält eine neue Serving-Konfiguration einen neuen Eintrag, eine neue Version oder einen verknüpften Bereitstellungsdatensatz? Zählt ein erfasster Zustand eines adaptiven Systems als dieselbe Modellidentität? Wenn das Register diese Fragen nicht entscheidet, wird jeder Leser sie anders entscheiden. So wird aus einer kurzen Liste ein langer Streit.

Die Auswahl macht auch Abwesenheit bedeutsam. Wenn der Geltungsbereich besagt, dass alle öffentlich zugänglichen Hochrisikosysteme erscheinen müssen, ist ein fehlender Eintrag ein Governance-Problem. Wenn der Geltungsbereich besagt, dass nur auf einem Markt bereitgestellte Modelle aufgenommen werden, kann ein internes Experiment bewusst fehlen. Die Öffentlichkeit kann ein leeres Suchergebnis nicht interpretieren, ohne zu wissen, welche der beiden Situationen zutrifft. Schweigen ist nicht neutral, wenn das Register sein Vokabular nicht erklärt hat.

Es liegt ein kleiner administrativer Wert darin, dies klar auszusprechen. Register müssen nicht so tun, als wüssten sie alles. Sie müssen dem Leser mitteilen, was sie wissen, wofür sie verantwortlich sind und was außerhalb des Rahmens liegt. Ein Register erlangt seine Autorität, indem es die Grenze seines Geltungsbereichs explizit macht, nicht indem es das Deckblatt verziert. Die Technologie ist neuer. Der Papierkram-Instinkt ist es nicht.

Was die europäische Regel tatsächlich auf die Tafel bringt

Der KI-Act verleiht dem Wort Registrierung eine konkrete rechtliche Form, aber keine einzige universelle. Artikel 49 verlangt, dass ein Anbieter oder ein bevollmächtigter Vertreter bestimmte Hochrisiko-KI-Systeme registriert, bevor er sie auf dem Markt bereitstellt oder in Betrieb nimmt. Er verlangt auch eine Registrierung, wenn ein Anbieter festgestellt hat, dass ein System unter den Bedingungen von Artikel 6 Absatz 3 nicht als Hochrisikosystem einzustufen ist. Öffentliche Behörden und gleichgestellte öffentliche Stellen, die bestimmte Hochrisikosysteme einsetzen, haben eine eigene Registrierungspflicht, einschließlich der Registrierung ihrer Nutzung.

Derselbe Artikel macht die Grenze zwischen öffentlich und privat explizit. Bestimmte Hochrisikosysteme, die in den Bereichen Strafverfolgung, Migration, Asyl und Grenzkontrollmanagement eingesetzt werden, werden in einem sicheren, nicht öffentlichen Bereich registriert. Hochrisikosysteme nach dem zweiten Punkt von Anhang III werden auf nationaler Ebene registriert. Dies sind keine Umsetzungsdetails, die in einem Dashboard ausgebügelt werden können. Sie beschreiben unterschiedliche Zielgruppen, unterschiedliche Risiken und unterschiedliche Berechtigungen, den Datensatz einzusehen.

Artikel 71 besagt, dass die Kommission zusammen mit den Mitgliedstaaten die EU-Datenbank einrichtet und pflegt. Die nach Artikel 49 registrierten Informationen sollen in benutzerfreundlicher Weise zugänglich und öffentlich verfügbar sein und sollten leicht navigierbar und maschinenlesbar sein, mit Ausnahmen für eingeschränkte Bereiche. Die Datenbank sollte personenbezogene Daten nur in dem Umfang enthalten, wie es erforderlich ist. Dies ist eine nützliche Definition öffentlicher Transparenz: ein Datensatz, den Menschen finden und verarbeiten können, ohne den Datensatz in ein zweites Problem personenbezogener Daten zu verwandeln.

Anhang VIII ist der Ort, an dem das Schwarze Brett konkret wird. Für einen Anbieter, der ein Hochrisikosystem registriert, umfasst der Datensatz die Identität und Kontaktdaten des Anbieters, einen eindeutigen Handelsnamen oder eine eindeutige Referenz, den vorgesehenen Zweck, eine grundlegende Beschreibung der verwendeten Informationen und der Betriebslogik, den Status des Systems, relevante Zertifikate, die Mitgliedstaaten, in denen es auf dem Markt bereitgestellt oder in Betrieb genommen wird, die Konformitätserklärung, die Gebrauchsanweisung und eine optionale URL für weitere Informationen. Dies sind keine Marketingfelder. Es sind Anknüpfungspunkte für Identifikation und Rechenschaftspflicht.

Für einen öffentlichen Bereitsteller sind die Informationen anders. Der Datensatz umfasst die Identität des Bereitstellers, die Person, die die Informationen übermittelt, die URL des Eintrags des Anbieters sowie Zusammenfassungen einer Folgenabschätzung für Grundrechte und, sofern zutreffend, einer Datenschutz-Folgenabschätzung. Die Unterscheidung ist wichtig, weil ein Modellanbieter und eine öffentliche Behörde nicht dieselben Dinge wissen und nicht dieselbe Verantwortung tragen. Ein Register, das sie in einer einzigen Anbieterkarte zusammenfasst, löscht die Stelle aus, an der ein System auf eine Institution trifft.

Die Rechtsdatenbank hat daher einen gestuften Charakter. Sie erfasst eine Systemidentität. Sie erfasst einen Anbieter. Sie kann einen Bereitsteller und eine Nutzung erfassen. Sie erfasst Status und unterstützende Erklärungen. Sie ersetzt nicht die technische Dokumentation, das Risikomanagement, das Qualitätssystem oder die Überwachung nach dem Inverkehrbringen, die das Gesetz an anderer Stelle verlangt. Die Datenbank ist ein öffentlicher Index rechenschaftspflichtiger Fakten. Sie ist nicht die gesamte Compliance-Akte.

Diese Unterscheidung geht leicht verloren, weil Menschen eine einzige URL mögen, die die Antwort zu enthalten scheint. Das Gesetz ist weniger sentimental. Es schafft eine öffentliche Oberfläche, eingeschränkte Oberflächen und kontrollierte Dokumentationswege. Die öffentliche Oberfläche muss nutzbar sein. Die eingeschränkte Oberfläche muss eingeschränkt bleiben. Die Dokumentation muss der zuständigen Behörde oder dem nachgelagerten Anbieter, der sie benötigt, weiterhin zur Verfügung stehen. Ein ernsthaftes Register ist eine Schnittstelle zwischen diesen Pflichten, keine Abkürzung an ihnen vorbei.

Ein Register wird nützlich, wenn Identität, Status und Änderung miteinander verbunden sind. Eine Farbe ohne Übergang ist nur Dekoration.

Es gibt eine weitere wichtige Grenze. Die Bestimmungen des KI-Gesetzes zu allgemeinen KI-Modellen sind nicht dasselbe wie ein öffentlicher Katalog aller allgemeinen KI-Modelle. Artikel 53 verlangt von Anbietern, technische Dokumentation zu führen, Informationen für nachgelagerte KI-Systemanbieter bereitzustellen, eine Urheberrechtspolitik zu unterhalten und eine ausreichend detaillierte Zusammenfassung der Trainingsinhalte zu veröffentlichen. Die Leitlinien der Kommission erläutern, dass die technische Dokumentation für das KI-Büro und die nationalen zuständigen Behörden auf Anfrage bestimmt ist, während die Dokumentation für nachgelagerte Systeme Integratoren hilft, Fähigkeiten und Grenzen zu verstehen. Nur ein Teil dieses Materials gehört auf ein öffentliches Schwarzes Brett.

Das Gesetz verlangt außerdem, dass die Kommission eine Liste allgemeiner KI-Modelle mit systemischem Risiko veröffentlicht und pflegt. Eine Liste von Modellen mit systemischem Risiko ist ein wertvolles öffentliches Signal, aber sie ist nicht dasselbe wie ein vollständiges Modellregister. Sie hat einen engeren Zweck und muss Rechte des geistigen Eigentums, vertrauliche Geschäftsinformationen und Geschäftsgeheimnisse respektieren. Jede Liste als Register zu bezeichnen, ist nur so lange harmlos, bis jemand annimmt, dass eine Liste mehr beweist, als sie tatsächlich beweist.

Ein Modell ist keine einzelne Zeile

Menschen sprechen über ein Modell, als wäre es ein Glas im Regal. Der Name steht auf dem Etikett, die Version ist unten eingestanzt und der Inhalt bleibt unverändert, bis jemand den Deckel öffnet. Dieses Bild funktioniert für ein statisches Artefakt. Es wird unzuverlässig, wenn ein Modell angepasst, feinabgestimmt, in Werkzeuge eingebettet, über mehrere Wege bereitgestellt oder während der Nutzung verändert wird.

Ein Register benötigt mindestens zwei Identitäten: die Modellidentität und die Identität dessen, was tatsächlich ausgeführt wurde. Die erste beantwortet, welches Modell der Anbieter meint. Die zweite kann einen erfassten Zustand, ein versiegeltes Bereitstellungspaket, einen lokalen Export oder ein Wiedergabebündel identifizieren. Die Verknüpfung verhindert zwei entgegengesetzte Fehler. Ein Dienst kann aufhören, so zu tun, als hätte jeder Live-Zustand einen permanenten Hash, und ein Betreiber kann aufhören, so zu tun, als beschreibe ein Paket-Digest allein die gesamte Modellfamilie.

Versionsnummern sind nur dann nützlich, wenn ihre Änderungsregel sichtbar ist. Eine Version kann einen neuen Satz gelernter Parameter bedeuten, einen neuen Einschränkungskatalog, eine Änderung beim Abruf, eine geänderte Sicherheitsebene oder eine wesentliche Änderung im Bereitstellungsvertrag. Wenn ein Anbieter für all das eine einzige Nummer verwendet, wird die Nummer zu einer höflichen Art zu sagen, dass sich etwas geändert hat. Ein Register sollte einen Nachfolger mit seinem Vorgänger verknüpfen und angeben, welcher Teil des Vertrags sich bewegt hat.

Adaptives Verhalten fügt eine weitere Komplikation hinzu. Wenn sich ein System während der Nutzung ändern kann, sollte der Datensatz dies angeben. Das ist kein Eingeständnis, dass das System unkontrolliert ist. Es ist ein Eingeständnis, dass das Wort Version nicht die gesamte Arbeit leisten kann. Das Register kann eine stabile Modellidentität führen, zeitgebundene erfasste Zustände daran anhängen und die Bedingungen aufzeichnen, unter denen ein Zustand erstellt wurde. Es geht nicht darum, ein lebendes System in ein falsches Foto einzufrieren. Es geht darum, jedem bedeutungsvollen Foto ein Datum und einen Rahmen zu geben.

Identität hat auch eine soziale Seite. Ein Modellname reicht nicht aus, wenn mehrere juristische Personen ähnliche Artefakte vertreiben, wenn ein nachgelagerter Anbieter das Modell ändert oder wenn ein Produkt ein Modell unter eigenem Namen einbettet. Das Register sollte die Kette sichtbar machen: Anbieter, Vertreiber, sofern abweichend, Bereitsteller, sofern relevant, und das System oder den Weg, in dem das Modell verwendet wird. Eine von einer Entscheidung betroffene Person sollte nicht forensische Archäologie an einem Produktlogo betreiben müssen, um herauszufinden, wer dafür verantwortlich ist.

Status ist ein Verb, keine Farbe

Statusfelder werden oft als Abzeichen dargestellt, weil Abzeichen sauber auf Karten passen. Das Abzeichen ist nicht der Status. Der Status ist eine Aussage über eine Handlung und einen Zeitpunkt. Interne Tests bedeuten etwas anderes, wenn der Zugriff vom Anbieter kontrolliert wird. Vorabveröffentlichung bedeutet etwas anderes, wenn eingeladene Externe einen Weg unter definierten Bedingungen nutzen können. Auf dem Markt, in Betrieb, ausgesetzt, zurückgezogen und zurückgerufen haben jeweils unterschiedliche betriebliche Konsequenzen.

Ein nützlicher Datensatz gibt an, was der Status erlaubt und was nicht. Wenn ein System nur intern ist, sollte ein Leser nicht aus einer Dokumentationsseite auf öffentliche Verfügbarkeit schließen. Wenn eine externe Beta geplant ist, sollte das Datum als geplant gekennzeichnet werden und nicht als Veröffentlichung präsentiert werden. Wenn ein System zurückgezogen wird, sollte der Datensatz die bisherige Identität bewahren und angeben, ob bestehende Bereitstellungen fortgeführt werden dürfen, beendet werden müssen oder migriert werden. Ein Status ohne Wirksamkeitsdatum ist ein Gerücht in Uniform.

Der Status sollte auch eine verantwortliche Stelle haben. Wer kann einen Eintrag von intern auf extern umstellen? Wer kann einen Weg aussetzen? Wer kann ein Veröffentlichungsdatum als geändert erklären? Welche Nachweise sind vor dem Übergang erforderlich? Diese Fragen gehören in den Betriebsprozess, aber der öffentliche Eintrag sollte die daraus resultierende Entscheidung nachvollziehbar machen. Ein Register, das das aktuelle Abzeichen zeigt, während es die dahinterstehende Autorität verbirgt, ist nur ein Stimmungsbrett für Governance.

Veranschaulichendes Beispiel, kein realer Eintrag: Ein Datensatz könnte besagen, dass sich ein Modell in kontrollierter Evaluierung befindet, dass kein externer Weg offen ist, dass eine nur auf Einladung zugängliche Erprobung für ein späteres Datum vorgeschlagen ist und dass der Vorschlag weiterhin einer Veröffentlichungsschranke unterliegt. Das Beispiel nennt keine Organisation, kein Modell und kein Ereignis. Sein Zweck ist es zu zeigen, wie ein Datensatz einen Plan von einer Tatsache getrennt hält. Dieselbe Disziplin gilt für einen Rückzug, eine Fähigkeitsbehauptung oder eine Zertifizierung, die noch nicht erteilt wurde.

Diese Trennung schützt Leser vor einem vertrauten Trick. Eine zukünftige Absicht wird oft genug wiederholt, dass sie anfängt, wie Geschichte zu klingen. Register sollten der Ort sein, an dem dieser Trick nicht mehr funktioniert. Der Eintrag kann einen Plan zeigen, aber der Plan muss sein Etikett behalten. Europa hat bereits genug Kalender. Ein Datum ist nicht allein deshalb eine Tatsache, weil es in ein farbiges Rechteck gesetzt wurde.

Das Register ist nicht der Beweisraum

Ein öffentlicher Eintrag sollte kurz genug sein, um gelesen zu werden, und stark genug, um eine ernsthafte Frage auszurichten. Der Belegraum dahinter kann viel größer sein. Die Dokumentationspflichten aus Artikel 53 der KI-Verordnung zeigen, warum das so ist. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck müssen technische Dokumentationen erstellen und aufbewahren, die Entwicklung, Training, Tests und Bewertung abdecken. Sie müssen Informationen und Dokumentationen nachgelagerten KI-Systemanbietern zur Verfügung stellen, damit diese Anbieter Fähigkeiten und Grenzen verstehen können. Sie müssen eine ausreichend detaillierte Zusammenfassung der Trainingsinhalte veröffentlichen und eine Politik zur Einhaltung des Unionsrechts zum Schutz des Urheberrechts aufrechterhalten.

Diese Pflichten bedienen unterschiedliche Leser. Eine zuständige Behörde benötigt möglicherweise den vollständigen technischen Nachweis. Ein nachgelagerter Anbieter benötigt Integrationsinformationen und Grenzen. Die Öffentlichkeit benötigt eine klare Darstellung dessen, was das Modell ist und wie seine Zusammenfassung der Trainingsinhalte abgegrenzt ist. Ein Registereintrag kann diese Oberflächen verbinden, ohne so zu tun, als müsste eine öffentliche Seite jedes sicherheitsrelevante Detail, jede Gewichtsdatei oder jede personenbezogene Daten enthaltende Testprobe enthalten.

Links sind auch nicht durch Magie ein Beleg. Ein Register, das auf einen Bewertungsbericht verweist, sollte angeben, welche Version der Bericht abdeckt, was die Bewertung gemessen hat und welche Bedingungen das Ergebnis einschränken. Ein Link zu einer Trainingszusammenfassung sollte angeben, ob die Zusammenfassung Vortraining, Feinabstimmung oder eine definierte Menge von Inhaltskategorien abdeckt. Ein Link zu einem Zertifikat sollte zeigen, wer es ausgestellt hat, was es bescheinigt und wann es abläuft. Andernfalls ist die Seite ein Regal voller ungeöffneter Umschläge.

Die gleiche Regel gilt für Sicherheitsbehauptungen. Ein Register darf sagen, dass eine Risikobewertung existiert, dass ein Überwachungsplan verlinkt ist oder dass ein Weg für schwerwiegende Vorfälle veröffentlicht ist. Es sollte nicht den Eindruck erwecken, dass die Existenz eines Dokuments beweist, dass das zugrunde liegende System sicher ist. Dokumentation ist eine Möglichkeit, eine Behauptung zu prüfen. Sie ist kein Ersatz für die Behauptung.

Hier braucht öffentliches Schreiben Disziplin. Eine Modellkarte, Transparenzseite oder ein Registereintrag kann den beabsichtigten Verwendungszweck und bekannte Grenzen beschreiben. Es darf den Begriff vertrauenswürdig nicht als Schlussfolgerung verwenden, es sei denn, die Belege und der Umfang machen diese Schlussfolgerung vertretbar. Der ehrliche Satz ist oft nützlicher: Dies sind die Bedingungen, die wir bewertet haben, dies sind die Grenzen, die wir beobachtet haben, und dies sind die Fälle, für die wir keine Abdeckung beansprucht haben.

Das niederländische Register zeigt den Wert einer gewöhnlichen öffentlichen Liste

Das niederländische Algorithmenregister ist gerade deshalb lehrreich, weil es nicht wie ein futuristischer Kontrollraum wirken will. Es gibt Regierungsorganisationen einen öffentlichen Ort, um Algorithmen zu beschreiben, die in ihrer Arbeit verwendet werden. Seine englische Seite warnt davor, dass Beschreibungen automatisch übersetzt wurden und dass das niederländische Original die maßgebliche Version der Beschreibung ist. Diese kleine Anmerkung ist eine Lektion in Sachen Herkunft. Zugang ist nicht dasselbe wie Genauigkeit, und eine übersetzte Oberfläche sollte die Ausgangssprache nicht auslöschen.

Der öffentliche Zweck des Registers wird ebenfalls ohne theatralische Sprache dargestellt. Es konzentriert sich auf folgenreiche Algorithmen, einschließlich Hochrisiko-KI-Systemen, und gibt Besuchern Einblick, wie sie funktionieren. Der Besucher kann Algorithmen, Organisationen und Vorlagen durchsuchen. Das Ziel ist nicht, eine Bewertung für jeden Algorithmus anzubieten. Es geht darum, die Nutzung algorithmischer Systeme sichtbar genug zu machen, damit Menschen, Organisationen und Medien die Praxis der Regierung verfolgen, hinterfragen und prüfen können.

Das begleitende niederländische Algoritmekader macht aus diesem Zweck eine Anforderung. Es besagt, dass öffentliche Stellen, sofern keine Ausnahme gilt, folgenreiche Algorithmen und Hochrisiko-KI-Systeme im Register veröffentlichen. Es besagt auch, dass eine falsche oder unvollständige Veröffentlichung es betroffenen Personen und anderen Interessengruppen erschweren kann, die Nutzung von Technologie zu verstehen und anzufechten, die ihre Rechte berühren kann. Transparenz ist daher nicht nur eine Höflichkeit. Die Qualität des Eintrags kann die Qualität der öffentlichen Kontrolle beeinflussen.

Dieselbe Leitlinie ist hinsichtlich ihres Geltungsbereichs sorgfältig formuliert. Sie beschreibt das Register als ein Werkzeug innerhalb eines breiteren Gefüges von Gesetzen und Anforderungen und warnt davor, dass der Rahmen unvollständig ist und sektorspezifische Rechtsvorschriften möglicherweise nicht enthält. Die Tatsache, dass ein Algorithmus in einem Register erscheint, klärt nicht jede rechtliche oder ethische Frage. Die Tatsache, dass er nicht erscheint, beweist nicht, dass er unbedenklich ist. Eine Leserin oder ein Leser benötigt die Aufnahmeregel des Registers und den umgebenden Rahmen, um den Eintrag zu interpretieren.

Das ist das nützliche Muster für Modellregister. Eine öffentliche Liste sollte leicht auffindbar sein, für Menschen geschrieben sein, die nicht an der Beschaffungssitzung teilgenommen haben, und mit den Datensätzen verbunden sein, die mehr Details enthalten. Sie sollte Unsicherheit offenlegen statt sie zu verbergen. Sie sollte angeben, wann eine englische Beschreibung maschinell übersetzt wurde. Sie sollte erklären, welche Systeme enthalten sind und welche nicht. Sie sollte einen fehlenden oder veralteten Eintrag zu einem sichtbaren Governance-Problem machen statt zu einer privaten Enttäuschung.

Es ist nicht nötig, einen dramatischen Vorfall zu erfinden, um zu sehen, warum das wichtig ist. Eine Bürgerin oder ein Bürger, die oder der versucht, einen automatisierten Verwaltungsprozess zu verstehen, hat bereits eine praktische Frage: Wird ein System eingesetzt, von wem, für welchen Zweck und unter welcher Erläuterung? Ein Register gibt dieser Frage eine Adresse. Die Antwort mag weiterhin unvollständig sein. Zumindest kann die Institution nicht so tun, als gäbe es keine Stelle, an die man sich wenden könnte.

Öffentlich bedeutet nicht nackt

Transparenz wird kontraproduktiv, wenn sie als Anweisung behandelt wird, alles zu veröffentlichen. Öffentliche Aufzeichnungen können personenbezogene Daten, sicherheitsrelevante Informationen, geschäftliche Details und Angriffspfade offenlegen. Sie können auch falsches Vertrauen erzeugen, indem sie technische Fragmente veröffentlichen, die keine gewöhnliche Leserin und kein gewöhnlicher Leser interpretieren kann. Die Grenze zwischen öffentlich und privat muss gestaltet, dokumentiert und überprüft werden, nicht improvisiert von dem Team, das zufällig das Content-Management-System betreibt.

Der AI Act liefert ein rechtliches Beispiel. Artikel 49 Absatz 4 platziert bestimmte Systeme in einem sicheren, nicht öffentlichen Abschnitt und beschränkt den Zugang auf die Kommission und die zuständigen nationalen Behörden. Artikel 71 macht die nach Artikel 49 registrierten Informationen öffentlich zugänglich, mit Ausnahme der eingeschränkten Abschnitte, während Informationen, die nach Artikel 60 registriert sind, nur den Marktüberwachungsbehörden und der Kommission zugänglich sind, sofern der Anbieter nicht einer öffentlichen Zugänglichkeit zustimmt. Öffentlichkeit ist daher eine Regel mit Ausnahmen, kein universeller Standard.

Artikel 53 trifft eine ähnliche Unterscheidung für Allzweckmodelle. Anbieter müssen dem AI Office und den zuständigen nationalen Behörden auf Anfrage technische Dokumentation zur Verfügung stellen, und sie müssen nachgelagerte Dokumentation für integrierende Anbieter bereitstellen. Die Pflichten unterliegen ausdrücklich der Notwendigkeit, Rechte des geistigen Eigentums, vertrauliche Geschäftsinformationen und Geschäftsgeheimnisse zu beachten und zu schützen. Ein Register sollte einen Anbieter nicht zwingen, Material zu veröffentlichen, das das Gesetz als kontrolliert behandelt wissen will. Ebenso sollte Vertraulichkeit nicht zu einer höflichen Ausrede werden, um die Existenz, den Zweck oder den Status eines Systems zurückzuhalten, das die Öffentlichkeit betrifft.

Ein praktisches Modellregister kann mit Ebenen arbeiten. Die öffentliche Ebene identifiziert das Modell, den Anbieter, den Status, den beabsichtigten Zweck, die allgemeinen Fähigkeiten, bekannte Grenzen, Zugangswege, Freigabebedingungen, Nachweislinks und den Änderungsverlauf. Eine kontrollierte Ebene enthält detaillierte technische Dokumentation, Bedrohungsmodelle, eingeschränktes Bewertungsmaterial, Vorfallsdetails und andere Informationen, die autorisierte Prüferinnen und Prüfer benötigen. Eine private operative Ebene enthält Geheimnisse, personenbezogene Daten und interne Kontrollinformationen, die überhaupt nicht offengelegt werden sollten. Die Ebenen sind unterschiedliche Datensätze mit Verknüpfungen, nicht eine Seite mit einem Akkordeon mit der Beschriftung Transparenz.

Gute Transparenz hat eine Grenze. Sie veröffentlicht, was Menschen brauchen, um das System zu verstehen, und schützt, was autorisierte Prüfer kontrollieren müssen.

Die öffentliche Ebene sollte dennoch konkret sein. Sie kann sagen, dass ein Modell während der Nutzung adaptiv ist, ohne eine private Zustandsdarstellung offenzulegen. Sie kann feststellen, dass eine Route nur auf Einladung zugänglich ist, ohne Einladungstoken zu veröffentlichen. Sie kann Ausgabemodalitäten und eine Richtlinie zur Kennzeichnung von Inhalten beschreiben, ohne Signaturschlüssel offenzulegen. Sie kann sagen, dass eine Risikobewertung existiert, und ihren Umfang benennen, ohne ein Sicherheitsdiagramm zu veröffentlichen, das den Dienst angreifbarer machen würde.

Die kontrollierte Ebene braucht ihre eigene Ehrlichkeit. Ein Dokument, das als vertraulich gekennzeichnet ist, ist nicht automatisch vollständig, aktuell oder korrekt. Es braucht einen Eigentümer, eine Version, eine Zugriffsregel und eine Aufbewahrungsregel. Wenn ein öffentliches Register auf einen kontrollierten Datensatz verweist, sollte der Link seinen Status und die zuständige Route offenlegen, auch wenn der Inhalt eingeschränkt ist. Andernfalls sieht die Öffentlichkeit ein schwarzes Loch und soll das Governance nennen.

Versionierung macht ein Register nützlich

Die meisten Registerfehler sind nicht dramatisch. Es sind kleine Akte des Vergessens. Ein neues Modell ersetzt ein altes, aber der Eintrag wird direkt bearbeitet. Eine Richtlinie ändert sich, aber der Absatz zur beabsichtigten Verwendung bleibt. Ein Anbieter verschiebt eine Route von internen Tests zu einer externen Beta, aber das Statusabzeichen ändert sich, bevor das Wirksamkeitsdatum erfasst wird. Eine Bereitstellung wird zurückgezogen, aber der alte Eintrag verschwindet und nimmt die Historie mit. Die Gegenwart wirkt aufgeräumt. Die Vergangenheit wird unbeantwortbar.

Ein versionierter Datensatz hält mindestens vier Uhren getrennt. Die Inhaltsversion sagt, welcher Datensatztext und welche Felder aktuell sind. Das Wirksamkeitsdatum sagt, ab wann die Aussage gilt. Die Modell- oder Paketversion sagt, welches technische Objekt beschrieben wird. Das Prüfdatum sagt, wann jemand den Datensatz geprüft hat. Diese Daten können zusammenfallen. Sie müssen es nicht. Sie als ein Datum zu behandeln, ist bequem und oft falsch.

Frühere Versionen sollten gemäß einer angemessenen Aufbewahrungsregel auffindbar bleiben. Die Öffentlichkeit braucht nicht jede interne Bearbeitung, aber sie muss wissen, wann sich eine wesentliche Aussage zu Zweck, Status, Route, Einschränkung oder Eigentümerschaft geändert hat. Ein Änderungsprotokoll kann sagen, was sich bewegt hat, ohne private Informationen offenzulegen. Ein maschinenlesbarer Datensatz kann die vorherige Version und ein Manifest verlinken. Eine für Menschen lesbare Seite kann die Konsequenz in einfacher Sprache erklären. Die beiden Oberflächen sollten übereinstimmen.

Versionierung macht auch den Rückzug bedeutungsvoll. Wenn ein Modell zurückgezogen wird, weil eine Route geschlossen ist, unterscheidet sich das von einem Rückruf, weil ein schwerwiegender Defekt oder ein rechtliches Problem Maßnahmen erfordert. Wenn ein Modell in bestehenden privaten Bereitstellungen verbleibt, sollte das öffentliche Register das sagen. Wenn ein Nachfolger nur für einige Integrationen kompatibel ist, sollte die Migrationsgrenze sichtbar sein. Ein Register, das einen Namen entfernt, ohne den Grund zu erfassen, lässt jeden nachgelagerten Leser einen Grund erfinden.

Die Änderungshistorie ist besonders wichtig für adaptive Systeme. Die Modellidentität kann stabil bleiben, während erfasste Zustände, Einschränkungssätze, Abrufquellen oder Ausgabesteuerungen sich ändern. Das Register kann feststellen, welche Änderungen ein neues Paket erzeugen, welche Änderungen eine neue Bewertung erfordern und welche Änderungen innerhalb der erklärten Identitätsgrenze bleiben. Das ist kein übertriebenes Detail. Es ist der Unterschied zwischen einem System, das wiedergegeben werden kann, und einem System, an das man sich nur erinnern kann.

Eigentümer sind Teil des Datensatzes

Ein Model-Registry-Eintrag ohne Eigentümer ist wie ein Wetterbericht. Er sagt Ihnen, wie der Himmel aussah, und lässt Sie ohne Ansprechpartner zurück, wenn das Dach undicht wird. Die Rollen von Anbieter und Bereitsteller sind nicht dasselbe, und keine der beiden Rollen sollte in dem Wort Plattform aufgehen dürfen.

Der Anbieter besitzt die Modellidentität, den Entwicklungsnachweis und die Freigabeentscheidung innerhalb seines Zuständigkeitsbereichs. Ein Bereitsteller besitzt die Entscheidung, ein System unter seiner Verantwortung zu nutzen, einschließlich des lokalen Zwecks, der Schutzmaßnahmen, der Folgenabschätzung und der Betriebskontrollen. Ein nachgelagerter Anbieter kann ein Allzweckmodell in ein KI-System integrieren und Verantwortlichkeiten tragen, die der Modellanbieter nicht sehen kann. Ein öffentliches Register sollte diese Beziehungen offenlegen, wo Gesetz und Risiko es erfordern.

Kontaktinformationen sind kein administratives Beiwerk. Sie geben einer betroffenen Person einen Weg, um zu fragen, wer eine Entscheidung getroffen hat, welche Version verwendet wurde oder wie eine Korrektur beantragt werden kann. Ein allgemeines Postfach kann angemessen sein, sollte aber zu einem gepflegten Prozess führen. Der Eintrag sollte auch angeben, ob der Kontakt für technischen Support, Rechtsanfragen, Meldung von Vorfällen, Beschaffung oder öffentliche Rechenschaft gedacht ist. Ein Postfach kann nicht gleichzeitig jede Institution sein, trotz der besten Bemühungen moderner Formulare.

Eigentum sollte die Befugnis umfassen, den Eintrag zu ändern. Wenn der benannte Eigentümer eine Route nicht anhalten, einen Status nicht korrigieren oder einen Rückzug nicht veröffentlichen kann, ist der Eintrag nur Dekoration. Die Organisation kann anderswo durchaus einen rechtlichen Eigentümer haben, aber die betriebliche Lücke bleibt. Ein gutes Register macht Verantwortung sichtbar, bevor ein Vorfall Menschen dazu zwingt, die Organisation auf ein Whiteboard zu zeichnen.

Ein Register gestalten, das Menschen tatsächlich lesen können

Der erste Leser eines Model-Registers ist nicht immer eine Aufsichtsbehörde oder ein Ingenieur. Es kann eine Journalistin, ein Beschaffungsbeauftragter, eine lokale Amtsperson, ein Forscher, eine Mitarbeiterin, die das System nutzen soll, oder eine Person sein, die verstehen möchte, warum ein automatisierter Dienst ihren Fall betroffen hat. Die Seite sollte die häufige Frage beantworten, bevor sie zu Fachvokabular greift.

Beginnen Sie mit der Identität und dem Grund für den Eintrag. Sagen Sie, wer das Modell bereitstellt, welche Version beschrieben wird, um welche Art von Objekt es sich handelt und ob es ein Modell, ein integriertes KI-System oder ein Bereitstellungsdatensatz ist. Sagen Sie, ob es intern ist, für eingeladene Nutzer verfügbar, auf dem Markt, ausgesetzt oder zurückgezogen ist. Die Leserin sollte den Status nicht aus einem Download-Button ableiten müssen.

Zeigen Sie dann den Zweck und die Grenze auf. Geben Sie an, wofür das Modell gedacht ist, welche Verwendungen außerhalb des Anspruchs liegen und welche Entscheidungen es nicht treffen darf. Erklären Sie, ob sich das Modell während der Nutzung anpassen kann, ob ein erfasster Zustand für die Wiedergabe erforderlich ist und ob eine nachgelagerte Route die Bedingungen ändert. Eine Fähigkeitsliste ohne Zweck ist eine Speisekarte ohne Küche.

Nutzen Sie progressive Offenlegung. Der obere Teil der Seite sollte ruhig und lesbar sein. Tiefere Abschnitte können den Maschinendatensatz, Bewertungsmethoden, eine Zusammenfassung der Trainingsinhalte, Rechtsdokumente und Freigabenachweise offenlegen. Eine öffentliche Leserin kann nach der ersten Ebene aufhören. Eine Prüferin kann weitermachen. Ein Ingenieur kann eine stabile Darstellung herunterladen. Details zu verbergen ist keine Einfachheit. Es ist nur eine langsam ladende Überraschung.

Barrierefreiheit ist Teil der Glaubwürdigkeit des Datensatzes. Die Seite und die maschinelle Darstellung sollten klare Beschriftungen, Tastaturnavigation, nützliche Überschriften und Textalternativen für Visualisierungen verwenden. Daten sollten nicht nur als Farbe kodiert sein. Ein rotes Abzeichen ist kein Status für eine Leserin, die Rot nicht sehen kann, und ein Diagramm, das ohne Maus nicht lesbar ist, ist keine zugängliche Erklärung. Ein Anschlagbrett auf dem Marktplatz wird nicht öffentlich, wenn die Rampe an der ersten Stufe endet.

Maschinenlesbarkeit ist aus einem anderen Grund wichtig. Sie ermöglicht es Forschenden, Einträge zu vergleichen, öffentlichen Stellen, Bestandsverzeichnisse aufzubauen, Prüfenden, veraltete Datensätze zu erkennen, und nachgelagerten Werkzeugen, zu überprüfen, ob die Seite und der strukturierte Datensatz sich auf dieselbe Version beziehen. Maschinenlesbar bedeutet nicht maschinenexklusiv. Die Seite für Menschen und der maschinelle Datensatz sollten Kennungen, Status, Daten und Links gemeinsam haben, mit einer Integritätsbeziehung, die überprüfbar ist.

Registerfelder sind Entscheidungen

Jedes Feld sagt der Leserschaft, was die Organisation für erhaltenswert hält. Ein Anbieterfeld sagt, wer hinter dem Modell steht. Ein Modellname und eine Version sagen, wie man es von einem Nachfolger unterscheidet. Ein Routenfeld sagt, wo es erreichbar ist. Ein Feld für den Verwendungszweck sagt, welche Arbeit der Anbieter zu beschreiben bereit ist. Ein Feld für Einschränkungen sagt, wo die Beschreibung endet. Das Schema ist ein Governance-Dokument, geschrieben in kleinen Rechtecken.

Identitätsfelder sollten eindeutig und stabil sein. Sie können den rechtlichen Namen des Anbieters, den Modellnamen, die Version, eine eindeutige Referenz und Links zu einem kanonischen Datensatz enthalten. Wenn das Modell über mehrere Produkte bereitgestellt werden kann, sollte das Register die Modellidentität von der integrierenden Oberfläche unterscheiden. Wenn ein Produkt mehrere Modelle enthält, sollte der Eintrag diese Tatsache nicht hinter dem Produktnamen verbergen.

Statusfelder sollten den Wert, das Datum des Inkrafttretens, den Grund oder die Autorität für den Übergang sowie etwaige Nachfolger oder Vorgänger enthalten. Ein Datum, das lediglich geplant ist, sollte als geplant gekennzeichnet werden. Ein Datensatz, der nicht kürzlich verifiziert wurde, sollte dies angeben. Die Leserschaft sollte erkennen können, ob ein Modell verfügbar, vorgeschlagen, pausiert oder historisch ist, ohne ein Adjektiv interpretieren zu müssen, das von einem Marketingteam erfunden wurde.

Felder für Zweck und Umfang sollten die Arbeit in Begriffen beschreiben, die auch Nichtfachleute verstehen. Sie sollten die vorgesehenen Nutzenden benennen, wo dies relevant ist, die Arten von Eingaben und Ausgaben sowie die Entscheidungen oder Handlungen, die das Modell unterstützen kann. Sie sollten auch verbotene oder nicht unterstützte Verwendungen angeben. Ein Modell, das Text erzeugen kann, ist dadurch nicht befugt, eine Entscheidung über die Berechtigung zu treffen, und ein Modell, das Dokumente klassifizieren kann, ist dadurch nicht befugt, Menschen zu klassifizieren.

Fähigkeitsfelder benötigen Bedingungen. Modalitäten, Kontextgrenzen, Werkzeugzugriff, Sprachabdeckung, Anpassungsverhalten und Ausgabekennzeichnung sind nur dann aussagekräftig, wenn sie an eine Route und eine Veröffentlichung gebunden sind. Eine Fähigkeit, die in einem internen Experiment existiert, aber nicht in der externen Route, sollte nicht als ein universelles Merkmal dargestellt werden. Das Register ist keine Wunschliste.

Datenfelder sollten angeben, was das Modell empfängt, was es speichert, woraus es während der Nutzung lernt und was für die Bewertung verwendet wird, auf einer Ebene, die öffentlich gemacht werden kann, ohne persönliches oder vertrauliches Material offenzulegen. Zusammenfassungen der Trainingsinhalte und Richtlinien zu Rechten sollten verlinkt werden, wo dies erforderlich ist. Ein vager Satz wie „mit vielfältigen Daten trainiert“ sagt der Leserschaft fast nichts und verlangt von ihr, eine schmeichelhafte Interpretation zu liefern.

Bewertungsfelder sollten die Frage, die Methode, die Datengrenze, das Datum, das Ergebnis und die Einschränkungen identifizieren. Der Eintrag muss nicht jede Tabelle wiedergeben, aber er sollte keine Punktzahl ohne Nenner oder einen Test ohne Zweck anzeigen. Ein guter Bewertungslink ermöglicht es der Leserschaft zu sehen, ob die Belege die beabsichtigte Verwendung, eine angrenzende Verwendung oder nur eine Laborbedingung abdecken.

Aufsichtsfelder sollten identifizieren, wer das System pausieren, überstimmen, überprüfen und untersuchen kann. Wenn ein Modell nur Empfehlungen ausspricht, sollte angegeben werden, welche Handlung beim Menschen verbleibt. Wenn eine Route auf externe Systeme einwirken kann, sollten die geltenden Berechtigungen und Zugangskontrollen angegeben werden. Wenn die Meldung von Vorfällen einen eigenen Weg hat, sollte dieser veröffentlicht werden. Aufsicht ist kein Absatz darüber, den Menschen im Entscheidungskreis zu halten. Sie ist eine Karte darüber, wer was tun kann, wenn das System unsicher ist.

Nachweis- und Integritätsfelder sollten den öffentlichen Eintrag mit einem versionierten Maschinendatensatz, einem Release-Paket, einer Erklärung, einem Evaluationsbündel oder einem Transparenzprotokoll verbinden. Ein Hash kann belegen, dass sich eine Datei geändert hat oder nicht geändert hat. Er kann nicht belegen, dass die Datei wahrheitsgemäß war. Daher sollte das Register die Behauptung und die Integritätsprüfung getrennt halten. Technische Präzision ersetzt kein Urteilsvermögen, aber sie erleichtert es, das Urteilsvermögen zu verorten.

Schließlich sollten Änderungsfelder die Historie erklären. Was wurde geändert, wann, warum, wer hat es genehmigt, welche Routen sind betroffen und ob eine neue Evaluierung erforderlich ist. Der Eintrag sollte es ermöglichen, die naheliegendste Frage im Raum zu beantworten: Was unterscheidet sich von dem Datensatz, den wir letzten Monat gelesen haben?

Was ein Register belegen kann

Ein gut gepflegtes Register kann belegen, dass ein definiertes Objekt von einem benannten Anbieter unter einer bestimmten Datensatzversion beschrieben wird. Es kann den erklärten Zweck, den Status, den Zugriffsweg und die Eigentümerschaft belegen. Es kann belegen, welche unterstützenden Dokumente und Integritätsdatensätze eine Leserin oder ein Leser einsehen kann und welche Informationen bewusst kontrolliert werden. Es kann belegen, dass eine Änderung veröffentlicht wurde und dass ein früherer Datensatz gemäß der angegebenen Aufbewahrungsregel weiterhin verfügbar bleibt.

Es kann auch die eigene Position der Organisation belegen. Wenn ein Anbieter sagt, dass ein Modell der Entscheidungsunterstützung dient und nicht der automatischen Ablehnung, ist diese Aussage eine öffentliche Grenze. Wenn ein Einsatzverantwortlicher sagt, dass eine Folgenabschätzung abgeschlossen wurde, wirft diese Aussage die Frage auf, wo die Zusammenfassung oder der kontrollierte Datensatz zu finden ist. Wenn ein Anbieter ein Release als geplant kennzeichnet, verhindert diese Kennzeichnung, dass der Plan als Historie ausgegeben wird.

Das sind nützliche Fakten. Sie machen die Beschaffung präziser, die Integration weniger spekulativ und öffentliche Fragen leichter zuzuordnen. Sie machen auch Widerspruch schärfer. Eine Leserin oder ein Leser kann sagen, dass der erklärte Zweck zu weit gefasst ist, der Status veraltet ist, die Einschränkung fehlt oder die unterstützenden Nachweise die Behauptung nicht abdecken. Ein Register rechtfertigt seinen Zweck, wenn es diese Kritik ermöglicht.

Was ein Register nicht belegen kann

Ein Registereintrag kann nicht belegen, dass ein Modell für jede Nutzerin und jeden Nutzer genau, in jeder Umgebung sicher, gegenüber jeder Gruppe fair oder für jede Bereitstellung rechtmäßig ist. Er kann nicht belegen, dass eine öffentliche Behörde das richtige Verfahren eingehalten hat, nur weil ein System gelistet ist. Er kann nicht zeigen, dass eine menschliche Prüferin oder ein menschlicher Prüfer eine Ausgabe verstanden hat, dass eine betroffene Person einen wirksamen Rechtsbehelf hatte oder dass ein Vorfall rechtzeitig erkannt worden wäre. Diese Schlussfolgerungen erfordern Nachweise über das System im Einsatz, die Institution, die es einsetzt, und die Menschen, die davon betroffen sind.

Er kann auch nicht belegen, dass ein Modell unabhängig von seinem Anbieter ist, dass eine Route souverän ist, weil sie in Europa gehostet wird, oder dass eine offene Lizenz die Verantwortung verschwinden lässt. Eigentümerschaft, Zuständigkeit, Lieferkette, Betriebskontrolle und Wartung sind getrennte Fragen. Ein Register kann die Namen und Links offenlegen, die nötig sind, um diese Fragen zu stellen. Es kann sie nicht durch Typografie beantworten.

Ein Register kann auch das Negative nicht belegen. Ein fehlender Eintrag kann bedeuten, dass das Objekt außerhalb des Geltungsbereichs liegt, dass eine Ausnahme gilt, dass die Veröffentlichung verspätet ist oder dass jemand es versäumt hat zu veröffentlichen. Die Leserin oder der Leser benötigt eine klare Abdeckungserklärung und einen Weg, Fehler zu melden. Ein öffentliches Schwarzes Brett ist nur so zuverlässig wie der Prozess, der bemerkt, wenn eine Bekanntmachung fehlt.

Ein illustrativer Datensatz, keine verdeckte Fallstudie

Das Folgende ist ein illustratives Datensatzdesign, kein Bericht über eine reale Organisation, ein reales Modell oder ein reales Ereignis. Es verwendet keine Kundin oder keinen Kunden, keine öffentliche Behörde, kein Bereitstellungsdatum und kein gemessenes Ergebnis. Sein Zweck ist es zu zeigen, wie eine Leserin oder ein Leser von einem öffentlichen Eintrag zu einem kontrollierten Nachweisweg gelangen kann, ohne die beiden Ebenen zu vermischen.

  • Identität: ein Anbietername, ein Modellname, eine Version und eine stabile Maschinenkennung.
  • Status: kontrollierte Evaluierung, mit einem Wirksamkeitsdatum und einem Hinweis, dass kein externer Weg offen ist.
  • Zweck: Unterstützung bei der Dokumentenanalyse für geschultes Personal, wobei automatische externe Entscheidungen außerhalb des erklärten Anwendungsbereichs liegen.
  • Eingaben und Ausgaben: die dargestellten Modalitäten, die Arten des erwarteten Quellmaterials und die Ausgabetypen, die der Weg erzeugen kann.
  • Grenzen: bekannte Sprach-, Domänen-, Aktualitäts-, Sicherheits- und Zugriffsgrenzen, jeweils verknüpft mit der relevanten Evaluierung oder Richtlinie.
  • Aufsicht: die Rolle, die den Weg anhalten kann, der Überprüfungspfad für unsichere Ergebnisse und der Ansprechpartner für Vorfälle.
  • Nachweise: eine öffentliche Zusammenfassung, ein versionierter technischer Datensatz für autorisierte Prüfer und ein Integritätsmanifest für die veröffentlichten Dateien.
  • Änderung: ein Link zum vorherigen Datensatz, eine Aussage darüber, was sich geändert hat, und die Bedingung, die eine neue Evaluierung erfordern würde.

Nichts in diesem Datensatz besagt, dass das Modell gut ist. Er sagt, was der Anbieter zu behaupten bereit ist, wo die Behauptung gilt und wie eine andere Person sie testen oder anfechten kann. Das reicht für ein Schwarzes Brett. Es reicht auch aus, um eine große Menge an Werbesprache davon abzuhalten, unbemerkt in eine rechtliche oder operative Entscheidung einzudringen.

Warum der Vorabveröffentlichungsstatus Respekt verdient

Vorabveröffentlichung ist keine schwächere Version der Öffentlichkeit. Es ist ein anderer Zustand. Interne Tests können Entwicklungs- und Sicherheitsarbeit unterstützen und gleichzeitig den Zugriff kontrolliert halten. Eine eingeladene Beta kann einen Weg für Außenstehende öffnen, während Bedingungen, Umfang und das Recht zum Stoppen erhalten bleiben. Eine öffentliche Veröffentlichung ändert, wer sich auf das System verlassen kann und welche Verpflichtungen für Anbieter, Integratoren und Bereitsteller gelten. Das Register sollte diese Übergänge sichtbar machen, anstatt die Veröffentlichung als einen einzigen Trompetenstoß zu behandeln.

Ein Vorabveröffentlichungsdatensatz kann für die Öffentlichkeit dennoch nützlich sein. Er kann das Modell, den Anbieter, den vorgesehenen Weg, den Status, die vorhandenen Nachweise und die noch ausstehenden Nachweise identifizieren. Er kann sagen, dass ein Datum geplant ist und dass der Zugriff noch nicht geöffnet wurde. Er kann das Veröffentlichungstor veröffentlichen, ohne vorzutäuschen, dass das Tor bereits passiert wurde. Dies ist ein besonders guter Ort für ein Register, um langweilig zu sein. Langweiliger Status ist sicherer als aufregende Mehrdeutigkeit.

Bei Dweve versuchen wir, diese Disziplin auf unseren eigenen öffentlichen Datensatz anzuwenden. In unserem Trust Centre ist das Modellregister als Vorabveröffentlichung gekennzeichnet und listet Dweve Loom 1.0 als rein internen Vorabveröffentlichungstest zum 1. August 2026 auf. Es hält fest, dass bis zu diesem Datum keine externe Veröffentlichung stattgefunden hat, und listet den 1. September 2026 als geplantes Datum für den Marktzugang in der Union für eine nur auf Einladung zugängliche externe Beta auf. Geplant ist das wichtige Wort: Der Eintrag macht aus einem Plan kein Ereignis.

Unser öffentlicher Datensatz macht auch deutlich, dass Loom das einzige dort aufgeführte Modell ist, dass es proprietär ist und nicht unter einer Open-Source-Modelllizenz veröffentlicht wurde, und dass unsere Produkte und separat lizenzierten Open-Source-Tools nicht als zusätzliche Modelle dargestellt werden. Diese Grenze verhindert, dass ein Produktkatalog mit einem Modellregister verwechselt wird. Sie hält die öffentliche Behauptung auch klein genug, um sie zu überprüfen.

Das ist alles, was wir hier über Dweve sagen müssen. Ein Modellregister ist nützlich, wenn es unseren eigenen Veröffentlichungsstatus weniger schmeichelhaft, aber präziser macht. Es sollte für jeden anderen dasselbe tun.

Die Grenze zwischen öffentlich und privat ist eine Designentscheidung

Das stärkste Register ist nicht das mit den meisten Feldern. Es ist das, dessen Felder einen Grund, einen Verantwortlichen und eine Grenze haben. Öffentliche Leser brauchen eine stabile Identität, einen erklärten Zweck, einen wahrheitsgemäßen Status, eine rechenschaftspflichtige Organisation, brauchbare Links und genügend Einschränkungen, um die Aussage zu verstehen. Autorisierte Prüfer brauchen tiefere Belege, kontrollierte technische Details und einen Weg, um Vorfälle oder sensible Tests einzusehen. Betreiber brauchen Geheimnisse, Berechtigungen und Runbooks, die überhaupt nicht am schwarzen Brett hängen sollten.

Diese Ebenen sollten sich über die Fakten einig sein, die die Grenze überschreiten. Wenn die öffentliche Seite sagt, dass eine Route pausiert ist, sollte der kontrollierte Datensatz sagen, wer sie pausiert hat und warum. Wenn eine technische Datei ersetzt wurde, sollte der öffentliche Eintrag sie nicht weiterhin als aktuell verlinken. Wenn eine Auswertung eingeschränkt ist, sollte die öffentliche Seite trotzdem ihren Umfang und Status angeben. Die Grenze sollte den Zugang zu Details begrenzen, nicht drei unvereinbare Versionen der Realität schaffen.

Leser sollten in der Lage sein, fünf einfache Fragen zu stellen und fünf stabile Antworten zu erhalten. Was ist dieses Objekt? Wer ist dafür verantwortlich? Was darf es tun? Wie ist sein aktueller Status? Welche Belege und Abhilfemaßnahmen gibt es, wenn die Aussage angefochten wird? Ein Register, das diese Fragen beantwortet, leistet bereits institutionelle Arbeit. Ein Register, das sie nicht beantworten kann, sollte nicht durch animierte Abzeichen oder ein Dashboard mit zwölf Filtern gerettet werden.

Es gibt eine optimistische Art, die europäische Bewegung hin zu Modell- und Algorithmusregistern zu lesen. Es geht nicht darum, dass eine Datenbank die KI-Governance lösen wird. Es geht darum, dass öffentliche Institutionen Orte schaffen, an denen Aussagen Namen, Daten, Verantwortliche und Grenzen haben. Das sind die kleinen Bausteine, aus denen größere Rechenschaftssysteme entstehen.

Das schwarze Brett muss Veränderungen überstehen

Ein Modellregister ist nur dann das neue öffentliche schwarze Brett, wenn die Aushänge auch nach Wetterumschwüngen lesbar bleiben. Die Seite muss ein Modell-Update, einen Anbieterwechsel, eine neue Bereitstellung, eine korrigierte Einschränkung, eine zurückgezogene Route und eine schwierige Frage von jemandem überstehen, der nicht im Raum war. Das bedeutet, Verlauf zu bewahren, Pläne zu kennzeichnen, Belege zu verlinken und zu sagen, was der Datensatz nicht beweisen kann.

Die Arbeit ist weniger glamourös als eine Startseite. Sie ist auch beständiger. Ein öffentlicher Datensatz, der Modellidentität von Bereitstellungszustand, Status von Absicht, Dokumentation von Beweis und öffentliche Fakten von kontrollierten Belegen unterscheidet, gibt den Menschen etwas Besseres als Beruhigung. Er gibt ihnen einen Weg durch das System.

Gute Register verlangen von Lesern nicht, einer Farbe, einer Zahl oder einem berühmten Namen zu vertrauen. Sie machen die Aussage eng genug, um sie zu prüfen, und die Grenze klar genug, um sie anzufechten. Sie hinterlassen eine Spur zu den Menschen, die antworten können, zu den Datensätzen, die geprüft werden können, und zu der Entscheidung, die geändert werden kann. Das ist eine sehr alte bürgerliche Idee in einem einigermaßen modernen Dateiformat.

Hängen Sie den Aushang ans Brett. Legen Sie die Belege dahinter. Bewahren Sie den alten Aushang so auf, dass ihn jemand noch lesen kann. Dann lassen Sie die Öffentlichkeit entscheiden, was der Datensatz verdient.

Quellen