8 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die Datensouveränitätsgrenze zu artikulieren, hinter der die KI-Ebene sitzt: Inlandsverarbeitung, Zustandslosigkeit und keine Schulung mit Kundendaten.
  • Zu erklären, warum diese Grenze das ist, was einen gemanagten Inferenzdienst für einen regulierten Workload qualifiziert, und den Anspruch genau zu umreißen, anstatt ihn zu verallgemeinern.
  • Die Rollen des EU-KI-Gesetzes korrekt entlang der Wertschöpfungskette zuzuweisen, Ihre Verpflichtungen als Deployer von der Rolle der Plattform pro Modell zu unterscheiden.
  • Zu erkennen, wann die Verpflichtungen der Plattform von Distributor zu Provider wechseln, wenn sie ein Modell modifiziert, und was sich dadurch ändert, woher die autoritative Modell-Dokumentation stammt.

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

Einführung

Die Einheit 6.5 hat die verwaltete Inferenz auf AI Model Hub als Unternehmensstandard etabliert: Sie konsumieren Modelle durch eine OpenAI-kompatible API, und die Plattform behält nichts. Diese Einheit beantwortet die Compliance-Frage, die unter dieser Wahl liegt. Was genau macht einen gehosteten KI-Service für einen regulierten Workload zulässig, und wo enden Ihre Verpflichtungen und wo beginnen die der Plattform? Die Antwort hat zwei Teile: die Daten-Souveränitäts-Grenze, hinter der die KI-Ebene sitzt, die dieselbe Grenze ist, die die Einheiten 1.4 und 2.x als Design-Eingabe gemacht haben, und die Zuweisung von Aufgaben durch die Rolle über die Wertschöpfungskette des EU-KI-Gesetzes. Keines davon ist ein Feature, das Sie aktivieren. Beide sind Eigenschaften, über die Sie nachdenken, wenn Sie entscheiden, eine Workload auf der KI-Ebene der Plattform überhaupt zu platzieren.

1. Die Grenze der Datensouveränität

Der Grund, warum AI Model Hub überhaupt für einen regulierten Workload qualifiziert ist, ist die Grenze, hinter der es sitzt, und es ist dieselbe Grenze, die Einheit 1.4 als Filter über jede spätere Entscheidung gesetzt hat. Drei Eigenschaften definieren sie.

Erstens, Inlandsverarbeitung. Für AI Model Hub erfolgt alle Datenverarbeitung und Inferenz ausschließlich in Deutschland; der Service und seine gemanagten Vektordatenbanken laufen in ISO 27001-zertifizierten deutschen Rechenzentren (der Geltungsbereich des Zeugnisses beschränkt sich auf diesen Service und diesen Standort, anstatt ihn allgemein auf die Plattform auszuweiten). Prompts, Eingaben und alle hochgeladenen Dokumente zur Wiederherstellung verlassen niemals diese Gerichtsbarkeit.

Zweitens, Zustandslosigkeit. AI Model Hub funktioniert als zustandsloser Service: Prompts und Ausgaben werden am Ende jeder Sitzung verworfen und nicht protokolliert, nicht aufgezeichnet und nicht für die Modelltraining wiederverwendet. Jede Sitzung steht allein. Dies ermöglicht es Ihnen, sensible Prompts über den Hub ohne Schaffung einer neuen Aufbewahrungsfläche zur Regulierung zu übertragen.

Drittens, kein Training mit Kunden-Daten. Kunden-Daten werden unter keinen Umständen für die Schulung verwendet. Dies ist die Eigenschaft, die einen souveränen EU-KI-Service von dem üblichen Hyperscaler-Anliegen unterscheidet, dass Prompts die Verbesserung eines Anbietermodells fördern. Die Inferenz-Ebene verbraucht Ihre Eingabe, um eine Antwort zu produzieren, und behält nichts, das Ihre Daten in ein gemeinsames Modell einbeziehen könnte.

Begrenzen Sie jede dieser Eigenschaften genau, wie Einheit 6.5 für den ISO 27001-Anspruch insistierte. Sie sind an den gemanagten Inferenz-Service in seinen deutschen Rechenzentren angehängt; sie sind keine allgemeine Aussage über alles, was die Plattform ausführt. Wenn Sie die Kontrolle für einen Prüfer dokumentieren, nennen Sie den Service und den Standort, nicht "die Plattform".

2. EU-KI-Act-Rollen entlang der Wertschöpfungskette

Der EU-KI-Act weist Pflichten nach Rolle zu, und die Plattform dokumentiert ihre Position ausdrücklich, damit Sie Ihre eigene Rolle ableiten können. Der Korpus behandelt dies detailliert, so dass die folgenden Rollen dokumentiert sind, anstatt abgeleitet zu werden.

