Agentic Engineering DSGVO-konform: On-Premise-Stack

"Agentic Engineering" ist der präzisere Begriff für das, was im Frühjahr 2026 aus der Nische der KI-Enthusiasten in den DACH-Entwickler-Mainstream gesickert ist. Unter dem früheren Label "Vibe Coding" wird das Thema in Deutschland laut Ahrefs (Stand Frühjahr 2026) rund 18.000 Mal pro Monat gesucht — eine Zahl, die man für einen Anglizismus in einem technischen Fachfeld erstmal setzen lassen muss. Die frühe Diskussion geht auf Andrej Karpathys Tweet vom Februar 2025 zurück: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Das Problem mit dem Begriff ist, dass er mehrere sehr unterschiedliche Praktiken zusammenfasst — und dass er in seiner naiven Form auf DSGVO-Territorium krachend scheitert. Ich möchte mir in diesem Beitrag anschauen: Was bedeutet Agentic Engineering eigentlich konkret, wo stößt es an Grenzen, und wie kann man den produktiven Kern des Ansatzes auf einer On-Premise-KI-Infrastruktur betreiben, ohne dass Source-Code, Kundendaten und OAuth-Tokens in US-Clouds wandern.

Was Agentic Engineering wirklich ist — und was nicht

Im Kern meint Agentic Engineering vier Dinge, die oft durcheinandergehen:

1. Prompt-first-Entwicklung: Man beschreibt in natürlicher Sprache, was man will, und nimmt den generierten Code als Ausgangspunkt.
2. Agentische Workflows: Ein KI-Agent führt mehrere Schritte selbstständig aus — File lesen, Änderungen vorschlagen, Tests laufen lassen, ggf. neu versuchen.
3. Tool-Use über MCP: Der Agent kann strukturiert mit Datenbanken, APIs und Dateisystemen sprechen, statt nur Text zu generieren.
4. Kontinuierliche Session-Memory: Der Agent behält Projekt-Kontext über mehrere Interaktionen hinweg bei.

Wer nur Punkt 1 macht, macht im Grunde "assistiertes Programmieren" — das gibt es seit GitHub Copilot 2021. Erst die Kombination aus 2, 3 und 4 macht Agentic Engineering zu dem, was es heute in Claude Code, Cursor, Aider und dem Hermes Agent ist.

Thoughtworks beschreibt im Technology Radar Vol. 34 in diesem Zusammenhang das Risiko von "codebase cognitive debt": KI-generierter Code kann schneller wachsen als das Teamverständnis. Wenn ein Agent in 20 Minuten 800 Zeilen Code schreibt und der Entwickler nur 200 davon tatsächlich versteht, dann akkumuliert sich Tech Debt in hoher Geschwindigkeit. Agentic Engineering ist nicht per se gut oder schlecht — es ist ein Leistungsverstärker, der sowohl gute als auch schlechte Engineering-Praxis skaliert.

Wo DSGVO ins Spiel kommt

Agentic Engineering in seiner Standard-Ausprägung läuft heute primär über amerikanische Frontier-Modelle: Claude Opus 4.7, GPT-5, Gemini 2.5. Das ist praktisch, solange man Tutorial-Projekte baut oder Open-Source-Bibliotheken hackt. Sobald aber Produktions-Quellcode, Kundendaten oder regulierte Informationen ins Spiel kommen, wird es heikel.

Drei konkrete Probleme tauchen regelmäßig auf:

Erstens: Der US-CLOUD-Act (u. a. 18 U.S.C. § 2713) verpflichtet US-Provider zur Herausgabe von Daten, die ihrer "possession, custody, or control" unterliegen — unabhängig vom Speicherort. Das betrifft jede Inference-Anfrage an Anthropic-, OpenAI- oder Google-Endpoints.

Zweitens: Die Schrems-II-Entscheidung des EuGH hat klargestellt, dass Übermittlungen personenbezogener Daten in die USA nicht pauschal zulässig sind und zusätzliche wirksame Schutzmaßnahmen brauchen. Ein Prompt, der Kundennamen, E-Mail-Adressen oder interne Dokumente enthält, fällt potenziell darunter.

Drittens: Der EU AI Act erhöht je nach Rolle und Risikoklasse die Anforderungen an Dokumentation, Nachvollziehbarkeit und Governance. Bei geschlossenen Frontier-Modellen ist dieser Nachweis oft deutlich schwieriger als bei kontrollierbaren, selbst betriebenen Stacks.

