8 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die Daten-Souveränitätsgrenze, hinter der die KI-Ebene liegt, präzise beschreiben: Verarbeitung im Inland, Zustandslosigkeit und kein Training mit Kundendaten.
  • Erklären, warum diese Grenze ein verwalteter Inferenzdienst für regulierte Workloads qualifiziert, und die Aussage präzise einordnen, anstatt sie zu verallgemeinern.
  • Die Rollen im EU AI Act korrekt entlang der Wertschöpfungskette zuordnen und Ihre Pflichten als Deployer von der Rolle der Plattform je nach Modell unterscheiden.
  • Erkennen, wann sich die eigenen Pflichten der Plattform von Distributor zu Provider verschieben, wenn sie ein Modell modifiziert, und was sich dadurch hinsichtlich der Herkunft der maßgeblichen Modell-Dokumentation ändert.

Einheit 6.6: KI-Souveränität und das EU AI Act

Einführung

Einheit 6.5 hat das verwaltete Inferencing auf AI Model Hub als Standard für Unternehmen etabliert: Sie nutzen Modelle über eine OpenAI-kompatible API, und die Plattform speichert nichts. Diese Einheit beantwortet die Compliance-Frage, die dieser Entscheidung zugrunde liegt. Was genau macht einen gehosteten KI-Dienst für einen regulierten Workload geeignet, und wo enden Ihre Pflichten und beginnen die Pflichten der Plattform? Die Antwort besteht aus zwei Teilen: der Grenze der Datenhoheit, hinter der die KI-Ebene liegt, und die dieselbe Grenze ist, die Einheiten 1.4 und 2.x als Entwurfsgrundlage festgelegt haben, sowie der Zuweisung von Pflichten nach Rolle über die gesamte Wertschöpfungskette durch den EU AI Act. Keines dieser beiden Elemente ist eine Funktion, die Sie aktivieren können. Beide sind Eigenschaften, über die Sie nachdenken müssen, wenn Sie sich entscheiden, einen Workload überhaupt auf der KI-Ebene der Plattform zu betreiben.

1. Die Grenze der Datenhoheit

Der Grund, warum AI Model Hub überhaupt für eine regulierte Arbeitslast qualifiziert ist, ist die Grenze, hinter der es betrieben wird. Es handelt sich um dieselbe Grenze, die Einheit 1.4 als Filter für jede spätere Entscheidung festgelegt hat. Drei Eigenschaften definieren sie.

Erstens: Verarbeitung im Inland. Für AI Model Hub erfolgen alle Datenverarbeitung und Inferenz ausschließlich in Deutschland. Der Service und seine verwalteten Vektordatenbanken laufen in nach ISO 27001 zertifizierten deutschen Rechenzentren (beschränken Sie den Nachweis auf diesen Service und diesen Standort, statt ihn auf die gesamte Plattform zu verallgemeinern). Prompts, Eingaben und alle für die Abrufverarbeitung hochgeladenen Dokumente verlassen diese Gerichtsbarkeit niemals.

Zweitens: Zustandslosigkeit. AI Model Hub arbeitet als zustandsloser Service: Prompts und Ausgaben werden am Ende jeder Sitzung verworfen und werden weder protokolliert, noch aufgezeichnet, noch für das Training von Modellen wiederverwendet. Jede Sitzung ist eigenständig. Dadurch können Sie sensible Prompts über das Hub senden, ohne eine neue Aufbewahrungsfläche zu schaffen, die geregelt werden müsste.

Drittens: Kein Training mit Kundendaten. Kundendaten werden unter keinen Umständen für das Training verwendet. Diese Eigenschaft unterscheidet einen souveränen EU-KI-Service von der üblichen Sorge bei Hyperscalern, dass Prompts der Modellverbesserung eines Anbieters zugeführt werden. Die Inferenzebene verbraucht Ihre Eingabe, um eine Antwort zu erzeugen, und behält nichts zurück, das Ihre Daten in ein gemeinsames Modell einfließen lassen könnte.

Definieren Sie den Geltungsbereich jeder dieser Eigenschaften präzise, wie Einheit 6.5 es für die ISO 27001-Aussage gefordert hat. Sie beziehen sich auf den verwalteten Inferenzservice in seinen deutschen Rechenzentren. Es handelt sich nicht um eine pauschale Aussage über alles, was die Plattform ausführt. Wenn Sie die Kontrolle für einen Auditor dokumentieren, nennen Sie den Service und den Standort, nicht „die Plattform“.

2. Rollen des EU AI Act in der Wertschöpfungskette

Der EU AI Act weist Pflichten nach Rollen zu, und die Plattform dokumentiert ihre eigene Position ausdrücklich, damit Sie Ihre eigene Rolle ableiten können. Der Dokumentationskorpus behandelt dies im Detail, daher sind die unten aufgeführten Rollen dokumentiert und nicht abgeleitet.

