KI-Verantwortung braucht ein Betriebsmodell

CoSAI hat mit dem AI Shared Responsibility Framework eine Version 1.0 veröffentlicht, die eine einfache, aber für den Betrieb zentrale Frage stellt: Wer ist bei einem KI-System wofür accountable? Für DACH-Unternehmen ist das relevant, weil Agenten, RAG-Anwendungen und Modell-APIs selten in einer einzigen Verantwortungsgrenze bleiben.

Was das Framework konkret ordnet

Das CoSAI-Modell teilt KI-Verantwortung in fünf Schichten: Business & Usage, Information, Application, Platform und Model Provider. Jede Aktivität soll genau eine verantwortliche Partei haben. Damit wird aus „Shared Responsibility“ nicht ein weicher Sammelbegriff, sondern eine Zuordnung, die sich in Verträgen, Betriebsmodellen und Freigabeprozessen prüfen lässt.

Der Unterschied zur klassischen Cloud-Logik ist wichtig. Bei KI reicht die Trennung zwischen Anbieter und Kunde nicht mehr aus. Datenqualität, Prompt-Grenzen, RAG-Quellen, Agentenrechte, Modellrisiken und Plattformkontrollen greifen ineinander. Wenn ein Chatbot falsche Zusagen macht oder ein Agent ein Tool zu weitreichend nutzt, hilft ein vages „geteilt“ im Audit kaum weiter.

Warum das für Governance zählt

Die EU beschreibt den AI Act als risikobasierten Rahmen für Anbieter und Betreiber von KI-Systemen. OWASP nennt für Gen-AI-Anwendungen konkrete Risiken wie Prompt Injection, Sensitive Information Disclosure, Supply-Chain-Risiken und Excessive Agency. Beides zeigt: Unternehmen brauchen nicht nur Richtlinien, sondern eine belastbare Zuordnung zwischen Risiko, Kontrollpunkt und Owner.

Genau hier kann das SRF praktisch werden. Es ersetzt weder AI Act, ISO 42001 noch NIST AI RMF. Es ergänzt diese Rahmenwerke um die operative Frage, wer eine Kontrolle tatsächlich verantwortet.

Was DACH-Unternehmen jetzt prüfen sollten

Starten Sie nicht mit einem neuen Board-Papier. Nehmen Sie einen produktionsnahen Use Case: Copilot, Kundenservice-Bot, interner RAG-Assistent oder Coding-Agent. Ordnen Sie für jede Schicht einen Owner, die wichtigsten Kontrollen und offene Lücken zu.

Die entscheidende Frage lautet: Können Sie vor dem Rollout erklären, wer Datenzugriff, Modellgrenzen, Agentenrechte, Logging und Incident-Entscheidungen verantwortet — oder entsteht diese Antwort erst nach dem ersten Vorfall?