Der AI-Ready Contract für Firewall & IP Connectivity
Warum AI-Shoring neue Vertragsbausteine für Autonomie, Nachweise, Architecture Accountability, Fallback und Exit benötigt.
Traditionelle Managed-Service-Verträge messen Response Time, Resolution Time und Availability. Diese Kennzahlen bleiben wichtig. Sie reichen jedoch nicht aus, wenn AI Agents operative Entscheidungen vorbereiten oder selbst ausführen.
In einem AI-enabled Service ist die Einheit des Werts nicht mehr nur das bearbeitete Ticket. Es ist die kontrollierte Entscheidung: nachvollziehbar, policy-konform, sicher ausgeführt und anhand des tatsächlichen Ergebnisses verifiziert.
Verantwortung sauber trennen
Der Vertrag muss zuerst unterscheiden, was der Provider verantwortet und welche Accountability beim Kunden bleibt.
Der Provider kann verantworten:
- Solution Design innerhalb vereinbarter Architecture Patterns,
- Betrieb, Wartung und Incident Response,
- Modelle, Agents und Orchestration,
- Implementation, Testing und Platform Security,
- technische Dokumentation, Reporting und Evidence.
Der Kunde behält die Accountability für:
- Target Architecture und Architecture Principles,
- Zonen, Trust Boundaries und Routing Patterns,
- Risk Acceptance und Exceptions,
- verbindliche Policies und verbotene Kommunikationspfade,
- erlaubte Autonomy Levels,
- kritische Abhängigkeiten, Exit, Portability und Interoperability.
Diese Trennung verhindert zwei Extreme: Micromanagement des Providers und blinde Delegation der Verantwortung.
Autonomie vertraglich klassifizieren
„AI darf unterstützen“ ist zu unpräzise. Ein praktikables Modell verwendet definierte Stufen:
| Klasse | Bedeutung | Beispiel |
|---|---|---|
| A0 Observe | beobachten und Kontext sammeln | Logs und Configs korrelieren |
| A1 Recommend | Empfehlung erstellen | mögliche Root Cause nennen |
| A2 Prepare | Change vollständig vorbereiten | Config, Test und Rollback erzeugen |
| A3 Execute with approval | nach menschlicher Freigabe ausführen | Standard Firewall Change |
| A4 Autonomous low risk | vorab definierte Low-Risk-Fälle selbst ausführen | zeitlich begrenzte, reversible Regel |
| A5 Emergency response | vorab autorisierte Notfallmaßnahme | kompromittierten Endpoint isolieren |
Jeder Use Case erhält eine Klasse, klare Grenzen und messbare Exit Conditions. Autonomie ist damit kein Marketingbegriff, sondern eine prüfbare Berechtigung.
Neun testbare Verpflichtungen
Ein AI-Ready Contract sollte mindestens diese Punkte regeln:
- Eligible Use Cases: Welche Aufgaben darf AI bearbeiten?
- Decision Boundaries: Welche Entscheidungen bleiben Menschen vorbehalten?
- Approval Rules: Wer genehmigt welche Risikoklasse?
- Identity & Access: Welche technische Identity führt aus, mit welchen minimalen Rechten?
- Evidence: Welche Inputs, Reasoning Summary, Policies, Freigaben und Resultate werden protokolliert?
- Safe Recovery: Wie funktionieren Stop, Rollback und Wiederanlauf?
- Model & Agent Changes: Wie werden Versionen getestet, freigegeben und überwacht?
- Fallback: Wie bleibt der Service ohne AI sicher betreibbar?
- Exit & Portability: Welche Daten, Regeln und Artefakte werden in welchem Format übergeben?
Reasoning und Execution trennen
Ein Language Model sollte keine allgemeinen Admin Credentials besitzen. Es kann einen strukturierten Change Plan erzeugen. Eine unabhängige Policy Engine prüft erlaubte Objekte, Ports, Zeitfenster und Risk Thresholds. Erst danach führt eine deterministische Automation den freigegebenen Plan mit eigener Identity aus.
Logs sind dabei kein Nebenprodukt. Sie sind Evidence: Welche Version war beteiligt? Welche Daten wurden verwendet? Welche Policy hat freigegeben? Wer hat bestätigt? Was wurde tatsächlich geändert? Welcher Test belegt den Outcome?
Von Service Level zu Decision Level
Bestehende SLAs bleiben erhalten, werden aber ergänzt:
- Decision Quality: fachlich richtige und vollständige Empfehlungen,
- Architecture Compliance: Übereinstimmung mit Policies und Patterns,
- Control Integrity: kein Umgehen von Approval, Identity oder Guardrails,
- Reversibility: sichere Wiederherstellung nach einem Fehlversuch,
- Outcome Verification: Nachweis, dass der gewünschte Zustand wirklich erreicht wurde.
Der Vertrag wird so zu einem Teil der technischen Architektur. Er beschreibt nicht nur, wie schnell gearbeitet wird, sondern wie Entscheidungen kontrolliert werden.
Quellen und Vertiefung
- EU: Digital Operational Resilience Act (DORA)
- NIST: AI Risk Management Framework
- NIST: Zero Trust Architecture
- OWASP: Top 10 for Large Language Model Applications