Unabhängig von einzelnen Vorfällen bleibt ein viertes, operatives Problem: Wer Agentic Engineering über eine Kette aus SaaS-Integrationen betreibt, erweitert seine Angriffsfläche mit jedem zusätzlichen OAuth-Connector und jedem externen Tool.

Kurz für Entscheider: Worum geht's hier eigentlich?

Falls du kein Entwickler bist: Das alles bedeutet übersetzt, dass die produktivsten KI-Coding-Tools für deutsche oder österreichische Unternehmen mit sensibler Datenlage aktuell nicht ohne rechtliche Hausaufgaben nutzbar sind. Wenn du für dein Team eine praktikable Alternative suchst, die dieselben Arbeitsweisen ermöglicht, ohne dass Source-Code oder Kundendaten in die USA wandern, ist das der richtige Moment, sich das unten beschriebene Setup anzuschauen — oder uns kurz zu kontaktieren, damit wir gemeinsam prüfen, welcher Teil davon in deinem konkreten Fall Sinn ergibt.

Ein On-Premise-Stack, der Agentic Engineering trägt

Die gute Nachricht: Der Open-Source-Werkzeugkasten für AI-native Entwicklung ist im April 2026 so vollständig wie nie zuvor. Mit einer überschaubaren Anzahl von Komponenten lässt sich ein Stack bauen, der die vier Agentic-Engineering-Kernfähigkeiten (Prompt-first, Agenten, MCP, Memory) lokal abbildet. Hier ist ein pragmatischer Referenz-Aufbau, wie wir ihn für unsere AI-OpenStack-Lösung verwenden:

• Inference-Layer: vLLM als Hochdurchsatz-Inference-Server für GPU-Cluster. Laut Supported-Models-Doku werden in aktuellen Releases u. a. Gemma-, Qwen- und Llama-Familien unterstützt.
• API-Gateway: LiteLLM als OpenAI-kompatibler Proxy. Damit sprechen alle IDE-Integrationen (Cursor, Continue, Aider) direkt mit dem internen Cluster, als wäre es api.openai.com. In der 1.83.x-Reihe kamen unter anderem mehrere Budget-Fenster sowie MCP/OAuth-Härtungen hinzu (siehe Release Notes).
• Vektordatenbank: Qdrant als Standard-Vektorstore für RAG- und Memory-Anwendungen. Rust-basiert, skaliert horizontal, bietet saubere Python- und HTTP-APIs.
• Orchestrierung: Windmill für die Komposition von Agenten-Flows, Scheduler-Jobs und internen Operationen. Seit v1.681.0 automatisches Testen von Skripten und Flows beim Deploy.
• MCP-Server: Projektspezifische MCP-Server für Git, Jira, interne Datenbanken und Nextcloud — strukturiert über ein zentrales Registry, pro Nutzer authentifiziert, mit Token-Rotation.
• Frontend-Optionen: Für den Entwicklungsablauf setzen wir primär auf OpenCode-orientierte Coding-Frontends (CLI-/IDE-nah) und unsere eigenen, aufgabenspezifischen UIs für strukturierte Prozesse (Ticket-Triage, Dokumenten-Review, Code-Review-Agent). OpenWebUI bleibt optional für allgemeine Chat-Use-Cases außerhalb des Engineering-Flows.

Das Ganze ist keine theoretische Architektur. Wir betreiben diesen Stack bei Kunden in unterschiedlichen Größenordnungen — und bieten das Setup alternativ als Managed Service aus unserem eigenen Rechenzentrum an, sodass der Einstieg nicht an eigener GPU-Beschaffung scheitert.

Der LiteLLM-Proxy als Kern-Baustein

Der praktische Einstieg ist fast immer LiteLLM. Grund: Entwickler wollen weiter in ihrer gewohnten IDE arbeiten — und Cursor, Continue, Aider und die meisten anderen Tools sprechen OpenAI-Protokoll. LiteLLM spiegelt das Protokoll lokal und routet die Anfragen an dein Modell deiner Wahl.

Minimalbeispiel für ein config.yaml, das lokales Qwen 3.6 über vLLM einbindet und zusätzlich eine eigene Large-Model-Route für Kimi/DeepSeek bereitstellt:

model_list:
  - model_name: coding-fast
    litellm_params:
      model: openai/Qwen3.6-35B-A3B-Instruct
      api_base: http://vllm-qwen.local:8000/v1
      api_key: "local-cluster"
      order: 1

  - model_name: coding-large
    litellm_params:
      model: openai/moonshotai/Kimi-K2-Instruct
      api_base: http://vllm-kimi.local:8001/v1
      api_key: "local-cluster"
      order: 1
      rpm: 30

  - model_name: coding-large
    litellm_params:
      model: openai/deepseek-ai/DeepSeek-V3
      api_base: http://vllm-deepseek.local:8002/v1
      api_key: "local-cluster"
      order: 2
      rpm: 20

general_settings:
  master_key: sk-litellm-master-xxx
  database_url: postgres://litellm:litellm@pg:5432/litellm

router_settings:
  routing_strategy: latency-based-routing
  redis_host: redis.local
  redis_port: 6379

litellm_settings:
  budget_duration: 30d
  max_budget: 500
  success_callback: ["prometheus"]

Wenn du gezielt mit sehr großen Open-Weight-Modellen arbeiten willst, ist genau das der professionelle Hebel: Kimi-K2-Instruct ist als Open-Weight-Modell mit Modified-MIT-Lizenz und 1T-MoE/32B-aktiv dokumentiert, DeepSeek-V3 und DeepSeek-R1 liegen in der 671B/37B-Klasse. vLLM führt Kimi- und DeepSeek-Familien mittlerweile explizit in den unterstützten Modellen. Über ein gemeinsames model_name wie coding-large bleibt die IDE-Integration stabil, während LiteLLM intern Prioritäten, Cooldowns, Retries und Fallbacks steuert (siehe Routing-Doku und Config-Settings).

