# Anforderungskatalog für die Ausschreibung eines LLM-Gateways oder einer KI-Plattform

Stand 9. November 2026. Frei kopierbar, anpassbar und nutzbar in Ihren eigenen Vergabeunterlagen.

Ein Unternehmen oder eine öffentliche Stelle, die für Beschäftigte und Anwendungen Zugang zu großen Sprachmodellen einkauft, kauft meist ein Gateway: ein Konto und eine API vor mehreren Modellanbietern. Dieser Katalog nennt 43 Anforderungen für diesen Einkauf, gegliedert in der Reihenfolge, in der eine Sicherheits- und Einkaufsprüfung sie durchgeht. Zu jeder Anforderung steht, warum sie wichtig ist und welchen Nachweis Sie vom Bieter verlangen sollten.

Er ist herstellerneutral und eignet sich als Anforderungsanlage für eine Angebotsanfrage, eine öffentliche Ausschreibung oder eine Sicherheitsprüfung von Lieferanten. Für KI-spezifische Vertragsbedingungen kombinieren Sie ihn mit den freiwilligen EU-Mustervertragsklauseln für KI (MCC-AI) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses), die im März 2025 in der Public Buyers Community der Europäischen Kommission veröffentlicht wurden.

Jede Anforderung ist so formuliert, dass ein Bieter sie in einem Absatz beantworten und den Nachweis beifügen kann. Kennzeichnen Sie die Muss-Kriterien, gewichten Sie die übrigen und streichen Sie, was für Sie nicht zutrifft.

## 1. Datenstandort

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 1 | Verarbeitungsregion. Der Anbieter kann die Inferenz auf eine vom Auftraggeber benannte Region beschränken, etwa die EU/den EWR oder Europa, für die gesamte Organisation, ein Team oder einen einzelnen API-Schlüssel, einschließlich Wiederholungen und Fallbacks. | Gateways schalten zwischen Anbietern um. Ohne eine Regionsregel, die jeden Versuch erfasst, kann ein Fallback einen Prompt unbemerkt in eine andere Rechtsordnung verlagern. | Die Routing-Richtlinie für eingeschränkten Datenverkehr, die je Region zulässigen Endpunkte mit ihren Standorten und das Verhalten, wenn kein Endpunkt in der Region eine Anfrage bedienen kann. |
| [ ] | 2 | Definition der Region. Der Anbieter gibt an, welche Länder jede Region umfasst, zum Beispiel nur EU/EWR oder auch das Vereinigte Königreich, die Schweiz oder weitere Länder. | Vertriebsunterlagen verwenden Europa und EU oft gleichbedeutend. Ihre Bewertung der Datenübermittlung hängt von der genauen Liste ab. | Eine schriftliche Definition je Region und der Verarbeitungsort jedes Unterauftragsverarbeiters darin. |
| [ ] | 3 | Standort von Eingang und Gateway. Der Anbieter gibt an, wo TLS terminiert wird, wo das Gateway läuft und welcher Hostname für die regionale Verarbeitung zu verwenden ist. | Eine Anfrage kann von einem Modell in der richtigen Region bedient werden und trotzdem zuerst ein globales Edge-Netzwerk durchlaufen. | Hostnamen je Region, Hosting-Anbieter und Region von Load Balancer und Gateway sowie ein Datenflussdiagramm. |
| [ ] | 4 | Standort von Metadaten und Logs. Der Anbieter gibt an, wo Kontodaten, Nutzungsdatensätze, Betriebslogs, Backups und E-Mails gespeichert und verarbeitet werden. | Angaben zur Datenresidenz betreffen oft nur Prompts. Auch Metadaten enthalten personenbezogene Daten wie Namen, E-Mail-Adressen und IP-Adressen. | Ein Speicherort je Datenkategorie, einschließlich Backups und Transaktions-E-Mails. |

