Fragen zum AI Gateway-SLA für Modell-Routing, Fallback und Support

Ein AI-Gateway-SLA kann einfach aussehen, bis der erste Modellvorfall eintritt. Ein Käufer sieht einen Verfügbarkeitsprozentsatz, eine Support-Adresse und das Versprechen, dass das Gateway Anfragen weiterleitet. Das Produktionsteam muss jedoch schwierigere Fragen beantworten: Welcher Endpunkt ist abgedeckt, welcher Upstream-Anbieter ist ausgefallen, ob der Fallback den Modellvertrag geändert hat, welche Nachweise der Support benötigt und ob eine Abhilfe automatisch erfolgt.

Verwenden Sie diese Checkliste für AI-Gateway-SLAs, um die Sprache des Anbieters in eine Nachweisdatei umzuwandeln. Das Ziel ist nicht, mit Slogans zu verhandeln. Das Ziel ist zu wissen, was das SLA abdeckt, was es ausschließt, wie Routing und Fallback nachgewiesen werden und was Ihr Team vor einer Verlängerung überprüfen sollte.

Speziell für Flatkey besagt das öffentliche Service Level Agreement, das am 6. Juli 2026 geprüft wurde, dass der abgedeckte Bereich das gehostete Dashboard, das API-Gateway, das Routing, die Messung und die Kontodienste umfasst, die Flatkey direkt betreibt. Es zielt auf eine monatliche Verfügbarkeit von 99,5 % für abgedeckte Endpunkte ab, schließt Ausfälle von Drittanbietern von KI-Modellen und anbieterseitige Fehler aus, fordert Kunden auf, für den Support Anfrage-IDs, Zeitstempel, Fehler, Endpunkt, Konto-E-Mail und eine Zusammenfassung der Auswirkungen zu senden, und erstellt keine automatischen Gutschriften, es sei denn, eine separate schriftliche Vereinbarung besagt etwas anderes. Behandeln Sie dies als ersten Nachweis und überprüfen Sie dann Ihr Konto, Ihre Traffic-Klasse, Ihre Fallback-Richtlinie und Ihren Support-Prozess, bevor der Produktionsverkehr davon abhängt.

Kurze Antwort: Fragen zum AI-Gateway-SLA

| SLA-Bereich | Fragen Sie dies vor der Unterzeichnung oder Verlängerung | Aufzubewahrende Nachweise | |---|---|---| | Abgedeckter Dienst | Welche Dashboard-, API-Gateway-, Routing-, Messungs-, Konto- und Support-Funktionen sind abgedeckt? | Aktuelle SLA-URL, Vertragsplan, Endpunktliste und datierte Screenshots. | | Verfügbarkeitsberechnung | Wird die Verfügbarkeit durch Anbieterüberwachung, Kunden-Probes, öffentlichen Status oder einen Vertragsbericht gemessen? | Monatlicher Verfügbarkeitsbericht, Probe-Protokoll, Vorfallexport und Berechnungsmethode. | | Drittanbieter | Sind Upstream-Modellausfälle, Ratenbegrenzungen, regionale Einschränkungen, Modelländerungen und anbieterseitige Fehler ausgeschlossen? | Anbieter-Statuslinks, Modellfehlermeldungen, Routenprotokolle und Ausschlussklauseln des Anbieters. | | Routing | Welches Modell, welcher Anbieter, welches Konto, welche Region oder welche Gruppe wurde zuerst versucht? | Anfrage-ID, ausgewählte Route, Modell-ID, Endpunktfamilie, Schlüsselbesitzer und Zeitstempel. | | Fallback | Welche Fehler lösen Wiederholungsversuche, Fallback, Warteschlangen oder ein Fail-Closed-Verhalten aus? | Fallback-Richtlinie, Routenverfolgung, Anzahl der Wiederholungsversuche, endgültiges Modell und Nachweis der akzeptierten Ausgabe. | | Support | Welche Nachweise müssen gesendet werden und welcher Schweregradpfad gilt? | Ticket-Vorlage, Anfrage-IDs, Endpunkt, Zeitstempel, Fehler, Zusammenfassung der Auswirkungen und Antwortzeitrahmen. | | Abhilfemaßnahmen | Erfolgen Servicegutschriften automatisch, von Fall zu Fall oder nur in einer separaten schriftlichen Vereinbarung? | SLA-Abhilfeklausel, Vertragsänderung, Gutschriftsantrag und Finanzgenehmigung. | | Verlängerung | Was muss vor der nächsten Laufzeit überprüft werden? | Vorfallsregister, Fallback-Ausnahmen, Supportergebnisse, Quotenereignisse, Preisänderungen und Routengenehmigungen. |

