Souveräne agentische KI in der europäischen Fertigungsindustrie: Architektur autonomer Engineering-Workflows im Rahmen des EU AI Act

Zusammenfassung

Der europäische Industriesektor befindet sich im Jahr 2026 an einem tiefgreifenden technologischen Wendepunkt. Die Integration von künstlicher Intelligenz in Engineering, Computer-Aided Design (CAD) und Product Lifecycle Management (PLM) hat sich von der Einführung passiver, generativer Assistenten hin zur Implementierung autonomer, zielgerichteter agentischer KI-Systeme entwickelt.[1] Für Unternehmen, die komplexe industrielle Wertschöpfungsketten steuern, bietet diese Entwicklung beispiellose Möglichkeiten, anspruchsvolle Workflows zu automatisieren, Lieferkettendaten zu optimieren und die Produktentwicklung zu beschleunigen.[3] Gleichzeitig ist der Einsatz einer derart fortschrittlichen rechnergestützten Intelligenz innerhalb der Europäischen Union an zwei absolute Voraussetzungen geknüpft: die strikte Einhaltung des EU AI Act und die kompromisslose Sicherstellung digitaler Souveränität.[5]

Dieses technische Whitepaper liefert einen umfassenden architektonischen Blueprint für die Konzeption, Implementierung und Governance souveräner Multi-Agenten-Systeme in anspruchsvollen B2B-Engineering-Umgebungen. Entwickelt aus der Perspektive fortschrittlicher Systemintegration, kundenspezifischer Softwareentwicklung und spezialisierter Siemens NX Open API-Architektur behandelt dieser Bericht die entscheidenden technischen Anforderungen für die Operationalisierung von KI in industriellen Hochrisikokontexten. Durch die Untersuchung der Integration von Large Language Models (LLMs) mit deterministischen Engineering-Plattformen über das Model Context Protocol (MCP) sowie die Einordnung dieser Integrationen im Hinblick auf die strengen Vorgaben des EU AI Act und des Gaia-X Trust Framework schafft diese Analyse eine umfassende Roadmap für Chief Technology Officers (CTOs), Enterprise-Architekten und Engineering-Führungskräfte.[8] Ziel ist es, einen belastbaren Rahmen für die Erreichung rechnerischer Souveränität zu schaffen, nicht-deterministische KI-Ausgaben zu mitigieren und compliance-getriebene Innovation im Zeitalter der autonomen industriellen digitalen Transformation voranzutreiben.

1. Der Paradigmenwechsel: Von generativer Intelligenz zu agentischen Engineering-Workflows

1.1 Dekonstruktion des agentischen Engineering-Kreislaufs

Generative KI, die durch ihre Abhängigkeit von statischen Kontextfenstern und menschlich initiierten Eingaben gekennzeichnet ist, hat in ihrem Nutzen für Unternehmen einen Plateaupunkt erreicht.[2] Obwohl sie in hohem Maße dazu fähig ist, Texte und Code auf Basis probabilistischer Muster zu synthetisieren, sind generative Modelle grundsätzlich reaktiv. Die nächste Entwicklungsstufe, agentische KI, verlagert das Betriebsmodell von einem Frage-und-Antwort-Paradigma hin zu einem autonomen, zielgerichteten Ausführungsrahmen.[12]

Agentische Systeme arbeiten auf Grundlage eines kontinuierlichen Wahrnehmungs-, Denk- und Handlungszyklus (PRA), der es ihnen ermöglicht, in komplexen industriellen Umgebungen dynamisch zu agieren.[13] Innerhalb eines Fertigungs- und PLM-Kontexts funktioniert dieser kognitive Kreislauf über vier klar unterscheidbare Phasen:

• Perception: The agent ingests and interprets multimodal data streams. This includes unstructured requirements documents, real-time sensor telemetry from shop floor machinery, and highly structured CAD metadata and geometric parameters.14
• Reasoning: Durch den Einsatz fortschrittlicher LLMs als zentrale Reasoning-Engines zerlegt das System komplexe, übergeordnete Engineering-Ziele in aufeinanderfolgende, umsetzbare Teilaufgaben. Der Agent bewertet historische Designmuster, analysiert Randbedingungen und ruft die erforderlichen Kontextdaten über Vektordatenbanken ab.[2]
• Aktion: Der Agent führt deterministische Operationen über externe Systeme hinweg aus. Dies kann das Aufrufen der Siemens NX Open API beinhalten, um eine bestimmte geometrische Toleranz zu ändern, das Abfragen einer PLM-Datenbank hinsichtlich der Materialkonformität oder das Generieren automatisierter Routing-Skripte für Manufacturing Execution Systems (MES).[16]
• Reflexion und Lernen: Systemergebnisse, Fehlerprotokolle und Korrekturen durch Human-in-the-Loop (HITL) werden in die kognitive Speicherarchitektur zurückgeführt. Diese Reflexionsphase verfeinert zukünftige Iterationen und etabliert ein sich weiterentwickelndes institutionelles Gedächtnis, das sich an die spezifischen Engineering-Nuancen des Unternehmens anpasst.[13]

1.2 Überwindung der Single-Platform-Limitierung in CAD und PLM

Historisch gesehen litt der Einsatz von artificial intelligence im Engineering unter einem kritischen strukturellen Bottleneck: Intelligence blieb innerhalb der proprietären, abgeschotteten Ökosysteme einzelner Softwareanbieter gefangen.[19] Native Tools wie der Siemens Teamcenter BOM Copilot und der NX Design Copilot bieten erhebliche Verbesserungen der Usability.[19] Sie ermöglichen eine konversationelle BOM-Exploration, sodass Ingenieure Natural-Language-Queries nutzen können, um komplexe Produktstrukturen zu durchlaufen und relevante Softwarefunktionen zu entdecken.[20] Diese Single-Platform-Lösungen verfügen jedoch in der Regel nicht über die systemübergreifende semantische Interoperabilität, die für eine End-to-End-Orchestrierung des Digital Thread erforderlich ist.[19]