Als Kunde, der auf dem Service aufbaut, sind Sie ein Deployer (Betreiber) und können zum Provider (Anbieter) Ihres eigenen KI-Systems werden. Die daraus resultierende Verantwortung liegt bei Ihnen: Sie müssen eine eigene Risikobewertung durchführen, um festzustellen, ob Ihre spezifische Anwendung nach dem Gesetz als Risiko mit begrenztem Ausmaß oder als Hochrisiko eingestuft wird, und die für diese Einstufung erforderlichen Kontrollen implementieren. Die Plattform stellt das technische Fundament bereit (Logging-Hooks auf API-Ebene, die Sie mit Ihrer eigenen Audit-Trail-Infrastruktur verknüpfen können, sowie sufficiently flexible APIs, um menschliche Überwachungsschleifen zu bauen), trifft aber keine Einstufung für Sie.

Die Plattform selbst übernimmt je nach Modell eine von zwei Rollen:

Modell auf der Plattform Rolle der Plattform nach dem EU AI Act Bedeutung dieser Pflicht
Unverändertes Open-Source-Modell (die Mehrheit) Distributor / Vermittler Transparenz in der Lieferkette: Jede Modellseite fasst das Modell zusammen und verlinkt die offizielle Modellkarte und Lizenz des ursprünglichen Entwicklers, damit Sie auf die maßgeblichen Informationen zu Trainingsdaten und Fähigkeiten zugreifen können.
Von der Plattform verändertes Modell (zum Beispiel FP8-Quantisierung) KI-Provider Die Plattform übernimmt zusätzliche Transparenzpflichten für ihre eigene Veränderung: Dokumentation, die das Basismodell und die Art der Änderung identifiziert, sowie eine eigene technische Dokumentation für das veränderte Modell.

Der architektonisch wichtige Punkt ist der Wechsel in der zweiten Zeile. Sobald die Plattform ein Modell ändert, beispielsweise durch Quantisierung auf FP8 für eine effizientere Ausführung, hört sie auf, ein durchleitender Distributor zu sein, und wird zum Provider für dieses spezifische Modell. Dabei übernimmt sie Transparenzpflichten, die sie für unveränderte Modelle nicht trägt. Wenn Sie ein Modell auswählen, prüfen Sie, welche Rolle zutrifft: Ein verändertes Modell wird von der Plattform erstellter Dokumentation der Änderung begleitet, während ein unverändertes Modell Sie auf die Dokumentation des upstream-Entwicklers als maßgebliche Quelle verweist. In beiden Fällen bleiben Ihre nachgelagerten Pflichten als Deployer bei Ihnen; die Rolle der Plattform bestimmt nur, woher die maßgebliche Modelldokumentation stammt.

Unternehmensfallstudie (FinCorp)

Der kundenorientierte Assistent von FinCorp, der in Einheit 6.5 konzipiert wurde, läuft als RAG auf AI Model Hub: ein Standardmodell, das auf dem eigenen Korpus von FinCorp basiert, wobei zwischen den Sitzungen nichts gespeichert wird und die gesamte Verarbeitung in Deutschland stattfindet. Die Souveränitätsgrenze ist der entscheidende Faktor, der dies im Hinblick auf die DSGVO- und BSI-Konformität von FinCorp zulässig macht: Prompts mit Kundendaten verlassen niemals die deutsche Gerichtsbarkeit, die zustandslose Ebene erzeugt keine neue Speicheroberfläche, und nichts, was FinCorp sendet, wird zum Training eines gemeinsamen Modells verwendet.

Die folgenden Compliance-Entscheidungen sind rollenbasierte Entscheidungen. Für das EU AI Act ist FinCorp der Deployer eines kundenorientierten Assistenten und führt seine eigene Bewertung als begrenztes Risiko gegenüber hohem Risiko durch; die Plattform klassifiziert die Anwendung nicht für FinCorp. Für das von FinCorp ausgewählte spezifische Modell dokumentiert FinCorp, ob die Plattform als Distributor (ein unverändertes Modell mit autoritativer Dokumentation im Upstream) oder, falls eine quantisierte Variante ausgewählt wurde, als Provider (ein von der Plattform modifiziertes Modell mit von der Plattform erstellter Dokumentation zur Änderung) handelt, und legt die entsprechende Modell-Dokumentation in seiner Compliance-Akte ab. Der Assistent verbleibt auf dem Hub, innerhalb einer souveränen, in Deutschland gehosteten Grenze, und die Compliance-Akte von FinCorp benennt den Dienst, den Standort und die Herkunft des Modells, anstatt einen plattformweiten „zertifizierten“-Anspruch zu erheben.

Zusammenfassung der Entscheidungen

