Europas nächster KI-Vorteil könnte langweilige Interoperabilität sein

Europe wird KI nicht nützlicher machen, indem es jedes System identisch macht. Es kann sie besser regierbar machen, indem es darauf besteht, dass Systeme...

Europas nächster KI-Vorteil könnte langweilige Interoperabilität sein

Das unscheinbare Ding, das ein System nutzbar macht

Interoperabilität hat ein Imageproblem. Sie klingt nach dem Teil eines Programms, der den Leuten überlassen bleibt, die Referenzarchitekturen, Versionstabellen und die präzise Zeichensetzung eines Schemas mögen. Dieser Ruf ist nicht ganz unverdient. Ein guter Schnittstellenvertrag wird bei einer Produkteinführung nie gegen ein neues Modell gewinnen. Niemand bringt Kuchen mit, nur weil zwei Dienste sich endlich über die Bedeutung eines gelöschten Datensatzes einig sind.

Doch genau diese Einigung ist der Punkt, an dem ein Großteil der nützlichen Arbeit beginnt. Ein Modell kann für sich genommen beeindruckend sein und einer Organisation dennoch nur begrenzt helfen, wenn es nicht mit den Datensätzen, Regeln, Menschen und Entscheidungen verbunden werden kann, die der Arbeit einen Sinn geben. Das Modell mag eine flüssige Antwort liefern. Aber wenn die Antwort keine Quellenkennung tragen kann, wenn eine Korrektur nicht die Systeme erreicht, die darauf reagiert haben, wenn eine Person nicht sagen kann, welche Richtlinienversion angewendet wurde, dann ist das System nicht Teil der Arbeit geworden. Es ist zu einer weiteren Stelle geworden, an der man kopiert und einfügt.

Europas nächster KI-Vorteil könnte daher eher unspektakulär sein. Es könnte die Fähigkeit sein, Systeme an Grenzen zusammenzuführen, die explizit, überprüfbar und fair zu verlassen sind. Keine kontinentale Super-App. Keine Forderung, dass jedes Krankenhaus, jedes Rathaus, jedes Labor und jeder Hersteller eine einzige Datenbank nutzt. Der nützliche Ehrgeiz ist enger und schwieriger: Ein Dienst sollte Informationen austauschen können, die Bedeutung der Informationen bewahren, die Bedingungen um sie herum respektieren und betriebsfähig bleiben, wenn sich eine andere Komponente ändert.

Das ist eine strategische Fähigkeit. Sie verwandelt eine Sammlung von Werkzeugen in Infrastruktur. Sie erlaubt einer Verwaltung in einem Mitgliedstaat, einen in einem anderen erzeugten Datensatz anzuerkennen, ohne so zu tun, als wären ihre Gesetze, Sprachen oder Verfahren identisch. Sie erlaubt einem Unternehmen, einen Datenverarbeitungsdienst zu wechseln, ohne die digitalen Vermögenswerte zu verlieren, die den Dienst funktionsfähig machen. Sie gibt einem Käufer eine Möglichkeit zu fragen, ob ein KI-System sich in einen bestehenden Prozess einfügen kann, ohne ihn stillschweigend zu besitzen. Sie gibt einem kleineren Anbieter die Chance, an einer dokumentierten Grenze zu konkurrieren, statt an der Toleranz des Kunden für Migrationsschmerzen.

Der Punkt ist leicht misszuverstehen. Interoperabilität ist keine automatische Tugend. Eine schlecht gestaltete Schnittstelle kann eine schlechte Annahme schnell verbreiten. Ein gemeinsames Datenmodell kann zu breit, zu aufdringlich oder zu vage sein. Ein Standard kann zu einem Museumsstück werden. Eine offene API kann dennoch teuer, unsicher oder so schlecht dokumentiert sein, dass sie hauptsächlich als Beleg dafür dient, dass es einmal eine API-Abteilung gab. Europa braucht keinen dekorativen Haufen von Spezifikationen. Es braucht Verträge, die unter gewöhnlichen Bedingungen funktionieren, einschließlich Korrektur, Rücknahme, Aktualisierung, Unterbrechung und Weggang.

Das Gesetz für ein interoperables Europa liefert eine nützliche Definition für öffentliche Dienste. Es behandelt grenzüberschreitende Interoperabilität als die Fähigkeit von Unionsstellen und öffentlichen Stellen der Mitgliedstaaten, durch digitale Prozesse zu interagieren, die rechtliche, organisatorische, semantische und technische Anforderungen erfüllen, indem sie Daten, Informationen und Wissen austauschen. Die vier Wörter sind wichtig. Technische Kompatibilität ist nur eine Ebene. Zwei Dienste können Bytes austauschen und sich dennoch über Autorität, Zweck, Aufbewahrung oder die Bedeutung eines Status uneinig sein. Sie können ein Feld namens approved teilen, während das eine eine Vorprüfung und das andere eine endgültige rechtliche Entscheidung meint. Das Feld wandert. Die Entscheidung nicht.

Hier wird das Thema interessanter als Klempnerarbeit. Interoperabilität fragt, was wahr bleiben muss, wenn etwas eine Grenze überschreitet. Welche Organisation ist verantwortlich? Was ist die Informationseinheit? Wer kann sie ändern? Was passiert, wenn eine Quelle korrigiert wird? Was bedeutet ein fehlender Wert? Welche Identität wurde verifiziert? Wie lange darf der Empfänger sie aufbewahren? Kann ein anderes System nachweisen, welche Version es erhalten hat? Das sind öffentliche Fragen, kommerzielle Fragen und technische Fragen in einem Mantel.

KI macht den Mantel überfüllter. Ein KI-System kann sich zwischen Akten und Menschen setzen, Material aus mehreren Quellen abrufen, eine Modellversion anwenden, ein Werkzeug aufrufen, eine Handlung empfehlen und einen Entscheidungsnachweis hinterlassen. Wenn keiner dieser Übergaben ein definierter Vertrag zugrunde liegt, kann ein leistungsfähiges Modell eine Organisation eher unübersichtlicher als leistungsfähiger machen. Die Antwort mag überzeugend, aber nicht nachvollziehbar sein. Der Arbeitsablauf mag schneller erscheinen, wird aber abhängig von den privaten Nachrichtenformaten, dem privaten Agentenzustand und der privaten Definition einer Aufgabe eines einzelnen Anbieters. Das ist keine Intelligenz. Es ist ein Eigentümerwechsel, der in einer Komfortfunktion versteckt ist.

