KI Orchestration · Daten bleiben im Haus · n8n, offene Modelle, DLP

KI im Betrieb. Daten im Haus. Modell egal — Architektur trägt.

Souverän, modell-unabhängig, DMZ-tauglich. Cloud-API ist Option, nicht Standard.

Künstliche Intelligenz (KI) im Betrieb orchestriert — mit einer Architektur, die ohne Datenversand an US- oder China-Cloud funktioniert: n8n als Ablauf-Engine, offene Modelle wie Llama oder Mistral mit lokaler Inferenz, OpenCode als Entwicklungs-Agent, DLP-Filter beim Datenausgang. On-Prem, DMZ oder bei einem souveränen DACH-Hoster (AD IT Systems, IONOS, Hetzner, Open Telekom Cloud, StackIT). Cloud-Modelle (Anthropic, OpenAI, Google) sind Option, nicht Standard.

Lass uns reden Spezialisierungen
Architektur-Stack

Drei Schichten.
Eine bleibt im Haus.

AI ohne Cloud-Lock ist 2026 keine Forschungsfrage mehr, sondern Architektur-Wahl. Bitkom Cloud-Monitor 2024 zeigt: 65 % der DACH-Unternehmen bevorzugen deutsche Cloud oder Multi-Cloud mit DE-Anker, 41 % explizit aus Souveränitäts-Gründen. US CLOUD Act und unsichere EU-US-Datenadequacy machen den Frame doppelt scharf. Drei Schichten tragen jede souveräne AI-Operation, kombinierbar mit Cloud-APIs als Option, aber ohne sie zwingend zu brauchen.

Open-Weights Llama · Mistral · Qwen · Mixtral

Inferenz-Modelle mit kommerzieller Nutzungslizenz, lauffähig auf eigener GPU-Hardware oder bei souveränen DACH-Hostern. Llama 3.3 70B und Mistral Mixtral 8x22B (Apache 2.0) als Default-Wahl für DACH-B2B-Mid-Market. Qwen und DeepSeek als Reasoning-Optionen, aber wegen China-Origin für KRITIS und Verteidigung mit Compliance-Caveat. Quantisierung (int8 / int4) macht 70B-Modelle auf einer einzelnen H100 oder zwei A100 lauffähig. Modell-Wechsel ohne Skill-Neubau.

Quelle: Meta Llama 3.3 (12/2024) · Mixtral 8x22B (Apache 2.0) · Mistral Research License
n8n + OpenCode Workflow- und Engineering-Layer

n8n als self-hosted Workflow-Engine mit AI-Nodes für lokale Modelle und Cloud-APIs gleichermaßen — Mail-Triage, Document-Routing, RFQ-Automation, ERP-Sync laufen als ausführbare Workflows. OpenCode als terminal-basierter Engineering-Agent, modell-agnostisch, kann lokale Inferenz oder Cloud-API ansprechen. Beide on-prem-fähig, DSGVO-kompatibel ohne Drittland-Transfer.

Quelle: n8n.io · sst/opencode · self-hosted Sustainable License
DLP-Egress Daten-Hoheit auf Aufruf-Ebene

Wenn Cloud-API doch Sinn ergibt (Frontier-Reasoning, OCR-Speziallast), prüft eine DLP-Egress-Schicht jeden Aufruf: Kunden-IDs, interne Endpoints, sensible Strings werden vor dem Versand maskiert oder geblockt. Audit-Log pro Aufruf, Annex-III-Doku-fähig. Sovereignty ist Architektur-Default, Cloud-Egress die kontrollierte Ausnahme.

Quelle: NIS2 + KRITIS + EU AI Act Art. 10 Datengovernance-Pflichten
Vier Spezialisierungen

Eine Architektur.
Vier Einstiegs-Trigger.

Welche Spezialisierung zu euch passt, hängt nicht von Marketing-Wunsch ab, sondern vom Trigger im Betrieb. Die folgende Matrix zeigt für jede Zeile den Einstiegs-Anlass, das Phase-1-Ergebnis und den Sovereignty-Pfad.

