AI-Agent vor dem Start: Compliance-Check, den du nicht überspringen solltest

Früher ging es bei Integrationen um eine einzelne API-Key, einen klaren Auslöser und einen festen Datenpfad. Das ist vorbei.

Ein aktueller AI-Agent – etwa mit Claude und Model Context Protocol (MCP) – verbindet Dutzende Tools auf einmal. In einem Agenten landen Salesforce, Stripe, GitHub, Slack, Gmail, dein Payroll-System, Observability-Tools und eine Vector Database. Jede Verbindung erlaubt dem Agenten, für dich zu handeln.

Das macht starke Systeme. Aber es birgt Compliance-Risiken, die viele Teams noch unterschätzen.

Der Compliance-Loch

Die harte Wahrheit: SOC 2, GDPR, HIPAA, PCI, SOX und der EU AI Act passen zu Menschen und klassischen Apps. Kontrollen laufen über Jahresaudits, Change-Management und Vendor-Checks. Der Weg ist klar: Planen, dokumentieren, absegnen, loslegen.

Für Agenten fehlt ein Tool, das die Kernfrage stellt: "Welche Risiken entstehen durch genau diese Tool-Kombination?"

Das Gefährliche: Probleme tauchen spät auf. Der Agent läuft wochen- oder monatelang in Production. Dann kommt der Audit. Plötzlich zeigt sich: Dein Kundenservice-Agent hat slack.read_direct_messages (Hallo, PHI und Anwaltsgeheimnis). Oder der Zahlungsagent ruft stripe.create_refund auf (Verstoß gegen Aufgabentrennung, PCI-Scope erweitert).

Runtime-Sicherungen mildern das. Aber der Agent ist schon live. Die Erwartung, dass er läuft, sitzt fest.

Der Pre-Flight-Check

Stell dir vor, du findest Fehler schon beim Entwurf – wo Fixes günstig sind.

Pre-Flight-Compliance dreht den Zeitplan um. Beim Skizzieren ("Beobachtet fehlgeschlagene Stripe-Zahlungen, schaut Kunde in Salesforce nach, postet in Slack") läuft ein schneller Check. Noch vor dem ersten Production-Code.

Du siehst direkt:

• Risikostufen pro Aktion (niedrig, mittel, hoch, kritisch)
• Betroffene Regulierungen (GDPR? HIPAA? PCI? SOX? Alles?)
• Aufgabentrennungs-Alarme, die dein Compliance-Team später eh findet
• Klare Tipps: So lassen, Audit-Logging hinzufügen, Human-Review fordern oder blocken

Du hast noch Spielraum. Tool streichen. Schreibzugriff auf Read-Only kürzen. Kritische Aktionen per Approval schützen. Oder Risiko bewusst dokumentieren.

Warum das überzeugt

Kein LLM-Plugin, das Risiken einfach erfindet – das wäre nutzlos. Compliance braucht keine Halluzinationen oder Zufallsoutputs.

Pre-Flight lebt von zwei Prinzipien:

Deterministisch, keine Generierung: Risiken und Regulierungs-Tags stammen aus einer gepflegten Datenbank, nicht aus einem LLM. Gleicher Input, gleicher Output. Auditierbar. Verteidigbar im echten Meeting.

Offene Daten: Alle Regeln sind öffentlich einsehbar. Du verstehst, warum slack.read_direct_messages HIPAA-relevant ist. Passt nicht zu dir? Fordere Änderung an. Transparenz schafft Vertrauen.

Der große Kontext

Das zählt jetzt: Agenten werden von Experimenten zu Kerninfrastruktur. Sie greifen auf Kundendaten, Zahlungen, HR und Firmengeheimnisse zu.

Compliance-Rahmen hinken hinterher. Audits sind jährlich. Agenten-Deployments wöchentlich.

Ein deterministischer, auditierbarer Pre-Flight-Check schließt die Lücke. Er ersetzt keine Reviews. Aber er vermeidet Audit-Panik und peinliche Chef-Gespräche.

Für Entwickler und Gründer: Baut das ein. Prüft Risiken früh und oft, vor dem Launch, solange Änderungen einfach sind. Das ist Linting für Regulierungsrisiken.

Die bleibenden Agenten sind nicht die schnellsten. Sondern die mit klarem Blick auf ihre Aktionen – und der Erlaubnis dafür.