[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-multi-agent-systeme-mcp-dsgvo-konform-aufbauen":3},"\u003Cp>In den letzten zwölf Monaten ist viel über AI-Agenten geschrieben worden. Die meisten Artikel zeigen Single-Agent-Setups mit einem Chat-Frontend und ein paar Tools im Hintergrund. Das funktioniert für Demos. In der Praxis sieht das ganz anders aus — und der Sprung von einem Agent zu mehreren parallel laufenden Agents, die sich Tools teilen und über ein gemeinsames Protokoll reden, ist genau der Punkt, an dem die meisten Setups auseinanderbrechen.\u003C\u002Fp>\n\n\u003Cp>Wir bauen solche Setups nicht als Demo-Chatbot, sondern als Referenzarchitektur für produktive Unternehmensumgebungen: vLLM\u002FLiteLLM als Modell- und Routing-Schicht, LangChain Deep Agents als Orchestrierung, MCP für Tool-Anbindung und Docker\u002FKubernetes-Governance als Enforcement-Layer. Dieser Artikel erklärt, wie der Stack sauber zusammensteckt — und warum der durch den Digital Omnibus diskutierte spätere AI-Act-Zeitplan genau jetzt ein gutes Umsetzungsfenster für DACH-Unternehmen öffnet.\u003C\u002Fp>\n\n\u003Cp>Bevor wir tief einsteigen, ein kurzer Absatz für alle, die nicht jeden Tag in YAML-Files leben: Wenn du jemanden brauchst, der den Stack für dein Team evaluiert, aufsetzt, betreibt und sauber an deine bestehenden Systeme andockt — meld dich gern direkt \u003Ca href=\"\u002Fde-at\u002Fcontact\">bei uns über das Kontaktformular\u003C\u002Fa>. Dazu beraten wir gerne.\u003C\u002Fp>\n\n\u003Ch2>Was ist ein MCP-Server eigentlich?\u003C\u002Fh2>\n\u003Cp>Das Model Context Protocol (MCP) wurde Ende 2024 von Anthropic vorgestellt und ist 2026 eines der wichtigsten offenen Protokolle für die Kommunikation zwischen AI-Modellen und Tools. Mehrere Anbieter, IDEs und Agent-Frameworks unterstützen MCP direkt oder über kompatible Connectoren; bei Open-Weight-Modellen entsteht der Anschluss meist über Agent-Frameworks, Gateways oder lokale Runtimes.\u003C\u002Fp>\n\u003Cp>Technisch ist MCP ein JSON-RPC-Protokoll über stdio oder HTTP\u002FSSE. Ein \u003Cstrong>MCP-Server\u003C\u002Fstrong> stellt Tools, Resources und Prompts bereit — also: \"ich kann eine Mail schicken\", \"ich kann eine Datei aus dem Filesystem lesen\", \"ich kann eine SQL-Query gegen diese Datenbank ausführen\". Ein \u003Cstrong>MCP-Client\u003C\u002Fstrong> (das ist meistens dein AI-Modell oder der Agent, der das Modell steuert) ruft diese Tools auf, wenn das Modell entscheidet, dass es sie braucht.\u003C\u002Fp>\n\u003Cp>Der wichtige Punkt: MCP ist nicht das Modell. MCP ist die Schicht \u003Cstrong>zwischen\u003C\u002Fstrong> Modell und Welt. Wer das Protokoll sauber einsetzt, hat dieselbe Tool-Library für Claude, GPT, Llama, Qwen und Kimi — ohne das Wheel jedes Mal neu zu erfinden. Wer das nicht tut, baut Custom-Integrations gegen jede API einzeln. Das ist die Lücke, in die alle aktuellen Multi-Agent-Frameworks hineinwachsen.\u003C\u002Fp>\n\n\u003Ch2>Warum jetzt Multi-Agent statt Single-Agent?\u003C\u002Fh2>\n\u003Cp>Das ist die berechtigte Frage. Bis Mitte 2025 war Single-Agent das ehrliche Default — ein Modell mit ein paar Tools, das eine Aufgabe vom Anfang bis zum Ende durchzieht. Funktioniert. Skaliert aber nicht für komplexe Workflows.\u003C\u002Fp>\n\u003Cp>Multi-Agent macht den Unterschied bei drei Klassen von Problemen. \u003Cstrong>Erstens\u003C\u002Fstrong> Aufgaben mit echtem Parallelismus — wenn du gleichzeitig recherchieren, codieren und Security-prüfen willst, brauchst du drei spezialisierte Agents, nicht einen, der das nacheinander macht. In diese Richtung zielt auch \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab mit der Duo Agent Platform\u003C\u002Fa>: Software Developer, Security Analyst und Deep Research als getrennte Rollen statt ein einzelner Allzweck-Agent.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Zweitens\u003C\u002Fstrong> Long-Running-Workflows mit unterschiedlichen Modell-Anforderungen. Ein Reasoning-Step mit einem großen Modell ist teuer und langsam — den willst du nicht für jeden Tool-Call laufen lassen. Ein kleineres Routing-Modell reicht für viele Zwischenschritte. Multi-Agent erlaubt diese Aufteilung sauber.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Drittens\u003C\u002Fstrong> Governance und Trennung von Privilegien. Ein Agent, der Code committet, sollte keinen Zugriff auf Kunden-PII haben. Ein Agent, der Customer-Support-Tickets liest, sollte keine Deployments triggern. Multi-Agent macht diese Trennung explizit — über getrennte MCP-Server-Allowlists pro Agent. In diese Richtung geht auch Dockers \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fproducts\u002Fai-governance\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">AI Governance Suite\u003C\u002Fa>: Centralized Control über Agent-Execution, Network-Reach, Credentials und MCP-Tool-Allowance pro Agent.\u003C\u002Fp>\n\n\u003Ch2>Referenzarchitektur — von unten nach oben\u003C\u002Fh2>\n\u003Cp>Hier kommt der konkrete Aufbau, den wir für Kundenprojekte und interne Evaluierungen als belastbare Zielarchitektur verwenden. Wenn keine eigene Hardware vorhanden ist, läuft der Modell-Stack in einem regionalen Rechenzentrum, ohne dass du selbst Hardware beschaffen musst.\u003C\u002Fp>\n\n\u003Ch3>Inference-Layer: vLLM v0.21 mit drei Modell-Lanes\u003C\u002Fh3>\n\u003Cp>Auf der Inference-Schicht setzen wir auf \u003Cstrong>vLLM v0.21.0\u003C\u002Fstrong> als Inference-Engine und \u003Cstrong>LiteLLM\u003C\u002Fstrong> als Routing-Layer. Sinnvoll sind drei Modell-Lanes; die konkrete Modellwahl bleibt evaluierungsabhängig und richtet sich nach Hardware, Latenz, Datenschutzklasse und Kostenrahmen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Reasoning-Lane:\u003C\u002Fstrong> ein starkes Reasoning-Modell für komplexe Multi-Step-Tasks, je nach Datenklasse lokal oder über einen freigegebenen Provider.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Generation-Lane:\u003C\u002Fstrong> ein Code- und Textmodell der 30B-Klasse für längere Output-Tasks, Dokumentation und Refactorings.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Routing-Lane:\u003C\u002Fstrong> ein kleines, schnelles Modell für Classification, Routing-Entscheidungen und Tool-Selection.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>vLLMs neue \u003Cstrong>KV-Offloading + Hybrid Memory Allocator (HMA)\u003C\u002Fstrong> machen diese Aufteilung deutlich realistischer als noch vor sechs Monaten. Trotzdem bleibt die Hardware-Frage ein Architekturthema: Wie viele Modelle parallel laufen können, hängt an VRAM, Kontextlängen, Batch-Größen und Ziel-Latenzen. Das \u003Cstrong>TOKENSPEED_MLA Attention Backend\u003C\u002Fstrong> ist vor allem für Teams relevant, die Blackwell-GPUs evaluieren und DeepSeek-\u002FKimi-ähnliche MLA-Workloads sauber testen wollen.\u003C\u002Fp>\n\u003Cp>Falls eigene Hardware für dich nicht in Frage kommt: Der Modell-Stack kann in einem regionalen Rechenzentrum betrieben werden, ohne dass du selbst Hardware beschaffen musst. Das senkt die Einstiegshürde, weil keine GPU-Investition vorab nötig ist. Mehr dazu besprechen wir gerne über \u003Ca href=\"\u002Fde-at\u002Fcontact\">unsere Kontaktseite\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch3>Orchestrierung: LangChain Deep Agents v0.6\u003C\u002Fh3>\n\u003Cp>Auf der Orchestrierungs-Schicht ist \u003Cstrong>LangChain Deep Agents v0.6\u003C\u002Fstrong> seit dem \u003Ca href=\"https:\u002F\u002Fblog.langchain.com\" target=\"_blank\" rel=\"noopener noreferrer\">Mai-Release vom 13. Mai 2026\u003C\u002Fa> ein naheliegender Baustein. Das Framework definiert, startet und überwacht die einzelnen Agents.\u003C\u002Fp>\n\u003Cp>Die wichtigste Architektur-Entscheidung der Mai-Release ist \u003Cstrong>DeltaChannel\u003C\u002Fstrong> — der neue Checkpoint-Mechanismus. Statt bei jedem Agent-Step das komplette State-Object zu serialisieren, wird nur die Differenz zum vorherigen Checkpoint persistiert. Klingt nach Detail, ist aber bei Long-Running-Workflows ein Spielentscheider: Research-, Audit- oder Migrations-Agents laufen oft über Stunden oder Tage, und Full-Snapshot-Checkpointing wird dabei schnell teuer und langsam.\u003C\u002Fp>\n\u003Cp>Dazu kommen \u003Cstrong>Harness Profiles\u003C\u002Fstrong> für Modell-spezifische Tuning-Parameter (jeder Agent kann sein Modell-Profil unabhängig setzen) und \u003Cstrong>ContextHubBackend\u003C\u002Fstrong> als versioniertes File-Management. Letzteres ist relevant, wenn mehrere Agents auf gemeinsame Files zugreifen — ein Code-Reviewer-Agent darf nicht die Files lesen, die ein anderer Agent gerade ändert, ohne Versions-Konflikte zu produzieren.\u003C\u002Fp>\n\u003Cp>Für die Framework-Integration in der Front-End-Schicht ist \u003Cstrong>@langchain\u002Fvue\u003C\u002Fstrong> für Nuxt\u002FVue-Stacks spannend; die offiziellen v1-Integrationen für React, Vue, Svelte und Angular sind im Mai-Release final geworden.\u003C\u002Fp>\n\n\u003Ch3>Tool-Layer: MCP-Server (lokal + Atlassian + interne Tools)\u003C\u002Fh3>\n\u003Cp>Auf der MCP-Layer planen wir typischerweise mehrere Server in drei Gruppen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Lokale Tools:\u003C\u002Fstrong> Filesystem-MCP (mit Jail pro Agent), GitLab-MCP, Postgres-MCP, Vector-DB-MCP (zum Beispiel Qdrant).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Atlassian:\u003C\u002Fstrong> Rovo Studio mit Open-MCP-Skills für Confluence, Jira und Bitbucket. Atlassian hat den \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fblog\u002Fdevops\" target=\"_blank\" rel=\"noopener noreferrer\">MCP-Support auf der Team '26 Conference\u003C\u002Fa> breit ausgebaut, mit eigenen Analytics für Token-Costs und Agent-Optimization. Die genannten 48 % Token-Cost-Reduktion und 44 % bessere Graph-Search-Genauigkeit sind Herstellerangaben und sollten in jedem eigenen Workflow nachgemessen werden.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Interne Tools:\u003C\u002Fstrong> Custom-MCP-Server für kundenspezifische APIs, Customer-Databases (gefiltert per RLS), Document-Storage über Nextcloud oder bestehende interne Ablagen.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Jeder MCP-Server bekommt eine Tool-Allowlist pro Agent. Der Customer-Support-Agent sieht zum Beispiel nur Read-Tools für Tickets und Documentation, der Developer-Agent hat Write-Zugriff auf Code-Branches, aber keinen Zugriff auf Customer-PII. Diese Trennung wird über Governance-Regeln und Container-Isolation durchgesetzt — dazu gleich mehr.\u003C\u002Fp>\n\n\u003Ch3>Governance: Docker AI Governance + Container-Isolation\u003C\u002Fh3>\n\u003Cp>Der Enforcement-Layer kann mit \u003Cstrong>Docker AI Governance\u003C\u002Fstrong> und Container-Isolation aufgebaut werden. Jeder MCP-Server läuft in einem eigenen Container, mit definierten Network-Policies, Credential-Scopes und Tool-Allowance-Rules. Der Agent kann nur die MCP-Server erreichen, die seine Allowlist explizit zulässt — das ist Zero-Trust auf Agent-Ebene.\u003C\u002Fp>\n\u003Cp>Dazu kommt \u003Cstrong>Gordon GA\u003C\u002Fstrong> in Docker Desktop 4.61 für Dev-Workstations, der MCP- und Kubernetes-Support nativ bietet — und persistent local memory für Konversationen, die einen Reboot überleben. Für die Cluster-Seite ist \u003Cstrong>Kubernetes v1.36 \"Haru\"\u003C\u002Fstrong> mit \u003Cstrong>User Namespaces als Stable-Feature\u003C\u002Fstrong> relevant. Das ist wichtig, weil Multi-Tenant-Container-Setups mit User-Namespace-Isolation deutlich strenger sind als die alte Root-Container-Welt.\u003C\u002Fp>\n\u003Cp>Ein Wort zum Thema GitHub Copilot Cloud Agent in dieser Stack-Architektur: Copilot kann auf der Dev-Seite sinnvoll sein, zum Beispiel mit dem \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-for-eclipse\" target=\"_blank\" rel=\"noopener noreferrer\">Eclipse-Open-Source-Plugin\u003C\u002Fa>. Für Code, der Customer-Daten berührt, braucht es aber eine klare Policy: Closed-Vendor-APIs nur, wenn Vertrag, Datenklasse und Freigabeprozess das ausdrücklich erlauben; sonst läuft der Workflow über selbst kontrollierte Modelle und isolierte Tool-Zugriffe.\u003C\u002Fp>\n\n\u003Ch2>DSGVO und EU AI Act — was musst du wirklich erfüllen?\u003C\u002Fh2>\n\u003Cp>Hier wird es konkret. Wer in DACH Multi-Agent-Systeme produktiv betreibt, hat zwei Compliance-Schichten zu erfüllen: die \u003Cstrong>DSGVO\u003C\u002Fstrong> (seit 2018 in Kraft) und den \u003Cstrong>EU AI Act\u003C\u002Fstrong> mit seinen Annex-Klassen.\u003C\u002Fp>\n\u003Cp>Die DSGVO-Anforderungen für Multi-Agent-Systeme lassen sich auf drei Punkte runterbrechen: \u003Cstrong>Datenminimierung\u003C\u002Fstrong> (jeder Agent sieht nur, was er sehen muss), \u003Cstrong>Zweckbindung\u003C\u002Fstrong> (Customer-Daten, die für Support gesammelt wurden, dürfen nicht in Marketing-Automation laufen, ohne separate Rechtsgrundlage), und \u003Cstrong>Auditbarkeit\u003C\u002Fstrong> (welcher Agent hat wann welches Tool mit welchem Input aufgerufen?). Die Architektur adressiert alle drei Punkte über die MCP-Allowlist-Schicht plus zentrale Audit-Logs auf Container-Ebene.\u003C\u002Fp>\n\u003Cp>Beim \u003Cstrong>EU AI Act\u003C\u002Fstrong> ist die Lage gerade in Bewegung. Am 7. Mai 2026 wurde eine Einigung über das \u003Cstrong>Digital Omnibus\u003C\u002Fstrong> berichtet, die die Compliance-Deadline für \u003Cstrong>Annex-III-High-Risk-AI-Systeme von 2. August 2026 auf 2. Dezember 2027 verschieben würde\u003C\u002Fstrong> — 16 Monate mehr Zeit. Annex-I-HRAIS würde von 2. August 2027 auf 2. August 2028 rutschen. Wer also einen Agent für HR-Screening, Kreditscoring oder Bildungsbewertung baut, hätte mehr Spielraum für eine saubere Implementierung. Die Quelle ist \u003Ca href=\"https:\u002F\u002Fnetzpolitik.org\" target=\"_blank\" rel=\"noopener noreferrer\">netzpolitik.org\u003C\u002Fa>, die die Einigung kritisch einordnet.\u003C\u002Fp>\n\u003Cp>Wichtig: Dieser spätere Zeitplan würde \u003Cstrong>nicht\u003C\u002Fstrong> alle Anforderungen betreffen. Laut der Einordnung bleiben frühere Pflichten und Verbote rund um generative Inhalte, nicht-konsensuelle Intimate-Deepfakes und CSAM-Generation relevant. Wer Multi-Modal-Agents mit Bildgenerierung betreibt, sollte diese Schranken jetzt in die Tool-Allowlist einbauen, nicht erst 2027.\u003C\u002Fp>\n\u003Cp>Strategisch lesen wir den diskutierten Zeitplan so: Die nächsten 18 Monate sind die Phase, in der DACH-Unternehmen sich für DSGVO-konforme Multi-Agent-Architekturen positionieren können. \u003Cstrong>Wer 2026 sauber plant und pilotiert, ist 2027 deutlich entspannter. Wer 2027 erst anfängt, kommt in die HRAIS-Compliance-Welle, in der viele Teams gleichzeitig dieselben Beratungs-Ressourcen brauchen.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Ch2>Wo unsere AI-OpenStack-Lösung andockt\u003C\u002Fh2>\n\u003Cp>Das beschriebene Setup — vLLM\u002FLiteLLM mit drei Modell-Lanes, LangChain Deep Agents, MCP-Server für lokale und remote Tools, Docker AI Governance, Kubernetes v1.36 als Plattform — ist die Zielarchitektur, die wir mit unserer AI-OpenStack-Lösung unterstützen. Kernkomponenten sind vLLM, LiteLLM als Routing-Layer, Windmill für Workflow-Orchestrierung, Nextcloud für Document-Storage und Qdrant als Vektordatenbank. LDAP\u002FAD-Integration für saubere User-Management-Anbindung an bestehende Identitätsprovider kommt dazu.\u003C\u002Fp>\n\u003Cp>OpenWebUI kann dabei eines von mehreren Frontends sein — die AI-OpenStack-Lösung lässt sich zusätzlich mit eigenen, auf strukturierte Prozesse optimierten UIs kombinieren, zum Beispiel für Customer-Support-Workflows oder interne Knowledge-Suche. OpenWebUI hat seine Stärken (15+ Web-Search-Provider, lokale RAG mit mehreren Vector-DBs, Multi-Engine Content Extraction), aber die Limitierung ist klar: Es ist ein generisches Chat-Frontend, kein Workflow-Orchestrator. Für strukturierte Agent-Workflows brauchst du eine andere Schicht.\u003C\u002Fp>\n\u003Cp>Wer das Setup auf eigener Hardware betreiben will, kann das tun — wir liefern den Stack mit Configuration-as-Code und einer dokumentierten Deployment-Pipeline. Wer keine eigene Hardware aufbauen will, kann den Modell-Stack in einem regionalen Rechenzentrum betreiben lassen, ohne selbst GPUs beschaffen zu müssen. In beiden Fällen wird vorab geklärt, welche Daten wo verarbeitet werden und welche Modell-Lane welche Datenklasse sehen darf.\u003C\u002Fp>\n\n\u003Ch2>Ein konkretes Beispiel — wie das im Alltag aussieht\u003C\u002Fh2>\n\u003Cp>Ein typischer Ziel-Workflow, damit das nicht abstrakt bleibt: Ein Customer-Service-Mitarbeiter bekommt ein Ticket, in dem ein Kunde nachfragt, warum eine bestimmte Funktion in der Software nicht mehr funktioniert.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\"># Pseudo-Workflow-Definition in unserer Orchestrierung\nworkflow: customer-issue-triage\nagents:\n  - id: research-agent\n    model: local-reasoning-model\n    mcp_servers:\n      - confluence-mcp (read-only)\n      - gitlab-mcp (read-only)\n      - vector-db-mcp (read-only)\n    timeout: 5m\n  - id: code-agent\n    model: code-generation-model\n    mcp_servers:\n      - gitlab-mcp (read-only)\n      - filesystem-mcp (jailed)\n    timeout: 3m\n  - id: response-agent\n    model: small-routing-model\n    mcp_servers:\n      - confluence-mcp (read-only)\n    timeout: 2m\ngovernance:\n  enforced_by: docker-ai-governance\n  allowlist: per-agent\n  audit_log: central-loki\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Schritt eins: Der \u003Ccode>research-agent\u003C\u002Fcode> sucht in Confluence nach relevanter Dokumentation, in GitLab nach relevanten Issues und Merge Requests der letzten 90 Tage, und in der Vector-DB (Qdrant) nach semantisch ähnlichen alten Tickets. Dafür wird ein Reasoning-Modell verwendet, weil hier wirklich gedacht werden muss.\u003C\u002Fp>\n\u003Cp>Schritt zwei (parallel zur Research): Der \u003Ccode>code-agent\u003C\u002Fcode> schaut sich die genannte Funktion im aktuellen Code an. Dafür reicht oft ein spezialisiertes Code-Modell — es muss kein großes Reasoning-Modell sein, nur solides Code-Verständnis.\u003C\u002Fp>\n\u003Cp>Schritt drei: Der \u003Ccode>response-agent\u003C\u002Fcode> formuliert auf Basis der Research- und Code-Ergebnisse einen Antwort-Entwurf für den Customer-Service-Mitarbeiter. Ein kleineres Modell reicht, weil das ein strukturierter Text-Generation-Task ist, kein tiefes Reasoning.\u003C\u002Fp>\n\u003Cp>Der Customer-Service-Mitarbeiter sieht den Antwort-Entwurf, kann ihn editieren und absenden. \u003Cstrong>Wichtig:\u003C\u002Fstrong> Kein Agent hat Schreib-Zugriff auf das Ticket-System. Kein Agent kann eine Antwort autonom absenden. Die finale Entscheidung bleibt beim Menschen — das ist nicht nur DSGVO-relevant (Artikel 22 zu automatisierten Entscheidungen), sondern auch eine fundamentale Architektur-Entscheidung, die wir in jedem Multi-Agent-Workflow durchziehen.\u003C\u002Fp>\n\n\u003Ch2>Was wir gelernt haben — ehrlich\u003C\u002Fh2>\n\u003Cp>Drei Dinge, die ich gerne vor sechs Monaten gewusst hätte.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Erstens:\u003C\u002Fstrong> Multi-Agent skaliert die Komplexität nicht-linear. Drei Agents sind nicht drei Mal so kompliziert wie einer, sondern eher zehn Mal. Race-Conditions zwischen Agents, die parallel auf dieselben Files zugreifen, sind das nervigste Problem. ContextHubBackend in LangChain Deep Agents v0.6 hilft hier deutlich — aber wer ältere Stacks fährt, braucht trotzdem eine saubere Version-Locking-Schicht.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Zweitens:\u003C\u002Fstrong> Die Tool-Allowlist pro Agent muss \u003Cstrong>vom ersten Tag an\u003C\u002Fstrong> sauber sein. Wenn du nachträglich einbaust, was ein Agent darf, hast du schon verloren. Im Default-Deny ist die einzige Architektur, die mit der DSGVO und mit dem späteren Audit-Workflow zusammenpasst.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Drittens:\u003C\u002Fstrong> Der diskutierte spätere EU-AI-Act-Zeitplan im Digital Omnibus ist eine Atempause, kein Freifahrtschein. Wer 2027 plötzlich merkt, dass das HRAIS-Inventarisierungs-Modell aus dem AI Office nicht zum eigenen Setup passt, hat ein Problem. Die Compliance-Schicht gehört deshalb jetzt in die Architektur — auch wenn einzelne Fristen später greifen.\u003C\u002Fp>\n\n\u003Ch2>Fazit\u003C\u002Fh2>\n\u003Cp>Multi-Agent-Systeme sind 2026 in DACH nah an produktiven Enterprise-Setups. vLLM v0.21 GA, LangChain Deep Agents mit DeltaChannel, Docker AI Governance und MCP als offenes Tool-Protokoll liefern das technische Fundament. Der EU AI Act gibt mit dem Digital Omnibus voraussichtlich zusätzlichen Spielraum, in dem du dich für DSGVO-konforme Architekturen positionieren kannst. Die Atlassian-Rovo-Studio-Welle macht MCP zu einem wichtigen Skill- und Tool-Layer für interne Systeme. Und mit Qdrant als Vektordatenbank, Nextcloud als Document-Storage, klaren Modell-Lanes und regionalem Betrieb bleibt der Stack in deinem kontrollierten Hoheitsbereich.\u003C\u002Fp>\n\n\u003Cp>Wenn du den Stack für dein Team evaluieren, aufsetzen, betreiben oder an bestehende Systeme andocken willst — meld dich gern direkt \u003Ca href=\"\u002Fde-at\u002Fcontact\">bei uns über das Kontaktformular\u003C\u002Fa>. Wir beraten gerne zu eigener Hardware, bestehender Private-Cloud oder Managed Betrieb in einem regionalen Rechenzentrum, ohne dass du selbst Hardware beschaffen musst.\u003C\u002Fp>\n\n\u003Cp>Vertiefender Kontext zur Architektur und zur DSGVO-Lage findest du in unseren Pillars zu \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fmcp-server-selbst-hosten-dsgvo-konformes-setup\">MCP-Server selbst hosten\u003C\u002Fa>, \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fagentic-engineering-2026-dsgvo-mistral-vllm-cline\">Agentic Engineering 2026 mit Mistral, vLLM und Cline\u003C\u002Fa> und \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fkimi-k2-selbst-hosten-dsgvo-konformes-1t-moe-coding-modell\">Kimi K2 selbst hosten — realistische Einordnung\u003C\u002Fa>.\u003C\u002Fp>\n"]