Als Kunde, der auf dem Dienst aufbaut, sind Sie ein Deployer, und Sie können zu einem Anbieter Ihres eigenen KI-Systems werden. Die daraus resultierende Verantwortung ist Ihre: Sie müssen Ihre eigene Risikobewertung durchführen, um zu bestimmen, ob Ihre spezifische Anwendung nach dem Gesetz als geringes Risiko oder hohes Risiko eingestuft wird, und implementieren Sie die erforderlichen Kontrollen. Die Plattform liefert die technische Grundlage (API-Ebene-Protokollhooks, die Sie mit Ihrem eigenen Prüfspur verbinden können, und APIs, die flexibel genug sind, um eine menschliche Überwachung aufzubauen), aber sie führt die Klassifizierung nicht für Sie durch.

Die Plattform selbst hat je nach Modell eine von zwei Rollen:

Modell auf der Plattform Plattform-Rolle im EU-KI-Act Was diese Pflicht bedeutet
Unmodifiziertes Open-Source-Modell (die Mehrheit) Vertriebs-/Zwischenhändler Transparenz in der Lieferkette: Jede Modellseite fasst das Modell zusammen und verlinkt zur offiziellen Modellkarte und Lizenz des ursprünglichen Entwicklers, damit Sie die autoritative Trainingsdaten- und Funktionsinformationen erreichen können.
Modell, das die Plattform modifiziert (z. B. FP8-Quantisierung) KI-Anbieter Die Plattform übernimmt zusätzliche Transparenzpflichten für ihre eigene Modifikation: Dokumentation, die das Basismodell und die Art der Änderung identifiziert, sowie ihre eigene technische Dokumentation für das modifizierte Modell.

Der architektonisch wichtige Punkt ist der Wechsel in der zweiten Zeile. Sobald die Plattform ein Modell ändert, zum Beispiel durch Quantisierung auf FP8, um effizienter zu laufen, hört sie auf, ein reiner Vertriebs-/Zwischenhändler zu sein, und wird zu einem Anbieter für dieses spezifische Modell, indem sie Transparenzpflichten übernimmt, die sie für unmodifizierte Modelle nicht trägt. Wenn Sie ein Modell auswählen, prüfen Sie, welche Rolle zutrifft: Ein modifiziertes Modell kommt mit plattformautorierter Dokumentation der Änderung, während ein unmodifiziertes Modell auf die Dokumentation des upstream-Entwicklers als autoritative Quelle verweist. Auf jeden Fall bleiben Ihre nachgelagerten Deployer-Pflichten Ihre; die Rolle der Plattform bestimmt nur, woher die autoritative Modell-Dokumentation stammt.

Unternehmensfallstudie (FinCorp)

Die kundenorientierte Assistenz von FinCorp, die in Einheit 6.5 entworfen wurde, läuft als RAG auf AI Model Hub: ein Stockmodell, 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 es, die dies unter der GDPR- und BSI-Haltung von FinCorp zulässig macht: Prompts, die Kundendaten enthalten, verlassen niemals die deutsche Gerichtsbarkeit, die zustandslose Ebene schafft keine neue Speicherfläche und nichts, was FinCorp sendet, wird verwendet, um ein gemeinsames Modell zu trainieren.

Die nachfolgenden Compliance-Entscheidungen sind Rollenentscheidungen. Für den EU-KI-Act ist FinCorp der Deployer einer kundenorientierten Assistenz und führt seine eigene Bewertung von Limited-Risk versus High-Risk durch; die Plattform klassifiziert die Anwendung nicht. Für das spezifische Modell, das es auswählt, dokumentiert FinCorp, ob die Plattform als Distributor (ein unmodifiziertes Modell mit autoritativer Dokumentation upstream) oder, wenn es eine quantisierte Variante ausgewählt hat, als Provider (ein plattformmodifiziertes Modell mit plattformautorisierter Dokumentation der Änderung) agiert, und speichert die entsprechende Modell-Dokumentation in seiner Compliance-Akte. Die Assistenz bleibt auf dem Hub, innerhalb einer souveränen, in Deutschland gehosteten Grenze, und die Compliance-Akte von FinCorp nennt den Dienst, den Standort und die Herkunft des Modells anstelle eines plattformweiten "zertifizierten" Anspruchs.

Entscheidungszusammenfassung

