Leitfaden zum Risikomanagement von Large Language Models

Fragen, die CIOs bei jedem LLM-Einsatz stellen sollten

Bei der Planung von LLM-Implementierungen müssen CIOs Fragen formulieren, die sowohl an interne Teams im gesamten Unternehmen als auch an potenzielle Anbieter gerichtet werden.

Fragen an interne Teams

1. Welche geschäftliche Entscheidung oder welchen Workflow beeinflusst das LLM? Das LLM-Risikomanagement erfordert einen benannten Verantwortlichen aus dem entsprechenden Fachbereich (Business Owner), eine dokumentierte Prozessübersicht und eine Ausweichlösung für den Fall, dass das Modell nicht verfügbar ist.
2. Generiert das System nur Inhalte, oder kann es auch andere Aktionen ausführen? Das Risikoprofil ändert sich grundlegend, wenn ein LLM E-Mails versenden, Workflows auslösen oder Transaktionen genehmigen kann. CIOs sollten ein präzises Verzeichnis der möglichen Aktionen verlangen und festlegen, welche dieser Aktionen eine menschliche Freigabe erfordern.
3. Auf welche Unternehmenssysteme, APIs, Tools oder Datenbanken kann das LLM zugreifen? Konnektoren und Zugriffsmöglichkeiten bestimmen den potenziellen Schadensradius (Blast Radius) der LLM-Sicherheit. Gemeinsam genutzte Dienstkonten und weitreichende API-Berechtigungen ohne Überprüfung nach dem Prinzip der minimalen Rechtevergabe (Least-Privilege-Prinzip) sind Warnsignale für die Sicherheit.
4. Welche Daten verwendet das System und wie werden sie genutzt? Die Grundlage für KI-Compliance bildet ein Datenflussdiagramm, das Prompts, Embeddings, Protokolle (Logs) und nachgelagerte Ausgaben abdeckt.
5. Nutzt das System Retrieval-Augmented Generation (RAG), Fine-Tuning, Prompt Engineering, Tool-Aufrufe oder autonome Agenten? Unterschiedliche Architekturen weisen unterschiedliche Fehlerbilder auf. So birgt beispielsweise agentische KI das Risiko einer Zweckentfremdung der Ziele (Goal Hijacking), was bei Copilot-Implementierungen nicht der Fall ist.
6. Was geschieht, wenn das Modell eine falsche Antwort liefert? CIOs sollten auf definierte Fehlermodi, sichere Fallback-Mechanismen, Eskalationsregeln, den Umgang mit Konfidenz- oder Unsicherheitswerten sowie klare Benutzerhinweise dazu achten, wann man sich nicht auf die Ausgabe verlassen sollte.
7. Welche Punkte für menschliche Freigaben oder Eskalationen sind vorgesehen? Menschliche Aufsicht stellt nur dann eine wirksame Kontrollmaßnahme dar, wenn sie spezifisch, zeitlich festgelegt und durchsetzbar ist. Freigabepunkte, bei denen der Agent selbst entscheidet, wann eine Eskalation erfolgt, sind keine echten Kontrollmechanismen.
8. Wie werden Ausgaben validiert, bevor sie in nachgelagerten Systemen verwendet werden? Die direkte Übergabe von Ausgaben an Skripte oder Workflows ohne Validierung von Schemata oder Geschäftsregeln stellt eine kritische Sicherheitslücke bei LLMs dar.

Fragen an Anbieter

