KI-Sicherheitsreife: Eine praktische Scorecard für CISOs

KI-Sicherheitsreife („AI Security Readiness“) bezeichnet die nachweisbare Kontrolle über die Informationen, Identitäten, Abhängigkeiten, Werkzeuge und Wiederherstellungsprozesse eines KI-Dienstes. Eine effektive CISO-Scorecard dokumentiert präzise, was getestet wurde und was unklar bleibt. Sie darf einen kritischen Autorisierungsfehler niemals durch einen vermeintlich positiven Gesamtwert schönrechnen.

Die Untersuchungseinheit ist ein klar abgegrenzter Workflow: beispielsweise ein interner Assistent, der Richtlinien durchsucht und belegte Antworten ausarbeitet. Die zusätzliche Anbindung von E-Mail-Funktionen oder Datensatzaktualisierungen verändert das Risikoprofil und erfordert neue Nachweise für die Freigabe.

Wir haben Nouswise entwickelt, um Teams bei der Recherche, der Erstellung von Arbeitsergebnissen und der Ausführung mehrstufiger digitaler Aufgaben zu unterstützen. Für einen CISO bedeutet das, eine nützliche Automatisierung in ihrem tatsächlichen Betriebskontext zu bewerten: die herangezogenen Nachweise, die generierten Empfehlungen und die Werkzeuge, die sie aufrufen kann. Dieser Leitfaden zeigt, wie sich diese Bewertung in einen reproduzierbaren Nachweisprozess überführen lässt.

Die Richtlinien des NCSC für die sichere Entwicklung von KI-Systemen decken Konzeption, Entwicklung, Bereitstellung und Betrieb ab. Die Scorecard in diesem Artikel überträgt diese Lebenszyklus-Perspektive in eine neuartige, praxisnahe Prüfmethode für Wissensassistenten. Sie versteht sich als Bewertungshilfe, nicht als Zertifizierungsschema.

Die Lehre aus Sicherheitsvorfällen: Auch ein legitimer Zugriff kann zu einer unbefugten Offenlegung führen

Microsofts Bericht zur Sicherheit von KI-Anwendungen vom Dezember 2025 thematisiert EchoLeak – eine mittlerweile behobene Schwachstelle im Zusammenhang mit CVE-2025-32711. Unter bestimmten Bedingungen konnte manipulierter E-Mail-Inhalt einen Copilot-Workflow dazu verleiten, begrenzte Informationen preiszugeben, auf die das Opfer Zugriff hatte.

Dies ist ein publiziertes Schwachstellenbeispiel und impliziert weder, dass alle KI-Assistenten von diesem Problem betroffen sind, noch dass ein bestimmter Kunde einen bestätigten Vorfall erlitten hat. Die Erkenntnis für die Bewertung ist jedoch eindeutig: Nur weil ein Benutzer Zugriff auf Informationen hat, ist damit noch längst nicht jede nachgelagerte Nutzung oder Weiterleitung autorisiert.

Prüfen Sie daher den gesamten Offenlegungspfad. Kann ein abgerufener Inhalt eine Aufgabe umleiten? Kann eine Ausgabe oder ein Tool-Aufruf vertrauliche Daten an unbefugte Empfänger weitergeben? Welche Komponente verhindert diesen Transfer? Die Ablehnungsnachricht eines Modells ist dabei nur eine Momentaufnahme.

Führen Sie in Nouswise freigegebene Richtlinien, Lieferantendokumentationen und Testnachweise im Prüfprojekt zusammen. Wir haben Projektrecherche und MCP-Quellen miteinander verknüpft, damit das Team auf Basis dieser Materialien eine belegte Bewertung erstellen kann. Sicherheitsexperten weisen die Kontrollen nach; der Agent kann die wiederkehrende Erfassungs-, Abgleich- und Berichtsarbeit rund um diese Tests übernehmen.

Vier Nachweisstufen statt willkürlicher Reifegrad-Prozentsätze

Die folgenden Statusstufen beschreiben die Aussagekraft der verfügbaren Nachweise:

Sicherheitsreife beginnt mit prüfbaren Nachweisen, benannten Verantwortlichen und erprobten Wiederherstellungsprozessen.