Echtes agentic Engineering erfordert die Etablierung eines „Product Memory“ – eines intelligenten, persistenten und vernetzten Wissensmodells, das sich über vollständig voneinander getrennte Architekturen erstreckt, einschließlich Enterprise Resource Planning (ERP), MES, unterschiedlicher CAD-Umgebungen und externer Lieferantendatenbanken.19 Um dieses Integrationsniveau zu erreichen, müssen Unternehmen über starre Legacy-Automatisierungsskripte hinausgehen. Stattdessen benötigen sie hochentwickelte Multi-Agent-Orchestratoren, die in der Lage sind, übergeordnete Engineering-Intent zu interpretieren, gleichzeitig dynamisch mit mehreren APIs zu interagieren und die Datenfragmentierung entlang der globalen Lieferkette aufzulösen.[22]

1.3 Die Komplexitätsschwelle und Multi-Agent-Orchestrierung

Sobald industrielle Aufgaben die „complexity threshold“ eines einzelnen Large Language Models (LLM) überschreiten, erfordern belastbare technische Architekturen spezialisierte Multi-Agent Systems (MAS).[24] In einer produktionsreifen MAS-Deployment-Umgebung erhält ein primärer Orchestrator-Agent eine übergeordnete Benutzeranfrage – beispielsweise den Auftrag, eine Hochvolt-Baugruppe hinsichtlich der Wärmeableitung zu optimieren und gleichzeitig sämtliche relevanten Compliance-Dokumentationen sowie PLM-Datensätze zu aktualisieren. Der Orchestrator zerlegt dieses umfassende Ziel und delegiert die spezifischen Teilaufgaben an ein spezialisiertes Team von Worker-Agents.[12]

In dieser Architektur kann ein Agent direkt mit einem Computational Fluid Dynamics (CFD)-Solver interagieren, um thermische Lasten zu simulieren.[26] Gleichzeitig nutzt ein geometrischer Agent die NX Open API, um auf Basis des CFD-Feedbacks die Dichte der Kühlrippen anzupassen, während ein Regulatory-Agent eine externe Datenbank abfragt, um sicherzustellen, dass die neu ausgewählten Materialien den europäischen Standards zur chemischen Sicherheit entsprechen.[16] Dieser dezentrale Multi-Agent-Ansatz mitigiert systematisch eine Überlastung des Context Window, reduziert die Latenz und isoliert Ausführungsgrenzen, wodurch die Gesamtzuverlässigkeit und Fehlertoleranz des Systems erheblich verbessert werden.[24]

1.4 Das agentic Trust Fabric

Die Tragfähigkeit dieser autonomen Workflows hängt vollständig von der Etablierung eines agentic Trust Fabric ab.[13] Dieses Framework integriert die Agent Runtime Environment (ARE) – die strikte Ausführungsgrenzen durchsetzt, Isolation bereitstellt, Resets kontrolliert und das Lifecycle-Management sicherstellt – mit einem umfassenden Trust Envelope.[13] Der Trust Envelope steuert Security, Logging, Protokolle und Observability und stellt sicher, dass das autonome System weder driftet noch Fehler wiederholt oder stillschweigend ausfällt.[13] Dieses einheitliche adaptive Framework gewährleistet, dass Trust an jeder API-Grenze und innerhalb jedes cognitive loop gestärkt wird, sodass Multi-Agent Systems über Proof-of-Concept-Demonstrationen hinauswachsen und verantwortungsvoll im Enterprise-Maßstab betrieben werden können.[13]

2. Architektur von Interoperabilität: Das Model Context Protocol (MCP)

Um agentic AI innerhalb komplexer CAD- und PLM-Ökosysteme zu operationalisieren, muss die zugrunde liegende technische Architektur die Lücke zwischen stochastischen reasoning engines und deterministischen Engineering-Plattformen überbrücken. Der traditionelle Ansatz, für jede LLM-zu-System-Interaktion kundenspezifische, hart codierte API-Wrapper zu entwickeln, führt zu einer stark fragmentierten, fragilen Infrastruktur, die schwer zu warten und zu skalieren ist.[28]

2.1 Standardisierung der AI-to-Data-Integration

Das Model Context Protocol (MCP) hat sich rasch als maßgeblicher Open-Source-Standard zur Auflösung von API-Fragmentierung in agentic Architekturen etabliert.10 Es funktioniert analog zu einem universellen Schnittstellenstandard für artificial intelligence und legt exakt fest, wie Context an Modelle übergeben wird.10 Es ermöglicht Entwicklern, sichere bidirektionale Verbindungen zwischen ihren proprietären Datenquellen und AI-gestützten Tools aufzubauen, sodass autonome Agents sicher mit lokalen Data Spaces, PLM-Datenbanken und CAD-APIs interagieren können, ohne dass für jede neue Modelliteration maßgeschneiderter Integrationscode erforderlich ist.[10]

Die MCP-Architektur basiert auf drei grundlegenden Säulen, die die Grenzen der Agenteninteraktion definieren:

2.2 Implementierung von MCP für Siemens NX- und PLM-Umgebungen

Durch den Einsatz von MCP kann eine Engineering-Organisation oder ein spezialisierter Partner für Softwareintegration einen MCP-Server bereitstellen, der die Siemens NX Open API oder Teamcenter-Endpunkte sicher kapselt.[16] Wenn ein Design Engineer eine automatisierte Modifikation einer Baugruppe anfordert, übersetzt der lokale MCP-Client den cognitive intent des LLM in einen sicheren, strukturell validierten API-Call.[28]

Diese Architektur setzt Data Containment strikt durch. Das Modell ist darauf beschränkt, ausschließlich auf jene Daten zuzugreifen, die durch die Grenzen des Protokolls ausdrücklich freigegeben sind, wodurch unautorisierter Datenzugriff oder System-Jailbreaking rechnerisch praktisch nicht umsetzbar werden.[32] Darüber hinaus mitigiert diese Struktur inhärent das Risiko von AI hallucinations. Da der Agent vollständig auf strukturierte, mathematisch verifizierte Antworten angewiesen ist, die vom MCP-Server zurückgegeben werden – anstatt Informationen aus seinem eigenen latenten, probabilistischen Memory zu synthetisieren –, sind die Outputs in realen, aktuellen Engineering-Daten verankert.[32]

2.3 Überwindung von Token-Consumption- und Latenz-Bottlenecks

Da das Ökosystem vernetzter Tools innerhalb einer umfangreichen PLM-Umgebung wächst, kann das vorgelagerte Laden aller Tool-Definitionen sowie das Weiterreichen zwischengelagerter geometrischer Ergebnisse durch das Context Window des LLM die Latenz und die API-Kosten erheblich erhöhen.[28] Ein übermäßiger Token-Consumption durch komplexe Tool-Schemata verschlechtert die reasoning efficiency des Agenten.[28]

