BLUF: Steuern Sie keine Modellmarke, sondern ein konkret einsetzbares Lieferanten-Tupel. Ein produktives KI-System hängt von Modell oder Fine-Tune, Endpoint und Region, Retrieval-Komponente, Policy-Konfiguration und Änderungsprozess ab. Ein freigegebenes Modellregister und ein Inferenz-Gateway müssen nicht freigegebene Tupel ablehnen, Evidenz sichern und bei materiellen Lieferantenänderungen eine erneute Prüfung erzwingen.
Das ist eine Engineering-Kontrolle, keine rechtliche Einordnung. Artikel 53 des EU AI Act enthält Dokumentations-, Informations- und Urheberrechts-Policy-Pflichten für Anbieter von General-Purpose-AI-Modellen; Anhang XI konkretisiert Informationen für nachgelagerte Anbieter. Ob Ihr Unternehmen Anbieter, Betreiber, Importeur oder etwas anderes ist, hängt von der konkreten Konstellation ab. Lassen Sie diese Frage bei relevanten Folgen rechtlich prüfen; bauen Sie die Nachvollziehbarkeit dennoch technisch auf.
Warum ein Lieferantenregister allein nicht reicht
Eine Beschaffungsakte erfasst häufig Lieferant, Vertrag und Modellfamilie. Sie beantwortet meist nicht, welcher Endpoint eine Anfrage verarbeitet hat, welche Region Daten erhielt, ob ein gehosteter Alias wechselte, welches Embedding-Modell den Index erzeugte oder ob Fine-Tune und Basismodell kompatibel bleiben. Diese Lücken machen aus einem gewöhnlichen Vendor-Release eine nicht untersuchbare Produktionsänderung.
Die Kommission beschreibt für GPAI-Anbieter unter anderem Informationspflichten gegenüber nachgelagerten KI-System-Anbietern und eine Urheberrechts-Policy; ihre Leitlinien sind interpretativ, aber nicht rechtsverbindlich. Nutzen Sie Lieferantendokumentation daher als Evidenzinput, nicht als Ersatz für eigene Workload-Evaluation, Datenpfadentscheidung oder verantwortete Release-Freigabe.
Referenzarchitektur: die KI-Lieferanten-Kontrollschicht
Die Kontrollschicht besteht aus fünf getrennten Diensten. Erstens speichert ein Freigaberegister ein Modell-Komponenten-Tupel: Lieferant, unveränderliche Version oder Artefakt-Digest, Betriebsart, zulässige Regionen, Datenklasse, erlaubte Fähigkeiten, Owner, Ablaufdatum und Rollback-Ziel. Zweitens löst ein Inferenz-Gateway nur freigegebene Registereinträge auf und erzwingt Endpoint- und Regions-Policy, bevor Credentials verwendet werden. Drittens verknüpft eine Modell- und Komponentenstückliste Basismodell, Adapter, Tokenizer, System Prompt, Tool-Schema, Embedding-Modell, Retrieval-Index-Snapshot und Safety-Konfiguration. Viertens speichert ein Evidenz-Vault Lieferantendokumente, Evaluationsläufe, Verträge oder Notices, Freigaben und Gateway-Ereignisse. Fünftens vergleicht eine Änderungsdetektion Vendor-Notices und Laufzeitmetadaten mit dem freigegebenen Tupel und eröffnet eine Prüfung statt Drift stillschweigend zu akzeptieren.
Diagramm — Kontrollpfad: Produktanfrage → Policy Lookup → Freigaberegister → Regions-/Endpoint-Gate → Inferenz-Gateway → gehostete API oder selbst betriebene Runtime. Evidenzpfad: Lieferanten-Notice + Modelldokumentation + Evaluation + Gateway-Trace → Komponentenstückliste → Evidenz-Vault → Owner-Prüfung. Eine geänderte Version, Region, Fähigkeit oder Komponente führt in Quarantäne oder ein explizites Re-Freigabe-Gate.
Verbinden Sie dieses Muster mit einem unveränderlichen LLM-Release-Bundle: Produktivverkehr muss eine Release-ID tragen, die auf eine eingefrorene Komponentenmenge zeigt. Für die Beschaffungsseite ergänzt Modellwahl als Änderungskontrolle die zentrale Evidenzfrage: Bewerten Sie Workload und Datenpfad, nicht eine Vendor-Ankündigung.
Entscheidungstabelle: Kontrolle nach Bezugsart
| Bezugsart | Minimal erzwungene Kontrolle | Erwartbarer Fehler | Verantwortlicher Owner |
|---|---|---|---|
| Gehostete API | Provider-Revision, Endpoint und zulässige Region pinnen; Retention- und Subprozessor-Evidenz erfassen | Alias-Wechsel oder regionales Failover verändert den Dienst | Vendor Manager + Plattform-Owner |
| Open-Weight-Basismodell | Lizenz, Source-Digest, Model Card, Runtime-Image und Patch-Owner prüfen | Mutable Repository-Tag oder unsicheres Runtime-Image gelangt produktiv | Plattformsicherheit + Modell-Owner |
| Fine-Tune oder Adapter | Basisrevision, Adapter-Digest, Trainingsdaten-Freigabe und Evaluationssegmente verknüpfen | Adapter ist syntaktisch kompatibel, verschlechtert aber Deutsch oder kritische Fälle | ML-Owner + Business-Owner |
| Retrieval-Komponente | Embedding-Modell, Index-Snapshot, Corpus-Policy und Access-Control-Version pinnen | Das Modell bleibt gleich, Antworten driften nach Re-Indexing | Knowledge-Owner + Plattform-Owner |
Datenfluss und relevante Evidenzfelder
Zur Laufzeit übergibt die Anwendung Workload-Klasse und angeforderte Fähigkeit, keinen freien Supplier-Endpoint. Das Gateway ermittelt das freigegebene Tupel, validiert Datenklassifikation und Region, injiziert die aufgelöste Release-ID und schreibt einen Trace mit Decision-ID, Registerversion und Policy-Ergebnis. Loggen Sie nicht Prompts oder personenbezogene Daten nur für bessere Traces; halten Sie minimierte Korrelationsdaten vor und schützen Sie sensible Evidenz mit einer separaten Zugriffs-Policy.
Hinterlegen Sie pro Tupel: Zweckbestimmung; fachlichen und technischen Owner; Lieferant und Vertragsreferenz; Modell-, Basis- und Adapter-Digests; Endpoint und Region; Datenkategorien; Fähigkeits- und Tool-Rechte; Retrieval-Abhängigkeiten; Evaluationssuite und Segmentgrenzen; Evidenz-Aktualität; Notice-Kanal; Freigabe und Ablauf; sowie Rollback- oder Abschaltaktion. Das operationalisiert den NIST AI RMF: Governance und Messung werden laufende Arbeit, kein einmaliges Dokument.
Vier Fehlerbilder, die Sie vor Go-live testen sollten
1. Stiller Hosted-Model-Drift. Ein Anbieter ändert Alias oder Safety-Layer, während Latenz und Qualität sich verschieben. Gegenmaßnahme: Floating Aliases sperren, soweit ein Pin verfügbar ist; Laufzeitmetadaten prüfen; Notice dem betroffenen Tupel zuordnen; eingefrorene Evaluationssegmente vor Promotion erneut ausführen.
2. Umgehung der Regions-Policy. Ein Entwickler nutzt bei einer Störung einen direkten SDK-Endpoint. Gegenmaßnahme: Egress-Allow-Lists und Workload-Identitäten, die nur das Gateway erreichen; Alert auf unsignierte Direktaufrufe; Fail-closed kontrolliert testen.
3. Unterbrochene Fine-Tune-Lineage. Ein Adapter wird ohne exakte Basisrevision, Trainingsdaten-Freigabe oder Tokenizer-Nachweis ausgerollt. Gegenmaßnahme: Komponenten-Digests in der Stückliste verpflichtend machen und Deployments bei fehlender Beziehung ablehnen.
4. Retrieval-Drift wird als Modellstabilität missverstanden. Re-Indexing, Embedding-Wechsel oder Berechtigungsfilter verändern Antworten bei unverändertem Chatmodell. Gegenmaßnahme: Retrieval-Artefakte als Komponenten behandeln, Index versionieren und berechtigungsgesteuerte Retrieval-Evaluations ausführen. Die operative Grundlage liefert der Beitrag zum
Nachweis von Retrieval-Entscheidungen.
Rechtsfrage für Counsel; Engineering-Empfehlung
Rechtsfrage für Counsel: Bestimmen Sie Rolle und anwendbare Pflichten Ihres Unternehmens für das konkrete System, die Vertragskette und den Sektor. Artikel 53 und Anhang XI betreffen GPAI-Anbieter-Transparenz und Dokumentation; sie ersetzen keine fallbezogene Bewertung des nachgelagerten Systems.
Engineering-Empfehlung: Jede produktive Anfrage muss auf ein freigegebenes Lieferanten-Tupel und einen Evidenzdatensatz zurückführbar sein. Das reduziert Änderungsunklarheit unabhängig davon, ob eine bestimmte Rechtspflicht greift. Es begründet jedoch nicht automatisch Compliance, rechtmäßige Datenverarbeitung, Urheberrechtskonformität, fachliche Eignung oder Lieferantenhaftung.
Praktische Umsetzung in 30 Tagen
Woche 1: Inventarisieren Sie Endpoints, Weights, Adapter, Embeddings und Retrieval-Indizes, die tatsächlich Produktivverkehr erhalten; entfernen Sie unbekannte Direktpfade. Woche 2: Führen Sie Tupel-Schema und Gateway-Allow-List für einen Workload ein. Woche 3: Verknüpfen Sie eingefrorene Evaluationssegmente, Owner und Ablaufdatum. Woche 4: Simulieren Sie Versions- und Regionswechsel eines Anbieters, weisen Sie die Owner-Zuordnung nach und üben Sie Deaktivierung oder Rollback. Beginnen Sie mit Transparenz; strikte Deny-Regeln folgen, sobald der Abhängigkeitsgraph belastbar ist.
Quellen
Verordnung (EU) 2024/1689, Artikel 53 und Anhang XI (EUR-Lex)
Europäische Kommission: GPAI Code of Practice
Europäische Kommission: Leitlinien für Anbieter von GPAI-Modellen
NIST AI Risk Management Framework
Lieferantenevidenz produktiv nutzbar machen
Ich unterstütze B2B-Teams dabei, aus KI-Lieferanteninventaren durchsetzbare Gateway-, Release- und Evidenzkontrollen zu machen. Ein fokussiertes Architekturreview identifiziert direkte Pfade, fehlende Owner und Re-Review-Trigger, bevor die nächste Modelländerung zum Incident wird.