Dokumentieren Sie Datum, getestete Konfiguration, Nachweis-Link, Ausnahmen und die nächste Zuständigkeit. Der Status „Nachgewiesen“ ist nicht von Dauer: Eine neue Datenquelle, eine geänderte Identitätszuordnung, ein neues Modell oder Werkzeug kann das jeweilige Testergebnis entwerten.

Definieren Sie Release-Blocker vor Beginn der Bewertung. Bei einer vertraulichen internen Wissensdatenbank kann eine unbeabsichtigte Offenlegung gegenüber einer unberechtigten Rolle ein Blocker sein. Ein rein kosmetischer Formatierungsfehler wird hingegen als Optimierungsbedarf erfasst. Das Unternehmen legt seine Schwellenwerte anhand der potenziellen Risiken fest.

Die Sieben-Bereiche-Prüfung

Nutzen Sie diese Struktur als Agenda für eine Arbeitssitzung mit Serviceverantwortlichen, Wissensträgern, Identitätsexperten, Integrationsingenieuren und Sicherheitsprüfern.

Die OWASP-Leitlinien für agentische Anwendungen bieten einen zusätzlichen Prüfkatalog für Werkzeuge, Identitäten, Kontextspeicher und interagierende Agenten. Nutzen Sie diese, um den Fragenkatalog gezielt zu erweitern, wenn entsprechende Funktionen vorliegen – bewerten Sie jedoch keine Fähigkeiten, die im Einsatz gar nicht genutzt werden.

Das Security-Readiness-Workbook stellt strukturierte Felder für diese Bereiche sowie ein separates Register für Release-Blocker bereit.

Automatisieren Sie das Sicherheits-Nachweispaket mit Nouswise

Sicherheitsbewertungen wiederholen oft denselben zeitintensiven Ablauf: die aktuelle Anforderung heraussuchen, die Antwort des Dienstleisters abgleichen, den letzten Testbericht prüfen und die Zusammenfassung für einen weiteren Prüfer umschreiben. Die Automatisierung dieser Aufbereitung ist ein wirkungsvoller Ausgangspunkt, da das Ergebnis prüfbar bleibt und die Entscheidungskompetenz eindeutig zugeordnet ist.

Betrachten wir die interne Prüfung eines neuen Rechercheassistenten: Das Team verfügt über freigegebene Anforderungen, Architekturnotizen, Verarbeitungsvereinbarungen, ein Identitätskonzept und Zugriffstestprotokolle. Das Folgende skizziert eine exemplarische Umsetzung mit Nouswise – keinen Bericht über eine bereits abgeschlossene Kundenprüfung.

Beginnen Sie mit einer Prüffrage für jeden Scorecard-Bereich. Weisen Sie den Agenten an, die Anforderung zu identifizieren, die verfügbaren Nachweise zu zitieren und eventuelle Abweichungen aufzuzeigen. Ein Verarbeitungsvertrag beschreibt womöglich die beabsichtigte Aufbewahrungsfrist, während der Testbericht des Administrators das tatsächlich beobachtete Löschverhalten dokumentiert. Halten Sie diese Nachweistypen klar getrennt. Eine überzeugende Zusammenfassung darf eine Absichtserklärung niemals als nachgewiesenes Ergebnis darstellen.

Erstellen Sie anschließend zwei Dokumente: ein kurzes Entscheidungs-Briefing für den CISO und eine Nachweismatrix für die Kontrollverantwortlichen. Das Briefing sollte Release-Blocker und offene Abhängigkeiten priorisieren. Die Matrix sollte Quellverweise, die getestete Konfiguration, den Verantwortlichen und die nächste Maßnahme festhalten. Unser Recherche- und Artefakt-Workflow ermöglicht es Teams, die referenzierte Analyse in unterschiedlichen Dokumenten wiederzuverwenden, während Prüfer sicherstellen, dass wesentliche Einschränkungen auch in der Kurzfassung erhalten bleiben.