Nach einem litellm --config config.yaml --port 4000 lässt sich der Proxy in Cursor als Custom-OpenAI-Endpoint (http://litellm.internal:4000/v1) eintragen. Entwickler bemerken davon in der Praxis nichts — es sei denn, sie schauen explizit auf den HTTP-Target.

Der entscheidende Unterschied zur öffentlichen API: Bei sauberer Segmentierung verlassen Tokens, Prompts und generierter Code das interne Netz nicht. Das ist der Hebel, mit dem Agentic Engineering bei regulierten Datenbeständen überhaupt möglich wird.

Agenten, MCP und die Governance-Frage

Agentic Engineering im vollen Sinn ist agentisch. Das heißt: Der Agent darf Dateien lesen und schreiben, Tests ausführen, Commits vorschlagen, und idealerweise auch mit internen Systemen sprechen — Jira, Confluence, GitLab, Nextcloud. Genau an dieser Stelle wird MCP (Model Context Protocol) relevant.

MCP standardisiert, wie ein Agent mit Tools interagiert. Statt für jeden Anbieter eine eigene Integration zu bauen, beschreibt jeder Tool-Anbieter seine Fähigkeiten in einem einheitlichen Protokoll, und der Agent kann sie generisch aufrufen. Das MCP-Spezifikationsdokument wird mittlerweile von Anthropic, Cursor und Continue breit genutzt. In GitLab 18.11 ist der CI Expert Agent als Beta in der Duo Agent Platform gestartet, was den Trend zu agentischen, toolfähigen Workflows auch im Enterprise-Umfeld unterstreicht.

Die zentrale Governance-Frage lautet: Wie stellt man sicher, dass ein kompromittierter MCP-Server nicht zum Einfallstor für das gesamte Unternehmen wird? Unsere Empfehlung, die sich in Kundensetups bewährt hat, folgt vier Regeln:

1. Per-User-OAuth-Tokens statt geteilter Service-Accounts. Moderne LiteLLM-Releases unterstützen entsprechende Konfigurationsmuster für MCP/OAuth-Setups.
2. Minimal-Scopes. Ein GitLab-MCP-Server braucht nur Read-Access auf die relevanten Projekte, kein api-Scope.
3. Token-Rotation automatisieren. Idealerweise über kurze TTLs und automatisierte Refresh-Ketten.
4. Audit-Log bei allen Agent-Actions. Wer hat wann welches Tool mit welchen Parametern aufgerufen? Ohne dieses Log kein Compliance-Nachweis.

Wer das sauber aufsetzt, hat nicht nur eine regelkonforme Agentic-Engineering-Umgebung, sondern auch eine belastbare Grundlage für interne Audits und Compliance-Nachweise (inklusive Logging-Anforderungen in relevanten AI-Act-Szenarien).

Modell-Auswahl: Welches lokale Modell taugt für Agentic Engineering?

Der Stand im April 2026 ist erfreulich klar. Drei Modelle haben wir in den letzten Wochen intensiv getestet und können sie guten Gewissens für Coding-Workloads empfehlen:

• Qwen 3.6-35B-A3B — leistungsstarkes Open-Weight-MoE-Modell mit Fokus auf agentische Coding-Use-Cases; aktuelle Releases und Benchmarks findest du im Qwen Research Hub. In vielen Setups unser aktueller Default für allgemeines Coding.
• Gemma 4 (Apple-Silicon-freundliche Laufzeitoption) — in den Ollama-Releases wird die Modellunterstützung laufend ausgebaut; eignet sich gut als lokale Backup-Runtime auf Entwicklerrechnern.
• Mistral-Familie (z. B. Medium für API-Workloads) — solide Coding-Performance; für On-Premise-Szenarien unbedingt zwischen API-Angeboten und verfügbaren Open-Weight-/Lizenzmodellen unterscheiden.

Die frühere Voreinstellung Llama war im ersten Halbjahr 2025 oft naheliegend. Inzwischen ändern sich Release- und Lizenzstrategien der großen Anbieter jedoch schnell — deshalb prüfen wir Modellwahl und Lizenzlage pro Projekt regelmäßig neu, statt dauerhaft auf eine einzige Modellfamilie zu setzen.

Was du realistisch erwarten kannst

Zum Schluss eine ehrliche Einschätzung: Ein lokaler Agentic-Engineering-Stack ist nicht gratis, weder rechnerisch noch konzeptuell. Die Hardware-Dimensionierung für ein 20-Entwickler-Team liegt je nach Nutzungsintensität bei etwa einem Server mit zwei H100-GPUs — investiv oder, wie viele unserer Kunden es tun, als Managed Service bezogen. Die Einrichtung des Stacks selbst ist an einem Projekttag machbar, wenn jemand mit Erfahrung vor Ort ist. Die eigentliche Arbeit steckt danach in der Governance: MCP-Server sauber scopen, OAuth-Ketten absichern, Audit-Logs konsumierbar machen.

Gleichzeitig: Was wir regelmäßig sehen, ist, dass Teams nach zwei bis drei Wochen spürbar produktiver werden, weil sie Prompts nicht mehr selbst-zensieren müssen ("Darf das in Claude rein?") und weil lokale Modelle bei Code-Review- und Refactoring-Aufgaben heute ein sehr hohes Niveau erreichen. Die Lücke zwischen proprietärem Frontier und lokalem Open-Source ist bei Coding in vielen Fällen so klein geworden, dass die rechtliche und operative Ruhe eines On-Premise-Setups den kleinen Benchmark-Rückstand aufwiegt.

Fazit

Agentic Engineering ist kein Ersatz für solide Engineering-Praxis — aber als Produktivitätsschicht ist der Ansatz real und wird bleiben. Die Frage, die sich in Europa unterscheidet von der in Silicon Valley, ist nicht "Ob wir es nutzen", sondern "Auf welcher Infrastruktur". Ein On-Premise-Stack aus vLLM, LiteLLM, Qdrant, Windmill und einem klug kuratierten Set von MCP-Servern erlaubt dieselben Arbeitsabläufe wie die Frontier-Cloud-Angebote — und reduziert gleichzeitig CLOUD-Act-Exponierung, OAuth-Supply-Chain-Risiken und Compliance-Lücken deutlich.

Wenn du darüber nachdenkst, AI-native Entwicklung in deinem Team zu etablieren und dabei nicht in die nächste DSGVO-Baustelle laufen möchtest, melde dich bei uns. Wir schauen uns deinen konkreten Workflow an und skizzieren den kleinstmöglichen Stack, der für deine Situation funktioniert — sei es auf eigener Hardware oder als Managed Service aus unserem Rechenzentrum. Tieferer Kontext zur regulatorischen Lage findest du in unserem Pillar-Post zu Sovereign AI: DSGVO-konforme KI-Plattform 2026.

---

Dieser Artikel beschreibt unsere aktuelle Referenz-Architektur (Stand April 2026) und stellt keine Rechtsberatung dar. Für konkrete DSGVO-, Schrems-II- oder AI-Act-Fragen empfiehlt sich die Abstimmung mit einem auf IT-Recht spezialisierten Rechtsanwalt.