1. Wie geht das LLM mit vertraulichen, regulierten, personenbezogenen oder kundenspezifischen Daten um? Datenabflüsse können über Prompts, Embeddings, Protokolle (Logs) und nachgelagerte Aktionen entstehen. Personenbezogene Daten ohne entsprechende Richtlinien sowie als nicht sensibel eingestufte Embeddings sind Red Flags für die KI-Compliance.
2. Wie werden Prompts, Ausgaben und Benutzerinteraktionen protokolliert? Die Nachvollziehbarkeit (Auditability) ist für die Reaktion auf Sicherheitsvorfälle und die KI-Compliance unerlässlich. Ungeschützt gespeicherte sensible Prompts oder fehlende Verknüpfungen zwischen Anfragen, Tool-Aufrufen und abschließenden Aktionen sind kritische Warnsignale.
3. Wohin gelangen die Daten, sobald sie sich im System befinden? CIOs sollten auf eine Dokumentation der Datenflüsse, Angaben zur geografischen Speicherung (Regionen), Transparenz bezüglich Unterauftragsverarbeitern, Regeln für den Support-Zugriff sowie explizite Aussagen zum Anbieterzugriff auf Eingaben, Ausgaben und Trainingsdaten achten.
4. Darf der Anbieter die in das System eingegebenen Daten für das Modelltraining oder zur Verbesserung des Dienstes nutzen? Zusagen zum Training sind produktspezifisch; CIOs sollten klären, ob diese Zusagen auch Prompts, Ausgaben, Daten für das Fine-Tuning und Protokolle umfassen.
5. Welche Kontrollmechanismen gibt es für Aufbewahrung, Löschung und Speicherort (Residency)? KI-Governance scheitert oft schon am Datenlebenszyklus, noch bevor es um die Modellqualität geht. Angaben zum Speicherort, die Telemetriedaten ausklammern, sowie Löschzusagen ohne zeitliche Festlegung sind unzureichend.
6. Wie schützt das Tool sensible Daten? Allgemeine Formulierungen zu Sicherheitsstandards auf Unternehmensniveau ersetzen keine detaillierte Beschreibung der Kontrollmaßnahmen. CIOs sollten Verschlüsselung, Identitäts- und Zugriffsmanagement, private Netzwerke und Schlüsselmanagement überprüfen.
7. Welchen Systemzugriff benötigt der Anbieter? Agenten mit übermäßigen Berechtigungen ebnen oft den Weg von einem LLM-Missbrauch hin zur Kompromittierung des gesamten Unternehmens. Gemeinsam genutzte Zugangsdaten ohne Autorisierungsprüfung für jede einzelne Anfrage sind inakzeptabel.
8. Wie wird gegen Prompt Injection und indirekte Prompt Injection vorgegangen? Prompt Injection bleibt eine häufige Sicherheitsbedrohung bei LLM-basierten Agentensystemen.
9. Wie werden Modellaktualisierungen, Änderungen an System-Prompts und anbieterseitige Änderungen kommuniziert? LLM-Systeme können ihr Verhalten ändern, ohne dass ein Code-Release auf Kundenseite erforderlich ist. Lautlose Modellwechsel und das Fehlen von Optionen zur Festlegung fester Versionen (Version-Pinning) für regulierte Bereitstellungen sind inakzeptabel.
10. Welche Tests wurden hinsichtlich Verzerrungen, Toxizität, Halluzinationen, Datenlecks, Jailbreaks und unsicherer Tool-Nutzung durchgeführt? Benchmark-Ergebnisse allein, ohne Beweise aus Adversarial- oder Red-Team-Tests oder erneute Tests nach Konfigurationsänderungen, genügen nicht den Anforderungen an die KI-Governance.
11. Welche Prüfnachweise liegen vor? KI-Governance versagt bei genauer Prüfung, wenn keine Nachweiskette vorhanden ist. CIOs sollten Architekturdokumente, Risikobewertungen und unabhängige Bestätigungen verlangen.
12. Welche vertraglichen Schutzmaßnahmen bestehen und wie sieht der Ausstiegsplan aus, wenn sich der Anbieter, das Modell oder die regulatorischen Rahmenbedingungen ändern? Die Vertragsbedingungen müssen Dateneigentum, Meldung von Datenschutzverletzungen, Portabilität und Prüfrechte abdecken und einen Ausweichplan enthalten, der nicht von der Kooperation des Anbieters abhängt.

Aufbau eines LLM-Governance-Frameworks