Sofern die angebundenen Werkzeuge dies zulassen, kann eine assistierte Automatisierung eine Folgeaufgabe für den zuständigen Bearbeiter vorbereiten. Ein Zugriffstest ohne dokumentierten Berechtigungsentzug führt dann beispielsweise zu einer Nachforderung des Tests – nicht zu einem vorschnellen Urteil über eine gescheiterte Kontrolle. Der Prüfer bestätigt die vorgesehene Zuweisung und das Ziel vor dem Schreibzugriff im Zielsystem.

Dieser Ansatz weist Nouswise eine konkrete Rolle bei der Sicherheitsbereitschaft zu: Wir stellen die Recherche- und Integrationsfunktionen bereit; das Team nutzt sie, um Nachweise schneller zusammenzustellen, zu prüfen und weiterzuverarbeiten. Die Bewertung der Bereitschaft bleibt dabei stets an die dokumentierten Testergebnisse gebunden.

Geben Sie dem Prüf-Agenten einen präzisen Auftrag

Prüfe die freigegebenen Nachweise des KI-Dienstes anhand der Sieben-Bereiche-Scorecard. Zitiere für jede Anforderung das Belegmaterial, klassifiziere die Nachweisstufe und benenne fehlende Angaben. Leite aus einer bloßen Richtlinie keinen erfolgreichen Test ab. Erstelle ein CISO-Entscheidungs-Briefing sowie eine separate Maßnahmenliste für die Verantwortlichen. Hebe eventuelle Blocker hervor, bevor Folgemaßnahmen vorgeschlagen werden.

Betrachten Sie das Ergebnis als Bewertungsvorschlag, bis die Kontrollverantwortlichen die Nachweisstufen final bestätigt haben. Dies ist besonders wertvoll, wenn das Quellenmaterial mehrere Dienstleister oder unterschiedliche Versionen desselben Konzepts umfasst.

Fordern Sie eine Demonstration bei Berechtigungsänderungen ein

Eine statische Demonstration mit einem einzigen berechtigten Benutzer blendet eine zentrale operative Fragestellung aus: Was passiert, wenn sich Bedingungen ändern?

Erstellen Sie einen kleinen, kontrollierten Testdatenbestand mit einem Standarddokument, einem vertraulichen Dokument mit synthetischen Testdaten und einer Quelle, die deaktiviert werden kann. Prüfen Sie dies mit mindestens zwei Benutzerrollen.

1. Bestätigen Sie, dass die berechtigte Rolle die freigegebenen Informationen abrufen kann.

2. Bestätigen Sie, dass die unberechtigte Rolle diese weder über Abfragen, Zusammenfassungen, Zitate, Titel noch über Artefakte erlangen kann.

3. Entziehen Sie der berechtigten Rolle den Zugriff und wiederholen Sie die relevanten Abfragen.

4. Sperren oder entfernen Sie die Quelle und überprüfen Sie den Abruf, zwischengespeicherte Antworten und bestehende Ausgabeformate.

5. Dokumentieren Sie die Propagierungszeit der Änderung sowie etwaiges Übergangsverhalten.

Historische Datensätze erfordern im Hinblick auf die Aufbewahrung unter Umständen eine andere Behandlung als tagesaktuelle Antworten. Definieren Sie dieses Vorgehen eindeutig; gehen Sie nicht davon aus, dass eine Zugriffsänderung rückwirkend jeden zuvor erstellten Bericht bereinigt.

Bewerten Sie die Abhängigkeiten des realen Workflows – einschließlich des Datenflusses nach der Informationsgenerierung.

Demonstrieren Sie dieses Verhalten bei einer Nouswise-Implementierung in der gewählten Zielumgebung und den angebundenen Repositories. Stimmen Sie die betrieblichen Verantwortlichkeiten mit unserem Enterprise-Team ab und halten Sie die tatsächlichen Testergebnisse im Workbook fest. Trennen Sie vorgegebene Soll-Konzepte klar von beobachteten Ist-Ergebnissen, damit nachfolgende Prüfer beide Aspekte auditieren können.

Verstehen Sie Prompt-Injection-Resistenz als Systemeigenschaft

