Vom Service Level zum Decision Level
Wie SLAs für AI-Shored Infrastructure Services technische Qualität, Decision Quality, Architecture Compliance und Business Outcomes verbinden.
Ein AI Agent kann ein Ticket in Sekunden analysieren und trotzdem die falsche Entscheidung treffen. Genau darin liegt die Grenze klassischer Service Level Agreements: Sie messen häufig Geschwindigkeit und Verfügbarkeit, nicht die Qualität einer Entscheidung.
Für AI-Shored Infrastructure Services braucht es deshalb ein Modell aus vier Ebenen.
1. Technical Service Quality
Diese Ebene bleibt vertraut:
- Availability der Plattform,
- Response und Resolution Time,
- Latenz von APIs und Automations,
- Erfolgsrate technischer Jobs,
- Recovery Time und Backup-Qualität.
Ohne stabile Plattform gibt es keinen verlässlichen Service. Doch diese Kennzahlen sagen noch nichts darüber aus, ob ein Change fachlich richtig war.
2. Decision Quality
Hier wird die Qualität der AI-unterstützten Entscheidung messbar:
- Decision Latency: Zeit von vollständigem Kontext bis zu einer prüfbaren Empfehlung.
- Policy Compliance: verbindliche Policies müssen vollständig eingehalten werden. Für kritische Regeln ist das ein deterministisches Gate, kein Durchschnittswert.
- Unauthorized Actions: Zielwert null; ein Verstoß ist ein Material Control Failure.
- AI Change Failure Rate: fehlgeschlagene AI-initiierte Changes werden getrennt von manuellen Changes betrachtet.
- False Positives und False Negatives: beide benötigen use-case-spezifische Definitionen und Grenzwerte.
- Time to Validated Safe State: Zeit bis ein sicherer, überprüfter Zustand erreicht ist – nicht nur bis ein Ticket geschlossen wurde.
Bei Decision Quality ist die Testmenge entscheidend. Eine gute Prozentzahl auf einfachen Fällen kann gefährliche Fehler in seltenen, kritischen Situationen verdecken. Deshalb braucht es Risiko-Klassen und bewusst kuratierte Edge Cases.
3. Architecture Compliance
Ein Service kann verfügbar und schnell sein und trotzdem die Architektur verschlechtern. Diese Ebene misst daher:
- Anteil der Changes innerhalb freigegebener Patterns,
- Verstöße gegen Zonen und Trust Boundaries,
- Zahl und Alter aktiver Exceptions,
- Einhaltung von Naming, Object und Routing Standards,
- vollständige Lifecycle-Daten für temporäre Regeln,
- Drift zwischen dokumentiertem und tatsächlichem Zustand.
Jede Exception braucht Owner, Begründung, Ablaufdatum und Remediation Plan. Sonst wird die Ausnahme schleichend zum neuen Standard.
4. Business Outcome
Die oberste Ebene fragt nach Wirkung:
- Wie schnell kann ein Produkt sicher angebunden werden?
- Wie oft entstehen Verzögerungen durch unvollständige Requests?
- Sinkt die Zahl wiederkehrender Incidents?
- Wie viel Engineering-Zeit wird von repetitiver Arbeit zu Architektur und Improvement verschoben?
- Werden Audit und Compliance Evidence schneller und verlässlicher bereitgestellt?
Diese Ebene verbindet Technik und Geschäftsrealität. Sie verhindert, dass ein Provider formale SLA-Ziele erfüllt, obwohl Nutzer und interne Teams keine Verbesserung erleben.
Beispiel für ein kombiniertes Commitment
Ein belastbares Commitment könnte so aussehen:
Ein Standard Change wird innerhalb von 30 Minuten als vollständiger, policy-geprüfter Change Plan bereitgestellt. Kritische Policy Violations blockieren die Ausführung. Nach Freigabe wird deterministisch ausgeführt, technisch getestet und innerhalb von zehn Minuten in einen validierten sicheren Zustand überführt. Alle Inputs, Freigaben, Änderungen und Resultate sind auditierbar.
Hier werden Geschwindigkeit, Qualität, Control und Outcome verbunden.
Metric Theatre vermeiden
Ungeeignet sind Kennzahlen, die zwar leicht messbar sind, aber falsche Anreize setzen:
- Ticket Closure ohne verifizierten Outcome,
- Recommendation Acceptance Rate ohne Betrachtung der fachlichen Richtigkeit,
- Automation Rate als Selbstzweck,
- Durchschnittswerte ohne Risiko-Klassen,
- hohe Genauigkeit auf einer nicht repräsentativen Testmenge,
- Verfügbarkeit ohne Betrachtung der manuellen Fallback-Fähigkeit.
Ein gutes SLA beantwortet nicht nur „Wie schnell?“, sondern auch „Wie richtig?“, „Wie sicher?“, „Wie nachvollziehbar?“ und „Mit welcher Wirkung?“.
Quellen und Vertiefung
- NIST: AI Risk Management Framework
- Google Cloud: DORA Research
- EU-Durchführungsverordnung 2024/2690 zu NIS2
- MEF 61: IP Service Attributes