Ein tragfähiges KI-Governance-Framework sollte für risikoarme Anwendungsfälle schlank, für Systeme, die sensible Daten, regulierte Entscheidungen oder autonome Aktionen verarbeiten, jedoch streng sein. Die nachhaltigsten Designs richten Business Ownership, LLM-Sicherheitskontrollen, Data Governance, Beschaffung und Prüfnachweise auf das gesamte LLM-System aus, anstatt sich nur auf das Modell zu konzentrieren.

1. Schaffen Sie Verantwortlichkeiten und Zuständigkeiten. Der CIO ist für das operative Unternehmensmodell verantwortlich. Der CISO ist für die Sicherheit von LLM und die Reaktion auf Sicherheitsvorfälle zuständig. Der Chief Data Officer und die Datenschutzteams sind für die Datenkontrolle verantwortlich. Die Rechtsabteilung und die Compliance-Abteilung sind für die Auslegung der Vorschriften zuständig. Der Einkauf ist für die KI-spezifische Lieferantenprüfung verantwortlich, und die Geschäftsbereichsverantwortlichen bleiben für den Nutzungskontext und die Fehlertoleranz verantwortlich.
2. Definieren Sie Richtlinien für die zulässige KI-Nutzung. Die Richtlinien sollten genehmigte Datenklassen, zulässige Aktionen, Nutzungsbeschränkungen für Ergebnisse und verbotene Anwendungsfälle mit klaren Eskalationswegen für Sonderfälle umfassen.
3. Klassifizieren Sie LLM-Anwendungsfälle nach Risiko. Eine gestaffelte Klassifizierung, die zwischen Inhaltsgenerierung, Entscheidungsunterstützung und autonomen Aktionen unterscheidet, sollte angemessene Kontrollen beinhalten und verhindern, dass Genehmigungen mit geringem Risiko risikoreiche, agentische KI-Implementierungen abdecken.
4. Erstellen Sie ein unternehmensweites KI-Inventar. Jede registrierte LLM-Implementierung, einschließlich eingebetteter KI in SaaS-Tools und Drittmodelle, die von einem Anbieter gemanagt werden, sollte ihre Datenklassifizierung, den Geschäftsbereichsverantwortlichen und die Risikostufe enthalten.
5. Implementieren Sie LLM-Sicherheitskontrollen. Die Kontrollen müssen die zügige Dateneinspeisung, die Zugriffsbeschränkung, die Ausgabevalidierung und das Geheimnismanagement abdecken.
6. Implementieren Sie Data-Governance-Kontrollen. Die Data Governance für agentische KI muss festlegen, welche Daten in Prompts eingegeben, abgerufen, in eingebetteten Daten gespeichert und weiterverarbeitet werden.
7. Verwalten Sie agentische KI separat. Sie benötigt eine eigene Governance-Ebene für agentische KI, die Zielvorgaben, Nutzungsbeschränkungen für Tools und Eskalationsmechanismen für menschliche Nutzer umfasst und sich von denen für Copiloten unterscheidet.
8. Implementieren Sie Monitoring und Qualitätssicherung. Die operative Überwachung sollte Ausgabequalität, Kosten, Fehlerraten und anomale Tool-Aufrufe mit definierten Prüfintervallen und klarer Zuständigkeit für die Behebung von Problemen abdecken.
9. Managen Sie das Risiko von Drittanbietern und Lieferanten. Die Einhaltung der KI-Vorgaben erfordert eine servicespezifische Lieferantenprüfung, die bei Änderungen von Modellen oder Bedingungen aktualisiert und durch vertragliche Rechte auf Audits und den Ausstieg abgesichert ist.
10. Bereiten Sie sich auf Regulierungen und Audits vor. Die aktuellen Kontrollen müssen unter anderem ISO 42001 und dem EU AI Act zugeordnet werden. Lücken müssen frühzeitig identifiziert und die von den Aufsichtsbehörden geforderten Nachweise erstellt werden.

Dieser Artikel ist im Original in englischer Sprache auf Search CIO erschienen.