## 2. Aufbewahrung und Zero Data Retention

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 5 | Keine Speicherung von Inhalten durch den Anbieter. Der Anbieter verarbeitet Prompts und Ausgaben nur, um die Anfrage zu bedienen, oder gibt genau an, welche Inhalte er wo und wie lange speichert. | Das Gateway sieht jeden Prompt, den Ihre Organisation sendet. Seine eigene Aufbewahrung ist das erste Risiko, das Sie prüfen sollten. | Eine Beschreibung des Datenflusses, das Log-Schema mit den geschriebenen Feldern und die zugehörige Klausel im AVV. |
| [ ] | 6 | Zero Data Retention bei Modellanbietern. Der Auftraggeber kann verlangen, dass Anfragen nur an Modell-Endpunkte gehen, die zusagen, keine Kopie der Inhalte zu behalten, auf Ebene der Organisation, eines Teams oder eines Schlüssels, und untere Ebenen können dies nicht abschalten. | Modellanbieter bewahren Prompts zur Missbrauchsüberwachung üblicherweise eine Zeit lang auf, sofern für den Endpunkt keine Zero-Retention-Vereinbarung gilt. | Aufbewahrungsbedingungen je Anbieter, wie die Einstellung bei jeder Anfrage durchgesetzt wird und welche Funktionen deaktiviert sind, solange sie aktiv ist. |
| [ ] | 7 | Funktionen, die Inhalte speichern. Der Anbieter listet jede Funktion auf, die Inhalte speichert (Prompt-Caching, gespeicherte Antworten, Gesprächsverlauf, Dateien, Batch-Jobs), mit ihrer Aufbewahrungsdauer und der Einstellung, die sie abschaltet. | Aufbewahrungszusagen enthalten meist Ausnahmen für bestimmte Funktionen. Die Liste zeigt, wo diese Ausnahmen liegen. | Eine Funktionsliste mit Aufbewahrungsdauer je Funktion und der Einstellung, die sie deaktiviert. |
| [ ] | 8 | Löschung bei Vertragsende. Der Anbieter löscht die Daten des Auftraggebers innerhalb einer festgelegten Frist nach Ende der Leistung oder gibt sie zurück und bestätigt dies schriftlich. | Artikel 28 Absatz 3 Buchstabe g DSGVO verlangt, dass der Vertrag mit dem Auftragsverarbeiter die Löschung oder Rückgabe nach Abschluss der Leistungen regelt. | Die AVV-Klausel mit der Frist, die Behandlung von Backups und ein Muster einer Löschbestätigung. |

## 3. Training und Nutzung der Daten

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 9 | Kein Training durch den Anbieter. Der Anbieter verwendet Prompts, Ausgaben oder Metadaten nicht, um Modelle zu trainieren oder zu verbessern. | Training ist die Nutzung, die Auftraggeber am häufigsten ausschließen, und der Ausschluss bindet nur, wenn er im Vertrag steht. | Die Klausel in Vertrag oder AVV und der entsprechende Abschnitt der Datenschutzerklärung. |
| [ ] | 10 | Kein Training durch Modellanbieter. Der Anbieter leitet den Datenverkehr des Auftraggebers nur an Anbieter, die zusagen, nicht damit zu trainieren, und erklärt, wie dies bei jeder Anfrage durchgesetzt wird. | Die Zusage des Gateways bindet nicht die Modellanbieter dahinter. | Anbieterbedingungen je Endpunkt, der Durchsetzungsmechanismus und der Datenverkehr, den er abdeckt. |
| [ ] | 11 | Sonstige Sekundärnutzung. Der Anbieter gibt an, ob Inhalte oder Metadaten für Analysen, Benchmarking, Produktverbesserung oder menschliche Prüfung verwendet werden, und wie man dem widerspricht. | Sekundärnutzungen liegen außerhalb der Weisungen, die ein Verantwortlicher einem Auftragsverarbeiter erteilt, sofern sie nicht vereinbart sind. | Eine Liste der Sekundärnutzungen, die Richtlinie zur menschlichen Prüfung und die Einstellung zum Widerspruch. |

