A2A vs. MCP: Agent-to-Agent-Kommunikation und Model Context Protocol verständlich erklärt

Mit zunehmender Komplexität moderner KI-Systeme setzen immer mehr Unternehmen auf Agenten. Dabei handelt es sich um autonome Softwarekomponenten, die denken, planen, handeln und mit anderen Agenten zusammenarbeiten können. Beim Aufbau großer Multi-Agenten-Umgebungen haben Architekten zwei Protokollklassen entwickelt, um unterschiedliche Herausforderungen bei der Interoperabilität zu lösen. Agent-to-Agent-Protokolle beschreiben, wie ein Agent mit einem anderen Agenten Informationen austauscht. Model Context Protocols legen fest, wie eine KI-Anwendung oder ein Agent auf Werkzeuge, Ressourcen, Prompts, APIs, andere Agenten oder weitere Systeme zugreift. Wer die Unterschiede zwischen beiden Ansätzen versteht, kann sichere, zuverlässige und skalierbare agentenbasierte Architekturen entwerfen.

In diesem Beitrag werden beide Protokolle ausführlich betrachtet. Es wird erklärt, was sie sind, wie sie sich unterscheiden, welche Sicherheitsaspekte zu beachten sind, welche Vor- und Nachteile sie mitbringen und wie ein praxisnaher Workflow aussieht, in dem beide gemeinsam eingesetzt werden. Am Ende wird deutlich, wann sich welches Protokoll eignet und wie sich beide wirkungsvoll kombinieren lassen.

Wichtige Erkenntnisse

• Unterschiedliche Ebenen, ergänzende Aufgaben: A2A kümmert sich um die Grundlagen der Kommunikation zwischen Agenten, etwa Delegation, Discovery und Streaming. MCP konzentriert sich darauf, Agenten oder Anwendungen standardisiert mit Tools und externem Kontext zu verbinden. In den meisten Fällen stehen beide nicht in Konkurrenz, sondern ergänzen sich.
• A2A für die Orchestrierung von Multi-Agenten-Systemen einsetzen: A2A eignet sich besonders dann, wenn mehrere autonome Agenten auf Augenhöhe zusammenarbeiten, ihre Grenzen bewahren und Aufgaben asynchron erledigen sollen. Besonders hilfreich ist das bei komplexen Abläufen wie Recherche-Assistenten, Support-Netzwerken oder Planungs-Pipelines.
• MCP für Tool-Integration verwenden: MCP ist sinnvoll, wenn ein KI-Modell oder Agent in einheitlicher Form auf externe Werkzeuge, Datenquellen oder Prompts zugreifen muss. Es passt besonders gut zu Host-Anwendungen wie IDE-Assistenten, Chat-Systemen und ähnlichen Oberflächen.
• Protokolle gezielt kombinieren: Viele Architekturen setzen beide gemeinsam ein. So kann etwa ein Planungs-Agent über A2A mit anderen Agenten kommunizieren, während diese Agenten MCP verwenden, um Werkzeuge oder Ressourcen abzurufen. Die Trennung von Orchestrierung und Tool-Zugriff verbessert häufig Wartbarkeit und Sicherheit.
• Sicherheit auf jeder Ebene berücksichtigen: Da A2A und MCP in unterschiedlichen Bereichen des Stacks arbeiten, entstehen auch unterschiedliche Sicherheitsanforderungen. Deshalb sind eingeschränkte Rechte, saubere Authentifizierung, Eingabevalidierung und nachvollziehbare Audit-Prozesse besonders wichtig.

Was ist A2A (Agent-to-Agent)?

A2A (Agent-to-Agent) ist ein offener Standard, der definiert, wie autonome Agenten miteinander kommunizieren und zusammenarbeiten. Zu seinen Zielen gehören Capability Discovery, Aufgabenweitergabe, Modalitätsaushandlung und der sichere Informationsaustausch. Durch ein gemeinsames Kommunikationsframework ermöglicht A2A Agenten die Zusammenarbeit, während sensible Daten geschützt und interne Implementierungsdetails verborgen bleiben.

Agenten, die A2A unterstützen, veröffentlichen eine Agent Card – ein strukturiertes Dokument, das ihre Fähigkeiten, unterstützten Modalitäten und verfügbaren Endpunkte beschreibt. Andere Agenten können diese Karten entdecken und Aufgaben entsprechend delegieren, ohne die interne Architektur oder Logik des jeweiligen Agenten kennen zu müssen. Zu den Hauptzielen von A2A gehören:

1. Aufgabenorientierte Kommunikation

Agenten tauschen strukturierte Tasks mit klar definierten Lebenszyklus-Zuständen aus, etwa eingereicht, in Bearbeitung, abgeschlossen oder fehlgeschlagen. Zusätzlich können sie bei lang laufenden Prozessen Statusaktualisierungen per Streaming oder asynchronen Benachrichtigungen senden.

2. Discovery und Verhandlung

Agenten veröffentlichen Agent Cards an bekannten Stellen wie /.well-known/agent-card.json. Diese Karten beschreiben, welche Aktionen ein Agent unterstützt, welche Modalitäten er verarbeiten kann, zum Beispiel Text, Bilder oder Audio, und welche Protokolle akzeptiert werden.

3. Sicherheit und Authentifizierung

A2A kann signierte Agent Cards sowie mehrere Authentifizierungsmethoden unterstützen. So können Agenten gegenseitig Vertrauen aufbauen, ohne interne Speicher, Werkzeuge oder Logik offenzulegen.

4. Schichtenorientiertes Design

A2A läuft über Transportmechanismen wie HTTP oder WebSockets. Darüber hinaus lässt es sich mit anderen Protokollen kombinieren.

Zentrale A2A-Konzepte

Agent Card

Eine Agent Card ist ein JSON-Dokument, das die Identität eines Agenten, unterstützte Modalitäten wie Text, Bild oder Audio, Tool-Fähigkeiten, Authentifizierungsverfahren, Endpunkte und weitere Metadaten beschreibt.

Task

Ein Task ist die grundlegende Arbeitseinheit. Ein Client-Agent übermittelt einen Task zusammen mit beschreibenden Metadaten wie erforderlichen Eingaben und erwarteten Ergebnissen. Der Server-Agent führt die Aufgabe aus und liefert Statusmeldungen sowie Endergebnisse zurück. Tasks können synchron mit nur einer Antwort oder asynchron über Polling oder Streaming ablaufen.

Capabilities

Capabilities beschreiben die Funktionen, die ein Agent ausführen kann, zum Beispiel Texte übersetzen, Bilder generieren oder Dokumente zusammenfassen. Sie können Vorbedingungen, Nachbedingungen, Authentifizierungsanforderungen und sogar erwartete Latenzen festlegen.

Status Codes

Agenten können standardisierte Statuscodes austauschen, um eine robuste Orchestrierung und saubere Fehlerbehandlung zu unterstützen. Typische Beispiele sind submitted, queued, running, succeeded und failed.

Warum A2A existiert

Single-Agent-Anwendungen rufen interne Funktionen oft direkt auf. Doch mit wachsender Organisation und steigender Last werden monolithische Systeme schnell anfällig. Im Laufe der Zeit müssen Teams Aufgabenbereiche trennen. Ein Planungs-Agent kann etwa Arbeit an einen Coding-Agenten, einen Retrieval-Agenten und einen Summarization-Agenten verteilen. Diese Agenten können in unterschiedlichen Umgebungen laufen, verschiedene Programmiersprachen verwenden oder von getrennten Teams oder Anbietern betrieben werden. Ohne einen gemeinsamen Standard wie A2A wären eng gekoppelte, fest verdrahtete APIs nötig, was Wartungsaufwand und Sicherheitsrisiken deutlich erhöht.

A2A löst dieses Problem, indem es standardisiert, wie Agenten sich bekannt machen, Aufgaben aushandeln, Ausgaben streamen und mit Fehlern umgehen. Das Ganze geschieht sprachneutral und unabhängig von Frameworks. Besonders gut eignet sich A2A für Unternehmensumgebungen, in denen unterschiedliche Teams oder Anbieter spezialisierte Agenten mit eigener proprietärer interner Logik entwickeln möchten.

Was ist MCP (Model Context Protocol)?

Das Model Context Protocol ist ein offener Standard, der KI-Anwendungen oder Agenten den Zugriff auf externe Ressourcen ermöglicht. Während autonome Agenten über A2A miteinander kommunizieren, bietet MCP KI-Modellen einen standardisierten Weg, Tools, Ressourcen und Prompts zu nutzen. Die MCP-Spezifikation definiert dafür ein Host-Client-Server-Modell. Auf hoher Ebene umfasst es die folgenden Komponenten:

Host

Der Host verantwortet die Benutzererfahrung für Endanwender und verbindet sich mit KI-Modellen. Typische Hosts sind IDE-Erweiterungen, Chat-Oberflächen oder Orchestrierungsebenen für Agenten.

MCP Client

Der MCP Client ist eine Bibliothek, die in den Host eingebunden wird und die Kommunikation mit MCP-Servern übernimmt. Er verwaltet Authentifizierung, Transportverhalten, Sitzungszustand und Nachrichtenstruktur.

MCP Server

Der MCP Server ist ein Dienst, der Fähigkeiten wie Tools, Ressourcen und Prompts bereitstellt. Er kann als lokaler Prozess laufen, beispielsweise als vom Host gestarteter Python-Server, oder als entfernter HTTP-Dienst.

MCP verwendet JSON-RPC als Transportmechanismus und baut die Kommunikation auf einem zustandsbehafteten Sitzungsmodell auf.

Wenn der Host einen Client startet, verhandelt er Fähigkeiten mit den Servern, gibt unterstützte Transportarten wie HTTP oder Standard-Ein-/Ausgabe an und erhält eine Session-ID. Sobald die Sitzung eingerichtet ist, kann der Host Tools aufrufen oder Ressourcen auslesen.

Zentrale MCP-Primitiven

Tool

Ein Tool ist eine aufrufbare Funktion oder Operation, die dem Client zur Verfügung gestellt wird. Tools werden über Eingabe- und Ausgabeschemata sowie Namen und Beschreibung definiert. Zusätzlich können optionale Parameter vorhanden sein. Tools können Datenbankabfragen, Dateizugriffe, Such-APIs oder größere Workflows umsetzen. Wird ein Tool über MCP aufgerufen, sendet der Client Argumente passend zum Eingabeschema, und der Server liefert entweder Ergebnisse oder einen Fehler zurück.

Resource

Ressourcen sind strukturierte Datenelemente, die vom Server bereitgestellt werden. Dazu können Dateien, Schemata, Dokumente oder anwendungsspezifische Wissensbestände gehören. Der Client kann Ressourcen auflisten und in einem normalisierten binären oder strukturierten Format auslesen. Auch Streaming für große Ressourcen wird von MCP unterstützt.

Prompt

Prompts sind wiederverwendbare Text- oder Codevorlagen, die der Host abrufen und mit Variablen befüllen kann, um das KI-Modell gezielt zu steuern. Die dynamische Bereitstellung von Prompts erleichtert Workflows, die auf domänenspezifische Anweisungen oder Abfragevorlagen angewiesen sind.

Authorization

Wenn MCP HTTP als Transport verwendet, stützt sich die Autorisierung auf OAuth 2.1 und sichere Metadaten-Discovery. Für Standard-Ein-/Ausgabe-Transporte, etwa lokal gestartete Subprozess-Server, definiert MCP, wie Tokens sicher übergeben werden. Dadurch wird verhindert, dass externe Server ohne Erlaubnis im Namen eines Nutzers handeln oder beliebige Anfragen auslösen.

Session

Die Verbindung zwischen einem MCP Client und einem MCP Server findet innerhalb einer Session statt, die ihren eigenen Kontext verwaltet. Dazu gehören ausgehandelte Fähigkeiten, Nutzungsgrenzen und Verweise auf Ressourcen. Sessions sorgen für Konsistenz über mehrere Aufrufe hinweg und ermöglichen zustandsbehaftete Funktionen wie Konversationsverläufe.

Warum MCP existiert

KI-Modelle benötigen Kontext, um nützliche Ergebnisse zu erzeugen. Dieser Kontext kann aus lokalen Dateien, entfernten APIs, Datenbankeinträgen oder individuellen Prompts stammen. Ohne einen gemeinsamen Standard müssten Entwickler für jedes Sprachmodell eigene Konnektoren bauen oder umgebungsspezifische Logik direkt in die Modell-Schnittstelle integrieren. MCP trennt das Modell von externem Tool- und Datenzugriff. Tools und Ressourcen, die über einen MCP Server bereitgestellt werden, lassen sich von jedem kompatiblen Host in konsistenter Form nutzen. Dadurch wird die Interoperabilität von Agentensystemen über verschiedene Modelle und Frameworks hinweg einfacher, weil dieselbe Definition von Fähigkeiten verwendet werden kann.