Das Argument für langweilige Interoperabilität ist nicht, dass sie Technologie langweilig macht. Es ist, dass sie Technologie rechenschaftspflichtig macht. Europa ist ungewöhnlich gut positioniert, um diesen Unterschied zu schätzen. Seine öffentlichen Dienste überschreiten Grenzen. Seine Sprachen und Verwaltungstraditionen widersetzen sich der Fantasie, dass ein einziges Vokabular einfach auferlegt werden kann. Seine Datenschutzregeln behandeln Zugang, Portabilität und Governance zunehmend als Bedingungen für einen funktionierenden Markt. Und seine Organisationen versuchen oft, KI zu Arbeit hinzuzufügen, die bereits Pflichten, Aufzeichnungen und Konsequenzen hat. Die Grenze ist wichtig, weil Menschen bereits auf beiden Seiten von ihr stehen.

Kompatibilität ist noch kein Verständnis

Es gibt mehrere Möglichkeiten, wie zwei Systeme kompatibel erscheinen können. Sie können dasselbe Netzwerkprotokoll verwenden. Sie können denselben Dateityp akzeptieren. Sie können sich mit demselben Identitätsschema authentifizieren. Sie können sogar denselben Konformitätstest bestehen. Jede dieser Möglichkeiten ist nützlich. Keine beantwortet die größere Frage: Kann das empfangende System die Informationen korrekt für den erklärten Zweck verwenden?

Nehmen wir ein bescheidenes, hypothetisches Beispiel. Eine regionale Behörde sendet einer Nachbarbehörde eine Mitteilung über eine gut dokumentierte Schnittstelle. Die Nutzlast ist gültig. Die Signatur wird verifiziert. Jedes erforderliche Feld ist vorhanden. Ein Feld enthält ein Datum. Das sendende System meint den Tag, an dem das zugrunde liegende Ereignis eingetreten ist. Das empfangende System behandelt es als den Tag, an dem die Mitteilung rechtlich wirksam wurde. Kein Paket ging verloren. Kein Server fiel aus. Die Systeme waren technisch kompatibel und semantisch falsch ausgerichtet. Das Ergebnis kann eine falsche Frist, ein unnötiger Einspruch oder eine Person sein, die gebeten wird, Arbeit zu wiederholen, die eine Maschine bereits ausgeführt hat.

Das Beispiel ist bewusst hypothetisch. Es braucht kein fiktives Rathaus oder einen Dienstagmorgen, um den Punkt zu machen. Viele schwierige digitale Fehler sind nicht dramatisch. Sie kommen als scheinbar vollständiger Datensatz mit einer unausgesprochenen Annahme. Ein Zeitstempel hat keine Zeitzone. Ein Wert ist leer, aber niemand sagt, ob leer unbekannt, zurückgehalten, nicht zutreffend oder noch nicht geprüft bedeutet. Eine Kennung ist innerhalb eines Systems stabil und wird in einem anderen wiederverwendet. Ein Einwilligungs-Flag reist ohne den Zweck, den Umfang und das Ablaufdatum, die es bedeutungsvoll machten. Die Integration läuft, bis jemand sich auf sie verlässt.

Semantische Interoperabilität ist die Disziplin, diese Bedeutungen explizit genug zu machen, um geteilt zu werden. Sie erfordert kein universelles Wörterbuch für alle menschlichen Angelegenheiten. Sie erfordert, dass die Teilnehmer eines definierten Austauschs sich darüber einigen, worauf sich ihre Begriffe beziehen, welche Einschränkungen gelten, welche Werte zulässig sind und wie Änderungen kommuniziert werden. In der Sprache der Normungsarbeit betrifft sie Datenmodelle, Vokabulare, Kennungen, Beziehungen und die Regeln, die es einem Empfänger ermöglichen, sie zu interpretieren. In der Sprache eines Betreibers ist es der Unterschied zwischen dem Empfang eines Datensatzes und dem Empfang von etwas, auf das er sicher reagieren kann.

ETSI’s Technical Committee on Data beschreibt seine Arbeit mit den Begriffen Daten-Governance, semantische Interoperabilität, Ontologien und regulatorische Angleichung, mit dem Ziel, Daten über Sektoren und Grenzen hinweg teilbar und wiederverwendbar zu machen. Diese Rahmung ist erfrischend unspektakulär. Sie lehnt die Vorstellung ab, dass Daten allein deshalb einen Wert haben, weil sie in einem Lake, einem Space oder einer Tabellenkalkulation mit einer respektablen Anzahl von Registerkarten abgelegt wurden. Daten werden wiederverwendbar, wenn die Bedingungen um sie herum hinreichend klar sind, damit eine andere Partei eine begrenzte, legitime Nutzung daraus machen kann.

Der europäische Data Act vertritt denselben Standpunkt aus einer anderen Richtung. Seine Interoperabilitätsbestimmungen betreffen Datenräume und Datenverarbeitungsdienste. Die Erläuterung der Kommission besagt, dass Standards und Interoperabilität von zentraler Bedeutung sind, um Daten aus verschiedenen Quellen innerhalb und zwischen gemeinsamen europäischen Datenräumen zu nutzen und den Wechsel zwischen Datenverarbeitungsdiensten zu erleichtern. Das ist kein Versprechen, dass jedes System plötzlich jedes andere System verstehen wird. Es ist eine politische Anerkennung, dass ein Markt isolierter Dienste den Kunden weniger praktische Wahlmöglichkeiten lässt.

Es ist verlockend, bei „semantisch“ an eine große Ontologie zu denken, an ein Diagramm, das groß genug ist, um eine eigene Postanschrift zu benötigen. Manchmal braucht eine Domäne eine umfangreiche gemeinsame Modellierung. Aber der bessere Ausgangspunkt ist kleiner. Was ist das Objekt in diesem Austausch? Welche Version wird gesendet? Welche Organisation besitzt den maßgeblichen Wert? Welches Ereignis kann ihn verändern? Was muss der Empfänger tun, wenn dieses Ereignis eintritt? Welche Nutzung ist zulässig? Wie kann eine Person die Antwort prüfen, wenn der automatisierte Weg unsicher ist? Ein enger, beantwortbarer Vertrag ist wertvoller als ein umfassendes Diagramm, das niemand implementieren kann.