## 4. Unterauftragsverarbeiter und AVV

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 12 | Auftragsverarbeitungsvertrag. Ein AVV nach Artikel 28 DSGVO liegt vor Vertragsschluss vor und regelt Gegenstand, Dauer, Weisungen, Vertraulichkeit, Sicherheit, Unterstützung, Löschung und Prüfungen. | Artikel 28 Absatz 3 legt fest, was der Vertrag mit dem Auftragsverarbeiter enthalten muss. Ein Gateway verarbeitet personenbezogene Daten in jedem Prompt, der eine Person erwähnt. | Der Text des AVV, das anwendbare Recht und die Art der Unterzeichnung. |
| [ ] | 13 | Liste der Unterauftragsverarbeiter. Der Anbieter veröffentlicht jeden Unterauftragsverarbeiter mit Zweck, verarbeiteten Daten und Standort, einschließlich Modell- und Inferenzanbietern. | Bei einem Gateway ist jeder Modellanbieter, der Ihren Datenverkehr bedienen kann, ein Unterauftragsverarbeiter. | Die URL der Liste und das Datum ihrer letzten Änderung. |
| [ ] | 14 | Information über neue Unterauftragsverarbeiter. Der Anbieter informiert mit einer festgelegten Vorlaufzeit, bevor er einen Unterauftragsverarbeiter hinzufügt oder ersetzt, und räumt ein Widerspruchsrecht ein. | Artikel 28 Absatz 2 verlangt, dass der Verantwortliche über Änderungen informiert wird und Gelegenheit zum Einspruch erhält. | Die AVV-Klausel mit der Vorlaufzeit und der Kanal, über den informiert wird. |
| [ ] | 15 | Internationale Datenübermittlungen. Für jede Verarbeitung außerhalb des EWR nennt der Anbieter den Übermittlungsmechanismus (Angemessenheitsbeschluss, Standardvertragsklauseln, UK IDTA). | Übermittlungen brauchen eine Rechtsgrundlage nach Kapitel V DSGVO, und der Auftraggeber dokumentiert seine Bewertung. | Die Anhänge der Standardvertragsklauseln und eine Zusammenfassung der Transfer-Folgenabschätzung des Anbieters. |
| [ ] | 16 | Meldung von Datenschutzverletzungen. Der Anbieter meldet Verletzungen des Schutzes personenbezogener Daten unverzüglich und innerhalb einer festgelegten Zahl von Stunden. | Der Verantwortliche hat nach Artikel 33 72 Stunden für die Meldung an die Aufsichtsbehörde, daher muss die Frist des Auftragsverarbeiters kürzer oder gleich lang sein. | Die AVV-Klausel, eine Zusammenfassung des Incident-Response-Prozesses und der Sicherheitskontakt. |

## 5. Identität und Zugang

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 17 | Single Sign-on. Anmeldung über SAML 2.0 oder OpenID Connect mit dem Identitätsanbieter des Auftraggebers, etwa Microsoft Entra ID, Okta oder Google Workspace, für die Admin-Konsole und für Nutzer. | Arbeitskonten binden den Zugang an das Beschäftigungsverhältnis und wenden die MFA- und Anmelderichtlinien des Auftraggebers an. | Unterstützte Protokolle und Identitätsanbieter, die Einrichtungsanleitung und eine Testverbindung. |
| [ ] | 18 | SSO-Pflicht. Der Auftraggeber kann SSO für alle Nutzer vorschreiben und Passwort- und andere Anmeldeverfahren abschalten. | SSO neben Passwörtern lässt Konten außerhalb der Kontrolle des Identitätsanbieters. | Die Einstellung und wie sie mit bestehenden Sitzungen und API-Schlüsseln umgeht. |
| [ ] | 19 | Benutzerbereitstellung. Provisionierung und Deprovisionierung über SCIM 2.0 aus dem Identitätsanbieter, mit Zuordnung von Gruppen zu Rollen oder Teams. | Ohne Deprovisionierung behalten ausgeschiedene Beschäftigte den Zugang, bis jemand daran denkt, ihn zu entfernen. | Die unterstützten SCIM-Ressourcen (Benutzer, Gruppen) und wie schnell eine Deprovisionierung Sitzungen und Schlüssel widerruft. |
| [ ] | 20 | Rollen und API-Schlüssel. Rollenbasierter Zugriff, ein Schlüssel je Person und je Anwendung, eingeschränkte Schlüssel und sofortiger Widerruf. | Geteilte Schlüssel verschleiern, wer welche Anfrage gesendet hat, und lassen sich nicht für eine einzelne Person widerrufen. | Die Rollenmatrix und der Lebenszyklus der Schlüssel: Erstellung, Einschränkung, Rotation und Widerruf. |
| [ ] | 21 | Desktop-Apps und Coding-Agenten. Der Anbieter gibt an, wie sich Beschäftigte in KI-Desktop-Apps und Coding-Agenten (zum Beispiel Claude Desktop, Claude Code und IDE-Erweiterungen) authentifizieren: per Anmeldung mit dem Arbeitskonto oder über verteilte Schlüssel. | In diesen Werkzeugen tauchen private Konten und kopierte Schlüssel außerhalb des Einkaufs auf. | Die Einrichtungsanleitung und die Liste der unterstützten Werkzeuge. |