Fortgeschrittene MCP-Implementierungen lösen dieses Problem, indem sie Code-Execution-Capabilities ermöglichen.[28] Anstatt das LLM dazu zu zwingen, massive JSON-Payloads geometrischer Daten zu verarbeiten, kann der Agent Python- oder C++-Skripte über die NX Open API direkt innerhalb einer sicheren, sandboxed Runtime Environment generieren und ausführen.[16] Das Skript interagiert mit dem CAD-Kernel, führt die erforderlichen Berechnungen oder Modifikationen aus und gibt nur das finale, validierte Ergebnis an den Agenten zurück. Dieser Ansatz minimiert den Token-Overhead, beschleunigt die Ausführungsgeschwindigkeit und ermöglicht es dem agentic System, erheblich komplexere Multi-Tool-Workflows zu bewältigen.[28]

3. Überbrückung der Kluft zwischen deterministischen CAD-Systemen und probabilistischer AI

Die grundlegende Reibung zwischen artificial intelligence und Industrial Engineering liegt im Konzept des Determinismus. CAD-Systeme, strukturelle Solver und MES-Plattformen erfordern absolute mathematische Präzision und wiederholbare Ergebnisse.[3] Large Language Models sind hingegen inhärent probabilistisch; sie erzeugen selbst bei identischen Input-Prompts leicht unterschiedliche Texte, Code-Ausgaben oder Parameter.[37] Unkontrollierter Non-Determinism im industriellen Design ist inakzeptabel und kann zu katastrophalen physischen Ausfällen, Fertigungsfehlern und schwerwiegenden Sicherheitsverstößen führen.

3.1 RAG vs. Fine-Tuning für Engineering Context

Ein LLM mit tiefem, proprietärem Engineering-Wissen auszustatten, erfordert eine hochentwickelte und äußerst bewusst gestaltete Datenarchitektur. Der Branchenkonsens für industrielle Anwendungen weist auf einen hybriden Ansatz hin, bei dem sowohl Retrieval-Augmented Generation (RAG) als auch Fine-Tuning strategisch eingesetzt werden.[11]

Eine robuste, Enterprise-Grade-Architektur nutzt Fine-Tuning, um dem Modell beizubringen, wie es denken soll – indem ein tiefes semantisches Verständnis der komplexen hierarchischen Beziehungen innerhalb eines CAD-Assembly-Tree vermittelt wird – während RAG in Verbindung mit MCP dafür genutzt wird, worüber es nachdenken soll, indem die exakten, aktuellen Toleranzen für ein bestimmtes Bauteil aus einer lebenden, autoritativen PLM-Datenbank abgerufen werden.[31]

3.2 Mitigationsstrategien für nicht-deterministische Outputs

Um agentic Workflows in missionskritischen Umgebungen sicher zu deployen, müssen technische Architekturen strenge, mehrschichtige Mitigationsstrategien implementieren:

• Algorithmic Temperature Control und Seeding: Die stochastische Natur des LLM muss bei Engineering-Aufgaben streng begrenzt werden. Dies wird erreicht, indem die Inference-Temperature-Parameter auf nahezu null gesetzt und feste Random Seeds verwendet werden, um bei der Generierung von Automatisierungsskripten oder API-Calls ein Höchstmaß an Reproduzierbarkeit sicherzustellen.[37]
• Deterministic Fallbacks und Bounding: AI-Agents sollten strikt für Workflow-Orchestrierung, generative Design-Space-Exploration und Script-Generierung eingesetzt werden.[22] Die tatsächliche mathematische Validierung und das strukturelle Sign-off müssen jedoch unmittelbar an deterministische Tools weitergeleitet werden – validierte Solver, etablierte Finite-Elemente-Analyse-(FEA)-Methoden und zertifizierte Berechnungsverfahren –, damit sichergestellt ist, dass alle Ergebnisse den kompromisslosen Anforderungen des Engineerings entsprechen.[17]
• Continuous Output Validation via Judge Models: Implementierung spezialisierter „Judge LLMs“ oder strenger regelbasierter Linter, die AI-generierte NX-Open-Skripte automatisch anhand etablierter geometrischer und syntaktischer Constraints verifizieren, bevor innerhalb der CAD-Umgebung irgendeine Ausführung zugelassen wird.[32]
• Human-in-the-Loop (HITL) Checkpoints: Gestaltung der Agent Runtime Environment so, dass die Ausführung automatisch pausiert und kritische Entscheidungsmatrizen oder auffällige geometrische Vorschläge zur Freigabe an einen menschlichen Ingenieur markiert werden. Dadurch verschiebt sich die Rolle der AI von einem einseitigen, autonomen Entscheider hin zu einem schnellen, proaktiven cognitive assistant, der die menschliche Engineering-Fähigkeit verstärkt.[13]

3.3 Vektorisierung von CAD- und Engineering-Daten

Traditionelle RAG-Systeme sind für Text optimiert. Die Vektorisierung von CAD-Daten ist jedoch deutlich komplexer.[43] Engineering-Modelle enthalten tief verschachtelte hierarchische Metadaten, räumliche Constraints, parametrische Beziehungen und umfangreiche Versionshistorien, die präzise erfasst werden müssen, um für AI-Retrieval nutzbar zu sein.[43] Fortgeschrittene Implementierungen erfordern das Parsen proprietärer CAD-Dateien (wie etwa Siemens NX PRT-Dateien), um strukturierte geometrische und räumliche Merkmale zu extrahieren und diese in Sequenzrepräsentationen umzuwandeln, die eine nachgelagerte Natural-Language-Transkription und spatial reasoning durch das LLM unterstützen.[44] Durch den Einsatz fortschrittlicher Vector-Search-Engines zur Verwaltung dieser multidimensionalen Datensätze können Unternehmen LLMs in die Lage versetzen, präzise über physische Bauteile und Baugruppen zu reasoning.[43]

4. Souveräne AI-Infrastruktur: Sicherstellung digitaler Unabhängigkeit in Europa