Wichtige Unterschiede zwischen A2A und MCP

Obwohl beide Protokolle KI-Agenten-Workflows unterstützen, arbeiten sie auf unterschiedlichen Ebenen des Systems.

A2A sollte eingesetzt werden, wenn mehrere Agenten als gleichberechtigte Partner zusammenarbeiten müssen. MCP eignet sich, wenn eine KI-Anwendung oder ein Agent standardisierten Zugriff auf Tools und externe Daten benötigt. Beide zusammen sind dann sinnvoll, wenn eine anspruchsvolle Multi-Agenten-Architektur sowohl Delegation als auch strukturierten Tool-Zugriff benötigt. So kann ein Agent über A2A Aufgaben an spezialisierte Agenten übergeben, die ihrerseits MCP einsetzen, um Tools aufzurufen und Ressourcen abzurufen.

Praxisnaher Agenten-Workflow

Stellen wir uns vor, ein Orchestrierungs-Agent im Support erhält ein Kundenanliegen.

Er leitet abrechnungsbezogene Anfragen an einen Billing-Agenten weiter, Probleme mit Produktfehlern an einen technischen Support-Agenten und Rückerstattungsentscheidungen an einen Policy-Agenten. Der Orchestrator entdeckt diese Agenten und kommuniziert über A2A mit ihnen. Jeder dieser Agenten kann intern MCP nutzen, um auf Systeme wie ein CRM, ein Richtlinien-Repository oder eine Versand-API zuzugreifen. Die Spezialisierung liegt also auf Ebene der Agenten. A2A übernimmt die Kommunikation zwischen den Agenten, während MCP den Zugriff auf Werkzeuge steuert.

A2A vs. MCP in Python

Viele suchen nach praxisnahen Vergleichen von A2A und MCP in Python und möchten Beispielcode sehen, der realistische Einsatzszenarien abbildet. Die folgenden vereinfachten Beispiele zeigen typische Muster.

Minimaler MCP-Server in Python

from mcp.server.fastmcp import FastMCP

# 1. Create a FastMCP server with a namespace
mcp = FastMCP("my_app")

# 2. Expose a tool through MCP
@mcp.tool()
def get_customer_balance(customer_id: str) -> str:
    """Return the current balance of the customer."""
    # In a production setup, retrieve the value from a database or API
    return "Balance: $120"

if __name__ == "__main__":
    # 3. Start the MCP server using stdio transport
    mcp.serve()  # or the equivalent method that starts the stdio loop

Mit der Klasse FastMCP lassen sich Tools mithilfe von Decorators definieren. Die Docstrings der einzelnen Tools werden dabei als Beschreibung übernommen. Wenn der Host get_customer_balance über den MCP Client aufruft, erhält er ein strukturiertes Ergebnis.

Konzeptionelles A2A-Muster in Python

# 1. Expose a specialist agent through A2A (run through CLI)
#    adk api_server --a2a --module check_prime_agent

# 2. Discover and use the remote agent through its agent card
from google.cloud import agent

remote_agent = agent.RemoteA2aAgent(
    name="prime_checker",
    description="Checks whether a number is prime",
    agent_card="https://specialist.company.com/a2a/check_prime_agent/.well-known/agent.json",
)

# 3. Delegate a task to the remote agent
result = remote_agent.invoke(
    tool_name="prime_checking",
    inputs={"nums": [47]}
)

# 4. Read and print the output
print(result["output"])   # Example: {"is_prime": true, "number": 47}

Dieses Beispiel zeigt Folgendes:

• Es verwendet RemoteA2aAgent im Stil des ADK-Python-Quickstarts mit einer expliziten agent_card-URL.
• Es folgt einem schemaorientierten ADK-Muster mit einem tool_name und einem inputs-Dictionary, in dem nums eine Liste von Ganzzahlen ist.
• Es veröffentlicht einen spezialisierten Agenten über A2A, entdeckt ihn über eine Agent Card und delegiert eine Aufgabe, die dem Prüfen von Primzahlen ähnelt.

Sicherheitsaspekte