Dieselbe Zurückhaltung gilt für KI. Ein KI-Workflow muss möglicherweise ein Arbeitselement an ein Modell übergeben, einen vorgeschlagenen Klassifizierungsvorschlag erhalten, Quellen anhängen, eine Genehmigung einholen und die Entscheidung in ein Fallsystem schreiben. Er sollte nicht so tun, als sei eine Erklärung in natürlicher Sprache eine ausreichende Schnittstelle. Der Workflow benötigt typisierte Fakten ebenso wie Wörter: die Kennung des Arbeitselements, die Quellversionen, die deklarierte Aufgabe, die zulässigen Werkzeuge, die Konfidenz- oder Verweigerungsbedingung, sofern relevant, die Entscheidung des Prüfers, den Zeitpunkt und die Richtlinienversion. Das Modell kann probabilistisch bleiben. Die Grenze um das Modell sollte nicht aus Gewohnheit vage sein.

Deshalb ist Interoperabilität nicht dasselbe wie Integration. Eine Integration kann eine private Verbindung sein, die für eine einzige Beziehung aufgebaut wurde. Sie kann durchaus angemessen sein. Aber wenn ihre Semantik nur in der Implementierung eines Anbieters, im Gedächtnis eines Mitarbeiters oder in einer Präsentation aus einem Workshop lebt, lässt sich die Verbindung nicht gut übertragen. Eine interoperable Grenze hinterlässt einen Vertrag, den eine andere kompetente Partei lesen, testen und in Frage stellen kann. Sie ist langsamer aufzubauen als ein schneller Konnektor. Sie ist schneller zu reparieren, wenn der ursprüngliche Konnektor zu einer Abhängigkeit mit einem Logo geworden ist.

Der europäische Rahmen beginnt mit dem gesamten Problem

Der Interoperable Europe Act ist kein KI-Gesetz, und es wäre ein Fehler, ihn als eines darzustellen. Er ist eine Verordnung für die grenzüberschreitende Interoperabilität des öffentlichen Sektors. Sein Wert für KI ist grundlegender. Er beschreibt eine Denkweise über digitale öffentliche Dienste, bevor eine bestimmte Technologie in ihre Mitte gestellt wird.

Gemäß der Verordnung müssen Unionsstellen und öffentliche Stellen im Anwendungsbereich vor der Entscheidung über neue oder wesentlich geänderte verbindliche Anforderungen eine Interoperabilitätsbewertung durchführen. Die Bewertung identifiziert und bewertet Auswirkungen auf die grenzüberschreitende Interoperabilität, relevante Interessenträger und die Lösungen von Interoperable Europe, die die Umsetzung unterstützen können. Der daraus resultierende Bericht ist in einem maschinenlesbaren Format zu veröffentlichen, das die automatisierte Übersetzung erleichtert, vorbehaltlich der Schutzbestimmungen der Verordnung für geistiges Eigentum, Geschäftsgeheimnisse, öffentliche Ordnung und Sicherheit.

Das ist anspruchsvoller, als zu fragen, ob ein vorgeschlagenes System eine API hat. Eine API kann technisch sauber sein und trotzdem eine Hürde für eine Nachbarverwaltung, eine Bürgerin oder einen Bürger, ein kleines Unternehmen oder eine andere öffentliche Einrichtung darstellen. Die Bewertung stellt eine andere Frage: Was ändert sich an der Fähigkeit zur Interaktion, wenn diese Anforderung eingeführt wird? Das schafft Raum dafür, dass rechtliche Befugnis, organisatorische Verantwortung, semantische Bedeutung und technisches Design im selben Gespräch auftauchen. Sie waren schon immer Teil desselben Gesprächs. Der Software war lediglich gestattet worden, das Treffen in getrennten Räumen abzuhalten.

Die Verordnung macht das Teilen auch konkret. Artikel 4 verlangt, dass eine Unionseinrichtung oder eine öffentliche Einrichtung einer anderen solchen Einrichtung auf Anfrage eine Interoperabilitätslösung zur Verfügung stellt, die einen transeuropäischen digitalen öffentlichen Dienst unterstützt, einschließlich technischer Dokumentation und, sofern zutreffend, Versionshistorie, dokumentiertem Quellcode und Verweisen auf offene Standards oder technische Spezifikationen. Es gibt Ausnahmen, darunter Rechte des geistigen Eigentums Dritter und Tätigkeiten außerhalb des öffentlichen Auftrags. Das Prinzip ist nicht, dass jede Zeile öffentlicher Software ohne Urteil veröffentlicht werden muss. Das Prinzip ist, dass eine wiederverwendbare Lösung nicht jedes Mal zu einer privaten Entdeckung werden sollte, wenn eine andere Verwaltung sie benötigt.

In dieser Formulierung steckt eine leise Verschiebung. Dokumentation und Versionshistorie sind kein nachrangiger Papierkram, nachdem die nützliche Komponente hergestellt wurde. Sie sind Teil dessen, was die Komponente wiederverwendbar macht. Ein Quellcode-Repository ohne Kontext kann so wenig hilfreich sein wie ein Koffer ohne Schlüssel. Eine Referenzarchitektur ohne Erläuterung der Annahmen kann zu einer sehr gepflegten Art werden, Verwirrung zu exportieren. Das Wiederverwendbare sind der Code, die Spezifikation, die bekannten Grenzen, die Version, der Nachweis darüber, wie sie verwendet werden sollte, und die Bedingungen, unter denen sie nicht verwendet werden sollte.