Die praktische Antwort auf das AI-Gateway-SLA lautet: Trennen Sie die Verantwortung des Gateways von der des Upstream-Anbieters und testen Sie dann die Route. Wenn der Käufer die Route, den Fallback, das Support-Ticket und den monatlichen Verfügbarkeitsnachweis nicht prüfen kann, ist das SLA nicht für die Produktions-Governance bereit.

Trennen Sie die Gateway-Verfügbarkeit von der Verfügbarkeit des Upstream-Modells

Die erste Frage zum AI-Gateway-SLA ist, ob der Anbieter das Gateway, das Upstream-Modell oder das vollständige Endergebnis für den Benutzer verspricht. Das sind unterschiedliche Ebenen.

Das aktuelle öffentliche SLA von Flatkey macht diese Trennung explizit: Abgedeckte, von Flatkey betriebene Dienste sind im Geltungsbereich, während Drittanbieter von Modellen, Anbieterausfälle, Ratenbegrenzungen von Anbietern, Richtlinienänderungen, regionale Einschränkungen, Modellverhalten und anbieterseitige Fehler außerhalb des SLA liegen. Dies ist beim Kauf von Gateways so üblich, dass die Beschaffung einen einzelnen Verfügbarkeitsprozentsatz niemals als "alle Modellanfragen werden erfolgreich sein" behandeln sollte.

Verwenden Sie diese Aufteilung in der Nachweisdatei:

| Ebene | Was ausfallen kann | Nachweis des Käufers | |---|---|---| | Client und SDK | Falsche Basis-URL, falscher Schlüssel, nicht unterstützter Endpunkt, zu niedriges Timeout, Parser-Fehler. | Client-Konfiguration, SDK-Version, Anfrage-Body, Timeout und lokale Protokolle. | | Gateway | Authentifizierung, Routing, Messung, Gateway-Endpunkt, Dashboard, Nutzungsprotokoll, Kontodienste. | Gateway-SLA, Anfrage-ID, Routenverfolgung, Status, Nutzungsdatensatz und Support-Ticket. | | Upstream-Anbieter | Anbieterausfall, Anbieterkontingent, Modelleinstellung, regionale Sperre, Richtlinienablehnung, modellspezifisches Verhalten. | Anbieterstatus, Anbieter-Kontingentseite, Upstream-Fehlermeldung, Modell-ID und Fallback-Entscheidung. | | Geschäftsworkflow | Auswirkungen auf Benutzer, Warteschlangentiefe, verschlechterte Ausgabe, verfehltes internes Ziel. | Vorfallszeitachse, betroffene Traffic-Klasse, Zusammenfassung der Kundenauswirkungen, Rollback-Entscheidung. |

Hier wird ein AI-Gateway-SLA operativ. Der Käufer sollte eine Routenverfolgung auf Routenebene anfordern, nicht nur eine monatliche Verfügbarkeitszahl.

Fragen zu Routing und Fallback

Routing ist der Teil eines AI-Gateway-SLA, der am häufigsten zu ungenau spezifiziert wird. Ein Gateway kann mehrere Modelle und Anbieter unterstützen, aber die Produktionszuverlässigkeit hängt davon ab, welche Route für jede Traffic-Klasse zulässig war.

Die offizielle Gateway-Dokumentation von anderen Anbietern zeigt, warum die Details wichtig sind. Die Dokumentation zum Vercel AI Gateway beschreibt das Anbieter-Routing und Modell-Fallbacks, einschließlich der Kontrolle über die Routing-Reihenfolge und das Fallback-Verhalten. In der Dokumentation zum Modell-Fallback heißt es, dass Backups der Reihe nach ausprobiert werden können, wenn ein primäres Modell ausfällt oder nicht verfügbar ist. Die Dokumentation zum Pydantic AI Gateway beschreibt Routing-Gruppen, in denen Priorität und Gewichtung über Failover oder Lastausgleich entscheiden, mit einem Fallthrough, wenn ein Mitglied mit höherer Priorität nicht verfügbar ist, ratenbegrenzt ist oder Fehler aufweist. Dies sind nützliche Kategoriebeispiele, keine Garantien von Flatkey. Sie zeigen die Fragen, die ein Käufer jedem Gateway stellen sollte, einschließlich Flatkey.