Entscheidung Vorgehen Zeitpunkt
Platzierung einer regulierten Workload auf der AI-Ebene Bestätigen, dass die Grenze mit den drei Eigenschaften gilt Immer. Inländische (deutsche) Verarbeitung, zustandslose Inferenz und das Fehlen von Training auf Kundendaten machen das Hub zulässig.
Dokumentation der Souveränitätssteuerung Auf den Dienst und den Standort beschränken Immer. Die ISO 27001- und Verarbeitungsansprüche gelten für AI Model Hub in seinen deutschen Rechenzentren, nicht für die Plattform als Ganzes.
EU AI Act, Ihre Rolle Deployer (oder Provider Ihres eigenen Systems) Immer. Führen Sie Ihre eigene Bewertung von Begrenztem Risiko vs. Hohem Risiko durch; die Plattform klassifiziert Ihre Anwendung nicht.
EU AI Act, Modellauswahl Die Rolle der Plattform für das gewählte Modell dokumentieren Immer. Distributor (unverändert, Upstream-Dokumentation) vs. Provider (plattformmodifiziert, z. B. FP8-Quantisierung, von der Plattform erstellte Dokumentation).

Zusammenfassung

AI Model Hub erfüllt die Voraussetzungen für eine regulierte Arbeitslast aufgrund der Grenze, hinter der er betrieben wird, derselben Grenze, die der Kurs seit Einheit 1.4 verfolgt: Verarbeitung, die auf deutsche Rechenzentren beschränkt ist, eine zustandslose Inferenzebene, die nichts speichert, und eine absolute Garantie, dass Kundendaten niemals zur Schulung gemeinsamer Modelle verwendet werden. Beschränken Sie diese Eigenschaften auf den Dienst und den Standort, statt sie als plattformweite Zertifizierung zu lesen. Nach dem EU AI Act sind Sie der Deployer und tragen die Verantwortung für Ihre Risikobewertung, während die Plattform für unveränderte Modelle als Distributor und für von ihr modifizierte Modelle als Provider fungiert. Letzteres ist der Fall, in dem ihre Transparenzpflichten erweitert werden und die maßgebliche Modell-Dokumentation von der Plattform erstellt wird, statt von der vorgelagerten Quelle.

Wichtige Punkte:

  • Die Souveränitätsgrenze besteht aus drei Eigenschaften: Verarbeitung im Inland (Deutschland), ein zustandsloser Inferenzdienst, der nichts speichert, und keine Verwendung von Kundendaten zur Schulung unter keinen Umständen.
  • Beschränken Sie die Aussagen zur Souveränität und zu ISO 27001 auf AI Model Hub in seinen deutschen Rechenzentren; sie sind keine plattformweite Aussage.
  • Nach dem EU AI Act sind Sie der Deployer und tragen die Verantwortung für die Klassifizierung Ihrer Anwendung als Limited-Risk oder High-Risk; die Plattform trifft diese Entscheidung nicht für Sie.
  • Die Plattform ist ein Distributor für unveränderte Modelle (mit Verweis auf die vorgelagerte Dokumentation) und wird zu einem Provider mit zusätzlichen Transparenzpflichten für Modelle, die sie modifiziert, wie beispielsweise FP8-Quantisierung.
  • Welche Rolle zutrifft, bestimmt nur, woher die maßgebliche Modell-Dokumentation stammt; Ihre nachgelagerten Deployer-Pflichten bleiben in jedem Fall Ihre Verantwortung.

Wichtige Begriffe:

  • Daten-Souveränitätsgrenze: die Kombination aus Verarbeitung im Inland, Zustandslosigkeit und dem Verzicht auf Schulung mit Kundendaten, die den verwalteten KI-Dienst für eine regulierte Arbeitslast qualifiziert.
  • Zustandslosigkeit: die Eigenschaft, dass Eingaben und Ausgaben pro Sitzung verworfen und niemals protokolliert, aufgezeichnet oder zur Schulung wiederverwendet werden.
  • Deployer (EU AI Act): die Entität, die ein KI-System in Betrieb nimmt und die Verantwortung für die Risikoklassifizierung und die nachgelagerten Pflichten für ihre Anwendung trägt.
  • Distributor vs. Provider (EU AI Act): die Rolle der Plattform je nach Modell; Distributor für unveränderte Modelle (Verweise auf vorgelagerte Dokumentation), Provider für von ihr modifizierte Modelle (erstellt eigene Transparenzdokumentation).

Weitere Lektüre

  • Einheit 6.5: AI Inference (Managed Model Hub) - der Inferenzdienst, dessen Souveränitäts- und Compliance-Status diese Einheit untersucht
  • Einheit 1.4: Souveränität und Compliance als Design-Eingaben, sowie die Governance-Einheiten von Modul 2 - das Souveränitätsfundament, das hier gestärkt wird