Das Europäische Interoperabilitätsrahmenwerk, das das Gesetz in den Mittelpunkt seines Bewertungsmodells stellt, befasst sich ebenfalls mit rechtlicher, organisatorischer, semantischer und technischer Interoperabilität und Governance. Diese Vier-Ebenen-Sicht ist nützlich, weil sie verhindert, dass eine Art von Erfolg das Gesamtergebnis vortäuscht. Ein technisches Team kann eine Schnittstelle erfolgreich implementieren. Ein Rechtsteam kann kein Hindernis für den Austausch finden. Ein Betriebsteam kann sich auf Eskalation einigen. Ein Fachteam kann die Bedeutung der Objekte angleichen. Das System wird an der Grenze nur dann zuverlässig, wenn die relevanten Ebenen für die jeweilige Nutzung ausgerichtet sind.

Das ist auch der Grund, warum ein „europäischer Standard“ kein Zauberwort ist. Standards können unnötige Vielfalt verringern und einen Vertrag mehr Teilnehmern zugänglich machen. Sie können nicht entscheiden, ob ein bestimmter Austausch verhältnismäßig, rechtmäßig, sicher oder nützlich ist. Ein technisches Profil muss ausgewählt, implementiert, verwaltet und überprüft werden. Es braucht eine Versionsrichtlinie. Es braucht Fehlerbehandlung. Es braucht eine Möglichkeit, Unsicherheit darzustellen. Es braucht einen Prozess, um zu entscheiden, wann eine lokale Erweiterung gerechtfertigt ist und wann sie zu einem privaten Fork im öffentlichen Gewand geworden ist.

Der Fall des öffentlichen Sektors ist besonders aufschlussreich, weil die Kosten semantischer Abweichungen oft von jemandem außerhalb des technischen Teams getragen werden. Eine Einwohnerin oder ein Einwohner kann aufgefordert werden, Informationen zweimal einzureichen. Ein Unternehmen muss möglicherweise ein Formular von einer Verwaltungssprache in eine andere übersetzen. Eine Fachkraft kann Zeit verlieren, wenn sie Aufzeichnungen abgleicht. Ein grenzüberschreitender Dienst funktioniert möglicherweise nur für Personen, deren Fall zufällig auf den einfachsten Weg passt. Das Gesetz garantiert nicht, dass diese Ergebnisse verschwinden. Es schafft Mechanismen, um ihre Interoperabilitätsfolgen sichtbar zu machen, bevor eine Anforderung zu Infrastruktur verhärtet.

KI sollte diese Disziplin übernehmen. Bevor ein Modell zu einem transeuropäischen oder anderweitig folgenreichen Dienst hinzugefügt wird, sollte der Betreiber angeben können, welche Objekte das Modell lesen kann, welche Objekte es erstellen kann, welche Entscheidungen menschlich bleiben, wie sich eine Korrektur ausbreitet, welche Ausgabe eine Hilfe und kein maßgeblicher Datensatz ist, wie sich der Dienst verhält, wenn das Modell nicht verfügbar ist, und wie ein Empfänger das Ergebnis anfechten oder einsehen kann. Das ist keine zusätzliche Compliance-Ebene, die über ein ansonsten vollständiges Produkt gestülpt wird. Es ist die Schnittstellendefinition eines Systems, das von Menschen Vertrauen erwartet, die den privaten Kontext des Modells nicht teilen.

Bewegen Sie den Mauszeiger über eine Ebene und wählen Sie sie aus. Eine Grenze hält nur, wenn die relevanten Ebenen sich darüber einig sind, was geschehen muss.

Portabilität ist ein Test dafür, ob die Grenze real ist

Interoperabilität wird strategisch, wenn sich eine Beziehung ändert. Ein Dienst wird aktualisiert. Ein Anbieter wird ersetzt. Eine öffentliche Stelle muss eine Komponente wiederverwenden. Ein Teilnehmer eines Datenraums ändert seine Richtlinie. Ein Modellanbieter ändert sein Nachrichtenformat. Eine neue Sicherheitsbedingung bedeutet, dass eine Arbeitslast woanders ausgeführt werden muss. An diesem Punkt wird die Qualität der Grenze sichtbar.

Der Data Act behandelt dies als mehr als eine Unannehmlichkeit für Kunden. Seine Regeln zum Wechsel und zur Interoperabilität von Datenverarbeitungsdiensten sollen Hindernisse für den Wechsel zwischen Diensten, die parallele Nutzung mehrerer Dienste und die Portabilität von Daten und Anwendungen verringern. Die Studie der Kommission von 2026 zur Interoperabilität von Datenverarbeitungsdiensten beschreibt Artikel 35 als Aufruf zu offenen, harmonisierten Spezifikationen, die es Diensten desselben Typs ermöglichen, zusammenzuarbeiten, und Daten und Anwendungen portabel machen, ohne die Sicherheit zu beeinträchtigen. Sie weist auch auf das geplante Unionsverzeichnis für relevante Normen und offene Spezifikationen hin sowie auf die Möglichkeit gemeinsamer Spezifikationen, wenn harmonisierte Normen nicht ausreichen.

Es lohnt sich, genau zu sein, was dies bedeutet und was nicht. Der Data Act verspricht nicht, dass ein Kunde einen komplexen Dienst von einem Anbieter nehmen und ihn am Freitagnachmittag unverändert bei einem anderen platzieren kann. Er verlangt nicht, dass Anbieter Geschäftsgeheimnisse preisgeben, die Sicherheit gefährden oder alle Diensttypen identisch machen. Funktionale Äquivalenz, wo die Verordnung sie für Dienste desselben Typs verlangt, ist kein Anspruch auf identische Konsolen, identische Preismodelle oder identische technische Entscheidungen. Es ist eine nützlichere und bescheidenere Idee: Gemeinsame Funktionen sollten es ermöglichen, dass die Arbeitslast des Kunden ihre beabsichtigte Funktion über eine relevante Grenze hinweg fortsetzt.

Diese Unterscheidung ist wichtig, weil eine portable Datei nicht unbedingt ein portabler Dienst ist. Ein Datencxport kann Beziehungen, Ereignisreihenfolge, Konfiguration, Berechtigungsverlauf, Kennungen, Aufbewahrungsstatus, Richtlinienversionen und das operative Wissen, das zur Wiederherstellung des Systems erforderlich ist, auslassen. Eine Modellausgabe kann exportiert werden, während die Abrufkonfiguration, die Prompt-Version, die Bewertungskriterien und die Tool-Berechtigungen, die sie geprägt haben, privat bleiben. Die Datei ist umgezogen. Die Bedingungen, unter denen ihr vertraut werden konnte, sind es nicht.

