Ein 99,9-%-Badge lässt den Vergleich einfach aussehen, doch ohne eine klar definierte Grenze sagt die Zahl wenig aus. Eine einzige Anfrage an einen KI-Agenten kann Trigger, Queue, Runtime, KI-Modell-Provider, Retrieval-System, Kunden-Tool und Rückgabekanal durchlaufen. Je nach Vertrag sind möglicherweise nur Runtime und API abgedeckt. Käufer sollten das Versprechen deshalb am Pfad der tatsächlich eingesetzten Agenten im Produktivbetrieb prüfen.
Ausgangspunkt ist das vertragliche Versprechen
Produktseiten und Beschaffungsunterlagen verwenden Begriffe zur Zuverlässigkeit oft austauschbar. Die Kennzahl muss von ihrem Ziel und von den vertraglichen Folgen getrennt werden, wenn dieses Ziel verfehlt wird. Googles öffentliche SRE-Definitionen von SLI, SLO und SLA folgen derselben Trennung.
Wenn ein Dokument „99,9 % Uptime“ verspricht, aber weder gemessenen Service, Nenner, Beobachtungsquelle, Ausschlüsse noch Abhilfe definiert, ist es noch kein brauchbares Kaufkriterium. Der NIST-Leitfaden zu Cloud-Service-Metriken betont reproduzierbare Definitionen; auch ENISA empfiehlt Cloud-Käufern festzulegen, wann ein Service als verfügbar gilt und wie Sicherheits-Service-Levels überwacht werden.
SLA-Checkliste für KI-Agenten-Plattformen
Die Tabelle dient der ersten Vertragsprüfung. „Erfüllt“ bedeutet, dass die Antwort im bindenden Vertrag oder in einer einbezogenen Anlage steht und nicht allein in einem Vertriebsgespräch.
| # | Prüfen | Was der Vertrag regeln sollte | Warnsignal |
|---|---|---|---|
| 1 | Abgedeckte Services | Benennt Runtime, API, Trigger-Eingang, Verbindungen, Queues, Zustand, Logs, Control Plane und Ergebnisauslieferung einzeln. | „Die Plattform“ ohne Komponentenliste oder Environment-Grenze. |
| 2 | Verfügbarkeitsformel | Definiert gültige Requests, Erfolg und Fehler, Response-Schwelle, Teilausfall und Nenner. | Ein Prozentsatz ohne überprüfbare Definition von Downtime. |
| 3 | Messung | Nennt Zeitraum, Aggregationsbereich, Monitoring-Quelle, Zeitzone und Nachweise für Streitfälle. | Ein Prozentsatz der Statusseite, der mit der vertraglichen Berechnung gleichgesetzt wird. |
| 4 | Abhängigkeiten | Ordnet die Verantwortung für KI-Modell-Provider, Tools, Datenspeicher, Verbindungen, Netzwerke und Kundencode zu. | Drittanbieter sind ausgeschlossen, ohne Fallback, Zuordnung oder Eskalationspfad. |
| 5 | Wartung und Ausschlüsse | Begrenzt geplante Zeitfenster, legt Vorlauf fest und beschränkt Ausschlüsse für Kunden, Quoten, höhere Gewalt und Sicherheitsvorfälle. | Weite Ausschlüsse, die genau die für den Käufer relevanten Incidents herausnehmen können. |
| 6 | Incident- und Support-Fristen | Trennt Erkennung, Bestätigung, Kundenbenachrichtigung, Update-Takt, Response, Wiederherstellung und Post-Incident Review. | Ein schnelles „Response“-Ziel, das als Lösungsversprechen dargestellt wird. |
| 7 | Wiederherstellung und Datenbeständigkeit | Legt RTO und RPO je Datenklasse sowie Backup-Takt, Aufbewahrung, Isolation und Nachweise von Restore-Tests fest. | „Regelmäßige Backups“ ohne numerische Recovery-Zusagen. |
| 8 | Sicherheits- und Betriebsnachweise | Stellt abgegrenzte Reports, Zertifikate, Audit-Rechte, exportierbare Logs, Aufbewahrung und Control-Verantwortung bereit. | Ein Badge ohne Rechtsträger, Service, Zeitraum, Ausnahmen oder Zugriff auf den Report. |
| 9 | Abhilfen | Definiert Gutschriftstufen, berechtigte Gebühren, Obergrenze, Antragsfrist, Nachweispflicht, Eskalation und Rechte bei wiederholtem Ausfall. | Gutschriften ohne Antragsverfahren oder Regelung zur ausschließlichen Abhilfe. |
| 10 | Änderung und Exit | Deckt Vorlauf bei nachteiligen Änderungen, Exportformate, Abrufzeitraum, Transition-Support, Löschbestätigung und Exit-Kosten ab. | Der Anbieter kann Bedingungen ändern, während der Kunde keinen getesteten Exportpfad hat. |
Lege fest, welche Zusagen und Nachweise du für Runtime, Verbindungen, KI-Modell-Provider, Wiederherstellung und Support benötigst. Wir können individuelle Enterprise-Bedingungen dokumentieren, wenn das öffentliche SLA nicht ausreicht.
Anforderungen besprechenDen kritischen Pfad des Agenten vor der Uptime-Verhandlung aufzeichnen
Ein Agenten-Run kann angenommen werden, obwohl die eigentliche Aufgabe fehlschlägt. Der KI-Modell-Endpoint kann in ein Timeout laufen, ein Tool Zugangsdaten ablehnen, eine Verbindung das Ergebnis nicht ausliefern oder das KI-Modell eine unbrauchbare Antwort liefern. Der gesamte Produktivpfad sollte auf einer Seite erfasst und jeder Ebene ein Verantwortlicher sowie ein Vertrag zugeordnet werden.
| Ebene | Zu testender Fehler | Anzufordernder Nachweis |
|---|---|---|
| Trigger und Eingang | Verworfenes, dupliziertes, verzögertes oder abgelehntes Event | Receipt ID, Zeitstempel, Retry-Verlauf, Dead-Letter-Status |
| Queue und Runtime | Run startet nie, bleibt hängen oder verliert dauerhaften Zustand | Run-Status, Queue-Verzögerung, Trace, Retry- und Timeout-Grund |
| KI-Modell | Provider-Fehler, Rate Limit, Latenz oder schlechte Ausgabe | Provider Request ID, KI-Modell/Version, Token- und Latenz-Trace |
| Tools und Daten | Berechtigungs-, Netzwerk-, Schema-, Retrieval- oder Kundencode-Fehler | Tool-Aufruf, Identität, Parameter, Response, Approval-Protokoll |
| Ergebnisauslieferung | Das Business-System erhält nie das Endergebnis | Auslieferungsversuch, Bestätigung, Retry, Endstatus |
Die Ausgabequalität gehört nicht in die Verfügbarkeitsdefinition. Genauigkeit, Richtlinientreue und Aufgabenerfüllung brauchen anwendungsfallspezifische Tests und Evaluation im Produktivbetrieb. Der folgende Artikel erklärt, wie sich eine Test Suite für Agenten aufbauen und Agenten-Runs im Produktivbetrieb nachvollziehen lassen. Das SLA sollte die Infrastruktur messbar machen; es kann nicht garantieren, dass ein probabilistisches KI-Modell auf jeden Prompt die richtige Antwort gibt.
Verfügbarkeitsziele in ein Ausfallbudget übersetzen
Das Verfügbarkeitsziel lässt sich in Minuten umrechnen. Entscheidend ist dabei der tatsächliche vertragliche Nenner. Die folgenden Werte gehen von einem Monat mit 30 Tagen und ohne ausgeschlossene Minuten aus. Wartung, Mindestdauer eines Events, Schwellen bei geringem Traffic oder Drittanbieterausschlüsse können den wirksamen Schutz deutlich verkleinern.
| Monatliches Ziel | Downtime-Budget | Vor Ausschlüssen |
|---|---|---|
| 99,9 % | 43 Minuten 12 Sekunden | 0,1 % von 43.200 Minuten |
| 99,95 % | 21 Minuten 36 Sekunden | 0,05 % von 43.200 Minuten |
| 99,99 % | 4 Minuten 19 Sekunden | 0,01 % von 43.200 Minuten |
Zu klären ist, ob Verfügbarkeit pro Kunde, Projekt, Region, Komponente oder über die gesamte Flotte des Anbieters gemessen wird. Ein flottenweiter Durchschnitt kann den Ausfall eines Kunden verbergen; eine Berechnung je Komponente kann mehrere enge Garantien schaffen, die nie den vollständigen Produktivpfad messen. Außerdem muss feststehen, ob die Telemetrie des Anbieters abschließend ist oder Kunden-Logs sie widerlegen können.
Incident-Kommunikation und Support-Reaktion getrennt betrachten
Ein Reaktionsziel von einer Stunde verpflichtet den Anbieter üblicherweise dazu, das Ticket zu bestätigen. Es verspricht keine Wiederherstellung innerhalb einer Stunde. Jede Frist braucht eine eigene Definition und einen eindeutigen Startpunkt: Erkennung durch den Anbieter, Meldung durch den Kunden oder Bestätigung des Schweregrads.
Ein brauchbarer Eskalationsplan benennt außerdem den unterstützten Kanal, wer einen P1 ausrufen darf, den Ansprechpartner für Eskalationen auf Führungsebene und die vom Kunden bereitzustellenden Informationen. Zu klären ist, ob der Bericht nach einem Vorfall den zeitlichen Ablauf, begünstigende Faktoren, Auswirkungen, Korrekturmaßnahmen und die Vermeidung einer Wiederholung abdeckt, statt lediglich die Statusseite zusammenzufassen.
Wiederherstellungsziele und Nachweise schriftlich festhalten
Verfügbarkeit beschreibt, ob ein Dienst erreichbar ist. Sie sagt nicht, wie viel Zustand verloren gehen kann oder wie schnell sich ein beschädigter Dienst wiederherstellen lässt. Der NIST-Leitfaden zur Notfallplanung behandelt Recovery Time Objective (RTO) und Recovery Point Objective (RPO) als getrennte Planungsgrößen.
Der Vertrag sollte fortlaufenden Zugriff auf Betriebsnachweise sichern. Käufer sollten Zeitstempel, Ausführungszustände, Fehler, KI-Modell- und Konfigurationsversionen, Tool-Aufrufe, Identitäten, Freigaben und Auslieferungsversuche exportieren können. Aufbewahrungsfristen und Schwärzung müssen so festgelegt sein, dass Logs lange genug für SLA-Ansprüche und Untersuchungen erhalten bleiben, ohne zu einem unkontrollierten Speicher für personenbezogene oder geheime Daten zu werden. Der ENISA-Leitfaden zum Monitoring von Cloud-Verträgen empfiehlt fortlaufende Rückmeldungen zur Sicherheit zwischen regelmäßigen Assessments.
Die Gutschriftklausel von der Antragsfrist her prüfen
Ausgangspunkt ist der Antragsmechanismus: berechtigte Gebühren, automatische oder beantragte Gutschriften, Prozentstufen, monatliche Obergrenze, Einreichungsfrist, erforderliche Logs, Entscheidungsverfahren des Anbieters und Verfall. Anschließend ist zu prüfen, ob Gutschriften die ausschließliche Abhilfe sind. Bei einem kritischen Workload kann die Rechtsberatung nach wiederholten wesentlichen Ausfällen auch Eskalations- oder Kündigungsrechte verlangen, statt lediglich eine höhere Gutschrift.
Vor der Unterzeichnung sollte feststehen, welche Agentencodes, Konfigurationen, Secret-Referenzen, Ausführungsverläufe, Traces, Evaluationsdaten, Dateien und Retrieval-Inhalte exportiert werden können. Ebenso wichtig sind Formate, API-Verfügbarkeit, Abrufzeitraum, Übergangsunterstützung, Löschbestätigung und Kosten. Die freiwilligen Cloud-Switching-Klauseln der EU-Kommission bieten eine aktuelle Referenz für Switching, Kündigung, Security und Business Continuity. Ob der EU Data Act anwendbar ist, muss weiterhin service- und vertragsspezifisch rechtlich geprüft werden.
Rechtliche Prüfung des gesamten Vertragswerks
| Dokument | Was es beantworten sollte | Was es nicht ersetzt |
|---|---|---|
| SLA | Verfügbarkeit, Incidents, Support, Recovery, Messung und Abhilfen | Datenschutzbedingungen oder Continuity-Planung des Kunden |
| DPA | Rollen, Weisungen, Security, Subprocessors, Unterstützung bei Verletzungen, Audits, Rückgabe und Löschung | Rechtsgrundlage, Hinweise, DSFA und Konfigurationspflichten des Verantwortlichen |
| Security Schedule | Technische Controls, Verantwortungsaufteilung, Umgang mit Schwachstellen und Assurance-Nachweise | Einen abgegrenzten Report, ein Zertifikat, Testergebnis oder vertragliches Recovery-Ziel |
| Subprocessor Schedule | Rechtsträger, Zweck, Standort, Transferpfad, Änderungshinweis und Widerspruchsverfahren | Die Prüfung kundenseitig gewählter KI-Modell-, Tool- oder Data Provider |
| Order Form und Addenda | Individuelle Uptime, Support, RTO/RPO, Haftung, regulierte Workloads und Rangfolge | Tests, ob das Betriebsdesign diese Anforderungen erfüllen kann |
Nach Artikel 28, 32 und 33 DSGVO muss ein Käufer in der Rolle des Verantwortlichen Auftragsverarbeiter einsetzen, die hinreichende Garantien bieten, das Auftragsverarbeitungsverhältnis dokumentieren, eine dem Risiko angemessene Security bewerten sowie Meldung und Unterstützung bei Verletzungen regeln. Diese Pflichten umfassen Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit und rechtzeitige Wiederherstellung; der Uptime-Prozentsatz einer Plattform belegt jedoch keine DSGVO-Compliance.
Branchenregeln können weiter gehen. Für erfasste Finanzunternehmen verlangt Artikel 30 DORA detaillierte ICT-Vertragsbedingungen und ergänzt für Services, die kritische oder wichtige Funktionen unterstützen, präzise Serviceziele, Incident-Unterstützung, Notfalltests, Audit-Zugriff und Transition-Anforderungen. NIS2 verpflichtet erfasste wesentliche und wichtige Einrichtungen, Risiken aus Incidents, Continuity und direkten Lieferanten nach nationalem Umsetzungsrecht zu steuern. Der offizielle DORA-Text und der NIS2-Text sollten gemeinsam mit Rechtsbeistand geprüft werden, statt beide als universelle Regel für KI-Plattformen zu behandeln.
So beantwortet unser öffentliches Regelwerk die Checkliste
Mit unseren öffentlichen Dokumenten können Käufer einen Großteil der ersten Prüfung vor einem Enterprise Vertriebsgespräch abschließen. Das Service Level Agreement ist auf den 30. Juli 2026 datiert und gilt für Pro und Enterprise. Weil abgedeckte Grenze, Berechnung, Ausschlüsse, Gutschriften, Incident-Kommunikation und Support-Fristen sichtbar sind, kann sich die Vertragsprüfung auf die für den Workload nötigen individuellen Bedingungen konzentrieren.
| Checklistenbereich | Veröffentlichte Connic-Baseline | Punkt für die Vertragsprüfung |
|---|---|---|
| Verfügbarkeit und Umfang | 99,9 % pro monatlichem Abrechnungszyklus für Agent Execution, Verbindungen und REST API | Ein höheres Ziel oder weitere abgedeckte Bereiche verhandeln, wenn die geschäftlichen Auswirkungen es erfordern. |
| Ausschlüsse | Dashboard, Development/Preview, Nicht-GA-Features, Kundencode, Quoten und Drittanbieter liegen außerhalb der genannten Grenze. | Fallbacks für KI-Modelle, BYOK, Tools und Auslieferung planen, statt eine End-to-End-Abdeckung anzunehmen. |
| Incidents | Bestätigung binnen 15 Minuten nach Erkennung, Updates mindestens alle 30 Minuten und Bericht zu einem wesentlichen Ausfall binnen fünf Geschäftstagen | Bei Bedarf kundenspezifische Bedingungen für Benachrichtigung, Wiederherstellung, Eskalation und Berichtsinhalte ergänzen. |
| Support | Erste P1-Response binnen einer Stunde; Standard-Supportzeiten sind werktags von 09:00–18:00 UTC. | Wo erforderlich, 24×7-Abdeckung und Ziele für Lösung oder Wiederherstellung festlegen. |
| Recovery | Die Security-Seite beschreibt Backups, Redundanz und regelmäßig getestete Disaster Recovery, veröffentlicht aber keine numerische RTO oder RPO. | Numerische Ziele je Zustands- und Datenklasse festlegen und aktuelle Nachweise von Restore-Tests anfordern. |
| Gutschriften | Stufen von 10 %, 25 % oder 50 %; monatliche Obergrenze 50 %; Antrag binnen 30 Tagen; Gutschriften sind die einzige SLA-Abhilfe. | Berechtigte Gebühren, Eskalation bei wiederholtem Ausfall und ausgehandelte Kündigungsrechte prüfen. |
| Datenschutz und Assurance | Öffentliches DPA, Security Practices, Subprocessor-Liste, Audit-Verfahren und Aufteilung der Kundenverantwortung | Aktuelle Reports und Zertifikate anfordern und Rechtsträger, Umfang, Zeitraum, Ausnahmen und Serviceabdeckung prüfen. |
Eine Enterprise-Vertragsprüfung beginnt mit einer einseitigen Liste der geschäftskritischen Agentenpfade. Pro Pfad werden Ausfallbudget, Datenverlustbudget, Support-Zeitraum, erforderliche Nachweise und rechtliche Vorgaben festgehalten. Die Lücken zwischen diesen Anforderungen und der öffentlichen Baseline werden zur Verhandlungsgrundlage für das Order Form.
Teile die kritischen Agentenpfade, Support-Zeiten, Recovery-Ziele, Datenpflichten und Nachweisanforderungen. Wir zeigen, wo die öffentliche Baseline passt und wo individuelle Enterprise-Bedingungen sinnvoll sind.
SLA besprechen