Verwenden Sie diese Routing-Tabelle, bevor Sie den automatischen Fallback genehmigen:

| Fehlersignal | Standardfrage des Käufers | Sicherer Nachweis | |---|---|---| | Gateway 401 oder 403 | Waren der Schlüssel, das Konto, die Umgebung oder der Richtlinienbereich falsch? | Schlüsselbesitzer, Umgebung, Authentifizierungsfehler und Aufzeichnung der Richtlinienverweigerung. | | Modell nicht gefunden | Existierte das angeforderte Modell im aktuellen Katalog für dieses Konto? | Katalogzeile, Modell-ID, Endpunktfamilie und Nachweis des Veröffentlichungs- oder Testdatums. | | Provider 429 | War das Kontingent für dieses Konto, diese Region, dieses Modell oder diese Bereitstellung erschöpft? | Kontingentseite, Upstream-Fehlertext, Retry-After-Daten und Fallback-Richtlinie. | | Provider 5xx oder Timeout | Sollte das Gateway es erneut versuchen, die Route für dasselbe Modell wechseln, in die Warteschlange stellen oder geschlossen ausfallen? | Routenverfolgung, Anzahl der Wiederholungsversuche, Timeout-Schwellenwert, Endergebnis und Kostenaufzeichnung. | | Kontextlimit oder nicht unterstützte Eingabe | Ist ein Fallback erlaubt, wenn das Backup-Modell den Kontext, die Werkzeuge, das Sehvermögen oder das Medienverhalten ändert? | Modellvertrag, Funktionstest, Überprüfung der akzeptierten Ausgabe und Genehmigung durch den Product Owner. | | Richtlinien- oder Sicherheitsablehnung | Darf ein anderer Anbieter dieselbe Anfrage erhalten? | Datengrenze, Anbietergenehmigung, Prompt-Klassifizierung und Compliance-Freigabe. | | Unbekannter Fehler | Was ist die Abbruchbedingung? | Incident-Runbook, maximale Versuche, Fail-Closed-Regel und Support-Eskalation. |

Der stärkste Nachweis für ein AI-Gateway-SLA ist eine Routenverfolgung, die die Startroute, die Fallback-Regel, die endgültige Route und den Grund für jeden Übergang benennt.

Fallback ist nicht immer ein Gewinn für die Zuverlässigkeit

Die Beschaffung fragt oft, ob das Gateway über einen automatischen Fallback verfügt. Plattformteams sollten mit einer zweiten Frage antworten: Fallback worauf?

Ein automatischer Wechsel von einem Konto zu einem anderen Konto für dasselbe genehmigte Modell kann sinnvoll sein. Ein Wechsel von einer Modellfamilie zu einer anderen kann Qualität, Datenverarbeitung, Latenz, Ausgabeformat, Werkzeugverhalten, Bild- oder Videorichtlinien und Kosten verändern. Einiger Datenverkehr sollte geschlossen ausfallen, da ein versteckter Fallback den Vorfall verschlimmern würde.

Definieren Sie den Fallback nach Verkehrsklasse:

| Verkehrsklasse | Fallback-Haltung | Warum | |---|---|---| | Kunden-Chat | Nur genehmigte äquivalente Routen verwenden oder einen kontrollierten Fehler zurückgeben. | Die für den Benutzer sichtbare Qualität und Sicherheit müssen vorhersehbar bleiben. | | Interne Zusammenfassung | Erneut versuchen, in die Warteschlange stellen oder eine kostengünstigere genehmigte Route verwenden. | Latenz kann gegen Kosten und Abschluss eingetauscht werden. | | Bewertungen und Benchmarks | Geschlossen ausfallen. | Versteckte Modelländerungen verfälschen Vergleichsdaten. | | Finanzsensible Batch-Jobs | In die Warteschlange stellen oder vor dem Fallback eine Genehmigung einholen. | Wiederholungsversuche und Backup-Modelle können die Ausgaben vervielfachen. | | Agenten-Workflows mit Werkzeugen | Fallback erst nach Testen des Werkzeugaufrufverhaltens. | Werkzeugschemata und Streaming-Verhalten können je nach Anbieter unterschiedlich sein. | | Regulierter oder kundenisolierter Datenverkehr | Geschlossen ausfallen, es sei denn, der Backup-Anbieter und die Region sind vorab genehmigt. | Datengrenzen und Beschaffungsnachweise sind wichtiger als die automatische Fertigstellung. |