Der richtige Test ist nicht „Können wir etwas herunterladen?“ Es ist „Kann ein kompetentes Ziel den Teil des Dienstes interpretieren und betreiben, der wichtig ist?“ Das sind unterschiedliche Fragen. Die erste kann mit einem Knopf beantwortet werden. Die zweite erfordert ein Inventar, ein Schema, einen Empfangspfad, einen Test, Menschen, die die Grenze verstehen, und eine ehrliche Aussage darüber, was nicht mitwandern kann.

Betrachten wir ein weiteres ausdrücklich hypothetisches Beispiel. Ein Team nutzt einen KI-Dienst, um einen ersten Entwurf zur internen Prüfung zu erstellen. Der Dienst verfügt über eine Exportfunktion. Bei einem geplanten Umzug erhält das Team den generierten Text und eine Liste von Benutzerkonten. Es erhält nicht die Versionen der Wissensquellen, die Entscheidungsprotokolle, die festlegten, welche Quellen zulässig waren, den Genehmigungsstatus der Entwürfe, die Modellkonfiguration oder die Regeln, die verhinderten, dass der Dienst einen Entwurf an einen externen Empfänger sendete. Das Team hat seinen Text. Es hat seinen Workflow nicht wiederhergestellt. Wäre der alte Dienst ein Dokumenteneditor, wäre das vielleicht hinnehmbar. Wenn die Entwürfe regulierte oder sicherheitsrelevante Arbeit prägen, handelt es sich um eine andere Kategorie von Problem.

Portabilität hat daher mindestens vier Ebenen. Es gibt technische Portabilität: Können die Daten und Schnittstellen in nutzbaren Formen übertragen werden? Es gibt semantische Portabilität: Kann der Empfänger die Aufzeichnungen, Ereignisse und Einschränkungen verstehen? Es gibt operative Portabilität: Können Menschen die Arbeitslast ausführen, sichern, überwachen, korrigieren und wiederherstellen? Und es gibt institutionelle Portabilität: Kann die Organisation ihre öffentlichen, vertraglichen und rechtlichen Pflichten erfüllen, während der Umzug stattfindet? Kein einzelnes Exportformat klärt alle vier.

Hier kann Beschaffung zu einer konstruktiven Kraft werden. Eine Ausschreibung kann nach den Kategorien exportierbarer Daten und digitaler Assets fragen, nach Schemata und Versionen, Ratenbegrenzungen, Integritätsprüfungen, Auswirkungen auf Identität und Zugriff, bekannten Einschränkungen, Aufbewahrungs- und Löschverhalten sowie nach der Unterstützung, die während eines Übergangs verfügbar ist. Sie kann fragen, ob ein repräsentativer Export von einem Zielsystem ohne privaten Zugriff auf die Konsole des Anbieters empfangen und validiert werden kann. Sie kann fragen, welche Teile konstruktionsbedingt anbieterspezifisch sind. Eine offene Einschränkung ist beherrschbar. Eine versteckte Einschränkung wird zu einem Notfallbudget.

Dieselben Fragen helfen einem Anbieter. Ein Anbieter, der weiß, welche Grenze er stabil halten muss, kann weniger versehentliche Abhängigkeiten entwerfen. Er kann eine Versionsrichtlinie explizit machen. Er kann einen Abkündigungspfad veröffentlichen. Er kann Kunden eine Testumgebung geben, die sich wie eine echte Schnittstelle verhält und nicht wie eine Marketing-Demo. Er kann den Teil eines Systems, der wirklich proprietär ist, von dem Teil unterscheiden, der geteilt werden muss, damit ein Kunde Handlungsfähigkeit behält. Das ist keine Wohltätigkeit. Es ist ein klarerer Vertrag für beide Seiten.

Europas Vorteil liegt hier nicht darin, dass es Abhängigkeit beseitigen kann. Ernsthafte Systeme haben Abhängigkeiten. Der Vorteil ist die Möglichkeit, Abhängigkeit lesbar, verhandelbar und für den jeweiligen Verwendungszweck ausreichend umkehrbar zu machen. Ein System, das bei einem Anbieter bleiben kann, weil es die Beziehung weiterhin verdient, ist stärker als eines, das bleibt, weil niemand andernorts die Bedeutung seiner Aufzeichnungen rekonstruieren kann.

Datenräume sind keine Lagerhallen mit besserer Beleuchtung

Der Begriff „Datenraum“ kann ein falsches Bild erzeugen. Er suggeriert einen großen Raum, in dem alle Daten bringen, sie auf ein Regal stellen und mit der Interoperabilität zufrieden nach Hause gehen. Der europäische Ansatz ist anspruchsvoller. Gemeinsame europäische Datenräume sollen Daten für den Zugriff und die Weiterverwendung in einer vertrauenswürdigen und sicheren Umgebung verfügbar machen. Die Kommission beschreibt gemeinsame Infrastrukturen und Governance-Rahmen als die Dinge, die Bündelung, Zugriff und Austausch unterstützen, neben fairen, transparenten, verhältnismäßigen und nicht diskriminierenden Zugriffsregeln.

Das ist eine wichtige Korrektur. Datenaustausch ist kein einmaliger Übertragungsakt. Es ist eine fortlaufende Beziehung zwischen Parteien mit unterschiedlichen Zwecken, Befugnissen und Verantwortlichkeiten. Ein Teilnehmer darf einen Datensatz möglicherweise für Forschung, aber nicht für Marketing nutzen. Ein anderer kann die Pflicht haben, einen Wert zu korrigieren. Ein Dritter darf möglicherweise ein abgeleitetes Ergebnis erhalten, nicht aber den zugrunde liegenden Datensatz. Manche Daten müssen aufbewahrt werden. Manche müssen gelöscht werden. Manche dürfen nur in einer bestimmten Umgebung verarbeitet werden. Die maßgeblichen Bedingungen sind Teil der Interoperabilität, nicht eine Fußnote in einem separaten Rechtsordner.