Da europäische Industrieunternehmen AI zunehmend offensiv adaptieren, führt die Abhängigkeit von US-basierten Hyperscale-Cloud-Providern zu erheblichen Compliance-, Rechts- und Intellectual-Property-Risiken.[45] Die Implikationen des US CLOUD Act, der US-Unternehmen dazu verpflichten kann, auf europäischen Servern gespeicherte Daten an US-Behörden herauszugeben, stehen in direktem Widerspruch zu den europäischen Ambitionen im Bereich Data Sovereignty.[45] Als Reaktion darauf hat sich die Implementierung einer „Sovereign AI“-Infrastruktur von einer theoretischen Präferenz zu einem absoluten strategischen Imperativ für europäische B2B-Technologieführer entwickelt.[7]

4.1 Der strategische Imperativ für Bare-Metal- und On-Premise-Deployments

Sovereign AI verlangt, dass eine Organisation die absolute, kryptografisch abgesicherte Kontrolle über ihre gesamte artificial-intelligence-Infrastruktur behält; sensible Engineering-Daten verlassen niemals die Grenze des Unternehmensnetzwerks, und die Organisation bestimmt vollständig, wie Modelle gesteuert, trainiert und ausgeführt werden.]46] Für regulierte europäische Fertigungsindustrien bietet die Bereitstellung fortschrittlicher LLMs on-premises oder auf privaten, in Europa gehosteten Bare-Metal-Servern drei unbestreitbare strategische Vorteile:

1. Überlegene Performance und deterministische Latenz: Die Ausführung von Inference auf lokaler Bare-Metal-Infrastruktur eliminiert externe Netzwerk-Round-Trips und die Unvorhersehbarkeit gemeinsam genutzter Public-Cloud-Ressourcen. Dies ermöglicht eine Inference-Latenz von unter 20 ms, was eine absolute Voraussetzung für Shopfloor-Automatisierung in Echtzeit, Robotics-Integration und hochfrequente autonome Agent-Loops ist.[47]
2. Superior Performance and Deterministic Latency: Executing inference on local bare-metal infrastructure eliminates external network round-trips and the unpredictability of shared public cloud resources. This enables sub-20ms inference latency, which is an absolute prerequisite for real-time shop floor automation, robotics integration, and high-frequency autonomous agent loops.47
3. Planbare Kostenökonomie: Während Public-Cloud-AI-APIs inkrementell pro Token abrechnen, können agentic Workflows mit hohem Volumen – die kontinuierliches Background-Polling, iteratives Tool-Calling und konstante Metacognition erfordern – zu exponentiell steigenden und unvorhersehbaren Cloud-Computing-Kosten führen. Bare-Metal-Infrastruktur bietet hingegen einen fixen, planbaren operativen Kostenaufwand. Bei Workloads mit einer Auslastung von mehr als 60 % wird der finanzielle Break-even-Punkt für die Anschaffung dedizierter GPU-Hardware typischerweise innerhalb von drei bis acht Monaten erreicht.[47]

4.2 Architektur eines produktionsreifen Sovereign-LLM-Stacks

Ein moderner, produktionsreifer Sovereign-AI-Stack, der komplexe B2B-Engineering-Workflows unterstützen kann, erfordert die anspruchsvolle Orchestrierung mehrerer unterschiedlicher, leistungsstarker Open-Source-Technologien:

4.3 Integration mit Gaia-X und föderierten Datenräumen

Um souveräne Fähigkeiten über die interne Unternehmens-Firewall hinaus zu skalieren und entlang der breiteren europäischen Lieferkette zu kollaborieren, adaptieren Industrien zunehmend das Gaia-X Trust Framework.[48] Es ist entscheidend zu verstehen, dass Gaia-X keine neue Cloud-Plattform ist; vielmehr handelt es sich um einen dezentralen Architekturstandard und ein Regelwerk, das einen transparenten, kontrollierbaren und interoperablen Datenaustausch in ganz Europa sicherstellt und Vendor Lock-in sowie Machtkonzentration verhindert.[6]

Das technische Fundament von Gaia-X, insbesondere das „Danube“-Release, ermöglicht es Organisationen, Daten über unterschiedliche Ökosysteme hinweg sicher föderiert bereitzustellen, indem kryptografische Self-Descriptors, digitale Identifikatoren und Verifiable Credentials genutzt werden.[8] Für einen europäischen Automobilhersteller ermöglicht diese Architektur, dass ein internes agentic AI-System sicher die Materialdatenbank eines Tier-1-Lieferanten nach Carbon-Footprint-Metriken abfragt – die für Environmental Compliance erforderlich sind –, ohne dass der Lieferant dabei jemals seine proprietären CAD-Designs oder sein geistiges Eigentum im Bereich der Fertigung offenlegen muss.[49]

Die Integration von agentic AI mit Gaia-X Data Space Governance Authorities (DSGAs) ermöglicht die automatisierte Durchsetzung sektorspezifischer Compliance-Regeln.8 Dadurch wird sichergestellt, dass Multi-Agent-Systems strikt innerhalb der Grenzen europäischer digitaler Souveränität operieren und gleichzeitig eine grenzüberschreitende Zusammenarbeit nahtlos ermöglichen, während absolutes kryptografisches Trust gewahrt bleibt.[8]

5. Governance von High-Risk-AI: Das Framework des EU AI Act

Die Implementierung von artificial intelligence, insbesondere autonomer agentic Systems, in der europäischen Fertigungsindustrie wird maßgeblich durch den Artificial Intelligence Act der Europäischen Union (EU AI Act) bestimmt. Das Gesetz wurde konzipiert, um Sicherheit, Grundrechte und Accountability zu gewährleisten, und auferlegt der Entwicklung und dem Deployment von AI strenge, kompromisslose technische Anforderungen.[5]

5.1 Risikoklassifizierung im Fertigungskontext

Nach dem EU AI Act werden AI-Systeme rechtlich nach ihrem potenziellen Risiko kategorisiert: Unacceptable (die verboten sind), High, Limited und Minimal.[9] Im Kontext von Industrial Automation, CAD-Generierung und PLM-Orchestrierung werden AI-Agents, die direkt Einfluss auf das Design, Sicherheitsparameter oder die Qualitätskontrolle sicherheitskritischer Produkte nehmen (z. B. Maschinen, Automotive-Komponenten, Medizinprodukte oder Infrastruktur), eindeutig als High-Risk eingestuft.[9]

Diese Klassifizierung löst die verpflichtende, strenge Einhaltung von Kapitel III, Abschnitt 2 des Gesetzes aus und verändert dadurch grundlegend den Software Development Lifecycle, die Risk-Management-Strategien und die operative Governance für B2B-Engineering-Softwareanbieter und System-Deployers.[56]

