Organisationen, die auf einem gehosteten Sprachmodell aufbauen, erhalten vom Anbieter ein sicherheitstrainiertes Modell und eine Plattform und bleiben für die Anwendung darum herum verantwortlich. Microsoft, die Cloud Security Alliance und der EU AI Act teilen die Arbeit jeweils zwischen dem Modellanbieter und der Partei auf, die das Modell einsetzt, mit unterschiedlichem Vokabular und unterschiedlichem rechtlichem Gewicht. Diese Notiz vergleicht die drei Ansätze und legt eine praktische Aufteilung für den häufigen Fall eines über eine API genutzten Modells dar. Sie ergänzt den Artikel How Anthropic red-teams Claude, and what it leaves to you, der die Seite des Anbieters an einem veröffentlichten Fall untersucht.
Hintergrund: das Cloud-Modell, auf KI erweitert
Das Modell geteilter Verantwortung in der Cloud weist jede Kontrolle je nach Diensttyp dem Anbieter oder dem Kunden zu: Software as a Service (SaaS), Platform as a Service (PaaS) oder Infrastructure as a Service (IaaS). Sowohl Microsoft als auch die Cloud Security Alliance (CSA) übertragen diesen Gedanken auf generative KI. Die Erweiterung ändert eher das Vokabular als die Logik: Je tiefer im Stack ein Kunde aufbaut, desto mehr Kontrollen liegen bei ihm.
Modelle der Anbieter
Microsoft: Plattform, Anwendung und Nutzung
Das Modell geteilter Verantwortung für KI von Microsoft beschreibt eine KI-gestützte Anwendung in drei Schichten: die KI-Plattform, die KI-Anwendung und die KI-Nutzung. Die Plattformschicht stellt das Modell über APIs bereit und umfasst ein Sicherheitssystem, das schädliche Eingaben und Ausgaben filtert. Die Anwendungsschicht ist die Oberfläche, die der Nutzer verwendet, mit Grounding, Plugins und Datenkonnektoren, und sie benötigt ein eigenes Sicherheitssystem auf Anwendungsebene. Die Nutzungsschicht betrifft, wie Menschen die Funktion verwenden; Microsoft verweist hier auf Identitäts- und Zugriffskontrollen, Richtlinien zur zulässigen Nutzung und Schulung der Nutzer. [1]
Welcher Anteil jeder Schicht beim Kunden liegt, hängt vom Bereitstellungstyp ab. Die Seite hält fest, dass die Verantwortlichkeiten zwischen SaaS, PaaS und IaaS variieren, und empfiehlt, mit SaaS-Angeboten wie Copilot zu beginnen, erst dann zu PaaS-Diensten wie Azure OpenAI Service überzugehen, wenn Standardfunktionen nicht passen, und die Entwicklung eigener Modelle Organisationen mit tiefgehender Expertise vorzubehalten. Die Seite fügt hinzu, dass die Hinweise der Veranschaulichung dienen, im Sinne der Governance verwendet werden und keine Vereinbarung mit Microsoft ändern. [1]
Microsoft: die Erweiterung für Agenten
Eine zweite Seite von Microsoft behandelt Agenten. Sie grenzt diese von einem bloßen Modell ab, weil ein Agent handelt, ohne dass ein Mensch jeden Schritt freigibt, plant und in Schleifen arbeitet, ein Gedächtnis hat, über eine eigene Identität verfügt und mit anderen Agenten zusammenwirken kann. Sie ergänzt drei Schichten: Orchestrierung des Agenten, Werkzeuge und Aktionen sowie Gedächtnis und Zustand. In ihrer Verantwortungsmatrix behält der Kunde im PaaS-Fall die Anweisungen und den Umfang des Agenten, die Berechtigungen pro Werkzeug und die menschliche Freigabe für folgenreiche Aktionen, während Laufzeitumgebung und Orchestrierungsplattform bei Microsoft liegen. [2]
Die Seite führt Verantwortlichkeiten auf, die stets beim Kunden bleiben: Daten, Identität und minimale Berechtigungen, Autorisierung von Aktionen, menschliche Aufsicht sowie zulässige Nutzung und Governance. Außerdem hält sie fest, dass Autonomie die Rechenschaftspflicht nie verringert. [2]
Cloud Security Alliance: ein Vorschlag von 2023
In einem Blogbeitrag vom 28. Juli 2023 schlug ein Fellow der CSA ein Modell mit drei Parteien vor: dem Anbieter des KI-Dienstes, dem Nutzer des KI-Dienstes, der eine Anwendung baut, und dem Unternehmen oder Endnutzer dieser Anwendung. Nach dem Vorschlag stellt ein IaaS-Anbieter Infrastruktur und Foundation-Modelle bereit, während der Nutzer Training, Datenvalidierung, Prompt-Filterung und Anwendungssicherheit übernimmt; im PaaS-Fall liefert der Nutzer Kontext und Anwendungssicherheit; im SaaS-Fall verwaltet der Nutzer Grounding, Prompt-Filterung und den Schutz geistigen Eigentums. Der Beitrag stellt dies als Vorschlag zur Trennung von Pflichten dar, nicht als Standard. [3]
Recht: Der EU AI Act verteilt Pflichten nach Rollen
Der EU AI Act weist Pflichten nach Rollen zu. Nach den FAQ der Europäischen Kommission zu ihren Leitlinien ist Anbieter eines KI-Modells mit allgemeinem Verwendungszweck die Stelle, die das Modell entwickelt oder entwickeln lässt und es unter eigenem Namen in Verkehr bringt. Zu den Anbieterpflichten gehören technische Dokumentation, Dokumentation für nachgelagerte Entwickler über Fähigkeiten und Grenzen, eine Strategie zur Einhaltung des Urheberrechts und eine öffentliche Zusammenfassung der Trainingsinhalte. Diese Pflichten gelten seit dem 2. August 2025. Für Modelle, bei denen ein systemisches Risiko vermutet wird, ab 10^25 Gleitkommaoperationen an Trainingsrechenleistung, gelten weitere Pflichten, darunter adversariale Tests und Schutzmaßnahmen für die Cybersicherheit. [4]
Dieselben FAQ nennen den 2. August 2026 als Datum, ab dem die Durchsetzung einschließlich Geldbußen für diese Anbieter gilt, und den 2. August 2027 als Frist für Modelle, die vor dem 2. August 2025 in Verkehr gebracht wurden. Sie halten außerdem fest, dass ein nachgelagerter Entwickler, der ein Modell verändert, nur in Ausnahmefällen zum Anbieter wird, etwa wenn er mehr als ein Drittel der ursprünglichen Trainingsrechenleistung einsetzt, sodass die meisten Fine-Tunings die Anbieterrolle nicht verschieben. [4]
Betreiber, also Organisationen, die KI-Systeme verwenden, tragen eigene Pflichten. Eine Analyse einer Anwaltskanzlei vom 24. Juli 2026 nennt die Offenlegung von Deepfakes sowie die Information betroffener Personen über Emotionserkennung und biometrische Kategorisierung als Betreiberpflichten ab dem 2. August 2026. Für Hochrisikosysteme nennt sie kompetente menschliche Aufsicht, die Information von Personen über den Einsatz von KI und die Konsultation von Beschäftigten. [6] Die Zeitleiste der Kommission ergänzt, dass Betreiber menschliche Aufsicht und Überwachung sicherstellen und schwerwiegende Vorfälle melden müssen, sobald Systeme in Verkehr sind. [5]
Die Verschiebung durch den Digital Omnibus
Die Fristen für Hochrisikosysteme haben sich verschoben. Die Zeitleiste der Kommission nennt den 2. Dezember 2027 für Hochrisikosysteme in sensiblen Bereichen wie Biometrie, Beschäftigung und Strafverfolgung und den 2. August 2028 für Hochrisikosysteme, die in regulierte Produkte eingebettet sind, und führt dies auf den Digital Omnibus zur KI zurück, dessen Inkrafttreten sie für July 2026 angibt. [5] Die Analyse von Norton Rose Fulbright nennt dieselben zwei Daten und hält fest, dass der Omnibus im Amtsblatt der EU veröffentlicht wurde. [6] Zwei unabhängige Quellen stimmen somit darin überein, dass die Verschiebung beschlossen und nicht nur vorgeschlagen wurde. Die Anbieterpflichten für Modelle mit allgemeinem Verwendungszweck und die oben genannten Transparenzpflichten werden durch diese beiden Daten nicht verschoben.
Die Aufteilung der Arbeit bei Nutzung eines Modells über eine API
Für den PaaS-Fall, in dem eine Anwendung ein gehostetes Modell aufruft, stützen die Quellen die folgende Aufteilung. Die Zeilen nach Microsoft folgen den oben beschriebenen Plattform- und Anwendungsschichten; die Zeilen zu Tests auf Frontier-Risiken, Systemdokumentation und Meldekanälen spiegeln die Anbieterpflichten aus den EU-Leitlinien und die von Modellanbietern veröffentlichten Praktiken wider. Die Tabelle ist eine Synthese von FireAI, kein Text aus einer der Quellen.
| Bereich | Seite des Anbieters | Ihre Seite |
|---|---|---|
| Modellverhalten | Sicherheitstraining und Alignment des Modells | System-Prompt und Schutzmechanismen der Anwendung |
| Risikotests | Tests des Modells selbst auf Frontier-Risiken | Tests Ihrer Anwendung, einschließlich Prompts, Daten und Werkzeugen |
| Plattform | Plattformsicherheit und grundlegende Filter für Ein- und Ausgaben | Sicherheitsprüfungen der Anwendung für Inhalte, Plugins und Konnektoren |
| Dokumentation | System Card und Dokumentation für nachgelagerte Entwickler | Sie lesen und festhalten, welches Modell in welcher Version eingesetzt wurde |
| Daten und Werkzeuge | Nichts über den API-Vertrag hinaus | RAG-Daten, Werkzeuge, Agenten und ihre Berechtigungen |
| Ausgaben | Liefert generierten Text | Weiterverarbeitung der Ausgaben: Validierung, Escaping, menschliche Freigabe |
| Betrieb | Kanal zur Meldung von Schwachstellen des Modells | Protokollierung, Überwachung und Reaktion auf Vorfälle für die Anwendung |
| Menschen | Bedingungen der Nutzungsrichtlinie | Eigene Nutzungsrichtlinie und Schulung der Nutzer |
Zwei Bereiche sind im engeren Sinn geteilt. Der erste ist Prompt-Injection: Der Anbieter trainiert das Modell darauf, eingeschleusten Anweisungen zu widerstehen, und der Betreiber begrenzt über Werkzeugberechtigungen und Datenzugriff, was eine eingeschleuste Anweisung bewirken kann. Die Agentenseite von Microsoft beschreibt dieselbe Aufteilung und rät Kunden, abgerufene Inhalte, Werkzeugausgaben und Nachrichten anderer Agenten als nicht vertrauenswürdig zu behandeln und folgenreiche Aktionen an eine Freigabe zu binden. [2] Der zweite ist der Datenschutz: Der Anbieter legt Bedingungen für Aufbewahrung und Training fest, und der Betreiber entscheidet, welche Daten überhaupt in einen Prompt oder einen Abrufindex gelangen.
Empfehlungen
- Bestimmen Sie zuerst den Bereitstellungstyp (SaaS, PaaS oder selbst gehostet) und halten Sie fest, welche Zeilen der obigen Aufteilung bei der Organisation liegen.
- Testen Sie die Seite des Betreibers direkt: System-Prompt, Abrufdaten, Werkzeugberechtigungen und Umgang mit Ausgaben. Die Tests des Anbieters am Modell decken diese nicht ab.
- Lesen Sie vor der Einführung eines Modells die System Card des Anbieters sowie seine Bedingungen zu Datenaufbewahrung und Training, und ermitteln Sie seinen Kanal zur Meldung von Schwachstellen.
- Begrenzen Sie, was eine eingeschleuste Anweisung bewirken kann: Werkzeuge mit minimalen Berechtigungen, eingegrenzter Datenzugriff und menschliche Freigabe für unumkehrbare Aktionen.
- Legen Sie fest, welche Daten in Prompts gelangen dürfen, und führen Sie Protokolle, die ausreichen, um einen Vorfall zu rekonstruieren.
- Lernmaterial zu Rahmenwerken und Red Teaming bietet der Kurs der FireAI University zu KI-Sicherheitsrahmenwerken und Red Teaming.
Bezug zu FireAI
Eine lokale App oder ein Agent, der eine Modell-API aufruft, ist eine App auf dem Mac, und ihre Ziele sind für FireAI sichtbar. Aktivität zeigt, welche Apps online gegangen sind, und mit Regeln kann ein Nutzer eine App oder ein bestimmtes Ziel erlauben oder blockieren. Das ist eine Kontrolle auf der Seite des Betreibers, auf einem einzelnen Mac. FireAI prüft keine Prompts, bewertet keine Modellausgaben, erkennt keine Prompt-Injection und beurteilt nicht, ob ein Anbieter rechtliche Pflichten erfüllt.
Einschränkungen
- Die Seiten von Microsoft sind Herstellerhinweise für Azure-Produkte, bezeichnen sich selbst als veranschaulichend und ändern keine Vertragsbedingungen. Der Text der CSA ist ein Vorschlag aus dem Jahr 2023.
- Diese Notiz ist keine Rechtsberatung. Ob eine Organisation nach dem EU AI Act Anbieter, Betreiber oder Betreiber eines Hochrisikosystems ist, hängt von Umständen ab, die diese Notiz nicht beurteilt, und nationale Behörden können den Rechtsakt unterschiedlich auslegen.
- Die Daten zum Digital Omnibus stammen aus der Zeitleiste der Kommission und einer Analyse einer Anwaltskanzlei. Der Text der Verordnung selbst wurde für diese Notiz nicht geprüft.
- Die API-Tabelle ist eine Synthese, und einzelne Anbieter ordnen manche Zeilen in ihren Bedingungen anders zu.
Wo FireAI und HisnLabs ins Spiel kommen
Zu Ihrer Seite gehört, was den Mac verlässt. FireAI zeigt es und lässt Sie entscheiden.
FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die FireAI-Pilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.
Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.