Spezialisierung Anlass im Betrieb Phase-1-Ergebnis Sovereignty-Default
AI Readiness Audit Vorstand verlangt Strategie, Shadow-AI im Haus, kein neutrales Vendor-Urteil, KRITIS- oder NIS2-Druck. Schriftliche Entscheidungsgrundlage mit Use-Case-Liste, Sovereignty-Mapping, AI-Act-Filter, Roadmap. Vendor-neutrale Bewertung Cloud vs. On-Prem pro Use-Case, ohne Reseller-Bias.
AI in Engineering Operations Codebase-Konventionen werden ignoriert, Senior-Review-Bottleneck, Code-Versand an US-Cloud blockiert. Skill-Map des Codebases, OpenCode-Setup mit lokalem Modell, erste produktive Skills im Pilot-Team. OpenCode plus Open-Weights-Modell auf eigener Hardware, Cloud-API als optionaler Boost für Frontier-Reasoning.
AI Content Operations Content-Output-Druck steigt, Brand-Voice droht zu verwässern, Voice-Daten sollen nicht an externe Provider. Voice-Extraction als ausführbarer Voice-Lock, n8n-Pipeline mit lokaler Inferenz, Drift-Metrik dokumentiert. n8n on-prem, Open-Weights-Inferenz für Voice-Review, Cloud nur für nicht-sensitive Outputs optional.
Spryker plus AI Spryker stabil im Betrieb, ACP-Apps gekauft aber ungenutzt, Customer-Daten sollen nicht an Vertex AI. Stack-Audit mit ACP-Aktivierungs-Status, Use-Case-Map, Sovereignty-Optionen pro Use-Case. Spryker-Glue als modell-agnostische Anbindung, lokale Reorder-Modelle als Alternative zu Vertex AI.
Architektur in der Praxis

Drei Pattern, die Sovereignty kosten.

Drei Pattern aus aktiven Mandaten — was im Discovery-Workshop und in den ersten Pilot-Wochen regelmäßig sichtbar wird, wenn AI-Setups gegen ihre Datenschutz-Realität laufen.

  1. Pattern 01 · Cloud-Default-Bias

    „Wir nehmen einfach OpenAI" — bis Legal kommt.

    Pilots starten mit Cloud-Frontier-API, weil das schnell geht. Drei Wochen später kommt die Datenschutz-Folgenabschätzung, Drittland-Transfer-Frage, KRITIS-Auditor. Was als Schnellstart gedacht war, wird zum Re-Architekturieren mit Open-Weights-Inferenz und DLP-Egress. Wer Sovereignty-Default von Tag 1 plant, vermeidet die Schleife, ohne Cloud-Optionen zu verlieren.

    Folge
    Pilot-Pause für Re-Architektur unter Compliance-Druck
    Frame-Reset
    On-Prem-Default, Cloud als kontrollierte Option
  2. Pattern 02 · Modell-Lock

    Skills sind ans Vendor-Featureset getackert.

    Wer Skills nur gegen einen Vendor-spezifischen Skill-Mechanismus baut, kann später nicht ohne Komplettumbau wechseln. Wir bauen Workflows als n8n-Graphen mit Tool-Calling-Spezifikationen, die mit Llama, Mistral, Qwen, Anthropic und OpenAI gleichermaßen sprechen. Modell-Wechsel ist Konfigurations-Aufgabe, nicht Re-Implementation. Open-Source-Frameworks (LangChain, LangGraph, CrewAI) sind die portablen Bauteile.

    Risiko
    Vendor-Skill-Lock erzwingt Komplettumbau
    Frame-Reset
    Workflows als portable Graphen, nicht als Vendor-Feature
  3. Pattern 03 · Governance-Nachgedanke

    DLP, Audit-Logs, Approval-Gates kommen erst beim Betriebsrat.

    Pilots laufen frei und werden produktiv geschaltet. Dann erst kommt Compliance-Review, Betriebsrat, DSGVO-Folgenabschätzung. Pilot-Pause, Nachbau, Frust auf allen Seiten. Wir bauen Governance-Hooks von Tag 1 ein: DLP-Egress-Filter pro Workflow, n8n-Execution-Logs als Audit-Trail, Approval-Gates für sensitive Aktionen. Compliance ist nicht Bremse, sondern Plattform-Anforderung.

    Folge
    Pilot-Pause für Compliance-Nachbau
    Frame-Reset
    Governance-Hooks ab Workflow-Tag-Eins

Sovereignty, Modell-Portabilität und Governance lassen sich als eine Architektur bauen, nicht als drei separate Workshops. Das ist der Unterschied zwischen Werkbank und Whitepaper.

Bevor ihr anruft