5.2 Artikel 9–15: Technische und operative Vorgaben

Anbieter (Entwickler) von High-Risk-AI-Systemen müssen ihre Lösungen von Grund auf so architektieren, dass sie die strengen Anforderungen erfüllen, die in den Artikeln 9 bis 15 des EU AI Act festgelegt sind.9 Compliance ist nicht lediglich ein rechtliches Abhakfeld; sie erfordert eine tiefgreifende, architektonische Integration von Governance-Mechanismen.

5.3 Erfüllung der Anforderungen an die technische Dokumentation gemäß Anhang IV

Artikel 11 schreibt vor, dass die technische Dokumentation mindestens die in Anhang IV des Gesetzes ausführlich festgelegten Elemente enthalten muss.59 Diese Anforderung zwingt Organisationen dazu, eine tiefgehende, strukturierte und auditierbare Dokumentation ihrer gesamten Softwarearchitektur und ihres Entwicklungsprozesses zu führen.61 Für B2B-Softwareanbieter, Systemintegratoren und Unternehmen, die kundenspezifische Siemens-NX-Integrationen oder private Cloud-AI-Lösungen deployen, muss die technische Akte gemäß Anhang IV umfassend Folgendes dokumentieren:

1. Systemelemente und Entwicklungsprozess: Eine hochgradig granulare Aufschlüsselung der Systemarchitektur. Diese muss die Dokumentation sämtlicher verwendeter vortrainierter Drittanbieter-Modelle, der zugrunde liegenden Designlogik, der mathematischen Ziele zur Parameteroptimierung sowie der spezifischen rechnerischen Ressourcen umfassen, die für Training und Inference zugewiesen wurden.[59]
2. System Elements and Development Process: A highly granular breakdown of the system architecture. This must include documentation of any pre-trained third-party models utilized, the underlying design logic, the mathematical goals for parameter optimization, and the specific computational resources allocated for training and inference.59
3. Data-Governance-Dokumentation: Umfassende Datenblätter, die sämtliche Trainingsmethoden, die Datenherkunft, Labeling-Protokolle und Datenbereinigungstechniken beschreiben, die auf die Datensätze angewendet wurden.[59]
4. Monitoring, Funktionsweise und Kontrolle: Detaillierte Performance-Metriken, explizit definierte Fähigkeitsgrenzen, vorhersehbare unbeabsichtigte Ergebnisse sowie die spezifischen technischen Vorkehrungen, die für menschliche Aufsicht implementiert wurden.[59]
5. Validierung und Testing: Signierte und datierte Berichte aller Test-Logs, die die Genauigkeit, Robustheit des Systems sowie etwaige Bewertungen hinsichtlich diskriminierender Auswirkungen rigoros dokumentieren.[59]
6. Post-Market-Monitoring-Plan: Ein detailliertes operatives Framework im Einklang mit Artikel [72], das exakt darlegt, wie die Performance, Sicherheit und Compliance des Systems in der Live-Produktionsumgebung fortlaufend evaluiert werden.[59]

Angesichts der enormen Komplexität der Erstellung und Pflege dieser Dokumentation setzen zukunftsorientierte Organisationen zunehmend spezialisierte LLMs und Compliance-Tools ein, um Lücken in technischen Akten automatisch zu identifizieren und sicherzustellen, dass die Architekturdokumentation jederzeit präzise mit den sich weiterentwickelnden rechtlichen Vorgaben des Gesetzes in Einklang bleibt.[63]

6. Der digitale Produktpass (DPP): Ein Multi-Agent-Anwendungsfall

Die Konvergenz von agentic AI, Sovereign Infrastructure und europäischer Regulierung zeigt sich am deutlichsten in den bevorstehenden Anforderungen des Digital Product Passport (DPP). Der DPP, der im Rahmen der Ecodesign for Sustainable Products Regulation (ESPR) vorgeschrieben ist, ist ein umfassender digitaler Datensatz, der darauf ausgelegt ist, die Nachverfolgbarkeit, Zirkularität und Nachhaltigkeit von Produkten, die auf dem EU-Markt in Verkehr gebracht werden, drastisch zu verbessern.[27]

6.1 Regulatorische Zeitpläne und technische Spezifikationen

Hersteller müssen sich auf strenge Regeln hinsichtlich Datengenauigkeit, Interoperabilität und Serialisierung vorbereiten, wobei eine breite Implementierung rasch nach der Etablierung der DPP-Systeme erforderlich sein wird.[27] Die Verordnung schreibt vor, dass der DPP über einen maschinenlesbaren Datenträger (wie etwa einen QR-Code, RFID-Chip oder eine standardisierte URL) zugänglich sein muss, der physisch am Produkt angebracht ist.[27]

Das technische Framework für den DPP ist äußerst anspruchsvoll. Es schreibt vor, dass DPP-Daten ohne Vendor Lock-in übertragbar sein, von unabhängigen Drittanbieter-Service-Providern gehostet und über die gesamte Lieferkette hinweg hochgradig interoperabel sein müssen.[27] Der Pass selbst muss mehrere Dimensionen hochspezifischer Engineering-, Rechts- und Lifecycle-Daten aggregieren, was für Hersteller eine enorme Herausforderung im Datenmanagement schafft.[27] Zu den zentralen Datenanforderungen gehören:

• Eindeutige Produktidentifikatoren (UID, Chargennummern, Seriennummern, TARIC-Warencodes).[64]
• Exakte chemische Zusammensetzung und granulare Materialaufschlüsselungen.[64]
• Umweltbezogene Performance-Metriken, insbesondere einschließlich Global Warming Potential (GWP), umfassender Carbon-Footprint-Berechnungen und Ressourcennutzungsdaten.[27]
• Rechtliche Compliance-Dokumentation (CE-Kennzeichnungen, Sicherheitszertifizierungen).[27]
• Anweisungen für das End-of-Life-Handling, umfassende Repairability-Richtlinien und Recyclability-Indizes.[27]

6.2 Einsatz von agentic AI für die Aggregation von DPP-Daten