Ein Dokument oder eine Tool-Rückmeldung kann Textbausteine enthalten, die wie Systemanweisungen formuliert sind. Ihr Vorhandensein im Modellkontext macht sie jedoch nicht zu einem autorisierten Befehl.

Der AgentDojo-Forschungs-Benchmark evaluiert werkzeugbasierte Agenten im Umgang mit nicht vertrauenswürdigen Daten und potenziell bösartigen Eingaben. Er zeigt zugleich, dass reguläre Aufgaben auch ganz ohne Angriffe fehlschlagen können. Daraus ergeben sich zwei Kernfragen: Wurde die legitime Aufgabe erfolgreich ausgeführt, und hat der Workflow seine Sicherheitsgrenzen eingehalten?

Entwickeln Sie kontrollierte Testszenarien rund um den genehmigten Aufgabenbereich des Dienstes: Ein Recherchedokument könnte die Anweisung enthalten, eine andere Datensammlung offenzulegen; ein Tool-Ergebnis könnte ein unautorisiertes Update anfordern. Überprüfen Sie, ob dieser Text den Informationszugriff oder Handlungsspielraum beeinflusst. Nutzen Sie dafür synthetische Daten und freigegebene Testkonten.

Eine Anwendung darf sich nicht allein darauf verlassen, dass das Sprachmodell jede bösartige Anweisung zuverlässig erkennt. Repository-Berechtigungen, Werkzeug-Geltungsbereiche, serverseitige Validierungen, Zielbeschränkungen und aufgabenspezifische Freigaben bilden zusätzliche Sicherheitsebenen. Deren Konfiguration muss explizit geprüft werden – eine reine Begutachtung der Prompts reicht nicht aus.

Prüfen Sie den Ausführungspfad ebenso wie die Nachweisdokumentation

Sobald eine Automatisierung Werkzeuge einsetzen kann, ist eine korrekte Sicherheitszusammenfassung nur ein Teilkriterium für die Abnahme. Prüfen Sie, ob eine vorgeschlagene Aktion im Rahmen der Autorisierung der Aufgabe bleibt. Unsere Tools- und MCP-Dokumentation beschreibt Genehmigungsanfragen und Tool-Ereignisse, die eine integrierende Anwendung ihren Nutzern transparent anzeigen kann.

Ergänzen Sie die Scorecard um eine gezielte Auswahl an handlungsbasierten Testszenarien:

Diese Tests erbringen unterschiedliche Nachweise: Ein Genehmigungsereignis belegt eine Interaktion innerhalb der Anwendung. Ein Protokoll im Zielsystem belegt ein externes Resultat. Sichern Sie beide Nachweise, wo immer der Ablauf dies vorsieht. Verlassen Sie sich niemals auf den Bericht eines Assistenten über einen angeblich erfolgreichen Abschluss, sondern prüfen Sie die tatsächliche Systemquittung.

Die Anwendung sollte zudem sauber zwischen einer verweigerten Operation und einem Systemfehler unterscheiden. Wenn ein Benutzer eine Aufgabe bewusst ablehnt, ist das ein reguläres Verhalten. Wenn eine Operation trotz Ablehnung unbemerkt fortgesetzt wird, ist das ein Release-Blocker. Diese Differenzierung macht die CISO-Scorecard deutlich aussagekräftiger als eine bloße Erfolgsquote ausgeführter Vorgänge.

Führen Sie eine Simulation für ein plausibles Ausfallszenario durch

Vorgeschlagenes Szenario: Das Richtlinien-Repository ist während einer dringenden Rechercheaufgabe nicht erreichbar. Dies ist ein Prüfszenario, kein realer Kundenstörfall.

Der Dienst sollte fehlende Daten transparent kommunizieren und deren Auswirkungen auf die Antwort darlegen. Prüfen Sie, ob klar zwischen einem Teilergebnis und einer vollständigen Analyse unterschieden wird. Eine wohlformulierte Antwort, die das Fehlen der Datenbasis stillschweigend übergeht, stellt ein ernstes Qualitäts- und Betriebsrisiko dar.