Sicherheit ist einer der wichtigsten Gründe dafür, warum es problematisch ist, A2A und MCP als austauschbar zu betrachten. Da beide auf unterschiedlichen Ebenen arbeiten, unterscheiden sich auch ihre Angriffsflächen.

MCP-Sicherheit

Die Sicherheitsrichtlinien von MCP weisen auf mehrere Risiken hin, darunter die folgenden:

• Confused-Deputy-Problem: Ein MCP Server könnte ohne saubere Berechtigungen oder Scope-Einschränkungen im Namen des Clients mit einem anderen System interagieren. Server sollten deshalb Scopes und Freigabeprozesse durchsetzen. Clients sollten Tokens nicht unkontrolliert weiterreichen und Berechtigungen so weit wie möglich einschränken.
• Risiken beim Token-Pass-Through: Bei HTTP-Transporten können Tokens in Authorization-Headern übertragen werden. Wird der Server kompromittiert, können diese Tokens gestohlen werden. Daher sollten kurzlebige, regelmäßig rotierte Tokens mit engen Berechtigungen eingesetzt werden. Bei Standard-Ein-/Ausgabe-Transporten sollten Tokens explizit statt über Umgebungsvariablen übergeben werden.
• Server-Side Request Forgery (SSRF): Wenn vom Benutzer gelieferte URLs an einen MCP Server weitergegeben werden, könnte dieser versehentlich Ressourcen aus internen Systemen abrufen. Um dieses Risiko zu verringern, sollten Server Eingaben validieren und ausgehende Netzwerkzugriffe streng kontrollieren.
• Session Hijacking und Replay-Angriffe: Da MCP auf Sessions basiert, sollten Session-IDs unvorhersehbar sein und ausschließlich über HTTPS sowie andere sichere Transportkanäle geschützt werden.
• Kompromittierung lokaler Server: Wenn Hosts lokale MCP Server starten, zum Beispiel mit mcp.run(transport="stdio"), sollte der gestartete Prozess so isoliert werden, dass Dateioperationen nicht außerhalb des vorgesehenen Arbeitsverzeichnisses möglich sind.
• Human-in-the-Loop-Freigaben: Die offizielle MCP-Spezifikation erlaubt es, sensible Tools hinter einer menschlichen Freigabe zu schützen. Das ist zum Beispiel bei Aktionen wie dem Versand von E-Mails oder dem Auslösen von Käufen sinnvoll.

A2A-Sicherheit

A2A schützt die Kommunikation, indem es sich auf Agentenidentität und Task-Berechtigungen konzentriert:

• Agenten-Authentifizierung: Agenten können sich beispielsweise durch signierte Agent Cards authentifizieren, etwa über JSON Web Signatures, damit andere Agenten Echtheit und Integrität prüfen können.
• Einschränkung von Capabilities: Agenten veröffentlichen nur die Fähigkeiten, die sie tatsächlich freigeben möchten. Diese Capabilities können Authentifizierung und clientabhängige Rate Limits voraussetzen.
• Task-Isolation: Delegierte Aufgaben laufen im Kontext des empfangenden Agenten. Sie erhalten nicht automatisch Zugriff auf Daten oder Werkzeuge des aufrufenden Agenten. Jeder Agent entscheidet selbst, welche Tasks er akzeptiert, und kann Aufgaben bei Bedarf beenden.
• Push versus Pull: Agent-to-Agent-Systeme können Push-basierte Benachrichtigungen nutzen, um den Status lang laufender Aufgaben zu melden. Solche Push-Kanäle sollten authentifiziert werden, damit keine gefälschten Meldungen eingeschleust werden können.
• Audit Trails: Agenten sollten Tasks, Eingaben, Ausgaben und Statuswechsel zusammen mit Metadaten wie Aufruferkennung und Zeitstempeln protokollieren. Ohne saubere Protokollierung können bösartige Aktivitäten unentdeckt bleiben.

Vor- und Nachteile von A2A und MCP

Die folgende Tabelle fasst die wichtigsten Vor- und Nachteile von A2A und MCP zusammen. Sie zeigt, worin die Stärken der jeweiligen Protokolle liegen und an welchen Stellen Teams Abwägungen in Bezug auf Architektur, Skalierbarkeit oder Sicherheit treffen müssen.

FAQ-Bereich

Was ist der Unterschied zwischen A2A und MCP?