Dies ist der vom Käufer durchgeführte Test: Führen Sie denselben Prompt über die primäre Route und die vorgeschlagene Fallback-Route aus und vergleichen Sie dann die Antwortform, Protokolle, Kosten, Latenz, akzeptierte Ausgabe und Support-Nachweise. Betrachten Sie ein AI-Gateway-SLA erst dann als vollständig, wenn der Fallback-Nachweis vorliegt.

Support-Fragen für das Nachweispaket

Das aktuelle SLA von Flatkey fordert Kunden auf, sich mit der Konto-E-Mail, dem betroffenen Endpunkt, den Anfrage-IDs (falls verfügbar), Zeitstempeln, Fehlermeldungen und einer Zusammenfassung der Auswirkungen an den Support zu wenden. Dies ist eine nützliche Vorlage für jeden Support-Prozess eines AI-Gateway-SLA.

Erstellen Sie vor dem Start ein Support-Paket mit diesen Feldern:

| Feld | Warum es wichtig ist | |---|---| | Konto-E-Mail und Arbeitsbereich | Ermöglicht dem Support, den richtigen Mandanten, Schlüssel und die Berechtigung zu finden. | | Betroffener Endpunkt | Trennt Vorfälle in den Bereichen Chat, Antworten, Nachrichten, Bild, Video und Dashboard. | | Anfrage-IDs | Verbindet Anwendungs-Logs mit Gateway- und Upstream-Traces. | | Zeitstempel mit Zeitzone | Verhindert, dass monatliche Verfügbarkeits- und Vorfallfenster abweichen. | | Modell-ID und Routenklasse | Zeigt an, welche Routenrichtlinie und Anbieterfamilie beteiligt waren. | | Fehlermeldungen und Statuscodes | Trennt Authentifizierungs-, Kontingent-, Timeout-, Anbieter- und Parser-Fehler. | | Zusammenfassung der Auswirkungen | Erklärt betroffene Benutzer, Einnahmen, Aufträge, Warteschlangentiefe oder interne Arbeitsabläufe. | | Kundenseitige Wiederholungsversuche | Zeigt, ob doppelte Versuche die Kosten oder die Last erhöht haben. | | Erforderliche Maßnahme | Klärt, ob Sie eine Diagnose, eine Routen-Deaktivierung, eine Gutschriftsprüfung oder eine Vertragsverfolgung benötigen. |

Verknüpfen Sie dieses Support-Paket mit Ihrem Prozess für Audit-Protokolle zur Nutzung der KI-API. Wenn nach einem Vorfall keine Anfrage-IDs und Routennachweise verfügbar sind, wird der Support-Prozess zu einer Gedächtnisübung.

Fragen zu Abhilfe und Gutschriften

Der Abschnitt „Abhilfe“ eines AI-Gateway-SLA ist wichtig, da er oft definiert, was der Käufer tatsächlich zurückfordern kann. Ein Ziel von 99,5 % ohne Gutschriftsklausel unterscheidet sich von einem zugesicherten SLA mit automatischen Servicegutschriften, schriftlichen Benachrichtigungsanforderungen, Ausschlüssen und Antragsfristen.

Das öffentliche SLA von Flatkey besagt, dass es keine automatischen Servicegutschriften, Rückerstattungen, Strafen oder pauschalierten Schadensersatz gibt, es sei denn, eine separate schriftliche Vereinbarung sieht eine andere Abhilfe vor. Jede Kulanzanpassung, Saldokorrektur oder Support-Abhilfe wird von Fall zu Fall im Rahmen der Nutzungsvereinbarung und der geltenden Richtlinien behandelt.

Das macht das SLA nicht unbrauchbar. Es bedeutet, dass die Beschaffung die richtigen Fragen stellen sollte:

1. Ist das öffentliche SLA die gesamte Vereinbarung, oder gibt es einen separaten Unternehmensplan?
2. Wenn Gutschriften existieren, wie lautet das Antragsfenster?
3. Welche Nachweise muss der Kunde erbringen?
4. Sind Ausfälle von Upstream-Anbietern ausgeschlossen, auch wenn das Gateway diesen Upstream ausgewählt hat?
5. Sind geplante Wartungsarbeiten und Notfallsicherheitsmaßnahmen ausgeschlossen?
6. Werden Latenz, Modellqualität, Drosselung und Fallback-Verhalten abgedeckt oder nur die Verfügbarkeit?
7. Gilt die Abhilfe für Prepaid-Guthaben, Rechnungsgutschriften, Rückerstattungen, Support-Maßnahmen oder Kündigungsrechte?
8. Wer in der Finanzabteilung genehmigt den endgültigen Anspruch?

Die Antwort sollte in derselben Anbieterdatei wie die Risikobewertung für KI-API-Anbieter gespeichert sein. Rechts- und Finanzabteilungen benötigen dieselben Nachweise, die Plattform-Ingenieure bei der Überprüfung von Vorfällen verwenden.

Kontingente, Ratenbegrenzungen und Anbieterabhängigkeiten

Ein KI-Gateway-SLA kann gültig sein, während eine Anfrage dennoch fehlschlägt, weil ein Kontingent eines Upstream-Anbieters erschöpft ist. Aus diesem Grund gehören Nachweise über Kontingente in die SLA-Überprüfung.

Die Dokumentation zu den Kontingenten von Microsofts Azure OpenAI besagt, dass die Limits für Token pro Minute und Anfragen pro Minute pro Region, Abonnement und Modell- oder Bereitstellungstyp gelten. Die Dokumentation von AWS Bedrock verweist Teams ebenfalls auf Service-Kontingente für Bedrock-Ressourcen und stellt fest, dass die Modellinferenz durch Token-Nutzungskontingente gesteuert wird. Diese Fakten der Anbieter sind keine Versprechen von Flatkey. Sie sind Erinnerungen daran, dass die Konfiguration des Upstream-Kontos darüber entscheiden kann, ob während eines realen Vorfalls ein Fallback verfügbar ist.

Fügen Sie diese Prüfungen zur Startdatei hinzu:

| Abhängigkeitsprüfung | Nachweis | |---|---| | Umfang des Upstream-Kontingents | Region, Konto oder Abonnement, Modell, Bereitstellungstyp, TPM/RPM oder Anbieteräquivalent. | | Umfang des Gateway-Kontingents | Schlüssel, Team, Umgebung, Modellgruppe, Budgetobergrenze und Rücksetzfenster. | | Wiederholungsbudget | Maximale Anzahl an Wiederholungsversuchen, Jitter/Backoff-Richtlinie und Kostenschutz. | | Fallback-Kapazität | Kontingent für Backup-Route, Modellverfügbarkeit und Anbietergenehmigung. | | Drosselungsverhalten | Fehlercode, Retry-After-Signal, Support-Eskalation und benutzerseitige Handhabung. |

Wenn das Kontingent nicht vom selben Verantwortlichen wie das Routing gemessen wird, wird die Überprüfung des KI-Gateway-SLA den häufigsten Fehlermodus übersehen: Die Route existiert, aber das Konto kann den Produktionsverkehr nicht aufnehmen.

Flatkey Staging-Überprüfung

Für Flatkey unterstützt der am 6. Juli 2026 überprüfte öffentliche Produktnachweis ein KI-API-Gateway, einen API-Schlüssel, die OpenAI-kompatible Router-Basis-URL https://router.flatkey.ai/v1, eine Dashboard-orientierte Nutzungs- und Abrechnungstransparenz, eine Preisüberprüfung und eine routingbezogene Positionierung. Der Live-Snapshot der Preisgestaltungs-API lieferte success: true, die Preisversion a42d372ccf0b5dd13ecf71203521f9d2, 45 Modellzeilen, 48 Anbieter, unterstützte Endpunkt-Metadaten für Anthropic-Nachrichten, Gemini generateContent, Bilderzeugung, OpenAI-Chat-Vervollständigungen und Videoanfragen sowie Verfügbarkeitszustände von available und unknown_failure über die Zeilen hinweg.

Verwenden Sie dies nur als datierten öffentlichen Nachweis. Es beweist nicht die Abhilfe Ihres Kontos im Rahmen des SLA, die Support-Stufe, den Routenerfolg, die Fallback-Berechtigung, die permanente Modellverfügbarkeit, die Latenz, den Compliance-Umfang oder die kontospezifische Preisgestaltung.