Die Arbeit der Kommission zu Datenräumen identifiziert Unterstützung in Referenzarchitektur, Bausteinen, Semantik, Interoperabilitätsspezifikationen und Datenmodellen sowie Beratungsdienste über das Data Spaces Support Centre. Diese Breite ist sinnvoll. Ein sicherer Connector ohne gemeinsames Vokabular löst kein semantisches Problem. Ein gemeinsames Vokabular ohne Identität, Zugriffskontrolle oder Governance löst kein Vertrauensproblem. Ein Modell, das einen Datenraum abfragen kann, ohne erklärten Zweck, Quelldatensatz und Korrekturpfad, macht den Raum nicht nutzbarer. Es schafft einen neuen Informationskonsumenten, dessen Pflichten unklar sind.

Für KI ist die Implikation eindeutig. Ein Modell sollte nicht als privilegierte Abkürzung um eine Datenraumgrenze herum behandelt werden. Wenn eine Person oder ein Dienst eine Zugriffsgrundlage, einen definierten Zweck, eine Identität und eine Nutzungsaufzeichnung benötigt, braucht ein KI-Workflow dieselbe Disziplin. Es mag technische Unterschiede geben, wie ein Agent Daten anfordert oder wie ein Abrufschritt ausgeführt wird. Es sollte keine magische Ausnahme geben, in der das System sagt „das Modell brauchte Kontext“ und die üblichen Governance-Regeln das Feld räumen.

Das bedeutet nicht, dass jede Anfrage in eine bürokratische Zeremonie verwandelt werden muss. Es bedeutet, dass das System zwischen einer Frage und einer Autorisierung unterscheiden muss. Ein Modell kann eine Abfrage formulieren. Eine politikbewusste Schicht sollte entscheiden, ob die Abfrage eine bestimmte Quelle erreichen darf, unter welchem Zweck, mit welcher Minimierung und wie Anfrage und Ergebnis aufgezeichnet werden. Eine Antwort kann dann eine Quelle zitieren oder eine Einschränkung erläutern. Wenn sich die Quelle ändert, braucht das System einen Weg zu wissen, welche spätere Antwort oder Entscheidung möglicherweise überprüft werden muss. Sonst wird Provenienz zu einem dekorativen Link in einem Chatprotokoll.

Semantische Verträge sind hier besonders nützlich, weil sie die kleinste Vertrauenseinheit sichtbar machen. Eine Quellkennung ist nicht bloß eine Zeichenkette. Sie sollte eine Version oder eine stabile Referenz identifizieren. Eine Berechtigung ist nicht bloß wahr oder falsch. Sie kann einen Umfang, einen Zweck, einen Inhaber, eine Zeitbegrenzung und eine Grundlage haben. Eine Korrektur ist nicht bloß ein Update. Sie kann eine frühere Angabe ersetzen und dabei die Historie bewahren, die erklärt, was geschehen ist. Eine Ablehnung ist nicht bloß ein Fehler. Sie kann eine bewusste Grenze sein, die für die fragende Person verständlich sein muss.

Die Versuchung wird sein, dies mit einer universellen „KI-Interoperabilitätsschicht“ zu lösen, die behauptet, jeden Agenten, jedes Modell, jede Datenbank und jedes Workflow-Tool austauschbar zu machen. Eine solche Behauptung verwechselt üblicherweise gemeinsamen Transport mit gemeinsamer Bedeutung. Ein generisches Protokoll kann nützlich sein. Es kann einem Empfänger nicht sagen, was ein klinischer Code, ein Planungsstatus, eine Leistungsentscheidung oder ein Risikokennzeichen in der jeweiligen Domäne bedeutet. Es kann nicht entscheiden, wer einen automatisierten Vorschlag überstimmen darf. Es kann einer Organisation nicht sagen, wie lange sie einen abgerufenen Datensatz aufbewahren darf. Standards tragen Vereinbarungen. Sie heben die Notwendigkeit nicht auf, sie zu treffen.

Es gibt eine bodenständigere Ambition. Baut domänenspezifische Vereinbarungen dort, wo die gemeinsame Arbeit sie rechtfertigt. Nutzt allgemeine Bausteine dort, wo sie wirklich passen: Identität, Autorisierung, Herkunft, Ereignisbehandlung, Versionierung, Konformitätstests und zugängliche Dokumentation. Haltet die Verbindung zwischen einem allgemeinen Standard und einer lokalen Implementierung nachvollziehbar. Dann kann ein Teilnehmer beitreten, ohne sein gesamtes System aufzugeben, und ein Sektor kann sich weiterentwickeln, ohne bei jedem neuen Anbieter auf einem leeren Blatt zu beginnen.

Das ist eine bessere Vorstellung von Skalierung. Sie misst Erfolg nicht daran, wie viele Daten zentralisiert oder wie viele Dienste in eine einzige Schnittstelle gezwungen wurden. Sie misst Erfolg daran, ob ein legitimer Austausch mit ausreichender Klarheit stattfinden kann, sodass die Teilnehmer ihn nutzen, korrigieren, steuern und, wenn nötig, beenden können.

Wählt eine Karte aus, um den Teil eines Austauschs zu untersuchen, der einen Datensatz über sein ursprüngliches System hinaus nutzbar macht.

Standards brauchen ein Leben nach der Veröffentlichung

Standards werden oft so beschrieben, als ende ihre Arbeit mit der Veröffentlichung des Dokuments. In der Praxis ist die Veröffentlichung der Moment, in dem die schwierigere Arbeit beginnt. Jemand muss das anwendbare Profil auswählen. Jemand muss es implementieren. Jemand muss Randfälle testen. Jemand muss entscheiden, ob eine neue Version kompatibel ist, wann die alte Version ausläuft und was mit Datensätzen passiert, die nach früheren Regeln erstellt wurden. Jemand muss das gesamte Arrangement einem Team erklären, das nicht im Raum war, als das Akronym ausgewählt wurde.

Die EN 18235-1:2026 von CEN und CENELEC ist ein aktuelles Beispiel für diese Entwicklung. Der Standard befasst sich mit dem Datenaustausch zwischen Organisationen, mit Schwerpunkt auf Interoperabilität und Rechenschaftspflicht, und zu den angekündigten Anwendungen gehören die Common European Data Spaces. Das Detail ist hier weniger wichtig als das Signal. Vertrauen in den Datenaustausch wird nicht als ein Gefühl behandelt, das von einem Dashboard erzeugt wird. Es wird als etwas behandelt, das durch Vereinbarungen über Austausch, Verantwortung und die Fähigkeit, Rechenschaft über das Geschehene abzulegen, geprägt wird.