Entscheidung Machen Sie dies Wann
Platzierung eines regulierten Workload auf der AI-Ebene Bestätigen Sie die Dreifach-Eigenschaftengrenze Immer. Die inländische (deutsche) Verarbeitung, Zustandslose Inferenz und keine Schulung auf Kundendaten sind es, die den Hub zulässig machen.
Dokumentation der Souveränitätskontrolle Begrenzen Sie sie auf den Dienst und den Standort Immer. Die ISO 27001 und die Verarbeitungsansprüche beziehen sich auf AI Model Hub in seinen deutschen Rechenzentren, nicht auf die Plattform als Ganzes.
EU-KI-Gesetz, Ihre Rolle Deployer (oder Anbieter Ihres eigenen Systems) Immer. Führen Sie Ihre eigene Bewertung von Limited-Risk vs High-Risk durch; die Plattform klassifiziert Ihre Anwendung nicht.
EU-KI-Gesetz, Modellauswahl Aufzeichnen Sie die Rolle der Plattform für das gewählte Modell Immer. Distributor (unmodifiziert, upstream-Dokumente) vs Anbieter (plattformmodifiziert, z.B. FP8-Quantifizierung, plattformautorierte Dokumente).

Zusammenfassung

AI Model Hub qualifiziert sich für einen regulierten Workload aufgrund der Grenze, hinter der es sitzt, der gleichen Grenze, die der Kurs seit Einheit 1.4 getragen hat: die Verarbeitung ist auf deutsche Rechenzentren beschränkt, eine zustandslose Inferenz-Ebene, die nichts zurückhält, und eine absolute Garantie, dass Kundendaten niemals zur Schulung gemeinsamer Modelle verwendet werden. Diese Eigenschaften sind auf den Dienst und den Standort beschränkt und sollten nicht als platformweite Zertifizierung gelesen werden. Unter dem EU-KI-Gesetz sind Sie der Deployer und besitzen Ihre eigene Risikobewertung, während die Plattform ein Distributor für unmodifizierte Modelle und ein Anbieter für die Modelle ist, die sie modifiziert, wobei letzteres der Fall ist, in dem ihre Transparenzpflichten erweitert werden und die autoritative Modell-Dokumentation plattform-autorisiert wird, anstatt von Upstream.

Wichtige Punkte:

  • Die Souveränigkeitsgrenze besteht aus drei Eigenschaften: inländische (deutsche) Verarbeitung, ein zustandsloser Inferenzdienst, der nichts zurückhält, und keine Verwendung von Kundendaten zur Schulung unter keinen Umständen.
  • Die Souveränitäts- und ISO 27001-Ansprüche sind auf AI Model Hub in seinen deutschen Rechenzentren beschränkt; sie sind keine platformweite Aussage.
  • Unter dem EU-KI-Gesetz sind Sie der Deployer und besitzen die Klassifizierung Limited-Risk vs High-Risk für Ihre Anwendung; die Plattform macht diese nicht für Sie.
  • Die Plattform ist ein Distributor für unmodifizierte Modelle (verweist auf Upstream-Dokumentation) und wird zu einem Anbieter mit erweiterten Transparenzpflichten für Modelle, die sie modifiziert, wie z.B. FP8-Quantisierung.
  • Die Rolle, die anwendbar ist, bestimmt nur, woher die autoritative Modell-Dokumentation stammt; Ihre downstream-Deployer-Pflichten bleiben Ihre, egal wie.

Wichtige Begriffe:

  • Daten-Souveränigkeitsgrenze: die Kombination aus inländischer Verarbeitung, Zustandslosigkeit und keiner Schulung auf Kundendaten, die den gemanagten KI-Dienst für einen regulierten Workload qualifiziert.
  • Zustandslosigkeit: die Eigenschaft, die dazu führt, dass Eingaben und Ausgaben pro Sitzung verworfen werden und niemals protokolliert, aufgezeichnet oder für die Schulung wiederverwendet werden.
  • Deployer (EU-KI-Gesetz): die Entität, die ein KI-System in Gebrauch nimmt und die Risikoklassifizierung und downstream-Pflichten für ihre Anwendung besitzt.
  • Distributor vs Anbieter (EU-KI-Gesetz): die Rolle der Plattform pro Modell; Distributor für unmodifizierte Modelle (verweist auf Upstream-Dokumentation), Anbieter für Modelle, die sie modifiziert (verfasst ihre eigene Transparenz-Dokumentation).

Weiterführende Literatur

  • Einheit 6.5: KI-Schlussfolgerung (Managed Model Hub) - der Schlussfolgerungsdienst, dessen Souveränität und Compliance-Postur diese Einheit untersucht
  • Einheit 1.4: Souveränität und Compliance als Design-Eingaben, und Modul 2 Governance-Einheiten - die Souveränitätsgrundlage, die hier verstärkt wird