Multi-Agent-Systeme — also Programme, in denen mehrere KI-Agenten Aufgaben aufteilen — sind seit 2024 produktionsreif und werden von immer mehr Mittelstaendlern eingesetzt. Sie versprechen, ganze Geschaeftsprozesse zu automatisieren: ein "CEO"-Agent plant Strategie, ein "Engineer"-Agent schreibt Code, ein "Reviewer"-Agent prueft. Klingt elegant. Ist rechtlich anspruchsvoll. Dieser Artikel zeigt, wie man Multi-Agent-Systeme so baut, dass sie EU-AI-Act- und DSGVO-Art.-22-konform sind.
Das Compliance-Doppelproblem
Multi-Agent-Systeme kombinieren zwei Regelwerke, die zusammen mehr verlangen als jedes einzeln:
- EU AI Act Art. 26: Human Oversight an kritischen Entscheidungspunkten.
- DSGVO Art. 22: keine vollautomatisierten Einzelentscheidungen mit rechtlicher Wirkung ohne Opt-in.
Beides zusammen: Approval-Gates an Stellen, wo es um Geld, Personen oder kundensichtbare Inhalte geht. Ohne Audit-Trail kein Compliance-Nachweis. Ohne Rollback keine Fehlerkorrektur.
Die fuenf Saeulen eines compliant Agenten-Workflows
1. Audit-Trail pro Agent-Lauf
Jeder Agent-Lauf wird vollstaendig protokolliert: Eingabe, Modell, Output, Zeitstempel, Tool-Calls. Eine flache Logdatei reicht nicht — die ist nicht durchsuchbar, nicht auditierbar. Strukturiertes Logging in Postgres mit Such-UI ist Mindeststandard:
CREATE TABLE agent_runs (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
parent_run_id UUID REFERENCES agent_runs(id), -- Multi-Agent-Hierarchie
input JSONB NOT NULL,
model TEXT NOT NULL,
output JSONB,
tool_calls JSONB,
status TEXT CHECK (status IN ('pending', 'running', 'ok', 'error', 'rejected')),
duration_ms INTEGER,
approved_by UUID REFERENCES auth.users(id),
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_agent_runs_agent ON agent_runs (agent_name, created_at DESC);
CREATE INDEX idx_agent_runs_status ON agent_runs (status);
2. Approval-Gates an kritischen Entscheidungen
Vor jeder Aktion mit Aussenwirkung wartet das System auf menschliche Freigabe:
- Kundensichtbarer Inhalt (Blog-Post, E-Mail, Rechnung) → Approval-Queue, nicht direkt versenden.
- Geld-Bewegung (Rechnung, Erstattung) → Approval-Queue mit Hoehen-Limit.
- Personalentscheidung (Bewerber-Vorscreening) → DSGVO Art. 22 Opt-In + manuelle Pruefung.
- Code-Deploy in Produktion → Mensch klickt Deploy.
Faustregel: "Wuerde ich diesen Schritt einem unerfahrenen Mitarbeiter ohne Review erlauben?" Wenn nein, dann auch keinem KI-Agenten.
3. Memory-System fuer Continuous Learning
Agenten lernen aus eigenen Erkenntnissen. Best Practice: getrennte Memory-Kollektionen fuer "Insights" (was funktioniert) und "Improvements" (was bei naechstem Lauf besser zu machen ist). Beide sind menschlich auditierbar:
CREATE TABLE agent_memory (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
type TEXT NOT NULL CHECK (type IN ('insight', 'improvement')),
source_run UUID REFERENCES agent_runs(id),
content TEXT NOT NULL,
embedding vector(1536), -- pgvector fuer semantische Suche
created_at TIMESTAMPTZ DEFAULT NOW()
);
4. Rollback-Pfade
Jede Agent-Aktion muss rueckgaengig gemacht werden koennen. Konkret: vor dem Versand eines Blog-Posts liegt der Draft in der DB; vor dem Versand einer Rechnung wird ein Storno-Pfad eingebaut; vor jedem Code-Deploy gibt es einen Backup-Branch. Kein "irreversibel by design".
5. EU-Hosted Modelle als Default
Sensible Workloads (Personalakten, Gesundheitsdaten, Strategiepapiere) bleiben in der EU. Mein Default: Scaleway Mistral fuer Text, Pixtral fuer multimodale Aufgaben. US-Modelle (GPT-4, Claude) nur dort, wo der Use Case es rechtfertigt — und mit Standardvertragsklauseln und Transfer Impact Assessment.
Tool-Rules pro Agent
Jeder Agent darf nur, was ihm explizit erlaubt ist. Beispiel fuer einen Code-Engineer-Agenten:
agent: engineer
allowed_tools:
- read_file
- write_file
- run_tests
- create_git_commit
forbidden_tools:
- delete_file # Nur per Approval
- push_to_remote # Nur per Approval
- send_email # Nicht zustaendig
- create_invoice # Nicht zustaendig
data_access:
- source_code: read-write
- test_data: read
- production_db: NONE
Tool-Rules sind keine Empfehlung — sie sind Pflicht zur Compliance. Ein Agent, der zu viel darf, ist ein Compliance-Risiko.
Human Oversight Dashboard
Admin sieht alle Agent-Outputs vor Production. Filter nach Agent, Datum, Status. Approve / Reject mit einem Klick. Bei Reject kommt eine Begruendung in das Memory — der Agent lernt daraus.
Retention-Fristen
KI-Prompts und Outputs werden nach 30 Tagen geloescht — ausser es gibt eine rechtliche Aufbewahrungspflicht (z.B. fuer Rechnungen 8 Jahre, siehe Artikel zu E-Rechnung). Nicht vergessen: das Memory-System hat auch Retention. Insights laenger (z.B. 2 Jahre), Improvements kuerzer (z.B. 6 Monate).
Was ich konkret mache
Bei einem Multi-Agent-Setup fuer dein Projekt liefere ich: Architektur mit klaren Agent-Rollen (z.B. CEO/CTO/Engineer-Pattern) und Tool-Rules pro Rolle, Memory-System mit getrennten Insights-/Improvements-Kollektionen, Approval-Workflow vor Production-Aktionen mit Admin-UI und E-Mail-Benachrichtigung, Audit-Logging in Postgres mit Such-UI, EU-hosted Modelle als Default, AiBadge-Integration auf jedem KI-Output, und ein Dashboard mit Agent-Run-Historie.
Mehr unter /compliance/ai-agents.
