Referenz-Architektur
7-Layer-Architektur für Enterprise AI-Agenten. Governance als Querschicht durch alle Layer.
Überblick
Die Gosign Referenz-Architektur beschreibt die technische Struktur für Enterprise AI-Agenten. Sie besteht aus sieben Schichten (Layers), wobei die Governance-Schicht als Querschicht alle anderen Layer durchzieht.
Architektur-Übersicht
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.
- Dashboard: Statusübersicht für Agenten, laufende Workflows, offene Eskalationen.
- Auditor Portal: Prüfer-Zugang zu Audit Trail, Controls, Evidence. Read-only.
- REST API: Maschinenlesbare Schnittstelle für Integration in bestehende Systeme.
2. Orchestration Layer
Koordiniert den Datenfluss zwischen Agenten, Systemen und Nutzern. Verwaltet Workflows, Queues und API-Routing.
- n8n oder Camunda: Workflow-Engine für komplexe, mehrstufige Prozesse
- API Gateway: Einheitlicher Einstiegspunkt mit Rate Limiting, Authentication, Logging
- Workflow Engine: Zustandsbasierte Workflows mit Eskalation, Retry, Timeout
- Queue: Asynchrone Verarbeitung für Batch-Prozesse (z.B. Monatsabschluss)
3. Agent Layer
Die spezialisierten 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
Die zentrale Governance-Komponente. Der Decision Layer sitzt zwischen Agent und Zielsystem und macht jede LLM-Entscheidung transparent, auditierbar und nachvollziehbar.
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 + 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.
5. Model Layer
Die LLM-Schicht. Austauschbar, modell-agnostisch, entkoppelt von der Geschäftslogik.
- Claude (Anthropic)
- ChatGPT (OpenAI)
- Gemini (Google)
- Llama (Meta, open-source)
- Mistral (open-source)
- DeepSeek (open-source)
- gpt-oss (OpenAI, open-source)
Die Modellwahl hängt vom Einsatzzweck ab: Leistung, Kosten, Lizenzmodell, Data Residency. Der Agent kann mehrere Modelle nutzen – z.B. ein Open-Source-Modell für die Vorklassifizierung und ein leistungsfähigeres Modell für komplexe Entscheidungen.
Der Model Layer ist austauschbar. Wenn ein neues Modell verfügbar wird, kann es integriert werden ohne die darüberliegenden Layer zu ändern.
6. Integration Layer
Die Anbindung an bestehende Enterprise-Systeme. Der Agent ersetzt keine Systeme – er erweitert sie.
- SAP FI/CO, SAP S/4HANA
- SAP SuccessFactors
- Workday
- DATEV
- SharePoint, Microsoft Teams (via Microsoft Graph)
- Weitere über REST/SOAP-Schnittstellen
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.
- Azure (EU): Azure OpenAI, Azure Kubernetes Service, Azure SQL
- GCP (EU): Vertex AI, GKE, Cloud SQL
- Self-Hosted: On-Premises, eigene Server, eigenes Rechenzentrum
- Hybrid: Kombination aus Cloud und On-Premises
Alle Layer oberhalb der Infrastructure-Schicht bleiben identisch – unabhängig vom Deployment-Modell. Die Wahl der Infrastruktur ist eine Entscheidung des Kunden, nicht der Architektur.
Governance als Querschicht
Die Governance-Schicht ist kein einzelner Layer, sondern durchzieht die gesamte Architektur:
- Presentation Layer: Auditor Portal, rollenbasierter Zugriff
- Orchestration Layer: Workflow-Logging, Eskalations-Dokumentation
- Agent Layer: Agent-Entscheidungen erzeugen Audit-Trail-Einträge
- Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop
- Model Layer: Modellversions-Tracking, Input-Hashing
- Integration Layer: Schnittstellen-Logging, Datenfluss-Dokumentation
- Infrastructure Layer: Verschlüsselung, RLS, Mandantentrennung
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 │
│ SAP · DATEV · │
│ SuccessFactors │
└─────────────────┘Designprinzipien
Modell-agnostisch: Kein Vendor Lock-in auf ein einzelnes LLM. Modelle sind austauschbar.
Infrastruktur-agnostisch: Gleiche Architektur auf Azure, GCP, Self-Hosted oder Hybrid.
System-agnostisch: Agent-Logik ist vom Zielsystem entkoppelt. Buchungslogik getrennt von Export.
Governance by Design: Audit Trail, RBAC, Decision Layer und Human-in-the-Loop sind Architekturkomponenten – keine optionalen Features.
Cert-Ready by Design: Controls sind First-Class-Datenobjekte mit automatischer Evidence-Generierung.
Ownership: Der Kunde besitzt den vollständigen Source Code, alle Prompts und alle Regelwerke. Nach 12–18 Monaten betreibt der Kunde die Agenten eigenständig.
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 Gosign-Architektur ist die Schicht zwischen LLM und Enterprise-System die genau das ergänzt.
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.
Kann die Architektur on-premises betrieben werden?
Ja. Der Infrastructure Layer unterstützt Azure, GCP, Self-Hosted oder Hybrid. Die darüberliegenden Layer bleiben identisch – unabhängig vom Deployment-Modell.
Sprechen Sie mit uns über die Architektur.
7-Layer-Architektur. Governance als Querschicht. In Ihrer Infrastruktur.
Gespräch vereinbaren