Die beste Standardsarbeit lässt Raum für die Dinge, die sie nicht klären kann. Eine technische Spezifikation kann eine Nachrichtenstruktur definieren. Sie kann keine lokale Rechtsgrundlage festlegen. Ein Vokabular kann ein Konzept definieren. Es kann nicht garantieren, dass ein lokaler Prozess das Konzept ehrlich verwendet. Ein Konformitätstest kann zeigen, dass eine Implementierung benannte Fälle erfüllt. Er kann nicht beweisen, dass die Organisation die Personen geschult hat, die Ausnahmen bearbeiten. Das Gegenteil zu behaupten, tut Standards einen Bärendienst. Es lässt sie wie einen Ersatz für Urteilsvermögen aussehen, statt wie ein Werkzeug, das Urteilsvermögen weiter tragen lässt.

Konformitätstests sind besonders wertvoll, weil sie Interoperabilität von einem Versprechen in eine beobachtbare Eigenschaft verwandeln. Ein Anbieter kann sagen, dass er ein Profil unterstützt. Ein Käufer sollte fragen können, welche Version, welche optionalen Funktionen, welche Negativfälle, welche Fehlerantworten und welche veröffentlichten Testergebnisse diese Aussage stützen. Ein Implementierer sollte dieselben Fälle ausführen können, bevor eine Integration in Produktion geht. Eine Änderung sollte erklären, ob sie abwärtskompatibel ist und welche Verbraucher handeln müssen.

Bei KI-Schnittstellen mag das bis zur ersten inkompatiblen Änderung übertrieben wirken. Ein Tool-Aufruf erwartet einen Geldbetrag in Cent. Ein anderer gibt eine Dezimalzeichenfolge ohne Währung zurück. Ein Agent behandelt ein fehlendes Feld als Aufforderung, weitere Informationen anzufordern. Ein anderer interpretiert es als Erlaubnis, einen Wert abzuleiten. Eine Modellaktualisierung ändert die Struktur von Zitaten. Ein nachgelagerter Prozess parst weiterhin die alte Form. Keines davon ist ein philosophisches Rätsel. Es sind gewöhnliche Schnittstellenfehler, die durch ein System, das schnell handeln kann, folgenschwerer werden.

Ein guter Vertrag enthält daher sowohl Ablehnung als auch Erfolg. Er legt fest, was das System ablehnt, was es zurückgibt, wenn eine Quelle nicht verifiziert werden kann, was es tut, wenn eine Richtlinie fehlt, wie der Empfänger partielle von vollständigen Daten unterscheiden kann und wo die menschliche Prüfung beginnt. Schweigen ist eine schlechte Interoperabilitätsstrategie. Eine klare Ablehnung ist oft die kompatibelste Antwort, weil sie dem nächsten System einen ehrlichen Zustand zum Arbeiten bietet.

Versionierung verdient denselben Respekt. Eine nützliche Schnittstelle hängt nicht einfach eine Versionsnummer an eine URL und hofft auf das Beste. Sie erklärt die Änderung, nennt den Migrationspfad, bewahrt den alten Vertrag nach Möglichkeit für den zugesagten Zeitraum, dokumentiert, wie gespeicherte Daten über Versionen hinweg interpretiert werden, und gibt abhängigen Systemen genügend Vorlauf, um sich anzupassen. Das ist keine aufregende Arbeit. So hört eine Grenze auf, eine Überraschung zu sein. In den Niederlanden sagt man gern, dass eine Sache „klar genug“ sei, bis jemand sie bauen muss. Die Versionsrichtlinie ist das, was übrig bleibt, nachdem dieser Ausdruck auf ein Produktionssystem getroffen ist.

Hier gibt es einen europäischen wirtschaftlichen Aspekt. Kleinere Organisationen können teilnehmen, wenn die Regeln der Verbindung öffentlich, dokumentiert und testbar sind. Sie brauchen keine private Beziehung zu jeder dominanten Plattform, nur um herauszufinden, wie sich ein Austausch verhält. Auch größere Organisationen profitieren, weil sie individuellen Integrationsaufwand reduzieren und die Behauptungen eines Anbieters testen können, bevor sich eine zentrale Abhängigkeit bildet. Das Ergebnis ist nicht reibungslos. Es ist fairere Reibung: Die Arbeit ist sichtbar, bepreist und geteilt, statt entdeckt zu werden, nachdem der Vertrag die Optionen eingeschränkt hat.

Die praktische Frage ist, was die Übergabe übersteht

Die meisten Interoperabilitätsprogramme werden besser, wenn sie mit einem kleinen Austausch beginnen statt mit einer großen Vision. Wählen Sie eine Entscheidungs- oder Dienstleistungsgrenze. Beschreiben Sie die Informationen, die sie überqueren müssen. Benennen Sie die Autoritätsquelle, den Empfänger, den zulässigen Zweck, das Vokabular, die Lebenszyklusereignisse, die Sicherheitsbedingungen und die Nachweise, die zeigen, dass der Austausch wie beabsichtigt stattgefunden hat. Testen Sie dann sowohl Erfolg als auch Misserfolg.

Das daraus entstehende Gespräch ist oft aufschlussreicher als ein Funktionsvergleich. Was passiert, wenn die Quelle einen Datensatz korrigiert? Kann der Empfänger erkennen, welche Kopie betroffen ist? Was passiert, wenn ein KI-System eine Empfehlung nicht mit einer zulässigen Quelle belegen kann? Gibt es eine explizite Ablehnung, ein Teilergebnis oder eine erfundene Konfidenz zurück? Was passiert, wenn ein Empfänger eine Schema-Version erhält, die es nicht versteht? Kann es den Austausch sicher ablehnen? Was passiert, wenn eine Person eine Klassifizierung anficht? Wird die Korrektur zu einem neuen Ereignis mit einer Spur, oder wird das alte Ergebnis überschrieben, bis niemand mehr die Grundlage der ursprünglichen Aktion rekonstruieren kann?