Eine Staging-Überprüfung des Flatkey KI-Gateway-SLA sollte Folgendes umfassen:

1. Öffnen Sie die aktuelle Preisseite und wählen Sie das genaue Modell oder die Routenfamilie aus.
2. Bestätigen Sie die Modellzeile und die Endpunktfamilie in Ihrem Konto oder Dashboard.
3. Führen Sie eine risikoarme Anfrage über https://router.flatkey.ai/v1 aus.
4. Erfassen Sie Anfrage-ID, Modell-ID, Endpunkt, Zeitstempel, Status, Nutzungseinheiten, Kostennachweis und Schlüsselbesitzer.
5. Führen Sie einen genehmigten Fehlertest durch: schlechtes Modell, Kontingentgrenze, Zeitüberschreitung oder deaktiviertes Fallback.
6. Bestätigen Sie, wo Support-Nachweise in den Protokollen erscheinen.
7. Entscheiden Sie, welche Verkehrsklassen ein Fallback nutzen können und welche geschlossen fehlschlagen müssen.
8. Fügen Sie die Felder des Support-Pakets zum Incident-Runbook hinzu.
9. Speichern Sie das aktuelle SLA, die Preisgestaltung, den Routennachweis und den Support-Pfad im Ordner für Anbieternachweise.

Wenn dieser Nachweis vorliegt, können Plattform, Beschaffung und Finanzen dieselbe Datei auswerten, anstatt über Screenshots zu streiten.

Checkliste für Verlängerungsauslöser

Überprüfen Sie ein KI-Gateway-SLA nicht nur einmal. Fügen Sie Verlängerungsauslöser hinzu, damit die Käuferdatei aktuell bleibt.

| Auslöser | Was erneut zu prüfen ist | |---|---| | Aktualisierung der SLA-Seite oder des Vertrags | Umfang, Ausschlüsse, Abhilfemaßnahmen, Support-Prozess und Kontaktdaten. | | Neue Modellfamilie | Endpunkt, Anbieter, Kontingent, Datengrenze, Preiseinheit und Fallback-Richtlinie. | | Neue Produktionsverkehrsklasse | Failover-Haltung, Support-Schweregrad und Genehmigung durch den Verantwortlichen. | | Vorfall oder Beinahe-Unfall | Routenverfolgung, Support-Zeitplan, Auswirkungen auf Benutzer, Kostenauswirkungen und vorbeugende Maßnahmen. | | Änderung des Anbieterkontingents | Backup-Kapazität, Drosselungsverhalten und Verkehrszuweisung. | | Preisänderung | Kosten auf Anfrageebene, Wiederholungsbudget, Kosten für Fallback-Modell und Finanzschwelle. | | Sicherheits- oder Compliance-Überprüfung | Protokollierungsumfang, Aufbewahrung, Anbietergenehmigung und Zugriffsüberprüfung. |

Verknüpfen Sie diese Checkliste mit der Checkliste für Enterprise-KI-API-Gateways. Das SLA ist ein Teil des unternehmensweiten Nachweispakets, kein eigenständiges Vertrauenssiegel.

Häufige Fehler

Fehler	Warum er schadet	Bessere Prüfung
Ein Gateway-Uptime-Ziel als Garantie für den Modellerfolg behandeln	Upstream-Anbieter, Kontingente, Richtlinien und Modellverhalten können ausgeschlossen werden.	Nachweise für Gateway, Anbieter, Client und Geschäftsworkflow trennen.
Fragen, ob ein Fallback existiert, aber nicht, worauf es umschaltet	Backup-Modelle können Ausgabe, Datengrenzen, Funktionen und Kosten ändern.	Fallback nach Traffic-Klasse und Modellvertrag genehmigen.
Keine Anfrage-IDs aufbewahren	Der Support kann Kundenprotokolle nicht zuverlässig mit Routenprotokollen verbinden.	Erfassung von Anfrage-IDs zu jeder Produktionsroute hinzufügen.
Den Umfang des Kontingents ignorieren	Eine Backup-Route kann existieren, aber bei Spitzenverkehr dennoch gedrosselt werden.	Nachweise für Upstream- und Gateway-Kontingente zusammen speichern.
Annehmen, dass Gutschriften automatisch erfolgen	Viele SLAs erfordern eine separate Vereinbarung, einen Anspruchsprozess oder eine Einzelfallprüfung.	Abhilfebedingungen und Anspruchsinhaber vor dem Start speichern.
Überprüfung nur zum Zeitpunkt des Kaufs	Modellkataloge, Kontingente und Support-Pfade ändern sich.	Verlängerungsauslöser und vorfallgesteuerte Nachprüfungen hinzufügen.