Stellen Sie anschließend einen validierten Zustand des Datenbestands wieder her. Prüfen Sie Quellversionen, Berechtigungen, Testantworten und ob das Betriebsteam die Wiederherstellung nachvollziehbar erklären kann. Falls schreibende Werkzeuge aktiviert sind, simulieren Sie ein unklares Verbindungs-Timeout und prüfen Sie, ob das Zielsystem die Operation vor einem erneuten Versuch bereits erfasst hat.

Eine Wiederherstellung ist erst dann abgeschlossen, wenn der Wissensstand, die Berechtigungen und das Workflow-Verhalten nachweislich verifiziert wurden.

Nutzen Sie Nouswise während der Übung, um aus genehmigten Runbooks und Testnotizen ein belegtes Incident-Briefing zu erstellen. Wenden Sie unseren Leitfaden für Knowledge Ops an, um Quellenzuständigkeiten und Prüfprozesse transparent zu halten. Das Incident-Briefing sollte klar die Systeme und Teams benennen, die für die tatsächlichen Wiederherstellungskontrollen zuständig sind.

Passen Sie die Bewertung an das Einsatzszenario an

Interne Richtlinien- und Compliance-Recherche: Priorisieren Sie verbindliche Versionen, die strikte Isolierung vertraulicher Quellen, Nachweisvollständigkeit und Eskalationspfade, sobald Fachurteile erforderlich sind. Testen Sie gezielt plausible, aber veraltete Anweisungen – nicht nur offensichtlich unpassende Quellen.

Kundenservice-Assistenten: Prüfen Sie Mandanten- und Kundentrennung, den Zugriff auf Kontodaten und ob Entwürfe unkontrolliert nach außen gelangen können. Erfassen Sie sowohl Fehler, die einem menschlichen Prüfer entgehen, als auch Vorschläge, die korrigiert werden müssen.

Sicherheits- und Incident-Analyse: Behandeln Sie Vorfallsberichte und Zugangsdaten als hochsensible Eingaben. Trennen Sie generierte Lageberichte strikt von der Berechtigung, Endpunkte zu isolieren, Konfigurationen zu ändern oder externe Benachrichtigungen auszulösen.

Diese Anwendungen bergen völlig unterschiedliche Risiken. Ein einheitlicher, unternehmensweiter Score verwischt diese Unterschiede. Nutzen Sie die Methode wiederkehrend, aber behalten Sie anwendungsspezifische Blocker bei.

Etablieren Sie die Scorecard als kontinuierlichen Prüfprozess

Ein System verändert sich nach dem Go-Live: Ein neues Repository, erweiterte Werkzeugberechtigungen, angepasste Verarbeitungsverträge oder neue Zielgruppen können vorangegangene Freigaben hinfällig machen. Jede wesentliche Änderung erfordert einen definierten Prüfprozess.

Teams können ihr bestehendes Change-Management-System nutzen, um automatisierte Anfragen an die Nouswise Responses API zu stellen. Übergeben Sie den geänderten Umfang und den freigegebenen Vorab-Stand; fordern Sie einen referenzierten Abgleich an, der aufzeigt, was sich geändert hat, welche Nachweise weiter gültig sind und wo Nachtests erforderlich sind. Die API liefert die strukturierte Auswertung; die umgebende Systemlandschaft steuert Auslöser, Protokollierung und Verteilung.

Vermeiden Sie es, das gesamte Audit von vorn zu beginnen, wenn sich nur eine einzelne Abhängigkeit geändert hat. Wird der Geltungsbereich eines Konnektors erweitert, prüfen Sie gezielt die betroffenen Zugriffs- und Handlungstests. Korrigiert ein Richtlinienverantwortlicher eine Quellenbeschreibung, untersuchen Sie die daraus resultierenden Aussagen und Zitate. Die Automatisierung legt die betroffenen Bereiche offen, sodass Experten ihren Fokus auf folgenschwere Entscheidungen richten können.

Messen Sie den Zeitgewinn bei der Nachweisaufbereitung, die Zahl geklärter offener Fragen und die Reaktionszeit, bis eine wesentliche Änderung den zuständigen Prüfer erreicht. Dokumentieren Sie zugleich unbelegte Schlussfolgerungen und übersehene Blocker. Diese Kennzahlen belegen, ob der Prüfprozess an Reife gewinnt – ohne dass reine Nutzungszahlen fälschlicherweise als Sicherheitsbeleg herangezogen werden.