Das sind Designfragen, nicht nur Compliance-Fragen. Sie bestimmen, ob Menschen einen Dienst betreiben können, ob ein Anbieter ihn unterstützen kann und ob ein anderes System beitreten kann, ohne ein undokumentiertes Risiko zu übernehmen. Sie prägen auch die Qualität von KI. Ein Modell mit einer klaren Informationsgrenze hat weniger Raum, mehrdeutigen Kontext in unsichtbare Annahmen zu verwandeln. Ein Workflow mit typisierten Ausgaben und Quellenidentität gibt Prüfern etwas Konkretes, das sie untersuchen können. Ein versionierter Entscheidungsdatensatz macht die Bewertung möglich, nachdem sich Modell, Prompt oder Richtlinie geändert haben.

Es gibt vernünftige Grenzen. Manche Daten sollten nicht weitergegeben werden. Manche Informationen sollten minimiert oder aggregiert werden. Manche Dienste benötigen eine maßgeschneiderte Grenze, weil die Arbeit ungewöhnlich, sensibel oder mit hohem Risiko verbunden ist. Manche lokale Begriffe sollten lokal bleiben, weil eine erzwungene falsche Gleichsetzung die Bedeutung zerstören würde. Interoperabilität ist keine Forderung, dass jedes System alles offenlegt. Es ist eine Forderung, dass die gewählte Grenze ehrlich darüber Auskunft gibt, was sie offenlegt, warum, gegenüber wem und mit welchen Konsequenzen.

Diese Ehrlichkeit ist besonders wichtig, wenn KI-Anbieter eine schnelle Anbindung anbieten. Ein Konnektor, der stillschweigend einen großen Datenbestand in einen Modellkontext kopiert, mag ein Demonstrationsproblem lösen, während er ein Governance-Problem schafft. Ein Werkzeug, das ohne dauerhafte Arbeitskennung in ein Geschäftssystem schreibt, mag eine Automatisierung schaffen, während es die Möglichkeit zur Prüfung zerstört. Ein universelles Agentenprotokoll mag die Auffindbarkeit erleichtern, während Autorisierung, Zweckbindung und semantische Verantwortung ungeklärt bleiben. Die Frage sollte immer sein, was die Übergabe übersteht: die Daten, die Bedeutung, die Berechtigung, die Nachweise und die Möglichkeit zur Korrektur.

Ein brauchbares Programm gibt jedem dieser Aspekte einen Ort. Daten benötigen ein Format und eine Integritätsprüfung. Bedeutung benötigt ein Modell, ein Vokabular oder eine explizite Zuordnung. Berechtigung benötigt eine Identität, einen Zweck und eine Richtlinienabgrenzung. Nachweise benötigen eine Aufzeichnung von Quelle, Version, Transformation und Entscheidung. Korrektur benötigt einen Ereignispfad und eine verantwortliche Stelle. Betrieb benötigt ein Runbook, Beobachtbarkeit und eine Möglichkeit, eine Änderung zu stoppen oder zurückzurollen. Nichts davon ergibt einen heroischen Startfilm. Es macht es aber möglich, dass ein System nützlich bleibt, nachdem der Startfilm durch ein Support-Ticket ersetzt wurde.

Bei Dweve wenden wir das Prinzip in der öffentlichen Beschreibung von Fabric eng an. Die Website beschreibt ein arbeitszentriertes Objektmodell, in dem Modelle, Agenten, Werkzeuge, Personen und Arbeitsabläufe über typisierte Verträge teilnehmen, und sie beschreibt Benutzeroberflächen und APIs, die auf derselben Domäne arbeiten. Das ist eine Produktdesign-Position, kein Beleg dafür, dass eine Bereitstellung automatisch interoperabel ist oder dass eine typisierte Schnittstelle rechtliche, semantische oder betriebliche Fragen klärt. Es ist schlicht die Art von Grenze, die wir für ernsthafte KI-Systeme für notwendig halten: eine, in der die dauerhafte Arbeit nicht in einem anbieterspezifischen Gespräch verschwindet.

HEDL bietet ein kleineres, öffentliches Beispiel. Seine Dokumentation beschreibt ein unter Apache 2.0 lizenziertes Textformat, eine veröffentlichte Formatspezifikation und Konformitätsdokumente, mit Konvertierungen von und nach JSON, YAML, XML, CSV, Parquet und TOON. Diese Funktionen machen nicht jeden Datensatz kompatibel, und sie machen aus einer Formatumwandlung keine semantische Übereinstimmung. Sie machen aber eine nützliche Aussage über eine Grenze: Ein Austauschformat sollte prüfbar, testbar und in der Lage sein, neben bestehenden Systemen zu bestehen, statt zu verlangen, dass jedes System sein eigener privater Dialekt wird.

Europa muss kein KI-Rennen gewinnen, indem es vor seinen eigenen Institutionen davonläuft. Seine Chance besteht darin, diese Institutionen, Märkte und technischen Gemeinschaften leichter miteinander zu verbinden, ohne so zu tun, als spielten ihre Unterschiede keine Rolle. Die Arbeit wirkt aus der Ferne langweilig. Sie besteht aus Versionsverläufen, Testvorlagen, Vokabularentscheidungen, Zugriffsregeln, Migrationsübungen und dem gelegentlichen unangenehmen Gespräch darüber, wer ein Feld ändern darf. Aus der Nähe betrachtet ist es die Arbeit, die es einem System ermöglicht, von jemand anderem vertraut zu werden als von dem Team, das es gebaut hat.

Das ist ein Vorteil, den es zu haben lohnt. Ein Modell kann ersetzt werden. Ein Anbieter kann gewechselt werden. Ein Dienst kann eine Grenze überschreiten. Eine Korrektur kann den Ort erreichen, an dem sie zählt. Eine Person kann fragen, was passiert ist, und etwas Besseres erhalten als einen selbstbewussten Absatz. Die Technologie bleibt ambitioniert. Die Grenze bleibt gewöhnlich. Das Gewöhnliche ist das, was dem Ehrgeiz einen verlässlichen Standort gibt.

Quellen