KI-Agent-SLA-Vorlage: Genauigkeit, Latenz, Human Handoff und Auditierbarkeit
Ein Service Level Agreement für KI-Agenten ist ein Vertragsanhang, der definiert, wann ein Task erfolgreich ist, wie er gemessen wird, wann ein Mensch übernehmen muss, welche Nachweise der Anbieter aufbewahrt und was passiert, wenn der Agent die vereinbarte Latte reißt. Uptime allein reicht nicht. Eine API kann HTTP 200 liefern, während der Agent eine erfundene Quelle zitiert, das falsche Tool aufruft, eine Zahlung doppelt ausführt oder einen Kunden in einer toten Queue warten lässt.
Diese Vorlage gehört in die Vertragsphase, nachdem Workflow und wahrscheinlicher Anbieter feststehen. Definierst du noch den Build, nutze die Scope-Vorlage für ein KI-MVP. Entscheidest du nach dem Pilot über Produktion, nutze die Kill-or-Scale-Scorecard für KI-Piloten. Prüfst du noch Security und Datenzusagen eines Anbieters, nutze den EU-Sicherheitsfragebogen für KI-Anbieter. Dieses SLA beginnt dort, wo diese Artefakte enden: bei wiederkehrenden Produktionspflichten, Nachweisen und Rechtsfolgen.
Das ist eine technische und kommerzielle Formulierungshilfe, keine Rechtsberatung. Werte in Klammern und Beispielziele sind Verhandlungsanker. Passe sie mit qualifizierter Rechtsberatung an Workflow, Risikoklasse, anwendbares Recht, Branchenregeln und Haftungsmodell an.
Brauchst du eine Agentenarchitektur, die diese Nachweise wirklich erzeugen kann?
Auditierbaren KI-Agenten planenDer kopierfertige KI-Agent-SLA-Vertragsanhang
Füge diesen Text in Leistungsbeschreibung, Statement of Work oder Order Form ein. Fülle jede Klammer. Hat ein Feld keinen Owner, keine Uhr, keinen Nenner oder keine Nachweisquelle, ist es noch nicht durchsetzbar.
Service-Level-Anhang für KI-Agenten, [Workflowname]
Version [1.0] · gültig ab [Datum] · Service Owner [Name] · Anbieter-Owner [Name]
1. Scope. Unterstützte Task-Klassen [Liste], Kanäle [Liste], Sprachen [Liste], Servicezeiten [Zeitzone], autorisierte Tools [Liste], erwartetes Monatsvolumen [Bandbreite], maximale Concurrency [Wert] und ausdrücklich ausgeschlossene Anwendungen [Liste].
2. Qualifizierter Task. Eine vom Service angenommene Produktionsanfrage mit erforderlichem Input, Authentifizierung und kundenseitiger Konfiguration. Test-Traffic, dokumentierter Missbrauch und kundenseitig ungültiger Input sind ausgeschlossen. Retries, Ausfälle vom Anbieter gewählter Dependencies und erfolglose Versuche werden nicht entfernt.
3. Erfolgreicher Task-Abschluss. Der Agent erreicht das freigegebene Geschäftsergebnis, erfüllt Output-Schema und Policy-Checks, nutzt nur autorisierte Tools, erzeugt keinen doppelten oder unautorisierten Seiteneffekt, enthält keine Materielle Halluzination und erreicht innerhalb der Latenzgrenze einen zulässigen Endstatus. Monatliches SLO: ≥ [98,0]% der Qualifizierten Tasks.
4. Materielle Halluzination. Eine falsche, erfundene, widersprochene oder unbelegte Tatsachenbehauptung, Quellenangabe, ein Tool-Argument oder eine Aktion, die das Task-Ergebnis verändert oder vernünftigerweise verändern beziehungsweise wesentlichen finanziellen, rechtlichen, Security-, Datenschutz-, Sicherheits-, Kunden- oder Reputationsschaden verursachen kann. SLO: 0 nicht eingedämmte Severity-1-Ereignisse und ≤ [1,0]% der adjudizierten Qualitätsstichprobe.
5. Tool-Use Success. Das vorgesehene autorisierte Tool erhält gültige Argumente, wird einmal ausgeführt, außer ein idempotenter Retry ist nötig, liefert ein verifiziertes Ergebnis und erzeugt den beabsichtigten Zustand. SLO: ≥ [97,0]% First-Attempt und ≥ [99,0]% Ultimate Success. Jeder Versuch inklusive Retry bleibt in der Telemetrie.
6. Latenz. End-to-End-Zeit von der Task-Annahme bis Abschluss, sicherer Verweigerung oder Handoff mit vollständigem Kontextpaket. Interaktive Tasks: p50 ≤ [5] Sekunden, p95 ≤ [15] Sekunden, p99 ≤ [30] Sekunden. Asynchrone Tasks: p95 ≤ [5] Minuten. Time to first token wird separat berichtet und erfüllt nicht die Abschlusslatenz.
7. Eskalation und Handoff. [100]% der Pflichtauslöser gehen an [Queue] mit Task-Zusammenfassung, Quellen, versuchten Aktionen, Tool-Ergebnissen, Grund, Risikostufe und empfohlenem nächsten Schritt. Menschliche Bestätigung p95 ≤ [15] Minuten innerhalb [Servicezeiten]. Die menschliche Uhr startet, wenn das vollständige Handoff-Paket in der Queue liegt.
8. Dependencies und Degraded Mode. Dependencies, Owner, Fallback und Timeout stehen in Anhang [X]. Ist eine Dependency nicht verfügbar, darf der Agent kein Ergebnis erfinden und keinen Seiteneffekt wiederholen. Er muss angenommene Arbeit sichern, in den freigegebenen Degraded Mode wechseln und innerhalb [Zeit] wiederherstellen, verweigern oder eskalieren.
9. Änderungen. Eval-Set, Grader, Prompt, Modell, Provider, Routing, Retrieval-Quelle, Tool-Schema und Guardrails werden versioniert. Geplante wesentliche Änderungen brauchen [30] Tage Vorankündigung, einen Regressionsbericht auf der eingefrorenen Baseline und Kundenfreigabe vor Produktion. Notfalländerungen brauchen Nachricht innerhalb [1] Arbeitstag und einen getesteten Rollback.
10. Nachweise und Retention. Der Anbieter liefert einen monatlichen SLO-Bericht und auf Anfrage Task-Level-Nachweise. Datenschutzgefilterte Traces bleiben [90] Tage abfragbar und [12] Monate archiviert, sofern Gesetz oder Datenanhang nichts anderes verlangen. Zugriff, Redaction, Legal Hold und Löschung stehen in Anhang [Y].
11. Severity und Rechtsfolgen. Severity, Bestätigung, Eindämmung, Wiederherstellung, Root-Cause-Bericht, Credits, Rollback, Aussetzung und Kündigungsrechte folgen der Tabelle unten. Service Credits ersetzen keine Rechtsfolgen für Vertraulichkeit, Datenschutz, Security, IP oder unautorisierte Aktionen, außer der Hauptvertrag regelt dies ausdrücklich.
Messregeln, die den SLA-Streit verhindern
| Feld | Vertragsdefinition |
|---|---|
| Messfenster | Ein Kalendermonat in [Zeitzone], mit täglichen Betriebsdashboards und ohne rückwirkendes Löschen gescheiterter Tasks. |
| System of Record | Anbietertelemetrie, abgeglichen mit Kunden-Task-IDs. Der Kunde kann rohe Metrikereignisse und das Versionsregister exportieren. |
| Qualitätsstichprobe | Eine geschichtete Zufallsstichprobe von mindestens [200] Qualifizierten Tasks pro Monat, ergänzt um jede Beschwerde, jeden Override, jede Hochrisikoaktion und jede vermutete Materielle Halluzination. Bei geringerem Volumen werden alle Tasks geprüft und die Stichprobengrenze offengelegt. |
| Adjudikation | Wo möglich deterministische Validierung, danach eine dokumentierte Rubrik durch geschulte Reviewer. Reviewer sehen die Nachweise, aber nicht das bevorzugte Ergebnis des Anbieters. Streitfälle gehen an [benannter Facheigentümer oder unabhängiger Reviewer]. |
| Segmentierung | Bericht nach Task-Klasse, Sprache, Kanal, Risikostufe und Modellversion. Ein starker Gesamtwert darf ein scheiterndes Hochrisikosegment nicht verdecken. |
| Ausschlüsse | Nur die benannten Ausschlüsse zählen. Jeder ausgeschlossene Task behält Trace, Reason Code, Nachweis und Dauer. Eine pauschale Formulierung wie "Third-Party-Problem" genügt nicht. |
| Quelländerungen | Messungen benennen Prompt-, Modell-, Provider-, Tool-, Retrieval-Corpus-, Policy- und Eval-Set-Version im jeweiligen Fenster. |
Die Formel bleibt bewusst einfach: Erfolgsquote = erfolgreiche Qualifizierte Tasks / alle Qualifizierten Tasks × 100. Verwende nicht abgeschlossene Agent Runs als Nenner. Sonst verschwinden Timeouts, Dead Loops und gescheiterte Handoffs, also genau die Fehler, deren Kontrolle der Kunde kauft.
1. Definiere erfolgreichen Task-Abschluss als Geschäftsergebnis
"Das Modell hat geantwortet" ist kein Abschluss. Bei einem Support-Agenten kann Erfolg bedeuten: korrekte Policy-Antwort aus einer freigegebenen Quelle, genau ein CRM-Update und entweder eine korrekte Lösung oder die richtige menschliche Queue. Bei einem Rechnungsagenten kann Erfolg bedeuten: jedes Pflichtfeld stimmt mit dem Dokument überein, die Konfidenzregel wurde angewandt und ohne benannte Freigabe wurde keine Zahlung ausgelöst.
Schreibe je Task-Klasse ein Completion Predicate. Eine sichere Verweigerung kann korrektes Verhalten sein, sollte aber nur dann als abgeschlossenes Geschäftsergebnis zählen, wenn das kommerzielle Modell sie bewusst so definiert. Berichte Straight-Through Completion, sichere Verweigerung und Human Handoff getrennt, damit der Anbieter sein Ziel nicht durch Eskalation jedes Falls erreicht.
2. Mache materielle Halluzination zur Severity-Definition
Das NIST Generative AI Profile verwendet Confabulation für selbstsicher präsentierte falsche oder fehlerhafte Inhalte. Ein Vertrag braucht einen engeren Materialitätstest. Die Definition oben stellt zwei Fragen: Ist Aussage oder Aktion unbelegt oder falsch, und kann sie ein Ergebnis verändern oder relevanten Schaden verursachen?
Ein Tippfehler, harmloser Stilfehler oder korrekt gekennzeichnete Unsicherheit ist keine Materielle Halluzination. Eine erfundene Refund Policy, eine nicht existente Rechtsquelle, nicht vorhandene Kundeneinwilligung, falsche Bankdaten oder ein Tool Call auf erfundenem Zustand sind es. Ein falscher Entwurf, den ein Pflichtverifier vor jeder externen Wirkung abfängt, bleibt Qualitätsfehler, ist aber kein nicht eingedämmtes Severity-1-Ereignis. Bewahre beide Zähler. Containment senkt Severity, es löscht keinen Nachweis.
3. Miss Tool-Nutzung beim ersten Versuch und beim Endergebnis
Nur Ultimate Success zu messen belohnt Retry Storms. Nur First-Attempt Success ignoriert sichere Erholung nach einem transienten Fehler. Berichte beides und lasse jeden Versuch im Trace. Ein erfolgreicher Call braucht das richtige autorisierte Tool, gültige Argumente, Berechtigung zum Ausführungszeitpunkt, eine verifizierte Antwort und exakt eine beabsichtigte Zustandsänderung.
Verlange Idempotency Keys für schreibende Aktionen wie Refunds, Buchungen, E-Mails und Datenbankupdates. Ein unautorisierter Tool Call, eine doppelte irreversible Aktion oder die Umgehung einer Pflichtfreigabe ist automatisch erfolglos und löst die vereinbarte Severity aus, selbst wenn die Downstream-API Erfolg meldet.
4. Nimm den ganzen Workflow in die Latenzuhr
Miss das Erlebnis des Käufers, nicht den schnellsten Modellspan. Die Uhr umfasst Routing, Retrieval, Modellaufrufe, Tool-Ausführung, Validatoren, Retries und vom Anbieter kontrollierte Queue-Zeit. Sie stoppt erst bei Abschluss, sicherer Verweigerung oder vollständigem Handoff. Danach startet das separate SLO für die menschliche Reaktion.
Die SRE-Empfehlung von Google nutzt Perzentile, weil Durchschnittswerte den Long Tail verstecken. Nutze p50 für den typischen Fall, p95 als Betriebszusage und p99, wo ein plausibler Worst Case zählt. Interaktive, Voice-, Batch- und Hochrisiko-Freigabe-Tasks brauchen eigene Ziele.
5. Vertraglich fixierter Handoff braucht Kontext
Pflichtauslöser sollten beobachtbare Regeln sein, nicht das Bauchgefühl des Modells. Typische Trigger sind Out-of-Scope-Anfrage, fehlende Pflichtquelle, gescheitertes Write Tool nach dem Retry Budget, widersprüchliche Kundendaten, Policy-Schwelle, regulierte Entscheidung, Nutzerwunsch nach einem Menschen, vermutete Prompt Injection oder eine Aktion oberhalb eines Freigabewerts.
Ein Handoff ist erst erfolgreich, wenn er mit genug Kontext in der benannten Queue liegt, damit ein Mensch handeln kann, ohne die Konversation neu aufzubauen. Miss Trigger-Erkennung, Routing, Paketvollständigkeit, Bestätigung, Lösung und Reopen Rate. Die ICO-Leitlinie zur menschlichen Prüfung empfiehlt zudem, menschliche Overrides samt Gründen zu protokollieren. Genau daraus entstehen neue Eval-Fälle.
6. Weise unavailable Dependencies zu, statt sie auszuschließen
Liste jede wesentliche Dependency: Modell-API, Vector Store, Identity Provider, CRM, Zahlungsdienst, Kundendatenquelle und Human Queue. Benenne Auswahl und Kontrolle, Timeout, Retry Budget, Fallback, Datensicherung und Incident Owner.
Ein kundenseitig kontrollierter Ausfall kann für den belegten Zeitraum vom Qualitätscredit ausgenommen werden, bleibt aber in Dependency- und Degraded-Mode-Berichten. Ein vom Anbieter gewählter Modellprovider darf kein pauschaler Fluchtweg sein. Der Anbieter kontrolliert vielleicht nicht den Ausfall, aber Timeouts, Circuit Breaker, Queueing, Fallback, Duplicate Prevention und ehrliche Nutzerkommunikation.
7. Friere das Eval-Set ein, nicht das Lernen
Versioniere Fälle, erwartete Ergebnisse, Rubriken, Grader, Kategoriegewichte und Sampling. Speichere zu jedem Release einen Hash. Keine Partei darf einen schweren Fall löschen, einen Fail umetikettieren oder den Grader nur deshalb ändern, damit das aktuelle System besteht.
Neue Risiken müssen trotzdem ins Set. Die praktische Regel lautet Dual Reporting: Führe eingefrorene Baseline und vorgeschlagenes Set ein volles Messfenster parallel aus, zeige Kategorie-Deltas, genehmige die Änderung und mache das neue Set ab einem benannten Datum verbindlich. Halte einen versteckten Holdout und prüfe Testkontamination. Das NIST AI RMF verlangt dokumentierte Testsets, Metriken und Tools, Evaluation unter produktionsähnlichen Bedingungen und Monitoring in Produktion.
8. Behandle Modell- und Providerwechsel wie Production Releases
Eine wesentliche Änderung umfasst Provider, Modellfamilie, Snapshot, Routingregel, System Prompt, Tool-Schema, Retrieval-Corpus, Safety Policy oder Grader. Pinne Versionen, wo der Provider es unterstützt. OpenAIs eigene Hinweise zur API-Kompatibilität warnen vor verändertem Prompting-Verhalten zwischen Snapshots und empfehlen gepinnte Versionen plus Evals.
Verlange Vorankündigung, Regressionsevidenz nach Task-Segment, Security Review bei geändertem Datenpfad, Kosten- und Latenzdelta, Freigabe-Owner und Rollback. Bei erzwungener Provider-Retirement muss der Anbieter die Migration früh genug belegen, damit du Nachfolger, Fallback oder Aussetzung der Task-Klasse wählen kannst.
9. Bewahre beweisfähige Traces auf, aber nicht blind alles
Jeder Trace braucht eindeutige Task- und Trace-ID, Task-Klasse, Zeitstempel, Akteur und Tenant, Modell- und Prompt-Template-Version, IDs und Revisionen abgerufener Dokumente, Toolname und redigierte Argumente, Resultatstatus, Retries, Freigaben, Handoff-Events, Enddisposition, Metric Reason Codes und verknüpften Incident. Rohe Prompts oder Outputs werden nur gespeichert, wenn der Datenanhang das erlaubt.
Die GenAI-Observability-Leitlinie von OpenTelemetry zeigt Agent-, Modell- und Tool-Spans und weist ausdrücklich auf sensible Inhalte in aufgezeichneten Messages hin. Regle Zugriff, Redaction, Speicherregion, Legal Hold, Export und Löschung gemeinsam mit Retention. "Wir haben Logs" ist keine Audit-Klausel, wenn der Kunde sie im Streitfall nicht abrufen kann.
10. Verknüpfe Severity mit Containment und kommerziellen Rechtsfolgen
Die folgenden Werte sind anpassbare Ausgangspunkte. Reaktionszeiten müssen zu Servicezeit, Risiko und Supportpreis passen.
| Stufe | Beispieltrigger | Betriebspflicht | Vertragsfolge |
|---|---|---|---|
| Severity 1, kritisch | Unautorisierte irreversible Aktion, offengelegte personenbezogene Daten, nicht eingedämmte materielle Falschaussage mit ernstem Impact, breit unsicherer Output oder Verlust von Auditnachweisen. | Bestätigung in [15] Minuten, Deaktivierung oder Eindämmung in [60] Minuten, sicherer Service in [4] Stunden, Nachricht an benannte Kontakte, Evidence Hold und Root-Cause- samt Präventionsbericht in [5] Arbeitstagen. | Sofortige Aussetzung der betroffenen Autonomie, Rollback auf Anbieterkosten, [25]% Credit der betroffenen Monatsgebühr und Kündigungsrecht nach [einem] nicht behobenen oder [zwei] wiederholten Ereignissen in [sechs] Monaten. |
| Severity 2, schwer | Monatliches Qualitäts- oder Latenz-SLO verfehlt, wiederholter Tool-Fehler, defekter Handoff für ein wesentliches Segment oder nicht funktionierender Dependency-Fallback. | Bestätigung in [1] Arbeitsstunde, Mitigation in [1] Arbeitstag, Wiederherstellung in [2] Arbeitstagen, Korrekturplan in [5] Arbeitstagen. | [10]% Credit der betroffenen Monatsgebühr je verfehltem Kern-SLO, gedeckelt auf [25]% im Monat, plus Pflichtremediation. [Drei] Breach-Monate in rollierenden [sechs] Monaten schaffen ein Kündigungsrecht. |
| Severity 3, gering | Isolierter nicht materieller Defekt, unvollständige unkritische Metadaten oder verspäteter Bericht ohne Kundenwirkung. | Bestätigung in [1] Arbeitstag und Reparatur in [10] Arbeitstagen oder im vereinbarten Release. | Korrektur und Aufnahme in den Improvement Backlog. Wiederholte gleichartige Ereignisse werden zu Severity 2 zusammengefasst. |
Credits sollten aus gemeinsamen Nachweisen automatisch entstehen, nicht von einer kurzen Claim-Frist abhängen, die nur der Anbieter berechnen kann. Sie brauchen außerdem eine Eskalation. Ein Credit von 10% macht keine unautorisierte Zahlung akzeptabel. Für regulierte Finanzunternehmen liefert DORA Artikel 30 nützliche Vertragsmechanik: präzise quantitative und qualitative Service Levels, Meldung wesentlicher Entwicklungen, laufende Überwachung, Audit-Rechte, Korrektur und Exit-Planung. DORA gilt nicht für jeden Käufer, die Mechanik ist trotzdem solide.
Warum das SLA des Modellproviders deinen Agenten nicht abdeckt
Das Upstream-SLA ist ein Input deiner Architektur, nicht das Kundenergebnis. Das Vertex AI Platform SLA definiert Downtime etwa über serverseitige Fehlerraten und gestaffelte Credits. Es verspricht nicht, dass ein Agent das richtige Tool auswählt, eine echte Quelle zitiert oder einen Geschäftsprozess abschließt. Dein Anbietervertrag muss Provider-Verfügbarkeit in ein End-to-End-Design überführen und die fehlenden Qualitäts-, Handoff- und Auditpflichten ergänzen.
Darum gehört auch der Preis neben Reliability. Ein Fallback, der das SLO zum Zehnfachen der Normalkosten hält, schützt Kontinuität und kann trotzdem den Business Case zerstören. Miss den kommerziellen Nenner mit dem Kostenmodell pro erfolgreicher KI-Agent-Aktion und regle, wer Retries, Fallback-Provider, menschliche Nacharbeit und Incident-Remediation bezahlt.
EU-Kontext für Procurement und Compliance
Behaupte nicht, dass diese Vorlage ein System compliant macht. Einstufung und Pflichten hängen von Zweck und Branche ab. Wo die Hochrisiko-Regeln des EU AI Act gelten, behandelt der offizielle Text automatische Logs, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersecurity in den Artikeln 12, 14 und 15. Die europäische Public-Buyers-Community veröffentlicht außerdem Mustervertragsklauseln für KI und warnt zugleich, dass sie keine vollständige Vereinbarung sind und angepasst werden müssen.
Das kommerzielle SLA steht neben DPA, Security-Anhang, IP-Regeln, KI-Nutzungsgrenzen, regulatorischer Rollenverteilung, Versicherung, Haftung und Exit Assistance. Die ICO-Leitlinie zu Verträgen und Drittparteien empfiehlt ausdrücklich, akzeptable Genauigkeit vor der Beschaffung festzulegen und Accuracy-KPIs oder SLAs in schriftliche Anbieterverträge aufzunehmen.
"Der schwierige Teil ist nicht, 98 statt 97 Prozent zu wählen. Er besteht darin, den Nenner zu definieren, gescheiterte Traces aufzubewahren und festzulegen, was der Anbieter tun muss, wenn der Agent selbstsicher falsch liegt. Dort wird aus einer Metrik ein Vertrag."
FAQ zum KI-Agent-SLA
Was ist ein KI-Agent-SLA?
Wie wird die Genauigkeit eines KI-Agenten im Vertrag gemessen?
Was ist eine materielle Halluzination?
Soll ein Ausfall des Modellproviders vom SLA ausgeschlossen werden?
Was passiert bei Änderungen an Eval-Set oder Modell?
Welche Rechtsfolgen gehören in ein SLA für generative KI?
Ist ein KI-SLA dasselbe wie KI-Abnahmekriterien?
Fazit
Ein brauchbares KI-Agent-SLA bindet einen Workflow an einen Nenner, eine Beweiskette und eine Konsequenz. Es verspricht nicht abstrakt, dass ein Modell korrekt ist. Es sagt, welche Tasks zählen, wie guter Abschluss aussieht, welche Fehler materiell sind, wann die menschliche Uhr startet, wie Dependencies und Änderungen behandelt werden und was der Anbieter nach einem Breach schuldet.
Fülle die Klammern mit Evidenz aus deinem Pilot, nicht mit einem Vendor-Benchmark. Lass Engineering anschließend beweisen, dass Trace, Eval-Register, Handoff-Queue, Rollback und Monatsbericht tatsächlich erzeugt werden können. Kann das System den Nachweis nicht liefern, ist die Klausel nur Theater.
Recherchequellen
Recherchiert und geprüft am 19. Juli 2026. Standards, Provider-Bedingungen und regulatorische Umsetzung können sich ändern. Prüfe die aktuelle Quelle vor der Unterschrift.
- NIST AI 600-1, Generative Artificial Intelligence Profile, Confabulation und Risikokontrollen.
- NIST AI RMF Core, dokumentierte Testsets, produktionsnahe Evaluation und Monitoring.
- Verordnung (EU) 2024/1689, EU AI Act, insbesondere Artikel 12, 14 und 15.
- Verordnung (EU) 2022/2554, DORA, Artikel 30 für anwendbare Finanzunternehmen.
- ICO, Contracts and third parties in AI, Accuracy Due Diligence, KPIs und Auditklauseln.
- Google SRE Book, Service Level Objectives, Indikatoren, Perzentile, Messfenster und Error Budgets.
- Google Cloud Vertex AI Platform SLA, Provider-Uptime, Ausschlüsse und Credits.
- OpenTelemetry, GenAI Observability, Agent-, Modell- und Tool-Traces sowie sensible Inhalte.
- OpenAI API Backward Compatibility, Modell-Snapshots, Pinning und Evals.
- AgentSLA: Towards a Service Level Agreement for AI Agents, Forschungsrahmen für agentische Quality of Service.
Willst du SLA, Evals und Audit Trail als ein Produktionssystem entwerfen?
KI-Agenten besprechen