## 6. Ausgabenkontrolle

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 22 | Budgets auf den Ebenen, die Sie steuern. Harte monatliche Limits je Nutzer, je Anwendung und je Team oder Abteilung, die die Ausgaben beim Limit stoppen. | Agenten und Batch-Jobs können ein Monatsbudget in Stunden verbrauchen. Ein Limit, das nur warnt, ist ein Bericht. | Die unterstützten Ebenen und was beim Limit geschieht: Sperre, Warnung oder Überziehung. |
| [ ] | 23 | Obergrenze für die Organisation und Warnungen. Eine Obergrenze für die gesamte Organisation und Warnungen, bevor ein Limit erreicht ist. | Die Finanzabteilung braucht eine Zahl, die nicht überschritten werden kann, gleich was darunter geschieht. | Die Einstellungen und die Warnkanäle. |
| [ ] | 24 | Preise und Rechnungsstellung. Preis je Modell oder je Tarif, die Abrechnungswährung, Rechnungen mit Firmendaten und USt-IdNr. des Auftraggebers sowie Kostenberichte je Nutzer und Anwendung für die interne Verrechnung. | Token-Preise unterscheiden sich zwischen Modellen um Größenordnungen, daher braucht die Bewertung die Preisgrundlage und die Berichte. | Die Preisliste, eine Musterrechnung und ein Muster-Nutzungsbericht. |

## 7. Modellzugang und Freigabelisten

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 25 | Modellkatalog. Die angebotenen Frontier- und Open-Weight-Modelle und welche davon unter jeder Regionsregel verfügbar sind. | Ein Modell, das in Ihrer Region nicht verfügbar ist, steht Ihnen nicht zur Verfügung, sobald die Regionsregel aktiv ist. | Eine Modellliste je Region und die Richtlinie für die Aufnahme neuer Modelle. |
| [ ] | 26 | Modell-Freigabelisten. Admins legen fest, welche Modelle jedes Team, jede Anwendung oder jeder Schlüssel nutzen darf. Anfragen an andere Modelle werden abgelehnt. | Ihre Freigabe eines Modells für einen Anwendungsfall sollte durchgesetzt werden, nicht nur dokumentiert. | Die Einstellung und die Fehlermeldung für ein nicht freigegebenes Modell. |
| [ ] | 27 | Anbieter-Freigabelisten. Admins legen fest, welche Inferenzanbieter Datenverkehr bedienen dürfen. Fallbacks halten die Liste ein, und neue Anbieter werden nie ohne Freigabe hinzugefügt. | Ein Anbieter, den der Lieferant hinzufügt, ist ein neuer Ort, an dem Ihre Daten verarbeitet werden. | Die Einstellung, wie Fallbacks sie anwenden und was geschieht, wenn der Lieferant einen Anbieter hinzufügt. |
| [ ] | 28 | Modelländerungen. Der Anbieter kündigt die Abkündigung von Modellen und Versionswechsel im Voraus an, und der Auftraggeber kann eine Version festschreiben. | Ein stiller Modellwechsel verändert die Qualität der Ausgaben und kann die Bewertung eines Anwendungsfalls hinfällig machen. | Die Richtlinie zur Abkündigung und der Benachrichtigungskanal. |
| [ ] | 29 | Transparenz des Routings. Leitet der Anbieter automatisch zwischen Modellen oder Anbietern um, aus Kosten- oder Verfügbarkeitsgründen, dokumentiert er die Regeln und hält fest, welches Modell und welcher Anbieter jede Anfrage bedient hat. | Automatisches Routing ist nur dann wertvoll, wenn Sie sehen, wohin jede Anfrage ging. | Die Routing-Dokumentation und ein Muster eines Datensatzes je Anfrage. |