A2A standardisiert die Kommunikation zwischen Agenten, einschließlich Discovery, Task Delegation, asynchroner Statusaktualisierungen und Streaming. MCP standardisiert, wie Agenten oder Anwendungen über ein Host-Client-Server-Modell auf Tools, Ressourcen und Prompts zugreifen. Vereinfacht gesagt übernimmt A2A die Delegation, während MCP für die Integration von Fähigkeiten zuständig ist.

Ist MCP ein Ersatz für Agent-to-Agent-Kommunikation?

Nein. MCP ist nicht dafür gedacht, die Kommunikation zwischen Agenten zu ersetzen. Auch wenn beide zusammen genutzt werden können, lösen sie unterschiedliche Probleme. MCP bietet einen standardisierten Weg zur Integration von Tools und Kontextressourcen. A2A ermöglicht die Kommunikation zwischen gleichrangigen Agenten. Beide arbeiten auf verschiedenen Ebenen des Agenten-Stacks.

Können A2A und MCP gemeinsam eingesetzt werden?

Ja. In ausreichend komplexen Systemen kann ein Planungs-Agent Arbeit über A2A an spezialisierte Agenten delegieren. Diese spezialisierten Agenten können anschließend MCP verwenden, um Tools aufzurufen, Dateien zu lesen oder Prompts abzurufen. Zusammen schaffen beide eine klare Trennung zwischen Orchestrierungslogik und Tool-Integration.

Welches Protokoll eignet sich besser für Multi-Agenten-Systeme?

A2A ist die stärkere Wahl für reine Multi-Agenten-Systeme. Es bringt Discovery, Task-Lifecycle-Management, asynchrone Updates und ausgehandelte Fähigkeiten bereits mit. MCP allein bietet diese Funktionen nicht, weil es sich auf Tool-Aufrufe und den Zugriff auf Ressourcen konzentriert.

Verwaltet MCP Agenten-Memory?

Nicht direkt. MCP liefert ein Modell, um Ressourcen bereitzustellen und Tools über den Host aufzurufen. Zwar könnte ein Memory-System als Resource Server umgesetzt werden, zum Beispiel in Form eines Vector Stores, doch MCP standardisiert nicht, wie Memory oder Kontext gespeichert werden sollen. Langfristiges Memory bleibt deshalb eine Aufgabe auf Anwendungsebene.

Wie skalieren A2A-Systeme?

A2A skaliert, indem Arbeit in grobgranulare Tasks zerlegt und an Agenten delegiert wird, die auf diese Aufgaben spezialisiert sind. Die Fähigkeiten der Agenten werden über Agent Cards veröffentlicht, während Routing-Logik oder Orchestratoren entscheiden, welche verfügbaren Agenten welche Tasks erhalten. Horizontale Skalierung ist möglich, indem weitere Agenten hinzugefügt werden, solange Discovery-Dienste und Vertrauensbeziehungen entsprechend mitwachsen.

Welche Sicherheitsrisiken bestehen bei Agenten-Kommunikation?

Zu den typischen Risiken zählen schwache Identitätskontrollen, übermäßige Berechtigungen, Prompt Injection, Datenabfluss, SSRF, Session Hijacking und bösartige Tasks. Sowohl A2A als auch MCP erfordern starke Authentifizierung, sorgfältige Autorisierung, Eingabevalidierung, Ausgabefilterung und Auditierung, um diese Bedrohungen zu reduzieren. A2A bringt zusätzlich protokollspezifische Risiken mit sich, etwa bei Task-Akzeptanz, Identität entfernter Agenten und Integrität von Streams.

Fazit

A2A und MCP sollten nicht als konkurrierende Standards betrachtet werden, weil sie unterschiedliche Probleme in modernen KI-Architekturen lösen. A2A ist die bessere Wahl für Delegation, Koordination und Orchestrierung zwischen Agenten in Multi-Agenten-Systemen. MCP ist die bessere Wahl für standardisierten Zugriff auf Tools, Daten und externe Systeme. Viele robuste KI-Architekturen werden beide Ansätze kombinieren: A2A für die Zusammenarbeit zwischen Agenten und MCP für den sicheren Zugriff auf Werkzeuge. Teams, die diese beiden Konzepte klar voneinander trennen, sind besser in der Lage, skalierbare, interoperable und sichere KI-Systeme zu entwickeln.