FAQ

Was ist ein AI-Gateway-SLA?

Ein AI-Gateway-SLA definiert das Verfügbarkeitsziel, den Umfang, die Ausschlüsse, den Support-Prozess und die Abhilfemaßnahmen für die Gateway-Dienste, die ein Anbieter betreibt. Es deckt möglicherweise nicht die Ausfälle von Drittanbieter-Modellen, Kontingentgrenzen, das Modellverhalten, die Kundenkonfiguration oder jedes Fallback-Ergebnis ab.

Garantiert ein AI-Gateway-SLA den Erfolg jeder Modellanfrage?

Nein. Ein AI-Gateway-SLA kann die Verfügbarkeit des Gateways abdecken, während Ausfälle von Upstream-Anbietern, Ratenbegrenzungen der Anbieter, Richtlinienänderungen, Modellverhalten, Kundenanmeldeinformationen, geplante Wartungsarbeiten oder kundenseitige Probleme ausgeschlossen sind. Überprüfen Sie den Ausschlusstext und die Routennachweise.

Was sollte die Beschaffung über Modell-Fallback fragen?

Die Beschaffung sollte fragen, welche Fehler einen Fallback auslösen, welche Modelle oder Anbieter als Backups genehmigt sind, ob der Fallback die Datenverarbeitung oder das Ausgabeverhalten ändert, wie Wiederholungsversuche abgerechnet werden und wo die Routennachweise nach einem Vorfall gespeichert werden.

Welche Nachweise sollte der Support während eines SLA-Vorfalls erhalten?

Der Support sollte die Konto-E-Mail, den betroffenen Endpunkt, Anfrage-IDs, Zeitstempel, Fehlermeldungen, Modell-ID, Routenklasse, eine Zusammenfassung der Auswirkungen und das Wiederholungsverhalten des Kunden erhalten. Das öffentliche SLA von Flatkey verlangt derzeit mehrere dieser Felder, einschließlich Endpunkt, Anfrage-IDs, Zeitstempel, Fehler und eine Zusammenfassung der Auswirkungen.

Erfolgen Service-Gutschriften automatisch?

Nicht immer. Das öffentliche SLA von Flatkey besagt, dass automatische Service-Gutschriften, Rückerstattungen, Strafen oder pauschalierte Schadensersatzzahlungen nicht gewährt werden, es sei denn, eine separate schriftliche Vereinbarung besagt etwas anderes. Käufer sollten die Abhilfeklausel, die Frist für die Geltendmachung von Ansprüchen und den Genehmigungsweg bestätigen.

Wie oft sollten Teams ein AI-Gateway-SLA überprüfen?

Überprüfen Sie ein AI-Gateway-SLA beim Kauf, bei der Verlängerung, bei einer größeren Routenänderung, bei einer neuen Modellfamilie, bei einer neuen Produktions-Traffic-Klasse, bei einer Preisänderung, bei einer Kontingentänderung und nach jedem wesentlichen Vorfall oder Beinahe-Vorfall.

Abschließende Empfehlung

Ein AI-Gateway-SLA ist nur dann nützlich, wenn es testbar wird. Beginnen Sie mit dem öffentlichen oder vertraglich vereinbarten SLA, trennen Sie den Gateway-Umfang vom Umfang des Upstream-Anbieters, führen Sie Routen- und Fallback-Tests durch, speichern Sie Anfrage-IDs, definieren Sie Support-Nachweise und fügen Sie Verlängerungsauslöser hinzu.

Flatkey kann Teams dabei helfen, den Modellzugriff, das Routing, die Preisüberprüfung und die Nutzungsnachweise hinter einem einzigen Gateway-Workflow zu zentralisieren. Überprüfen Sie vor dem Produktions-Rollout das genaue Modell, den Endpunkt, das Routenverhalten, den Support-Prozess und die SLA-Nachweise für Ihr Konto. Holen Sie sich dann einen Schlüssel, wenn Sie bereit sind, einen AI-Gateway-SLA-Workflow mit echtem Staging-Traffic zu testen.