## 8. Audit-Logs und Export

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 30 | Admin-Audit-Log. Jede Änderung an Nutzern, Schlüsseln, Budgets und Richtlinien, mit handelnder Person, Zeitpunkt sowie Vorher- und Nachher-Werten. | Prüfer fragen, wer eine Richtlinie wann geändert hat. Ohne Vorher- und Nachher-Werte kann das Log nicht beantworten, was sich geändert hat. | Ein Muster-Logeintrag und die Aufbewahrungsdauer. |
| [ ] | 31 | Anfrageprotokoll. Für jede Anfrage: Zeitpunkt, Nutzer oder Schlüssel, Modell, bedienender Anbieter, Regionsregel, Status, Tokens und Kosten, ohne Inhalte, sofern der Auftraggeber dies nicht ausdrücklich aktiviert, mit festgelegter Aufbewahrungsdauer. | Für Hochrisiko-Verwendungen verlangt Artikel 26 Absatz 6 KI-Verordnung von Betreibern, die Protokolle unter ihrer Kontrolle mindestens sechs Monate aufzubewahren. Das Anfrageprotokoll ist zugleich der Nachweis für das KI-Inventar. | Die Feldliste, die Aufbewahrungsdauer und ein Muster-Export. |
| [ ] | 32 | Export. Logs lassen sich als CSV oder über eine API exportieren und an das SIEM des Auftraggebers senden. | Aufzeichnungen, die der Auftraggeber nicht herausholen kann, kann er für seine eigene Prüfung nicht nutzen. | Formate, Zeilen- oder Zeitraumgrenzen und die API-Dokumentation. |

## 9. Betreiberpflichten nach der KI-Verordnung

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 33 | Unterstützung bei Inventar und KI-Kompetenz. Der Anbieter liefert die Informationen, die der Auftraggeber für sein KI-Inventar und seine Maßnahmen zur KI-Kompetenz nach Artikel 4 braucht: die je Anwendung genutzten Modelle, ihre Anbieter und ihre dokumentierten Grenzen. | Artikel 4 gilt seit dem 2. Februar 2025, und ein Inventar ist der Ausgangspunkt für jede weitere Pflicht aus der KI-Verordnung. | Aufzeichnungen zu Modell und Anbieter je Anwendung und Links zur Modelldokumentation. |
| [ ] | 34 | Hochrisiko-Verwendungen. Will der Auftraggeber den Dienst für einen in Anhang III genannten Zweck nutzen, gibt der Anbieter seine Rolle nach der KI-Verordnung an und vereinbart die einschlägigen Klauseln der EU-Mustervertragsklauseln für KI. | Die Betreiberpflichten für Anhang III gelten ab dem 2. Dezember 2027 und hängen von Informationen ab, die nur Anbieter und Modellanbieter haben. | Die Erklärung des Anbieters zu seiner Rolle und ein ausgefüllter Anhang der MCC-AI (High Risk oder Light). |
| [ ] | 35 | Dokumentation der KI-Modelle mit allgemeinem Verwendungszweck. Für jedes angebotene KI-Modell mit allgemeinem Verwendungszweck verlinkt der Anbieter die Dokumentation, die dessen Anbieter nachgelagerten Anbietern bereitstellt, und die öffentliche Zusammenfassung der Trainingsinhalte. | Artikel 53 verpflichtet Anbieter von KI-Modellen mit allgemeinem Verwendungszweck, diese bereitzustellen, und Auftraggeber legen sie je Modell ab. | Links je Modell und das Abrufdatum. |
| [ ] | 36 | Transparenz. Der Anbieter gibt an, ob Ausgaben maschinenlesbar gekennzeichnet sind und wie er die Offenlegungspflichten des Auftraggebers unterstützt. | Die Transparenzpflichten nach Artikel 50 gelten ab dem 2. August 2026. | Angaben zur Kennzeichnung je Modell und Hinweise zur Offenlegung. |