Sorgen Sie für eine nachvollziehbare Freigabeentscheidung

Ein CISO muss anhand eines kompakten Freigabeprotokolls folgende Fragen unmittelbar beantworten können:

• Was genau wird freigegeben – für wen, mit welchen Quellen und welchen Werkzeugen?

• Welche kritischen Kontrollmechanismen wurden in der Produktivumgebung nachgewiesen?

• Welche Schwachstellen oder Restrisiken verbleiben, und wer hat diese formell akzeptiert?

• Welche Ereignisse lösen eine Neubewertung, Aussetzung oder ein Rollback aus?

• Wer übernimmt die Betriebsverantwortung, wenn das ursprüngliche Pilot-Team nicht verfügbar ist?

Verfolgen Sie offene Hochrisiko-Lücken, wiederkehrende Kontrollfehler, Incident-Zuständigkeiten und Wiederherstellungszeiten anhand der vereinbarten Anforderungen. Vermeiden Sie es, Adoption, flüssige Formulierungen oder unkalibrierte Modellwerte als Nachweis für Informationssicherheit zu werten.

Der nächste praxisnahe Schritt ist eine fokussierte Pilotprüfung. Bringen Sie Ihren Workflow, den Datenbestand und die Testfälle in ein Fachgespräch mit Nouswise Enterprise ein und evaluieren Sie die gesamte Kette von der Recherche bis zur Ausgabe – fundiert statt über pauschale Sicherheitsaussagen.

Häufig gestellte Fragen (FAQ)

Was unterscheidet KI-Sicherheitsreife von Modellgenauigkeit?

Genauigkeit bezieht sich auf die inhaltliche Qualität einer Antwort. Sicherheitsreife umfasst darüber hinaus Informationszugriff, Offenlegungspfade, Systemabhängigkeiten, Werkzeugnutzung, Überwachung und Wiederherstellung. Eine fachlich korrekte Antwort kann dennoch vertrauliche Daten verletzen.

Sollte jeder Bereich eine numerische Bewertung erhalten?

Nicht zwingend. Deskriptive Nachweisstufen und explizite Freigabeblocker bieten oft mehr Aussagekraft als Zahlenwerte, die eine Scheingenauigkeit vortäuschen. Wird ein Punktesystem genutzt, muss dessen Aussagegehalt klar definiert sein – und verhindert werden, dass gravierende Mängel im Durchschnitt untergehen.

Eliminiert quellengestützte KI das Risiko von Prompt Injections?

Nein. Die Quellengestütztheit („Grounding“) liefert Belege, doch die Quellen selbst können schadhafte Anweisungen enthalten. Entscheidend ist die Frage, wie das Gesamtsystem nicht vertrauenswürdige Inhalte von autorisierten Operationen trennt.

Wann muss die Prüfung wiederholt werden?

Nach wesentlichen Änderungen am Einsatzzweck, der Quellensensibilität, den Berechtigungen, den Modellen, den Schnittstellen oder dem Handlungsspielraum sowie nach relevanten Sicherheitsvorfällen. Die Validierung muss stets an die reale Konfiguration gebunden bleiben.

Was kann Nouswise bei einer Sicherheitsprüfung automatisieren?

Die Erfassung von Belegen aus freigegebenen Quellen, Soll-Ist-Abgleiche, referenzierte Bewertungsentwürfe, Maßnahmenlisten für Verantwortliche und angebundene Folgeaufgaben. Nutzen Sie unseren Workflow-Auswahlleitfaden zur Definition des passenden Umfangs; die operative Testdurchführung und die formelle Freigabekompetenz verbleiben stets bei den zuständigen Fachverantwortlichen.

Weiterführende Artikel von Nouswise

• Verantwortlichkeit und Wiederherstellung bei KI-Agenten

• Quellengestützte Recherche und agentische Workflows

• Knowledge Operations und gepflegte Datenquellen