Die primäre architektonische Herausforderung bei der Implementierung des DPP ist eine extreme Datenfragmentierung. Die erforderlichen Informationen für einen einzelnen Produktpass sind nur selten in einem einheitlichen Repository gespeichert; vielmehr sind sie über komplexe CAD-Modelle, finanzielle ERP-Systeme, unstrukturierte Lieferanten-PDFs und disparate Lifecycle Assessment (LCA)-Tools verteilt.[64] Die manuelle Zusammenstellung und Verifizierung dieser Daten für jede einzelne Produktvariante ist wirtschaftlich und operativ nicht umsetzbar.

Agentic AI-Systeme liefern das notwendige architektonische connective tissue, um die Generierung von DPPs effektiv zu automatisieren.[21] Durch die Nutzung des Model Context Protocol (MCP) zur Standardisierung von Tool-Calling kann ein Multi-Agent-System den gesamten Prozess der Datenerhebung und -synthese dynamisch orchestrieren:

1. Gleichzeitig fragt ein PLM Retrieval Agent Teamcenter ab, um spezifische Lieferantenknoten, Teilevarianten und historische Beschaffungsdaten zu identifizieren.
2. Simultaneously, a PLM Retrieval Agent queries Teamcenter to identify specific supplier nodes, part variants, and historical procurement data.
3. Ein Compliance Agent parst unstrukturierte Material Safety Data Sheets (MSDS) von Lieferanten autonom unter Nutzung einer On-Premise-RAG-Pipeline und standardisiert die Daten zur chemischen Zusammensetzung, um sicherzustellen, dass sie den ESPR-Anforderungen entsprechen.
4. Finally, a Synthesis Agent aggregates these verified data streams, calculates the baseline carbon footprint, and formats the final output into the strict, standardized JSON/XML schema required for the European registry submission.[52]

Dieser souveräne agentic Workflow gewährleistet nicht nur die kontinuierliche Einhaltung der sich weiterentwickelnden DPP-Vorgaben, sondern etabliert auch eine einheitliche Sustainability-Datenebene, die sich automatisch und in Echtzeit aktualisiert, während Engineering-Designs innerhalb der PLM-Umgebung iteriert werden.[64]

7. Strategische Implementierung und architektonische Integration

Die Realisierung von Sovereign Agentic AI in der europäischen Fertigungsindustrie kann nicht durch die Beschaffung von Standardsoftware von der Stange erreicht werden. Sie erfordert tiefgehende, spezialisierte Expertise in der kundenspezifischen Softwareentwicklung, in fortschrittlicher Cloud- und On-Premise-Infrastruktur sowie in komplexer Systemintegration. Der architektonische Ansatz, der sich aus dem Zusammenspiel von EU AI Act, Gaia-X und MCP ergibt, erfordert eine ganzheitliche Strategie der digitalen Transformation.

Organisationen müssen der Entwicklung von maßgeschneiderter Middleware und kundenspezifischen Agent-Orchestratoren Priorität einräumen, die die Lücke zwischen High-Performance-LLMs und deterministischen Engineering-Kernen wie Siemens NX nahtlos überbrücken können. Die Implementierung robuster, automatisierter digitaler Prozesse ist essenziell, um die umfangreichen Datenpipelines zu verwalten, die für RAG, Fine-Tuning und kontinuierliches Compliance-Monitoring erforderlich sind. Durch die Verbindung tiefgehender Expertise in der Siemens-NX-/Open-API-Entwicklung mit modernster, lokalisierter AI-Infrastruktur können Unternehmen kundenspezifische, compliance-native Softwarelösungen aufbauen, die sicher innerhalb der strengen Vorgaben europäischer Data Sovereignty operieren.

8. Fazit: Die Zukunft der autonomen europäischen Fertigungsindustrie

Die Integration von artificial intelligence in die europäische Fertigungsindustrie hat die Implementierung isolierter, generativer Algorithmen endgültig hinter sich gelassen. Die Branche entwickelt sich mit hoher Geschwindigkeit hin zum Deployment komplexer Multi-Agent-Systems, die in der Lage sind, die starren mathematischen Strukturen von Engineering-Plattformen wie Siemens NX autonom zu navigieren und gleichzeitig nahtlos und sicher über föderierte externe Data Spaces hinweg zu interagieren.[12]

Die operative Tragfähigkeit dieser autonomen Workflows hängt jedoch vollständig von der Etablierung eines robusten Agentic Trust Fabric ab, das durch kompromisslose Einhaltung von Data Sovereignty und regulatorischen Frameworks getragen wird.13 Um im Jahr 2026 und darüber hinaus erfolgreich zu sein, müssen B2B-CTOs, Engineering-Leader und Technologiearchitekten die Implementierung einer Sovereign-AI-Infrastruktur priorisieren. Indem sie agentic Architekturen in sicheren On-Premise-Umgebungen verankern, die Tool-Integration über das Model Context Protocol standardisieren und sämtliche Entwicklungspraktiken konsequent an den Vorgaben des EU AI Act und von Gaia-X ausrichten, können Organisationen die transformativen operativen Effizienzgewinne des autonomen Engineerings sicher erschließen.8 Diese strategische Ausrichtung gewährleistet nicht nur absolute regulatorische Compliance und den Schutz von IP, sondern sichert auch einen klaren, nachhaltigen Wettbewerbsvorteil für die Zukunft der europäischen industriellen Innovation.

Literaturverzeichnis