Fünf Fragen, fünf ehrliche Antworten.

„Was bedeutet souveräne AI-Architektur konkret?"
Datenhoheit über die volle Inferenz-Strecke: euer Prompt, eure Geschäftsdaten und der Modell-Output verlassen euer Netz nicht. Wir bauen Workflows mit n8n und einem Open-Weights-Modell (Llama, Mistral, Qwen oder Mixtral) auf eigener GPU-Hardware oder bei einem souveränen DACH-Hoster. Cloud-Frontier-APIs bleiben optional pro Use-Case, mit DLP-Egress vorgeschaltet — aber nicht als Default.
„Müssen wir uns für ein Modell entscheiden?"
Nein. Skill-Architektur, n8n-Workflows und Governance-Pattern sind modell-agnostisch. On-Prem-Default ist meist Llama 3.x oder Mistral, Cloud-Frontier (Anthropic, OpenAI, Vertex) bleibt als Option pro Use-Case. Modell-Wechsel ohne Skill-Neubau.
„Welche Spezialisierung passt zu unserem Setup?"
Kein Plan? Audit. Engineering-Team mit Code-Sovereignty-Bedarf? AI in Engineering Operations (OpenCode plus lokales Modell). Marketing-Output mit Voice-Daten-Hoheit? Content Operations. Spryker mit On-Prem-AI-Erweiterung? Spryker plus AI. Die Matrix oben ist die ehrliche Routing-Logik.
„Wie passt das zu EU AI Act, DSGVO und KRITIS?"
Sovereignty ist die einfachste Antwort auf Drittland-Transfer und Hochrisiko-Pflichten. Wenn die Daten das Netz nicht verlassen, entfallen viele Compliance-Diskussionen. Audit-Logs pro Workflow-Aufruf entstehen automatisch, Annex-III-Doku-fähig. KRITIS- und NIS2-pflichtige Betreiber bekommen eine Architektur ohne Cloud-Egress.
„Wie ist der Einstieg in ein Mandat?"
Phase 1 ist immer abgegrenzt: Audit, OpenCode-Skill-Onboarding, Voice-Extraction-Workshop oder Spryker-Stack-Audit. Konditionen mandatsspezifisch. Erweiterungen werden Phase für Phase entschieden, kein Lock-in, kein Retainer-Druck.
Architektur-Tiefe

Fünf Architektur-Prinzipien, die das Modell überleben.

Wer die Schicht-Architektur tiefer verstehen will: Datenklassen-Trennung, MCP-Werkzeugvertrag, Anbieter-Abstraktion. Mit verifizierten Quellen — Bitkom 09/2025, EU AI Act Annex III, Cohere/Aleph-Alpha-Mitteilung 04/2026. Architektur-Prinzipien lesen →

So arbeiten wir

Werkbank, Schleifen, Übergabe. Drei Prinzipien.

Wir bauen mit euch, nicht für euch. Mandate sind Werkbank, nicht Theater. Lieferung in kurzen Schleifen. Saubere Übergabe, danach trägt eure Mannschaft allein.

Methode im Detail
Erfahrung & Kontakt

Tiefe Plattform-Expertise.

25 Jahre IT, davon 14 Jahre in B2B-Commerce. Architektur-Mandate bei Großkonzernen, Aufbau und Steuerung verteilter Expertenteams, vendor-neutrale Projektrettung. Schwerpunkte: Plattform-Architektur, Projektrettung, Team-Operations.

Chris Zepernick

Senior Berater · Hamburg

Was wir gelernt haben

Sovereignty ist Default, nicht Premium.

Wer AI in den Betrieb bringt, hat zwei Architektur-Wahlen: Daten verlassen das Netz oder bleiben drin. Beide sind legitim, aber nur eine davon ist die ehrliche Default-Wahl für DACH-B2B-Industrie unter NIS2, KRITIS und AI Act. Wir bauen die Default-Architektur — n8n, Open-Weights, OpenCode, DLP-Egress. Cloud-API bleibt offen, wo sie passt. Aber sie ist Option, nicht Voraussetzung.

So arbeiten wir

Welche Spezialisierung trifft euren Engpass?

Audit, Engineering, Content Operations oder Spryker plus AI — ein paar Minuten am Telefon und wir sortieren ehrlich, in welcher der vier Spezialisierungen euer erster Hebel steckt.

Anrufen Mail schreiben