7-Layer-Referenz-Architektur
Enterprise AI-Agenten brauchen mehr als ein LLM. Diese Architektur trennt Benutzeroberfläche, Orchestrierung, Agenten, Entscheidungslogik, Modelle, Integration und Infrastruktur in sieben unabhängige Schichten. Governance durchzieht alle Layer als Querschicht.
Warum sieben Layer
Ein monolithisches AI-System ist nicht auditierbar, nicht skalierbar und nicht wartbar. Die 7-Layer-Architektur trennt Verantwortlichkeiten: Jeder Layer hat eine definierte Aufgabe und klare Schnittstellen. Ein Modellwechsel ändert nicht die Geschäftslogik. Ein neues Zielsystem ändert nicht den Agenten. Eine neue Compliance-Anforderung ändert nicht die Infrastruktur.
Die Architektur ist das Ergebnis von Enterprise-Anforderungen: Mandantentrennung, Audit Trail, Betriebsrats-Transparenz, EU AI Act-Konformität, modell-agnostisches Deployment. Standard-LLM-APIs liefern nichts davon.
1. Presentation Layer
Die Schnittstelle zwischen System und Nutzer. Keine Geschäftslogik, keine Entscheidungen - nur Darstellung und Eingabe.
- Chat UI: Webbasierte Oberfläche für Endnutzer (HR-Sachbearbeiter, Buchhalter). PWA-fähig, responsive.
- Dashboard: Statusübersicht für Agenten, laufende Workflows, offene Eskalationen. Rollenbasiert: Sachbearbeiter sehen ihre Fälle, Manager sehen Kennzahlen.
- Auditor Portal: Prüfer-Zugang zu Audit Trail, Controls, Evidence. Read-only. Für Wirtschaftsprüfer, Betriebsrat, interne Revision.
- REST API: Maschinenlesbare Schnittstelle für Integration in bestehende Systeme. Versioniert, dokumentiert, authentifiziert.
2. Orchestration Layer
Koordiniert den Datenfluss zwischen Agenten, Systemen und Nutzern. Verwaltet Workflows, Queues und API-Routing.
- Workflow-Engine: Open-Source Engines (Trigger.dev, Camunda) für komplexe, mehrstufige Prozesse. Visuelle Workflows, API-Integration, Webhooks.
- API Gateway: Einheitlicher Einstiegspunkt mit Rate Limiting, Authentication, Logging, Monitoring.
- Queue-System: Asynchrone Verarbeitung für Batch-Prozesse (Monatsabschluss, Massenimport).
- Event-System: Echtzeit-Reaktion auf eingehende Dokumente, Statusänderungen, Eskalationen.
3. Agent Layer
Spezialisierte AI-Agenten, die fachliche Aufgaben ausführen. Jeder Agent hat einen definierten Aufgabenbereich und arbeitet innerhalb der Grenzen, die der Decision Layer vorgibt.
Document Agents
Lesen, verstehen und verarbeiten Dokumente mit echtem Sprachverständnis. Rechnungen, Krankmeldungen, Verträge, Bescheinigungen, Belege. Keine Template-Erkennung, keine starren Regeln - sondern kontextuelles Verständnis.
Workflow Agents
Orchestrieren Prozesse systemübergreifend. Wenn ein Dokument gelesen, eine Entscheidung getroffen und eine Aktion in einem Zielsystem ausgelöst werden muss - der Workflow Agent koordiniert den Ablauf.
Knowledge Agents
Liefern kontextbasierte Antworten aus Unternehmenswissen. Betriebsvereinbarungen, Richtlinien, Tarifverträge, Compliance-Regeln. Die Antwort enthält die Quelle und die Regelversion.
4. Decision Layer
Zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Jede Entscheidung wird dokumentiert - prüfbar für Wirtschaftsprüfer, Betriebsrat und interne Revision.
Rules Engine: Fachliche Regelwerke, versioniert und nachvollziehbar. Tarifverträge, Betriebsvereinbarungen, Buchungslogik, Compliance-Regeln. Jede Regel hat eine Version, ein Gültigkeitsdatum und einen Geltungsbereich.
Confidence Routing: Automatische Bewertung der Entscheidungssicherheit. Hohe Confidence und niedriges Risiko: autonome Entscheidung. Niedrige Confidence oder hohes Risiko: Eskalation an Menschen.
Human-in-the-Loop: Architektonisch erzwungene menschliche Prüfung bei definierten Entscheidungstypen. Bias-Risiko, Diskriminierungspotenzial, Mitbestimmungsthemen.
Audit Trail: Vollständige, unveränderliche Dokumentation jeder Entscheidung. Input, Modell, Bewertung, Regel, Ergebnis, Zeitstempel. Append-only.
Vertiefung: Decision Layer im Detail · Drei Arten von KI-Entscheidungen
5. Model Layer
Die LLM-Schicht. Austauschbar, modell-agnostisch, entkoppelt von der Geschäftslogik.
Cloud-LLMs
Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - über EU-Regionen der jeweiligen Cloud-Anbieter.
Open-Source-/Open-Weight-LLMs
Llama (Meta), Mistral, DeepSeek, gpt-oss (OpenAI, Apache 2.0) - komplett self-hostbar auf eigener Hardware. gpt-oss-120B läuft auf einer einzelnen H100-GPU, gpt-oss-20B auf 16 GB Consumer-Hardware.
Hybrid
Cloud-LLMs für Standardfälle, Self-Hosted-LLMs für sensible Daten. Automatisches Routing je nach Datenklassifikation.
Die Modellwahl ist eine Abwägung zwischen Leistung, Kosten, Datenschutz und Latenz. Der Model Layer ist austauschbar - ein Modellwechsel ändert nichts an der darüberliegenden Geschäftslogik.
Konkrete Hosting-Optionen, Hardware-Anforderungen und Technologie-Stack: AI Infrastructure im Detail
6. Integration Layer
Die Anbindung an bestehende Enterprise-Systeme. Der Agent ersetzt keine Systeme - er erweitert sie.
| Systemkategorie | Integration |
|---|---|
| ERP / Finanzen | SAP FI/CO, SAP S/4HANA, DATEV, Oracle Financials |
| HR / Payroll | SAP SuccessFactors, Workday, Personio |
| Collaboration | SharePoint, Microsoft Teams (via Microsoft Graph) |
| DMS / ECM | SharePoint, d.velop, ELO, nscale |
| Weitere | Jedes System mit REST- oder SOAP-Schnittstelle |
Die Agent-Logik ist vom Zielsystem entkoppelt. Buchungslogik ist von Export getrennt. Wenn das Zielsystem wechselt (z.B. von DATEV auf SAP), ändert sich der Export-Layer - nicht der Agent.
7. Infrastructure Layer
Das Deployment-Fundament. Die gesamte Architektur läuft in der Infrastruktur des Kunden - nicht bei Gosign, nicht bei einem Drittanbieter.
- Cloud (EU): Azure, AWS oder GCP - ausschliesslich EU-Regionen. Managed Kubernetes, Managed Databases, LLM-Hosting.
- Managed EU: Vercel EU + Supabase EU. Leichtgewichtige EU-Option ohne eigene Kubernetes-Infrastruktur.
- Self-Hosted: Eigene Server, eigenes Rechenzentrum. Docker/Kubernetes, Open-Source-LLMs auf eigenen GPUs. Vollständige Cloud-Act-Freiheit.
- Hybrid: Kombination nach Datenklassifikation. Sensible Workloads Self-Hosted, Standard-Workloads Cloud.
Alle Layer oberhalb der Infrastructure-Schicht bleiben identisch - unabhängig vom Deployment-Modell.
Cloud-Regionen, Hardware-Dimensionierung, Technologie-Stack: AI Infrastructure im Detail
Governance als Querschicht
Governance ist kein einzelner Layer, sondern durchzieht die gesamte Architektur. Jeder Layer erzeugt Governance-Daten, jeder Layer wird durch Governance-Regeln kontrolliert.
- Presentation: Rollenbasierter Zugriff, Auditor Portal
- Orchestration: Workflow-Logging, Eskalations-Dokumentation
- Agent: Agent-Entscheidungen erzeugen Audit-Trail-Einträge
- Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop
- Model: Modellversions-Tracking, Input-Hashing, Reproduzierbarkeit
- Integration: Schnittstellen-Logging, Datenfluss-Dokumentation
- Infrastructure: Verschlüsselung, Row-Level Security, Mandantentrennung
EU AI Act · Cert-Ready by Design · Mitbestimmung · Data Residency
Runtime und Skalierung
Produktionsbetrieb ist keine Nacharbeit, sondern Architekturbestandteil. Die 7-Layer-Architektur ist für Betrieb unter Last ausgelegt.
- Container-Orchestrierung: Kubernetes-basiertes Deployment. Jeder Layer läuft in eigenen Containern, unabhängig skalierbar.
- Horizontale Skalierung: Agent Layer und Model Layer skalieren horizontal nach Auslastung. Ein neuer Agent bedeutet mehr Pods, nicht mehr Architektur.
- Health Checks und Self-Healing: Liveness und Readiness Probes auf allen Containern. Automatischer Neustart bei Ausfall, automatische Umleitung bei Überlast.
- Monitoring und Alerting: Prometheus-Metriken auf allen Layern. Grafana-Dashboards für Latenz, Throughput, Error Rates, Queue Depth. Alerting bei Schwellenwertüberschreitung.
- CI/CD: GitOps-basierte Deployments. Infrastructure as Code (Terraform/Pulumi). Automatisierte Tests, Blue-Green oder Canary Deployments.
Datenarchitektur
Daten fliessen durch alle sieben Layer. Die Architektur definiert, wo Daten entstehen, wie sie gespeichert werden und wer Zugriff hat.
- Datenfluss: Input (Dokument, Anfrage) → Agent (Analyse) → Decision Layer (Entscheidung) → Integration (Zielsystem-Export). Jeder Schritt erzeugt einen Audit-Trail-Eintrag.
- Vector Store: PostgreSQL mit pgvector für semantische Suche (RAG). Unternehmenswissen wird als Embeddings gespeichert, nicht an externe Dienste übermittelt.
- Mandantentrennung: Row-Level Security (RLS) auf Datenbankebene. Architektonisch erzwungen, nicht per Applikationslogik. Jeder Mandant ist vollständig isoliert.
- Verschlüsselung: At rest (AES-256) und in transit (TLS 1.3). Schlüssel-Management über den Identity Provider des Kunden oder Hardware Security Modules (HSM).
- Data Retention: Konfigurierbar nach Anforderung. Steuerliche Aufbewahrung (10 Jahre, AO § 147) und DSGVO Art. 17 (Recht auf Löschung) werden über Anonymisierung statt Löschung vereinbart.
- Backup und Recovery: Automatisierte Backups, Point-in-Time Recovery. Recovery Point Objective (RPO) und Recovery Time Objective (RTO) werden pro Mandant konfiguriert.
Schnittstellenarchitektur
Die Architektur kommuniziert über definierte Schnittstellen - intern zwischen Layern und extern mit Vorsystemen und Zielsystemen.
- REST API: Versionierte APIs (v1, v2) mit OpenAPI-Dokumentation. Breaking Changes nur in neuen Versionen, alte Versionen werden parallel betrieben.
- Event-Driven: Webhook-basierte Eventverarbeitung für Echtzeit-Reaktionen. Eingehendes Dokument → Event → Agent verarbeitet. Kein Polling, kein Batch-Delay.
- MCP (Model Context Protocol): Standardisiertes Protokoll für Tool-Integration in LLM-Agenten. Agenten greifen über MCP auf externe Werkzeuge zu - typisiert, dokumentiert, auditierbar.
- Batch-Verarbeitung: Für Massenoperationen (Monatsabschluss, Jahresabrechnung, Massenimport). Queue-basiert mit Fortschritts-Tracking und Fehlerbehandlung.
- API Gateway: Zentraler Einstiegspunkt. Authentifizierung (SSO/OIDC), Rate Limiting, Request-Logging, Monitoring. Entkoppelt interne Architektur von externen Konsumenten.
Designprinzipien
Modell-agnostisch: Kein Vendor Lock-in auf ein einzelnes LLM. Modelle sind austauschbar. Heute Claude, morgen gpt-oss, übermorgen ein Modell das heute noch nicht existiert.
Infrastruktur-agnostisch: Gleiche Architektur auf Azure, AWS, GCP, Self-Hosted oder Hybrid. Die Infrastrukturwahl ist eine Entscheidung des Kunden, nicht der Architektur.
System-agnostisch: Agent-Logik ist vom Zielsystem entkoppelt. Buchungslogik getrennt von Export. Ein Systemwechsel ändert den Integration Layer, nicht den Agenten.
Governance by Design: Audit Trail, RBAC, Decision Layer und Human-in-the-Loop sind Architekturkomponenten - keine optionalen Features, die nachgerüstet werden.
Cert-Ready by Design: Controls sind First-Class-Datenobjekte mit automatischer Evidence-Generierung. ISO 27001, PS 951, SOC 2 - die Architektur liefert die Nachweise.
Quellcode-Zugang: Voller Zugang zum Quellcode, allen Prompts und Regelwerken. Konfigurationen und Regelwerke liegen beim Kunden. Open-Source-Stack wo möglich. Nach 12-18 Monaten betreibt der Kunde die Agenten eigenständig.
Decision Layer - Entscheidungsfluss
┌──────────┐ ┌──────────────┐ ┌────────────────┐
│ Input │───>│ AI Agent │───>│ Decision Layer │
│(Dokument,│ │ analysiert, │ │ │
│ Anfrage) │ │ versteht, │ │ Regelwerk │
└──────────┘ │ bewertet │ │ prüfen │
└──────────────┘ │ │
│ Confidence │
│ bewerten │
│ │
│ Routing │
│ entscheiden │
└───────┬────────┘
│
┌─────────────┴──────────────┐
│ │
┌────────▼────────┐ ┌──────────▼──────────┐
│ Autonom │ │ Human-in-the-Loop │
│ │ │ │
│ Hohe Confidence │ │ Bias-Risiko │
│ Niedriges Risiko│ │ Niedrige Confidence │
│ Kein BV- │ │ BV-Constraint │
│ Constraint │ │ Mitbestimmung │
└────────┬────────┘ └──────────┬──────────┘
│ │
│ ┌──────────────┐ │
│ │ Mensch │ │
│ │ entscheidet │◄──┘
│ └──────┬───────┘
│ │
┌────────▼────────────────▼────────┐
│ Audit Trail │
│ Input · Modell · Regel · │
│ Bewertung · Ergebnis · │
│ Zeitstempel │
└──────────────────────────────────┘
│
┌────────▼────────┐
│ Zielsystem │
│ (ERP, HR, │
│ Payroll) │
└─────────────────┘Vertiefung
Implementierung
AI Infrastructure
Konkrete Technologien, Cloud-Regionen, Hardware-Dimensionierung, Tech-Stack-Tabelle.
Infrastruktur im Detail →Wissensressource
Blueprint 2026
Elf Fachartikel zu den Infrastruktur-Entscheidungen die 2026 zählen.
Zur Artikelserie →Agenten
AI Agents im Überblick
Document Agents, Workflow Agents, Knowledge Agents - drei Agententypen für Enterprise-Prozesse.
Zu den AI Agents →Governance
Governance-Framework
EU AI Act, Cert-Ready, Mitbestimmung, Data Residency - alle Governance-Themen im Überblick.
Zur Governance-Übersicht →Vertiefung im Agent Briefing
Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.
Häufige Fragen zur Referenz-Architektur
Warum eine eigene Architektur statt Standard-LLM-APIs?
Standard-LLM-APIs liefern Sprachverständnis, aber keine Governance, kein Audit Trail, keine Mandantentrennung, kein Rollenkonzept. Die 7-Layer-Architektur ist die Schicht zwischen LLM und Enterprise-System, die genau das ergänzt. Ohne diese Schicht bleibt jedes LLM ein Experiment.
Ist die Architektur modell-agnostisch?
Ja. Der Model Layer ist austauschbar. Aktuell unterstützt: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Neue Modelle werden integriert, ohne die darüberliegenden Layer zu ändern. Kein Vendor Lock-in auf ein einzelnes LLM.
Wie skaliert die Architektur bei wachsender Last?
Jeder Layer skaliert unabhängig. Agent Layer und Model Layer können horizontal skaliert werden, ohne den Decision Layer oder die Integration zu ändern. Kubernetes-basiertes Deployment ermöglicht Auto-Scaling nach Auslastung.
Wie wird Mandantentrennung gewährleistet?
Auf Datenbankebene durch Row-Level Security (RLS). Jeder Mandant sieht ausschliesslich seine eigenen Daten, Regeln und Audit Trails. Die Trennung ist architektonisch erzwungen, nicht nur per Applikationslogik.
Kann die Architektur schrittweise eingeführt werden?
Ja. Die Layer sind entkoppelt. Ein typischer Einstieg: Ein Agent (z.B. Document Agent) mit Decision Layer, angebunden an ein bestehendes System. Weitere Agenten, Integrationen und Governance-Funktionen werden schrittweise ergänzt.
Was unterscheidet diese Seite von der Infrastruktur-Seite?
Diese Seite beschreibt das Architekturmuster - welche Layer es gibt und warum. Die Infrastruktur-Seite beschreibt die konkrete Umsetzung - welche Technologien, welche Cloud-Regionen, welche Hardware. Architektur ist das Was, Infrastruktur ist das Wie.
Architektur-Assessment für Ihr Unternehmen
Wir analysieren Ihre bestehende Systemlandschaft und zeigen, wie die 7-Layer-Architektur in Ihre Infrastruktur passt.
Gespräch vereinbaren