## 10. Ausstieg und Portabilität

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 37 | Standardschnittstelle. Die API folgt einer verbreiteten Schnittstelle, etwa dem OpenAI-kompatiblen Chat-Completions-Format, sodass Anwendungen ohne Neuentwicklung wechseln können. | Eine proprietäre Schnittstelle macht aus einem Anbieterwechsel ein Softwareprojekt. | Die API-Referenz und die SDKs und Werkzeuge, die bekanntermaßen damit funktionieren. |
| [ ] | 38 | Datenexport beim Ausstieg. Der Auftraggeber kann Konfiguration, Nutzer, Schlüssel-Metadaten, Nutzung und Logs vor und nach der Kündigung in einem maschinenlesbaren Format exportieren. | Ist der Dienst ein Datenverarbeitungsdienst im Sinne der Datenverordnung (Data Act), gibt Kapitel VI dem Kunden Wechselrechte, und ab dem 12. Januar 2027 dürfen keine Wechselentgelte mehr erhoben werden. | Exportformate, die angebotene Unterstützung beim Übergang und wie lange die Daten nach der Kündigung verfügbar bleiben. |
| [ ] | 39 | Laufzeit und Kündigung. Vertragslaufzeit, Kündigungsfrist, etwaige Entgelte bei Kündigung und die Übergangsfrist. | Lange Laufzeiten und Kündigungsentgelte bestimmen, was ein Ausstieg kostet. | Die kaufmännischen Bedingungen und die Kündigungsklausel. |

## 11. Support und SLA

| Muss | Nr. | Anforderung | Warum sie wichtig ist | Zu verlangender Nachweis |
| --- | --- | --- | --- | --- |
| [ ] | 40 | Verfügbarkeits-SLA. Eine monatliche Verfügbarkeitszusage mit Service-Gutschriften, der Messmethode und den Ausnahmen. | KI wandert in produktive Abläufe, in denen Ausfallzeiten Geld kosten. | Das SLA-Dokument, die öffentliche Statusseite und die Verfügbarkeit der letzten 12 Monate. |
| [ ] | 41 | Failover zwischen Anbietern. Ist ein Modellanbieter nicht verfügbar, wechseln Anfragen zu einem anderen freigegebenen Anbieter desselben Modells, innerhalb der Regions- und Freigaberegeln. | Ein Failover, das Region oder Freigabeliste ignoriert, bricht die Regeln genau dann, wenn ohnehin ein Vorfall läuft. | Das Failover-Design und die Zahl der Anbieter je Modell unter jeder Regionsregel. |
| [ ] | 42 | Support und Kommunikation bei Vorfällen. Supportkanäle, Reaktionszeiten nach Schweregrad, Sprachen und wie Vorfälle kommuniziert werden. | Der Vorfallprozess des Auftraggebers hängt von dem des Anbieters ab. | Die Support-Richtlinie, die URL der Statusseite und aktuelle Vorfallberichte. |
| [ ] | 43 | Sicherheitsdokumentation. Eine Sicherheitsübersicht, ein ausgefüllter Sicherheitsfragebogen und die Prüfberichte oder Zertifizierungen, die der Anbieter und seine Hosting-Anbieter besitzen. | Das prüft das Sicherheitsteam des Auftraggebers vor der Freigabe. Wer es gleich mit der Ausschreibung anfordert, spart eine Runde. | Die Sicherheitsseite, ein ausgefüllter Fragebogen wie der offene Sicherheitsfragebogen für LLM-Gateways (https://standardcompute.com/sicherheitsfragebogen-llm-gateway) und etwaige Berichte. |

---

## Quellen

- [Aktualisierte EU-Mustervertragsklauseln für KI (MCC-AI High Risk und Light), Public Buyers Community, 5. März 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Verordnung (EU) 2016/679, Datenschutz-Grundverordnung (DSGVO), Artikel 28 und 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679)
- [Verordnung (EU) 2024/1689, KI-Verordnung, Artikel 4, 26, 50 und 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689)
- [Verordnung (EU) 2023/2854, Datenverordnung (Data Act), Kapitel VI zum Wechsel zwischen Datenverarbeitungsdiensten, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, SCIM-2.0-Protokoll](https://www.rfc-editor.org/rfc/rfc7644) und [SAML 2.0 Core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Kostenloser Anforderungskatalog für die Ausschreibung eines LLM-Gateways oder einer KI-Plattform von https://standardcompute.com/ausschreibung-llm-gateway-anforderungskatalog (Stand 9. November 2026). Frei kopierbar und anpassbar. Keine Rechtsberatung._