1. Agentic AI Architectures with Patterns, Frameworks & MCP, accessed on March 10, 2026, https://mehmetozkaya.medium.com/agentic-ai-architectures-with-patterns-frameworks-mcp-25afcc97ae62
2. What is Agentic AI? – IBM, accessed on March 10, 2026, https://www.ibm.com/think/topics/agentic-ai
3. AI-DRIVEN COMPUTER-AIDED DESIGN (CAD) SYSTEMS: LEVERAGING NEURAL NETWORKS FOR OPTIMIZED ENGINEERING PRODUCT DEVELOPMENT – TPM – Testing, Psychometrics, Methodology in Applied Psychology, accessed on March 10, 2026, https://tpmap.org/submission/index.php/tpm/article/download/2331/1782/5049
4. Realizing the role of agentic AI – Thought Leadership, accessed on March 10, 2026, https://blogs.sw.siemens.com/thought-leadership/realizing-the-role-of-agentic-ai/
5. European approach to artificial intelligence | Shaping Europe’s digital future, accessed on March 10, 2026, https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence
6. Focus on digital sovereignty in Europe: Gaia-X as a central topic at the 2025 Digital Summit, accessed on March 10, 2026, https://gaia-x.eu/focus-on-digital-sovereignty-in-europe-gaia-x-as-a-central-topic-at-the-2025-digital-summit/
7. Building a Sovereign AI Stack: From Zero to POC (Guide) – DEV Community, accessed on March 10, 2026, https://dev.to/janealesi/building-a-sovereign-ai-stack-from-zero-to-poc-guide-1id6
8. Gaia-X Enters Season 2.0 of Data Spaces and Digital Ecosystems …, accessed on March 10, 2026, https://gaia-x.eu/gaia-x-enters-season-two-of-dataspaces-and-digital-ecosystems-with-summit-2025/
9. Whitepaper The European Artificial Intelligence Act – Fraunhofer …, accessed on March 10, 2026, https://www.iks.fraunhofer.de/content/dam/iks/documents/whitepaper-eu-ai-act-fraunhofer-iks.pdf
10. Introducing the Model Context Protocol – Anthropic, accessed on March 10, 2026, https://www.anthropic.com/news/model-context-protocol
11. RAG vs. fine-tuning – Red Hat, accessed on March 10, 2026, https://www.redhat.com/en/topics/ai/rag-vs-fine-tuning
12. Siemens introduces AI agents for industrial automation | Press | Company, accessed on March 10, 2026, https://press.siemens.com/global/en/pressrelease/siemens-introduces-ai-agents-industrial-automation
13. New Book: Agentic AI Engineering for Building Production-Grade AI Agents – Medium, accessed on March 10, 2026, https://medium.com/generative-ai-revolution-ai-native-transformation/new-book-agentic-ai-engineering-for-building-production-grade-ai-agents-4dc121128e45
14. What is agentic AI: A comprehensive 2026 guide – TileDB, accessed on March 10, 2026, https://www.tiledb.com/blog/what-is-agentic-ai
15. AI Business Trends 2025 | Google Cloud, accessed on March 10, 2026, https://cloud.google.com/resources/ai-trends-report
16. NX Open API Programming – Siemens Xcelerator Academy, accessed on March 10, 2026, https://training.plm.automation.siemens.com/ilt/iltdescription.cfm?pID=TR13110_______NX___10.0___2500
17. Agentic Engineering: How AI Agents Can Accelerate Advanced Modeling and Simulation Workflows – Rescale, accessed on March 10, 2026, https://rescale.com/blog/agentic-engineering-for-modeling-and-simulation-workflows/
18. Manufacturing’s 2026 Mandate: From AI Pilot to Agentic Profit – Dataiku, accessed on March 10, 2026, https://www.dataiku.com/stories/blog/manufacturing-ai-trends-2026
19. AI in PLM: What Are Vendors Really Delivering, What Did I Learn …, accessed on March 10, 2026, https://beyondplm.com/2025/11/23/ai-in-plm-what-are-vendors-really-delivering-what-did-i-learn-and-is-the-hard-problem-still-unsolved/
20. AI Capabilities in NX CAD | Design faster with AI – Blogs – Siemens, accessed on March 10, 2026, https://blogs.sw.siemens.com/nx-design/ai-cad/
21. Best AI for PLM: PLM Search Tools and Assistants (2026) – CoLab Software, accessed on March 10, 2026, https://www.colabsoftware.com/post/best-ai-for-plm-plm-search-tools-and-assistants-2026
22. AI Agents Transform Engineering Workflows – Design News, accessed on March 10, 2026, https://www.designnews.com/artificial-intelligence/closing-the-gap-between-ai-s-promise-and-engineering-impact
23. The Model Context Protocol (MCP): A Game-Changer for Agentic AI …Part 1 | by nikhil goyal, accessed on March 10, 2026, https://medium.com/@goynikhil/the-model-context-protocol-mcp-a-game-changer-for-agentic-ai-6a55c180efb4
24. Agent studio: A multi-agent system for systems engineering | The Art of the Possible, accessed on March 10, 2026, https://blogs.sw.siemens.com/art-of-the-possible/agent-studio-a-multi-agent-system-for-systems-engineering/
25. 25 Agentic AI Terms Every Business User Needs To Know – Salesforce, accessed on March 10, 2026, https://www.salesforce.com/blog/agentic-ai-definitions/
26. Siemens brings AI copilot, immersive design and integrated fluid and thermal simulation to NX, accessed on March 10, 2026, https://news.siemens.com/en-us/siemens-designcenter-nx-summer-2025/
27. Digital Product Passport: What’s a DPP – OneClick LCA, accessed on March 10, 2026, https://oneclicklca.com/en/resources/articles/digital-product-passport-whats-a-dpp
28. Code execution with MCP: building more efficient AI agents – Anthropic, accessed on March 10, 2026, https://www.anthropic.com/engineering/code-execution-with-mcp
29. Building Agentic AI apps with Model Context Protocol, accessed on March 10, 2026, https://www.youtube.com/watch?v=xPedq8X87vg
30. What is the Model Context Protocol (MCP)?, accessed on March 10, 2026, https://modelcontextprotocol.io/introduction
31. Agentic AI & MCP – developer.siemens.com, accessed on March 10, 2026, https://developer.siemens.com/building-x-openness/dev-guide/mcp.html
32. Model Context Protocol Explained: The Key to Agentic Healthcare – Artera, accessed on March 10, 2026, https://artera.io/blog/model-context-protocol-explanation/
33. How to build a simple agentic AI server with MCP | Red Hat Developer, accessed on March 10, 2026, https://developers.redhat.com/articles/2025/08/12/how-build-simple-agentic-ai-server-mcp
34. Disruptive Innovation or Industry Buzz? Understanding Model Context Protocol’s Role in Data-Driven Agentic AI | Informatica, accessed on March 10, 2026, https://www.informatica.com/blogs/disruptive-innovation-or-industry-buzz-understanding-model-context-protocols-role-in-data-driven-agentic-ai.html
35. What is the Model Context Protocol (MCP)? – Databricks, accessed on March 10, 2026, https://www.databricks.com/blog/what-is-model-context-protocol
36. Has anyone tried to use AI using NX Open ? specifically calling a LLM end point with a prompt and then processing that answer within a NX session ? Just curious to see if anyone has tried this and learn from any experiences. – Community, accessed on March 10, 2026, https://community.sw.siemens.com/s/question/0D5Vb000012iaRAKAY/has-anyone-tried-to-use-ai-using-nx-open-specifically-calling-a-llm-end-point-with-a-prompt-and-then-processing-that-answer-within-a-nx-session-just-curious-to-see-if-anyone-has-tried-this-and-learn-from-any-experiences
37. What are non-deterministic AI outputs? – Statsig, accessed on March 10, 2026, https://www.statsig.com/perspectives/what-are-non-deterministic-ai-outputs-
38. RAG vs Fine-tuning vs Prompt Engineering: Everything You Need to Know | InterSystems, accessed on March 10, 2026, https://www.intersystems.com/resources/rag-vs-fine-tuning-vs-prompt-engineering-everything-you-need-to-know/
39. RAG vs fine-tuning vs. prompt engineering – IBM, accessed on March 10, 2026, https://www.ibm.com/think/topics/rag-vs-fine-tuning-vs-prompt-engineering
40. RAG vs Fine-Tuning: What Actually Works in Production? | by Pratik Chaudhari – Medium, accessed on March 10, 2026, https://medium.com/@pratikchaudhariworks/rag-vs-fine-tuning-what-actually-works-in-production-b05bde81db0f
41. RAG vs. Fine-Tuning: Choosing the Right Approach, accessed on March 10, 2026, https://www.thenile.dev/blog/fine-tuning-or-rag
42. Generative AI for CAD Automation: Leveraging Large Language Models for 3D Modelling, accessed on March 10, 2026, https://arxiv.org/html/2508.00843v1
43. Private AI for CAD and Engineering Data – inteliScience, accessed on March 10, 2026, https://inteliscience.net/case-studies/private-ai-for-cad-and-engineering-data/
44. HistCAD: Geometrically Constrained Parametric History-based CAD Dataset – arXiv, accessed on March 10, 2026, https://arxiv.org/html/2602.19171v1
45. Gaia-X warns US hyperscalers about selling cloud sovereignty | Channel Dive, accessed on March 10, 2026, https://www.channeldive.com/news/gaia-x-warns-us-hyperscalers-about-selling-sovereignty/807362/
46. Sovereign AI | alfatier, accessed on March 10, 2026, https://alfatier.io/en/services/sovereign-ai/
47. Own Your LLM Stack: On-Premise Deployment, accessed on March 10, 2026, https://blog.easecloud.io/ai-cloud/own-your-llm-stack/
48. Gaia-X Trust Framework, accessed on March 10, 2026, https://gaia-x.eu/wp-content/uploads/2024/05/An-Introduction-to-the-Gaia-X-Trust-Framework_2024-V4.pdf
49. Gaia-X: the bid for a sovereign European cloud – Polytechnique Insights, accessed on March 10, 2026, https://www.polytechnique-insights.com/en/columns/digital/gaia-x-the-bid-for-a-sovereign-european-cloud/
50. European Initiative for Data Sovereignty Released a Trust Framework – InfoQ, accessed on March 10, 2026, https://www.infoq.com/news/2026/01/data-sovereignty-trust-framework/
51. GAIA-X: Technical Architecture – bundeswirtschaftsministerium.de, accessed on March 10, 2026, https://www.bundeswirtschaftsministerium.de/Redaktion/EN/Publikationen/gaia-x-technical-architecture.pdf?__blob=publicationFile&v=1
52. How to prepare for the Digital Product Passport: our solution for European businesses, accessed on March 10, 2026, https://www.rina.org/en/media/News/2026/03/06/digital-product-passport
53. Gaia-X context – Gaia-X Architecture Document – main version (40f2e2e8), accessed on March 10, 2026, https://gaia-x.gitlab.io/technical-committee/architecture-working-group/architecture-document/gaia-x_context/
54. Gaia-X Summit 2025 Showcases the Next Phase of Trusted Digital Ecosystems, accessed on March 10, 2026, https://gaia-x.eu/gaia-x-summit-2025-showcases-the-next-phase-of-trusted-digital-ecosystems/
55. White Paper on Artificial Intelligence – A European approach to excellence and trust, accessed on March 10, 2026, https://commission.europa.eu/system/files/2020-02/commission-white-paper-artificial-intelligence-feb2020_en.pdf
56. High-level summary of the AI Act | EU Artificial Intelligence Act, accessed on March 10, 2026, https://artificialintelligenceact.eu/high-level-summary/
57. Technical documentation obligations for AI providers: drafting manuals – Hogan Lovells, accessed on March 10, 2026, https://www.hoganlovells.com/en/publications/technical-documentation-obligations-for-ai-providers-drafting-manuals
58. White Paper: Effectively Implementing the EU AI Act – Governance, Control and Transparency for AI Systems – Technology Insights, accessed on March 10, 2026, https://tcblog.protiviti.com/2025/08/12/white-paper-effectively-implementing-the-eu-ai-act-governance-control-and-transparency-for-ai-systems/
59. Annex IV: Technical Documentation Referred to in Article 11(1) | EU …, accessed on March 10, 2026, https://artificialintelligenceact.eu/annex/4/
60. Article 11: Technical Documentation | EU Artificial Intelligence Act, accessed on March 10, 2026, https://artificialintelligenceact.eu/article/11/
61. Technical Documentation for High-Risk AI Systems – Blue Arrow, accessed on March 10, 2026, https://bluearrow.ai/hrai-technical-documentation/
62. AI Act Service Desk – Annex IV – European Union, accessed on March 10, 2026, https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-4
63. Simplifying software compliance: AI technologies in drafting technical documentation for the AI Act – PMC, accessed on March 10, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC11965209/
64. Digital Product Passport Requirements 2026 | EU DPP & ESPR Guide for Manufacturers, accessed on March 10, 2026, https://www.eandox.com/resources/digital-product-passport-requirements-2026-eu-dpp-espr-guide-manufacturers
65. Digital Product Passports (DPPs) required by EU legislation across sectors: ESPR, toys, detergents, batteries, and more – Circularise, accessed on March 10, 2026, https://www.circularise.com/blogs/dpps-required-by-eu-legislation-across-sectors
66. The EU’s new Digital Product Passport (DPP): everything you need to know, accessed on March 10, 2026, https://blog.worldfavor.com/the-eus-new-digital-product-passport-dpp-everything-you-need-to-know
67. Unlocking the power of Model Context Protocol (MCP) on AWS | Artificial Intelligence, accessed on March 10, 2026, https://aws.amazon.com/blogs/machine-learning/unlocking-the-power-of-model-context-protocol-mcp-on-aws/