- AI-Software braucht mehr als nur das Aufrufen von Modellen: Sie benötigt betriebssystemähnliche Eigenschaften wie Sicherheit, Isolation, Skalierbarkeit und Portabilität. Dafür wird das Konzept einer virtuellen Maschine speziell für AI-Modelle (MVM) vorgeschlagen.
- So wie die Java Virtual Machine (JVM) Speichersicherheit und „einmal schreiben, überall ausführen“ ermöglicht hat, gewährleistet eine AI-VM durch die Trennung von Modell und Integrationslogik Austauschbarkeit und Interoperabilität.
- Die VM definiert einen standardisierten Befehlssatz für Modellaufrufe, Tool-Aufrufe, Ergebnisspeicherung, Benutzereingaben und bedingte Verzweigungen, damit sich das Verhalten von Modellen sicher einschränken und nachvollziehen lässt.
- Bestehende Arbeiten wie OpenAIs strukturierte Tool-Aufrufe, Anthropics MCP, Microsofts FIDES/AC4A und Open-Source-Runtimes zeigen bereits eine Richtung zur Standardisierung auf.
- Eine klar definierte AI-VM kann Sicherheit und Datenschutz verbessern, Performance überwachen, Ausgaben validieren und ein plattformübergreifendes Ökosystem aufbauen und so zur zentralen Infrastruktur für vertrauenswürdigere und sicherere AI-Systeme werden.
Einführung
- AI-Modelle werden in Software für viele Zwecke eingesetzt, etwa als Anwendungs-Copilots, in IDE-Integrationen oder für den Tool-Einsatz über das MCP-Protokoll.
- Diese Entwicklung erhöht die Notwendigkeit, Datenschutz, Sicherheit und korrektes Verhalten zu gewährleisten.
- Sicherheit und Datenschutz müssen bereits in der Systemarchitektur verankert werden; nachträgliches Ergänzen reicht nicht aus.
- Inspiriert von der Java Virtual Machine (JVM) wird die Bedeutung einer standardisierten virtuellen Maschine für AI-Modelle vorgeschlagen.
- Die JVM bietet eine vertrauenswürdige Ausführungsumgebung durch Speichersicherheit, Zugriffskontrolle und Bytecode-Verifikation.
- Dadurch wurde „einmal schreiben, überall ausführen“ möglich.
Die Rolle der virtuellen Maschine für AI-Modelle (MVM)
- Die MVM arbeitet als vermittelnde Software zwischen AI-Modellen und der Außenwelt.
- Beispiel: Gibt ein Benutzer den Prompt „einen Flug buchen“ ein, leitet die MVM ihn an das Modell weiter, einschließlich zusätzlichem Kontext.
- Antwortet das Modell mit „Buchungstool verwenden“, prüft die MVM die Liste erlaubter Tools und entscheidet, ob der Tool-Aufruf erfolgen darf.
- So wird sichergestellt, dass das Modell keine nicht autorisierten Aufrufe ausführt.
- Alle kommerziellen AI-Systeme benötigen ähnliche Kontrollsoftware.
- Die MVM definiert einen Befehlssatz, zum Beispiel für:
- Modellauthentifizierung, Laden, Initialisierung und Entladen
- Modellaufrufe einschließlich Kontext
- Parsen der Modellausgaben
- Tool-Authentifizierung, Laden, Aufrufen, Parsen von Ergebnissen und Speichern im Memory
- Anfordern von Benutzereingaben, Hinzufügen von Verlaufs-Memory und Kontrollstrukturen wie Bedingungen
Bestehende Forschung und Notwendigkeit
- OpenAIs Protokoll für strukturierte Tool-Aufrufe: klare Tool-Integration über eine JSON-basierte Function-Calling-API und OpenAPI-Spezifikationen
- Anthropics MCP (2024): ein offenes Protokoll, das AI-Assistenten mit externen Daten verbindet
- Es wird als „USB-C-Port für AI-Anwendungen“ beschrieben und bietet eine universelle Schnittstelle.
- Es gibt Beispiele für eine schnelle Übernahme, auch bei Großunternehmen.
- Sicherheits-Orchestratoren – FIDES & AC4A (2025):
- FIDES (Microsoft Research): erzwingt Information-Flow-Richtlinien, verfolgt Vertraulichkeitslabels von Daten und ergänzt eine Aktion zum „Prüfen“.
- AC4A: verwaltet Tools und Daten in einer OS-ähnlichen Hierarchie und erzwingt einen Betriebsmodus nach dem Prinzip der minimalen Rechte.
- Diese Projekte zeigen, dass eine MVM Sicherheit und Zugriffskontrolle eingebaut haben kann.
- Open-Source-Agent-Runtimes: langchain, Semantic Kernel, llguidance bieten Runtime-Services und unterstützen so die stabile Entwicklung von AI-Anwendungen.
- Eine MVM-Spezifikation setzt voraus, dass die Trainingsdaten der Modelle die Schnittstellenspezifikation widerspiegeln; nötig ist eine gemeinsame Weiterentwicklung von Modellen und MVM.
Vorteile der MVM
- Trennung von Zuständigkeiten: Modelllogik und Integrationslogik werden getrennt, wodurch Modelle zu austauschbaren Komponenten werden.
- Beim Wechsel auf ein neues Modell oder beim Plattformwechsel bleibt die Interoperabilität erhalten.
- Eingebaute Sicherheit und Governance: Die MVM sorgt über Berechtigungsprüfungen, Audit-Logs und Schutzmechanismen für Sicherheit.
- Wie bei AC4A kann die MVM als Gatekeeper fungieren und unerwartetes Verhalten unterdrücken.
- Transparente Performance-Nachverfolgung: Runtime-Diagnosen liefern Einblicke in Modellleistung, Ressourcenverbrauch und das Niveau des Datenzugriffs.
- Mit Benchmarks lassen sich Genauigkeit, Nützlichkeit und Reaktionsfähigkeit vergleichen.
- Validierung der Modellausgaben: Techniken wie Zero-Knowledge-Beweise können die Integrität von Ausgaben prüfen und so Vertrauen und Rechenschaftspflicht stärken.
Fazit
- Eine virtuelle Maschine für AI-Modelle ist nötig, um die Komplexität von AI-Systemen zu verringern und ihre Interoperabilität zu erhöhen.
- Sie stärkt Sicherheit, Datenschutz, Portabilität und Zuverlässigkeit und erhöht zugleich Entwicklungsgeschwindigkeit und Skalierbarkeit des Ökosystems.
- Auf Grundlage der Forschung von Technologieunternehmen, Startups und der Wissenschaft kann eine MVM-Spezifikation einen Standard schaffen, mit dem AI-Modelle sicher und reibungslos interagieren.
- Ziel ist es, gemeinsam mit der Community einen Konsens über die Notwendigkeit und die Bestandteile einer MVM-Spezifikation aufzubauen.
1 Kommentare
Hacker-News-Kommentare
Ich finde, dem Artikel fehlt es an konkreter Erklärung, sodass unklar bleibt, was genau vorgeschlagen wird. Eine VM (Virtual Machine) ist jedenfalls mit Befehlssatz, Kontrollfluss, Registern usw. verbunden, aber dieser Artikel konzentriert sich nur auf Autorisierung. Letztlich scheint er von "etwas Ähnlichem wie einer Sandbox, Jail oder einem Container zu sprechen, das es dem Modell erlaubt, mit der Außenwelt zu interagieren"
Ich frage mich, ob hier wirklich von einer VM-Runtime oder von einer Art Docker für LLMs die Rede ist. Insgesamt wirkt es wie eine gut verpackte, aber inhaltlich dünne Geschichte. Wenn das Packaging-System schlecht entworfen ist, kann das katastrophal enden. Ein Blick auf die vielen Packaging-Erfahrungen mit Python reicht dafür schon aus
Beim Wort VM hatte ich sofort das Gefühl, dass es ziemlich nahe an einer Sandbox ist. Im Artikel selbst wird ja auch von "Isolation" gesprochen, deshalb fand ich ihn weder mehrdeutig noch informationsarm. Allerdings ist die Behauptung des Autors zu selbstverständlich und die Lösung unvollständig. Selbst wenn man es in eine Sandbox auf OS- oder Hardware-Ebene steckt, wird es problematisch, wenn der Agent etwa eine AWS CLI mit falsch konfigurierten IAM-Einstellungen findet. Auch Remote-Grenzen sind kompliziert. Einen neuen Erkenntnisgewinn habe ich nicht gesehen. Ich denke nicht, dass die Wortwahl das Problem ist
Nach der Definition im Artikel könnte man sagen, dass heutige AI Agents bereits in einer VM laufen. Beispielsweise kann ein MCP-Host die Zustimmung des Nutzers zur Ausführung einholen oder wie Claude Code Regeln haben, die bestimmte Befehlsmuster automatisch genehmigen
Ich denke, die eigentliche Frage ist nicht, welche Tools man einem LLM gibt, sondern welche Handlungen man ihm erlauben will. In einem Flugbuchungs-Szenario möchte man zum Beispiel, dass ein LLM Preise auf verschiedenen Websites vergleicht und auch die Zahlung erledigt. Man möchte aber nicht, dass es nutzloserweise ein 37-Stunden-Ticket auswählt, nur weil es 3 Dollar billiger ist. Beim Abruf von Benefits-Informationen sollte es nur die eigenen Daten sehen dürfen, nicht die von Kollegen. Selbst beim gleichen Tool ist der Umfang der Berechtigungen unterschiedlich. Ein HR-Verantwortlicher darf natürlich die Daten der Mitarbeiter einsehen, die er verwaltet, aber dann kommen zusätzliche Themen wie Audit-Logs dazu. Das heißt: Noch wichtiger als Verhalten ist die Intention. Es ist sinnvoll, das LLM als Stellvertreter des Nutzers zu behandeln und in dieselbe Berechtigungsbox zu setzen
Am Ende geht es um ein Capability-Sicherheitsmodell. Man muss einem Software-Agenten die zugänglichen Capabilities explizit übergeben, und Handlungen außerhalb dieser Liste müssen physisch unmöglich sein. In Mainstream-Betriebssystemen ist dieses Modell aber in der Praxis nirgends umgesetzt. Es gab viele Forschungen und Versuche (OS-Beispiele: EROS, Fuchsia, Sandstorm), aber am Markt waren sie wenig erfolgreich. Deshalb ist der praktischste Ansatz wohl, eine VM zu verwenden und nur die nötigen Werkzeuge in diese VM zu legen. Perfekt ist das nicht, weil Werkzeuge selbst im Vergleich zu echten Capabilities zu allgemein sind. Software, die nach dem Prinzip der minimalen Rechte gebaut ist, scheitert am Markt häufig
Nicht entscheidend ist, welche Handlungen ein Tool ausführen kann, sondern die Kombination aus den Daten, auf die das Tool zugreifen kann, und den möglichen Handlungen. Weil man das Verhalten eines LLMs nicht vollständig vorhersagen kann, sollte man ihm nicht vertrauen. Man kann dem LLM zum Beispiel nur Zugriff auf Flugbuchungsseiten geben, aber keine SSN-, Bankkonto- oder ähnlichen Informationen weiterreichen. Es geht also um Datenherkunft (Provenance) und Berechtigungen. Je sensibler ein Task ist, desto mehr Einschränkungen braucht er; bei weniger sensiblen Aufgaben kann man mehr Handlungen erlauben. Daten sollten Berechtigungsinformationen mitführen, und ein Mediator sollte begrenzen, welche Daten und Handlungen neu erzeugte Tasks erhalten. Beispiel: Wenn ein Reiseplanungs-Task den Untertask Flugsuche startet, sollte der Mediator dem Untertask nur unkritische Daten wie einen Teil des Terminplans geben und den Zugriff auf sensible Daten blockieren
Man kann einen LLM-Agent einfach als einen weiteren Nutzer mit denselben Eigenschaften wie der Benutzer betrachten. Je nach Kontext hat er unterschiedliche Rechte. Beispielsweise hat er in einem Quellcode-Ordner Lese-/Schreibrechte und in einem anderen nur Leserechte. Die Berechtigungen des LLM-Agenten unterscheiden sich je Projekt und sind eine Schnittmenge oder Teilmenge der Benutzerrechte. Grundsätzlich gibt es drei Berechtigungstypen: Allow, Deny und Ask (um Erlaubnis bitten). Falls nötig, fragt das System den Nutzer, ob etwas erlaubt werden soll. Das Problem ist, dass bestehende OS- sowie App-/Daten-Berechtigungen nicht fein genug granuliert sind. Selbst
gitmüsste so entworfen sein, dass nicht der komplette Zugriff gewährt wird, sondern nur bestimmte Befehle erlaubt sind. Derzeit emulieren Anwendungen das jeweils im User Space und implementieren es auf unbeholfene Weise. Der Workflow ähneltsudo. Wenn ich eine App als mein LLM-Agent-User starte, werden je nach Kontext Rechte gewährt oder eingeschränkt. Nur wenn ich es anfordere, darf sie innerhalb meines erlaubten Rahmens handeln. Aktuell muss jedoch jede agentische App diesen Prozess selbst implementieren, daher sollte daraus ein systematischer OS-Dienst werden. Übergangsweise könnte man pro Agent-Kontext temporäre Benutzerkonten anlegen und wieder löschen und nur über IPC oder das Netzwerk kommunizierenIch bezweifle, dass so ein Modell wirklich funktioniert. Selbst wenn ein LLM etwas tun kann, könnten Websites das erkennen und Preise anpassen oder Entscheidungsbäume absichtlich stören. Dann wäre es viel besser, wenn alle Websites stattdessen eine API für LLMs oder einfach "rss + json" anbieten würden. So wie bei BBS oder SMS-Menüs, wo nur einfache Daten und Auswahlmöglichkeiten geliefert werden — ideal auch für LLMs. Dasselbe gilt für Werbung. Einem LLM muss man keine Werbung zeigen; wirkungsvoller wäre sogar Werbung, die versucht, das LLM zu täuschen. Bei der Flugsuche könnte eine Anzeige das LLM etwa dazu verleiten, das eigene Produkt fälschlich als das beste einzustufen. Da AI derzeit noch recht simpel ist, wären AI-spezifische Anzeigen fast schon amüsant
Wenn man definieren und durchsetzen kann, was eine „gute Antwort“ ist, braucht man vielleicht gar kein LLM mehr. Im Fall eines HR-Verantwortlichen kann man direkt nach der Intention fragen, aber bei einem LLM ist das schwierig, weil es keine eigene Intention hat
Ich hatte neulich den HN-Beitrag gelesen, in dem stand, dass John Carmack bei Meta mit XROS nur Zeit und Geld verschwendet habe. Der heutige Artikel argumentiert dagegen stark für die Notwendigkeit eines „neuen OS“. Eine VM ist zwar kein vollständiges OS, unterscheidet sich aber dadurch, dass man bestehende Betriebssysteme und Codebasen weiterverwenden und etwas Leichtgewichtiges darauf aufbauen kann
Die beiden Artikel handeln von völlig unterschiedlichen Dingen. Ich sehe auch nicht, dass dieser Artikel tatsächlich stark für eine VM oder ein neues OS plädiert. Am Ende geht es einfach nur um Access Control
Bei XR standen Performance und Developer Experience im Mittelpunkt, während es bei LLMs gerade der Kern ist, den Zugriff auf Tools und Daten zu sandboxen und zu vereinfachen. Es gibt viel zu tun, damit LLMs nicht die Laufzeitumgebung beschädigen oder Daten kaputtmachen, und Standards würden den Nachtrainingsaufwand senken und es anderen erleichtern, Modelle zu nutzen. Bei XR könnte man vieles einfach mit einem SDK und Training lösen, aber bei AI sind Forschungs- und Entwicklungsaufwand sowie Compute-Kosten wesentlich höher
WebAssembly bietet von Haus aus eine Sandbox, daher ist man schon zur Hälfte dort. Was fehlt, sind klare Schnittstellen für die Übertragung von Daten und Berechtigungen zwischen Instanzen sowie ein Mechanismus, mit dem Instanzen einander erzeugen können
Ich denke nicht, dass dieser Artikel eine Rechtfertigung dafür liefert, ein neues OS zu schreiben. Eine Laufzeitumgebung für AI aufzubauen und ein für AI optimiertes OS von Grund auf neu zu entwerfen, sind völlig verschiedene Dinge
Nachdem ich den Artikel sorgfältig gelesen und die verlinkten Quellen angesehen habe, habe ich den Eindruck, dass er ein grundlegenderes Problem anspricht als nur eine „VM für AI“. Eine VM allein reicht nicht aus, um die Sicherheit von LLM-Workflows zu gewährleisten. Der Workflow auf oberster Ebene muss auf sensible Aufgaben und Daten wie Netzwerk, PII und Credentials zugreifen, und LLMs sind anfällig für Prompt Injection und Konsistenzprobleme. Allein dadurch, dass man ein LLM in eine VM steckt, ist das nicht gelöst. Man braucht eine Art „Informationsflusskontrolle“, bei der Workflows, Daten und Rechenoperationen pro Aufgabe partitioniert werden, sodass nur die minimal nötigen Unteraufgaben Zugang zu eingeschränkten Informationen haben. Nur die Teilmenge, die mit sensiblen Aufgaben zu tun hat, sollte separat vertraut und verifiziert werden. Genau das sind die im Artikel erwähnten „Secure Orchestrators“ und das FIDES-Paper. „VM“ bedeutet hier letztlich, einen Task in einem Container mit nur begrenzten Rechten und Daten auszuführen. Der Orchestrator muss diesen Container erzeugen, ihm passende Berechtigungen geben und die erzeugten Daten zusätzlich mit Sensitivitäts-Labels (Taint-Tracking) versehen. Insgesamt halte ich „Partitionierung“ oder „Isolation“ mit stärkerem Fokus auf Datenfragen für treffender als den Ausdruck „VM for AI“
Klingt ähnlich wie Microsoft Wassette
Das Ziel sollte sein, den Begriff Workflow selbst abzuschaffen. In der Kombination LLM + VM ist schon das Bereitstellen eines Tools an das LLM an sich ein Workflow. Dieser Ansatz funktioniert bereits oft recht gut, stößt aber bei nicht vorab definierten Ausnahmen oder Aufgaben, die neue Werkzeuge brauchen, an Grenzen. Außerdem kommt man mit Workflow-basierten Ansätzen kaum über lineare Strukturen hinaus — oder allenfalls DAGs und Schleifen. Der nächste Schritt wäre, Tools gar nicht mehr vorzugeben, sondern das LLM die benötigten Tools jeweils spontan selbst erzeugen zu lassen. Manche Probleme erfordern einen eher brute-force-artigen Ansatz
Beim Lesen hatte ich fast den Eindruck, aktuelle Texte klängen so, als wären sie von AI geschrieben. Aus Hosting-Sicht ist es schon eine große Herausforderung, AI Agents in irgendeiner Umgebung stabil zum Laufen zu bringen. Als Entwickler nutze ich rootless Docker-Devcontainer unter WSL; manche Malware könnte da vielleicht ausbrechen, aber trotzdem wirkt das für mich sicherer als der VM-Ansatz. Dazu kommen Vorteile wie Reproduzierbarkeit und Umgebungsisolation, und wenn AI meine Umgebung zerstört, stelle ich den Container einfach neu auf — das fühlt sich deutlich weniger riskant an
Wenn man sich die kommerziell am weitesten entwickelten Methoden zur Bereitstellung von Modellen ansieht, sind fast alle Merkmale, die der Artikel nennt — etwa Isolation — bereits umgesetzt. Es ist nicht auf OS-Ebene, aber funktional ähnlich. Trotzdem reicht selbst das nicht aus. Damit ein Agent tatsächlich nützlich arbeiten kann, braucht er Zugriff auf wichtige Ressourcen, und diese Rechte exakt im nötigen Umfang zu vergeben, ist viel schwieriger als das LLM selbst zu isolieren. Das präziseste Sicherheitsmodell für LLMs ist „untrusted userspace“. Man muss nicht gleich das ganze OS neu entwerfen
Ich stimme zu, dass die Isolation von LLMs so gründlich wie auf der Ebene einer VM entworfen werden sollte. Der Grund ist derselbe wie bei traditionell strengen Regeln in Betriebssystemen. Ich hatte kürzlich in diesem Blog einige Ideen dazu aufgeschrieben. Ich habe die Arbeitsweise von LLMs mit klassischen OS-Prozessen und -Tasks verglichen, und die zentralen Abstraktionen sind nicht schwer umzusetzen — ich kann die Chat-/Tool-Schnittstellen von 8 LLM-Backends vereinheitlichen und die Tool-Freigabe zentral verwalten. Ein Capability-Modell habe ich noch nicht implementiert, aber aus meiner früheren OS-Erfahrung mit VSTa wirkt es wie ein natürlicher Weg. Ein LLM sollte eine Teilmenge seiner Rechte an ein anderes LLM delegieren können, und ich habe dafür bereits ein Delegation-Tool gebaut
Ich denke, eine neue abstrakte Maschine wie eine VM zu schaffen, macht alles nur unnötig komplizierter. Konten, Datei-Lese-/Schreib-/Ausführungsrechte sowie temporärer oder entfernter Zugriff lassen sich bereits mit Access Tokens ausreichend abdecken. Jedes Capability-Modell sollte sich mit diesen Konzepten umsetzen lassen. Ich halte es für besser, vorhandene Werkzeuge zu vereinfachen. Gerade jetzt, wo alle mit neuen Dingen experimentieren und auf tiefgreifende Veränderungen in der Software hoffen, sollte man eher unnötige Komplexität abbauen und Dinge einfacher machen. Zum Beispiel kann man einen MCP-Server in 10 Minuten mit Claude in ein einfaches CLI-Tool umwandeln. Das ist aus meiner Sicht schon gut genug brauchbar
Das Sicherheitsmodell moderner Desktop-Betriebssysteme ist für die heutige Zeit absurd unzureichend. Dem Nutzer einfach ohne nennenswerte Warnung oder Bestätigung sämtliche Rechte zu übergeben, grenzt an Wahnsinn. Wenn ein Benutzer wirklich eine völlig unbeschränkte Umgebung will, sollte er diese Wahl haben, aber der Standard muss das Prinzip der minimalen Rechte sein. Pro Programm sollten nur domänenspezifische Berechtigungen vergeben werden. Ein Tool zur Visualisierung von Speicherverbrauch mag etwa vollen Zugriff aufs Dateisystem brauchen, aber keinen Zugriff auf das lokale Netzwerk oder das Internet
Die größte Stärke einer VM ist die Begrenzung des Schadensradius. Ein guter Agent kann das System mit einem Zero Day im System sehr leicht kompromittieren. Schon reine Benutzerrechte sind gefährlich genug, und das Wissen eines Agenten per Firewall einzuschränken, ist extrem schwierig, weil es im Internet viele Umgehungsmöglichkeiten gibt. Solche Systeme werden sehr gut darin werden, Systeme zu knacken, daher braucht man äußerst robuste Sicherheitsvorkehrungen
In LLM-Umgebungen gibt es kein Konzept eines einmaligen Lesens („temporary read“). Sobald etwas in den Kontext gelangt, muss man davon ausgehen, dass die Daten an alle verbundenen Stellen abfließen können, bis der Agent beendet und der Kontext gelöscht wird. Das gilt unabhängig davon, ob eine VM im Spiel ist oder nicht; eine VM allein ist also keine Sicherheitslösung
Dem stimme ich größtenteils zu. Viele Sicherheitsrisiken entstehen unabhängig davon, ob es eine VM gibt oder nicht. Defense in Depth wird künftig noch wichtiger werden, aber derzeit gibt es einfach zu viele einfache Möglichkeiten, AI Agents gegen Nutzer zu missbrauchen
In dem Moment, in dem nur ein Datei-Editierwerkzeug erlaubt ist, verliert man faktisch fast die gesamte Sicherheit
Ich denke, Fuchsia könnte ein realistisches Betriebssystem sein, um das Verhalten von AI-Modellen zu kontrollieren. Es ist ein Object-Capability-OS, daher kann jede Komponente (jeder Prozess) nur auf die Capabilities zugreifen, die ihr explizit gegeben wurden
Wenn ChatGPT Code ausführt (zum Beispiel bei einer CSV-Verarbeitungsanfrage), scheint das in einer VM zu laufen, die nur auf bestimmte Tools und Bibliotheken zugreifen kann, eine sandboxte Festplatte hat und keinen Internetzugang besitzt. Im Grunde geht die Entwicklung also bereits in diese Richtung
Devin und OpenHands sind ähnlich. Auch in einem AI-Pilotprojekt, an dem ich vor einigen Monaten gearbeitet habe, war „Agent standardmäßig in einer VM ausführen“ ein zentrales Element
Es basiert auf Kubernetes auf AKS (Azure Kubernetes Service), dazu
gvisorund JupyterNicht unbedingt. Wenn man zum Beispiel zwei AIs (etwa ChatGPT usw.) auf einer Maschine laufen lässt, gibt es überhaupt keine Standards oder Interoperabilität dafür, wie sie zusammenarbeiten oder miteinander interagieren sollen.