Eine Prüfung des SOC 2 AI API gateway scope sollte nicht mit dem Badge beginnen. Sie sollte mit einer einfachen Frage beginnen: Welches System, welcher Zeitraum, welche Kontrollen, welche Abhängigkeiten und welche vom Käufer zu verantwortenden Pflichten hat der Bericht tatsächlich abgedeckt?
Dieser Unterschied ist für das Modell-Routing wichtig. Ein AI API Gateway kann zwischen Ihrer Anwendung und mehreren Modellanbietern, Endpoint-Familien, Protokollen, Support-Workflows, Abrechnungsunterlagen und Fallback-Pfaden sitzen. Ein SOC 2 Type 2-Bericht kann ein nützlicher Nachweis für das beschriebene System des Gateway-Anbieters und die abgedeckten Trust-Services-Kriterien sein. Er sollte nicht als Beweis dafür behandelt werden, dass jeder Upstream-Modellanbieter, jede Route, jede Einstellung zur Aufbewahrung von Prompts, jede Käuferkontokonfiguration oder jede zukünftige Modelländerung freigegeben ist.
Verwenden Sie diese Checkliste zum SOC 2 AI API gateway scope, wenn Einkauf, Sicherheit, Recht und Plattform-Engineering entscheiden müssen, was der Bericht belegen sollte, was er nicht belegen sollte und welche Folgedokumente in das Freigabepaket gehören.
Flatkey ist für diese Prüfung relevant, weil die aktuelle öffentliche Website flatkey.ai als AI API Gateway und Model-Operations-Plattform positioniert, um offiziellen GPT-, Claude-, Gemini- und anderem Modell-Traffic über einen Schlüssel zu routen, mit Oberflächen für Dashboard, Abrechnung, Routing, Nutzung und operative Nachweise. Öffentliche Flatkey-Seiten und Seiten zur Zertifikatsabfrage sind nur zeitpunktbezogene Prüfnachweise. Für die Produktionsfreigabe fordern Sie den privaten SOC 2-Bericht, falls zutreffend den unterzeichneten Vertrag/DPA, Kontoeinstellungen, Routenkonfiguration und Supportbestätigung für die Workload an, die Sie ausführen werden.
Für einen breiteren Beschaffungskontext kombinieren Sie diesen Artikel mit der SOC 2 AI API gateway evidence checklist, dem AI gateway procurement evidence packet und der AI API vendor risk assessment.
SOC 2 AI API Gateway Scope: Schnell-Entscheidungstabelle
Die erste Seite der Prüfung sollte Nachweise aus dem Bericht von Nachweisen aus dem Follow-up des Käufers trennen.
| Prüfbereich | Wobei der SOC 2-Bericht helfen sollte zu belegen | Was er für sich allein nicht belegen sollte |
|---|---|---|
| Rechtliche Einheit | Welche Serviceorganisation geprüft wurde | Dass jede verbundene Gesellschaft, jeder Wiederverkäufer oder jeder Upstream-Modellanbieter abgedeckt ist |
| Systemgrenze | Welche Plattform, Services, Standorte, Infrastruktur, Personen und Prozesse im beschriebenen System enthalten sind | Dass jede Dashboard-Funktion, jede Endpoint-Familie, jede Kundenroute oder jede zukünftige Integration im Scope ist |
| Berichtszeitraum | Der vom Type 2-Review abgedeckte Zeitraum | Dass die aktuellen Kontrollen nach Ablauf des Zeitraums unverändert sind |
| Trust-Services-Kategorien | Welche Kriterien abgedeckt wurden, etwa Sicherheit, Verfügbarkeit, Vertraulichkeit, Verarbeitungsintegrität oder Datenschutz | Dass nicht ausgewählte Kategorien geprüft wurden |
| Getestete Kontrollen | Welche Kontrollen der Prüfer getestet hat und die Ergebnisse für den Zeitraum | Dass Käuferkonfiguration, Richtlinie für Routen oder Workload-Datenklasse getestet wurden |
| Ausnahmen | Ob Kontrolleausnahmen vermerkt wurden und wie das Management reagiert hat | Dass Ausnahmen für Ihre spezifische Workload unerheblich sind |
| Subservice-Organisationen | Ob wichtige Abhängigkeiten eingeschlossen, ausgeklammert oder durch andere Berichte abgedeckt werden | Dass Aufbewahrung, Training, Logging oder regionales Verhalten des Upstream-Modellanbieters abgedeckt sind |
| CUECs | Welche ergänzenden Kontrollen der Benutzereinheit der Käufer betreiben muss | Dass der Anbieter für die Schlüsselspeicherung des Käufers, Redaktion, Provider-Allowlists oder Datenklassifizierung auf App-Ebene verantwortlich ist |
Dies ist die zentrale Regel zum SOC 2 AI API gateway scope: Der Bericht ist ein Nachweis über ein beschriebenes System einer Serviceorganisation während eines definierten Zeitraums. Er ist keine pauschale Freigabe für jede AI-Route, die Ihr Team möglicherweise erstellt.
Sperren Sie die fünf Scope-Felder, bevor Sie Kontrollen lesen
Beginnen Sie nicht damit, nach einer sauberen Meinung zu suchen. Beginnen Sie mit fünf Feldern.
| Feld | Frage des Käufers | Zu speichernder Nachweis |
|---|---|---|
| Einheit | Welche Serviceorganisation wurde geprüft? | Berichtstitelseite, rechtliche Einheit, Vertragspartner, falls öffentlich Zertifikatsabfrage |
| System | Welche Services, Infrastruktur, Teams, Prozesse und Datenflüsse sind enthalten? | Systembeschreibung, Produkt-/Serviceliste, Diagramm der Systemgrenze |
| Zeitraum | Welchen Type 2-Zeitraum deckte der Bericht ab? | Startdatum, Enddatum, bei Bedarf Bridge Letter |
| Kriterien | Welche Trust-Services-Kategorien waren enthalten? | Scope für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit, Datenschutz |
| Abhängigkeiten | Welche Subservice-Organisationen und CUECs wirken sich auf die Meinung aus? | Inklusive-/Carve-out-Methode, Liste der Subservices, Liste der Käuferkontrollen |
Für ein AI Gateway verdient das Systemfeld die meiste Aufmerksamkeit. „API gateway“ kann nur die Weiterleitung der Basis-URL bedeuten, oder es kann auch Dashboard-Zugriff, Modellkatalog, Kontostand, Nutzungs-Metering, Request-Logs, Alarmierung, Support-Workflows, Incident Response und Schlüsselverwaltung umfassen. Der private Bericht sollte Ihnen sagen, was in der Systembeschreibung enthalten war. Wenn nicht, bitten Sie den Anbieter, den Berichtsumfang auf die genaue Route abzubilden, die Sie verwenden möchten.
Was ein SOC 2-Bericht für ein AI Gateway belegen sollte
Ein eingegrenzter SOC 2 Type 2-Bericht sollte einem Käufer helfen, diese Fragen zu beantworten.
| Prüfbereich | Nützliche SOC-2-Nachweise | Übersetzung für das AI-Gateway |
|---|---|---|
| Kontrolldesign und -betrieb | Über den Berichtszeitraum getestete Kontrollen | Ob Zugriff, Änderungsmanagement, Monitoring, Incident Response, Lieferantenmanagement und zugehörige Kontrollen für das beschriebene Gateway-System funktioniert haben |
| Verfügbarkeitsumfang | Verfügbarkeitskriterien, SLA-nahe Überwachung, ggf. Incident-Prozesse | Ob der abgedeckte Service definierte Überwachungs- und Reaktionskontrollen hatte, nicht ob jeder Modellanbieter verfügbar bleiben wird |
| Vertraulichkeits- und Datenschutzumfang | Kriterien und Kontrollen, sofern diese Kategorien enthalten sind | Ob Kontrollen zur Handhabung von Kundendaten für das beschriebene System geprüft wurden, nicht ob jede Anbieterfunktion dieselbe Aufbewahrungseinstellung hat |
| Änderungsmanagement | Getestete Release-, Genehmigungs- und Änderungskontrollen | Ob Änderungen an Gateway-Code/Konfiguration kontrolliert wurden, nicht ob ein vom Käufer genehmigter Pfad später nicht vom Käufer geändert werden kann |
| Zugriffskontrollen | Zugriff der Belegschaft, privilegierter Zugriff, Admin-Prüfung, Kontoverwaltungskontrollen | Ob der Zugriff auf Anbieterseite kontrolliert wurde, nicht ob der Käufer API-Schlüssel sicher gespeichert hat |
| Logische Sicherheit | Authentifizierungs-, Autorisierungs-, Protokollierungs-, Schwachstellen- und Monitoring-Kontrollen | Ob die beschriebenen Sicherheitskontrollen des Gateways vorhanden waren, nicht ob Buyer-Apps Geheimnisse redigieren, bevor sie Prompts senden |
| Lieferantenmanagement | Kontrollen für Subservice-Organisationen und Lieferantenüberwachung | Ob Abhängigkeiten von Lieferanten gemanagt wurden, nicht ob jeder vorgelagerte Anbieter mit seinem SOC 2, DPA oder seiner Aufbewahrungseinstellung Ihre Route abdeckt |
Hier wird der SOC 2 AI API-Gateway-Scope praktisch. Der Bericht kann das Screening von Lieferantenrisiken unterstützen. Er muss dennoch in konkrete Routenfakten übersetzt werden: Endpunktfamilie, Datenklasse, Provider-Allowlist, Fallback-Policy, Prompt-/Output-Protokollierung, Metadaten-Aufbewahrung, Supportzugriff und Löschpfad.
Was der Bericht nicht belegen sollte
Der häufigste Fehler im Beschaffungsprozess besteht darin, einen SOC-2-Bericht als Ersatz für Entscheidungen zu verwenden, für die er nicht gedacht ist.
Verwenden Sie den Bericht nicht allein, um Folgendes zu belegen:
| Behauptung | Warum sie eine Nachprüfung erfordert |
|---|---|
| "Alle Modellanbieter sind abgedeckt." | Vorgelagerte Anbieter können Subservice-Organisationen sein, ausgeklammert oder außerhalb des Gateway-Berichts liegen. Fordern Sie die Anbietermatrix und den relevanten Anbieternachweis an. |
| "Nirgendwo werden Prompts oder Outputs gespeichert." | Gateway-Logs, Abuse-Monitoring-Logs der Anbieter, Anwendungszustand, Support-Tickets und Backups können ein unterschiedliches Aufbewahrungsverhalten haben. |
| "Für jede Route gilt kein Training." | Trainings- und Aufbewahrungszusagen sind oft an Anbieter, Konten, Endpunkte und Funktionen gebunden. Bewahren Sie Nachweise auf Kontoebene auf. |
| "Fallback ist genehmigt." | Ein Fallback-Pfad kann Daten an einen anderen Anbieter oder in eine andere Region senden. Der Genehmigungsnachweis sollte die zulässigen Fallback-Anbieter benennen. |
| "Die Anwendung des Käufers ist konform." | SOC 2 bezieht sich auf die Kontrollen der Service-Organisation. Redigierung durch den Käufer, Schlüsselspeicherung, Datenklassifizierung und App-Zugriffskontrollen liegen in der Verantwortung des Käufers. |
| "Datenschutz- oder DPA-Prüfung ist erledigt." | SOC 2 ist kein unterzeichnetes DPA, keine Datenübertragungsbewertung, keine Datenschutzerklärung, keine BAA und keine Verpflichtung zur regionalen Verarbeitung. |
| "Der aktuelle Stand ist identisch mit dem Berichtszeitraum." | Der Berichtszeitraum kann vor Monaten geendet haben. Fordern Sie Bridge Letters, aktuelle Richtlinien, die aktuelle Routenkonfiguration und aktuelle Nachweise an. |
| "Preise, Modellverfügbarkeit und SLA-Ergebnisse sind garantiert." | Modellkataloge, Preise, Rate Limits von Anbietern und die Verfügbarkeit Dritter können sich außerhalb des SOC-2-Berichts ändern. |
Wenn ein Anbieter sagt: „SOC 2 deckt das ab“, bitten Sie ihn, auf den genauen Abschnitt, die Formulierung zur Systemgrenze, das abgedeckte Kriterium, die Kontrolle, das Testergebnis sowie einen Hinweis auf CUEC oder die Subservice-Organisation zu verweisen.
Lesen Sie Subservice-Organisationen, bevor Sie Anbieter freigeben
Ein AI-Gateway kann von Cloud-Hosting, Zahlungssystemen, Analyse-Tools, Support-Software, Observability-Anbietern, Sicherheitstools und vorgelagerten Modellanbietern abhängen. Der SOC-2-Bericht sollte erläutern, wie mit Subservice-Organisationen umgegangen wird. Käufer sehen in der Regel einen von zwei Ansätzen:
| Methode | Was das für den Käufer bedeutet |
|---|---|
| Inklusivmethode | Die relevanten Kontrollen der Subservice-Organisation sind im Berichtsumfang enthalten. Prüfen Sie, welche Kontrollen enthalten sind. |
| Carve-out-Methode | Die Subservice-Organisation ist vom Berichtsumfang ausgeschlossen. Prüfen Sie separate Nachweise und die komplementären Kontrollen der Subservice-Organisation. |
Bei Model-Routing sind Ausnahmen wichtig. Ein SOC-2-Bericht eines Gateways kann die Lieferantenmanagement-Kontrollen des Gateways abdecken, während OpenAI, Anthropic, Google oder ein anderer vorgelagerter Anbieter außerhalb des geprüften Systems bleibt. Das macht den Bericht nicht nutzlos. Es bedeutet, dass die Prüfung des SOC 2 AI API-Gateway-Scope für jede freigegebene Route eine Zeile mit Anbieternachweisen enthalten muss.
Die Dokumentation des Anbieters zeigt, warum sich dies nicht ableiten lässt. Die API-Datenkontrollen von OpenAI trennen Abuse-Monitoring-Logs, Anwendungszustand, Zero Data Retention, Modified Abuse Monitoring und endpointspezifisches Verhalten. Die API-Datenaufbewahrungsdokumentation von Anthropic erklärt, dass unterschiedliche APIs und Funktionen unterschiedliche Speicheranforderungen haben und dass ZDR eine Vereinbarung ist, die Kunden für zulässige Anwendungsfälle anfordern. Die Dokumentation zum AI-Gateway-Logging von Cloudflare zeigt, wie ein Gateway Prompts, Antworten, Anbieter, Zeitstempel, Token-Nutzung, Kosten, Dauer, DLP-Aktionen und Logging-Kontrollen auf Payload-Ebene offenlegen kann. Das sind Beispiele für Kontrolloberflächen, die ein Käufer für jede Gateway-Route prüfen sollte, nicht Behauptungen über Flatkeys privaten Bericht.
Behandeln Sie CUECs als Käuferaufgabe, nicht als Floskel
Komplementäre Kontrollen des Nutzers sind kein Füllmaterial. Sie sind die Kontrollen, die der Käufer betreiben muss, damit die Kontrollen der Service-Organisation sinnvoll sind.
Für ein AI-Gateway umfasst die übliche CUEC-Arbeit auf Käuferseite:
| Vom Käufer verantwortete Kontrolle | Zu bewahrende Nachweise |
|---|---|
| Schlüsselspeicherung und -rotation | Pfad im Secret Manager, Verantwortlicher, Rotationsdatum, Notfall-Runbook für die Rotation |
| Routenfreigabe | Freigegebene Endpunktfamilien, Provider-Allowlist, Fallback-Policy, Datenklassen |
| Prompt-Redaktion | Redaktionsregeln auf Anwendungsebene, Test-Transkript, Beispiele blockierter Felder |
| Zugriffsprüfung | Admin-Liste, Schlüsselverantwortliche, Offboarding-Protokoll, Prüfung des Dashboard-Zugriffs |
| Logging-Richtlinie | Ob Prompts und Ausgaben gespeichert werden, Metadaten-only-Regel, Aufbewahrungsplan |
| Nutzungsmonitoring | Budgetverantwortlicher, Quoten-Einstellungen, Alarmgrenzen, Prüfungszyklus der Finanzabteilung |
| Incident-Workflow | Request-IDs, Eskalationspfad zum Support, Evidenzpaket, Verantwortliche für Benachrichtigungen |
| Verlängerungsauslöser | Prüfdatum und Auslöser für neue Provider, Endpunktfamilien, Datenklassen oder Änderungen am Logging |
Ein gutes Memo zum SOC 2 AI API gateway scope sollte die CUEC-Liste mit der technischen Arbeit verknüpfen. Wenn der Käufer Geheimnisse vor dem Senden von Prompts redigieren muss, sollte die Freigabe auf den Redaktions-Test verweisen. Wenn der Käufer Modell-Provider genehmigen muss, sollte die Route-Konfiguration die Allowlist zeigen.
Flatkey-spezifische Screening-Nachweise zum Anfordern und Speichern
Aktuelle öffentliche Flatkey-Seiten, geprüft am 11. Juli 2026, unterstützen den Einsatz von Flatkey in diesem Beschaffungsworkflow, ersetzen jedoch keine kontospezifischen Nachweise.
| Nachweis | Was die öffentliche Prüfung gezeigt hat | Wie man ihn verwendet |
|---|---|---|
| Startseite | Flatkey positioniert den Dienst öffentlich rund um offizielle GPT-, Claude- und Gemini-APIs über einen Schlüssel, Model Routing, Dashboard-Review, Nutzung, Kosten, Routing und Fehlersichtbarkeit. | Als datierten Produkt-Screening-Nachweis verwenden. Nicht als Scope des privaten SOC-2-Berichts behandeln. |
| Preisseite und Pricing-API | Öffentliche Preis-/Katalogoberflächen lieferten eine Live-Preisseite und eine Pricing-API-Antwort mit 158 Modellzeilen und Endpunktfamilien einschließlich openai, openai-response, anthropic, image-generation und openai-video. |
Nur als datierten Katalog-Snapshot verwenden. Modell- und Endpunktverfügbarkeit kann sich ändern. |
| SLA-Seite | Das SLA sagt, dass es für das von Flatkey betriebene gehostete Dashboard, das API-Gateway, Routing, Metering und Kontodienste gilt und Drittanbieter von KI-Modellen sowie andere externe Systeme ausschließt. | Verwenden, um zu rahmen, was Flatkey direkt betreibt gegenüber Drittanbieter-Abhängigkeiten. |
| Datenschutz- und AGB-Seiten | Öffentliche Richtlinienseiten behandeln API-Zugriff, Model Routing, Nutzungsaufzeichnungen, Abrechnung, Support, Drittanbieter-Model-Provider und sich ändernde Modell-/Provider-Regeln. | Als Screening-Nachweis verwenden; die endgültige Freigabe benötigt weiterhin unterzeichnete Bedingungen und route-spezifische Nachweise zur Datenverarbeitung. |
| Certificate lookup | Die öffentliche CAI-Abfrage zeigte das VOC AI Inc.-Zertifikat USA-SOC2-220513, SOC 2 Type II, aktiv, Zeitraum 15. Juli 2025 bis 14. Juli 2026. |
Nur als öffentliche Abfrage verwenden. Den tatsächlichen SOC-2-Bericht anfordern und abgedecktes System, Kriterien, Zeitraum, Ausnahmen, CUECs und Behandlung von Subservice-Organisationen bestätigen. |
Für Flatkey oder jedes andere AI-API-Gateway sollte die Freigabe sagen: "Öffentliche Seiten geprüft; privater Bericht angefordert; Routennachweise beigefügt; nicht unterstützte Annahmen aufgelistet."
Erstellen Sie ein Evidenzpaket vom Scope bis zur Route
Das Ergebnis dieser Prüfung sollte ein kleines Evidenzpaket sein, keine vage Freigabe.
| Paketbestandteil | Zu speichernde Datei | Verantwortlicher |
|---|---|---|
| SOC 2-Bericht | Privater Bericht, Berichtszeitraum, Kriterien, Meinung, Ausnahmen, Bridge Letter falls erforderlich | Einkauf/Sicherheit |
| Scope-Map | Berichtssystemgrenze abgebildet auf Dashboard, Gateway, API, Metering, Logs, Support und Routing-Konfiguration | Plattformtechnik |
| Anbietermapping | Genehmigte Anbieter, Fallback-Reihenfolge, Behandlung von Subservice-Organisationen, separate Anbieternachweise | Sicherheit/Plattform |
| Daten-Map | Prompts, Ausgaben, Dateien, Metadaten, Abrechnungsdatensätze, Logs, Support-Tickets, Backups | Sicherheit/Recht |
| Aufbewahrungsmatrix | Aufbewahrung für Gateway, Anbieter, Anwendung, Support und Backups nach Endpunktfamilie | Sicherheit/Recht |
| CUEC-Datensatz | Kontrollen des Käufers und Nachweis, dass jede einzelne umgesetzt ist | Plattform/Sicherheit |
| Testnachweis | Eine erfolgreiche Anfrage mit geringem Risiko und ein erwarteter Fehler mit Request-IDs und geschwärzten Logs | Plattformtechnik |
| Genehmigungsnotiz | Scope, Einschränkungen, offene Risiken, Namen der Prüfer, Erneuerungsauslöser | Geschäftsverantwortlicher/Einkauf |
Dieses Paket ist auch die Brücke zwischen der SOC 2-Prüfung und dem Engineering-Betrieb. Wenn ein neuer Anbieter, eine neue Modellklasse, ein neuer Logging-Modus oder eine neue Datenklasse hinzukommt, sollte das Team wissen, welche Dateien aktualisiert werden müssen.
Warnsignale, die die Genehmigung pausieren sollten
Setzen Sie die Genehmigung aus, wenn eines der folgenden Punkte ungeklärt ist:
- Der SOC 2-Bericht ist nicht verfügbar und es wird nur ein Badge oder ein Zertifikatsnachweis bereitgestellt.
- Der Berichtszeitraum ist abgelaufen und es ist kein Bridge Letter oder aktueller Nachweis verfügbar.
- Die Systembeschreibung umfasst nicht klar den Gateway-Pfad, den Sie verwenden möchten.
- Der Bericht schließt relevante Subservice-Organisationen aus und es sind keine separaten Anbieternachweise beigefügt.
- Die ausgewählten Trust-Services-Kategorien passen nicht zum angegebenen Risiko des Käufers, etwa Datenschutz oder Vertraulichkeit.
- CUECs verlangen Kontrollen des Käufers, die nicht umgesetzt wurden.
- Es wird angenommen, dass Prompt-/Output-Logging deaktiviert ist, aber kein Konto- oder Routennachweis belegt das.
- Ein Fallback kann Daten an einen nicht genehmigten Anbieter senden.
- Der Support kann den Anfrageinhalt einsehen, aber Supportzugriff, Ticketaufbewahrung und Schwärzung sind nicht dokumentiert.
- Die Genehmigung hat keinen Verantwortlichen, kein Ablaufdatum und keinen Auslöser für Routenänderungen.
Diese Warnsignale bedeuten nicht immer, dass der Anbieter scheitert. Sie bedeuten, dass die Prüfung des SOC 2 AI API gateway scope noch nicht abgeschlossen ist.
Eine praktische Genehmigungsformulierung
Eine nützliche Genehmigungsformulierung ist kurz, präzise und überprüfbar:
| Feld | Beispielformulierung |
|---|---|
| Berichtsnachweis | "SOC 2 Type 2-Bericht für Vendor X geprüft, Zeitraum A bis B, Sicherheits- und Verfügbarkeitskriterien, keine nicht akzeptierten Ausnahmen für diesen Pfad." |
| Genehmigter Scope | "Produktiver textbasierter Support-Workflow über die genehmigte Gateway-Base-URL und den Chat-Endpunkt." |
| Anbieter | "Provider A primär, Provider B Fallback; kein Bild-, Video-, Datei-, Web-Suche- oder Batch-Endpunkt." |
| Datenklasse | "Kundensupport-Text nach anwendungsebene-basierter Schwärzung; keine Zahlungsdaten, Secrets, PHI oder regulierten Aufzeichnungen." |
| Logging | "Gateway-Metadaten-Logs erlaubt; Roh-Prompt-/Output-Logging deaktiviert oder separat genehmigt; Nachweis zur Anbieteraufbewahrung beigefügt." |
| Kontrollen des Käufers | "Keys im Secret Manager gespeichert, vierteljährliche Zugriffsprüfung, Route-Allowlist, monatliche Nutzungsprüfung, Incident-Verantwortlicher zugewiesen." |
| Erneuerungsauslöser | "Vor Hinzufügen von Anbietern, Aktivieren neuer Endpunktfamilien, Ändern des Loggings, Routing regulierter Daten oder nach Ablauf des SOC 2-Zeitraums aktualisieren." |
Das ist die Bedeutung von "genehmigt". Entwickler wissen, welchen Pfad sie verwenden dürfen. Der Einkauf weiß, welche Nachweise geprüft wurden. Die Sicherheit weiß, was zu überwachen ist. Die Rechtsabteilung weiß, welche Annahmen weiterhin vertragliche Formulierungen erfordern.
Fazit
Eine Prüfung des SOC 2 AI API gateway scope ist wertvoll, wenn sie präzise bleibt. Der Bericht sollte dabei helfen, das beschriebene System der geprüften Dienstleistungsorganisation, die abgedeckten Kriterien, den Betrieb der Kontrollen, den Berichtszeitraum, Ausnahmen, die Behandlung von Subservice-Organisationen und die Verantwortlichkeiten des Käufers zu belegen. Er sollte nicht zu einem Beleg für jeden Pfad, jeden Anbieter, jede Aufbewahrungseinstellung, jedes Fallback-Verhalten, jede DPA-Klausel, jede Datenresidenzbehauptung oder jede Käuferkonfiguration ausgeweitet werden.
Für Flatkey beginnen Sie mit den aktuellen öffentlichen Nachweisen und fordern dann den privaten SOC 2-Bericht an, um ihn dem Pfad zuzuordnen, den Ihr Team tatsächlich betreiben wird. Wenn Sie einen API-Schlüssel und ein Dashboard für den Zugriff auf mehrere Modelle wünschen, holen Sie sich einen Schlüssel, fügen Sie die Checkliste zum SOC 2 AI API gateway scope dem Beschaffungspaket bei und genehmigen Sie jeden Produktionspfad mit explizitem Nachweis zu Anbieter, Logging, Aufbewahrung und CUECs.
Häufig gestellte Fragen
Was ist SOC 2 AI API gateway scope?
SOC 2 AI API gateway scope ist die Grenze des SOC 2-Berichts, soweit er für ein AI API Gateway gilt. Er umfasst die geprüfte Organisation, das beschriebene System, den Berichtszeitraum, Trust-Services-Kategorien, getestete Kontrollen, Subservice-Organisationen, Ausnahmen und vom Käufer zu verantwortende CUECs.
Beweist SOC 2, dass jeder AI-Model-Provider abgedeckt ist?
Nein. SOC 2 kann zeigen, wie der Gateway-Anbieter das beschriebene System und seine Abhängigkeiten verwaltet, aber vorgelagerte Modellanbieter können einbezogen, ausgeklammert oder durch separate Nachweise abgedeckt sein. Käufer sollten für jede genehmigte Route eine Anbieterkarte aufbewahren.
Beweist ein SOC 2 Type-2-Bericht, dass keine Prompt-Aufbewahrung stattfindet?
Nicht für sich allein. Die Aufbewahrung von Prompts und Ausgaben kann sich zwischen dem Gateway, vorgelagerten Anbietern, dem Anwendungsstatus, Support-Tickets, Protokollen und Backups unterscheiden. Der Käufer sollte Nachweise zur Aufbewahrung auf Endpunkt-, Konto- und Routenebene prüfen.
Was sollte die Beschaffung nach dem Ansehen eines SOC 2-Badges anfordern?
Fordern Sie den privaten SOC-2-Bericht, den Berichtszeitraum, die abgedeckten Kriterien, die Systembeschreibung, Ausnahmen, die Behandlung von Subservice-Organisationen, CUECs, falls erforderlich ein Bridge Letter, die Anbieterkarte, die Routenkonfiguration, die Logging-Einstellungen, die Aufbewahrungsmatrix sowie, sofern zutreffend, den unterzeichneten Vertrags-/DPA-Nachweis an.
Wie oft sollte die Scope-Prüfung aktualisiert werden?
Aktualisieren Sie die Scope-Prüfung für das SOC-2-AI-API-Gateway, wenn der Berichtszeitraum abläuft, wenn der Anbieter einen neuen Bericht bereitstellt, bevor Sie einen Anbieter oder eine Endpunktfamilie hinzufügen, bevor Sie eine neue Datenklasse routen, wenn sich Logging oder Aufbewahrung ändern, und nach wesentlichen Vorfällen.
Zu prüfende Quellen
- Flatkey-Startseite
- Flatkey-Preise
- Flatkey-Datenschutzerklärung
- Flatkey-Nutzungsbedingungen
- Flatkey-Service-Level-Vereinbarung
- CAI-SOC-2-Zertifikatsabfrage für USA-SOC2-220513
- AICPA SOC Suite of Services
- AICPA 2017 Trust Services Criteria mit überarbeiteten Fokuspunkten
- AICPA 2018 SOC-2-Beschreibungskriterien
- OpenAI-API-Datenkontrollen
- Anthropic API und Datenaufbewahrung
- Cloudflare AI Gateway-Protokollierung
