TL; DR
Inzwischen fragt jeder Vorstand nach den Risiken der künstlichen Intelligenz, und die meisten Sicherheitsteams antworten mit Adjektiven statt mit Zahlen. Die Governance-Rahmenwerke geben vor, was zu regeln ist. Sie sagen Ihnen nicht, was zu berücksichtigen ist. Diese KI-Risikokennzahlen stammen alle aus derselben Quelle: dem Code, den Ihr Unternehmen bereits ausliefert.
- Eine agentenbasierte KI-Strategie besteht aus drei Schichten, von denen nur eine das Modell ist. Was der Agent schreibt, womit er verbunden ist und welche Daten er abruft. Die meisten Programme messen das erste und ignorieren die beiden anderen.
- Der Explosionsradius ist im Modell nicht enthalten. Es befindet sich in der Skill-Datei, der MCP-Konfiguration, dem Werkzeugbereich und den Anmeldeinformationen, unter denen der Agent ausgeführt wird. Eine saubere Modellevaluierung und ein Agent mit übermäßigen Berechtigungen können problemlos nebeneinander existieren.
- Neun KI-Risikokennzahlen, jede einzelne eine Zahl und kein Adjektiv. Nicht genehmigte KI-Assets, prompte Injektionspfade, die zu einem Tool-Senke führen, Geheimnisse in
.mcp/servers.json, vom Agenten hinzugefügte Abhängigkeiten, die vor dem Vorhandensein einer Signatur gekennzeichnet wurden. - Wenn Sie diese Zahl in diesem Quartal nicht erreichen können, liegt das Problem nicht an der Kennzahl. Die Inventur ist abgeschlossen. Beginnen Sie mit drei Zählungen, nicht mit einem Programm.
Was bedeutet KI-Risiko konkret, wenn man selbst die Software ausliefert?
Fragt man zehn Personen, was KI-Risiko bedeutet, erhält man zehn Antworten. Modellverzerrung. Halluzinationen. Datenlecks. Regulatorische Risiken. Arbeitsplatzverlust. Alles real, alles beachtenswert, und keine dieser Gefahren lässt sich von einem Sicherheitsteam an einem Dienstagnachmittag beantworten.
Es gibt eine engere Version der Frage, die ein Sicherheitsteam tatsächlich beantworten kann: Welche KI läuft in der von uns entwickelten Software, worauf kann sie zugreifen und was passiert, wenn jemand sie manipuliert? Diese Version enthält eine Antwort, und die Antwort befindet sich in Ihren Repositories und pipelineeher in einem Strategiepapier als in einem Grundsatzdokument.
Dies ist die Art von KI-Risiko, um die es in diesem Beitrag geht. Nicht, weil die Governance-Fragen irrelevant wären, sondern weil sie erst beantwortet werden können, wenn diese Frage geklärt ist. Ein Rahmenwerk fordert Sie auf, Ihre KI-Systeme zu inventarisieren. Es sagt Ihnen aber nicht, dass sich das Inventar in einem .mcp/servers.json Datei, die seitdem niemand mehr geöffnet hat committed.
Warum messen die meisten KI-Risikoprogramme das Falsche?
Es gibt drei Fehlermuster, und die meisten Organisationen weisen mindestens zwei davon auf.
- Messung der Akzeptanz statt der Bekanntheit. „72 % unserer Entwickler nutzen KI-Tools“ ist eine Produktivitätskennzahl, die als Sicherheitskennzahl getarnt ist. Sie sagt nichts darüber aus, was diese Tools leisten können.
- Das Modell statt des Systems messen. Das Red-Teaming eines Endpunkts beantwortet die Frage, ob ein Modell dazu gebracht werden kann, etwas Falsches auszugeben. Es beantwortet jedoch nicht die Frage, was als Nächstes geschieht, da der Wirkungsbereich vom Werkzeug, den Anmeldeinformationen des Agenten und den zugehörigen Konfigurationsdateien abhängt. Eine unvoreingenommene Modellevaluierung und ein Agent mit extrem überprivilegierten Rechten können problemlos nebeneinander existieren.
- Messen, was leicht zu zählen ist. Anzahl der veröffentlichten KI-Richtlinien. Anzahl der Mitarbeiter, die eine KI-Schulung absolviert haben. Diese Zahlen steigen zuverlässig an und korrelieren mit nichts.
Das NIST AI Risk Management Framework Es wird ausdrücklich darauf hingewiesen, dass Messung neben Steuerung, Kartierung und Management eine seiner vier Kernfunktionen ist. Der Rahmen ist bewusst ergebnisorientiert und nicht vorschreibend, was für ein standard und am Dienstag wenig hilfreich. Man muss immer noch entscheiden, was man mitzählt.
Welche KI-Risikokennzahlen sagen tatsächlich etwas aus?
Neun Kennzahlen. Jede einzelne ist eine Zahl, jede einzelne ändert sich mit der Änderung Ihrer Exposition, und jede einzelne kann aus Code anstatt aus einer Umfrage generiert werden.
| Metrisch | Warum es wichtig ist | Woher kommt diese Zahl? |
|---|---|---|
| 01Entdeckte KI-Assets insgesamt und die Veränderung seit dem letzten Monat | Man kann keine KI-Risiken bewerten, die man nie erfasst hat. Der Trend ist wichtiger als die absolute Zahl. | Kontinuierliche Erkennung von Modellen, Frameworks, Datensätzen, Inferenzendpunkten, Agenten, MCP-Servern, Fähigkeiten und KI-Programmierwerkzeugen |
| 02Nicht genehmigte KI-Assets als Prozentsatz des Gesamtbetrags | Dies ist Ihre Schatten-KI-Risikorate. Sie ist die am häufigsten zitierte Kennzahl für das KI-Risiko im Vorstand. | Der Genehmigungsstatus wird für jedes Asset im Hinblick auf Ihre Richtlinie verfolgt. |
| 03KI-Assets ohne benannten Eigentümer | Ein Vermögenswert, der niemandem gehört, ist ein Vermögenswert, den niemand reparieren wird. Üblicherweise die unansehnlichste Zahl in der Menge. | Die Eigentumsverhältnisse wurden dem Vermögenswert zugeordnet. |
| 04Schnelle Injektionspfade, die eine Werkzeugsenke erreichen | Nicht vertrauenswürdige Eingaben, die eine Systemabfrage erreichen, sind nur dann relevant, wenn sich am anderen Ende etwas Gefährliches befindet. | KI-Risikoerkennung abgebildet auf OWASP Top 10 für LLM-Bewerbungen |
| 05Im Einsatz befindliche MCP-Server und wie viele davon Ergebnisse enthalten | Die MCP-Konfiguration ist der Ort, an dem der Agent seine Befehle entgegennimmt. Hier werden auch die Anmeldeinformationen gespeichert. | Die MCP-Serverkonfiguration wurde als Sicherheitsartefakt analysiert. |
| 06Geheimnisse in KI-Konfigurationsdateien | Untersuchungen aus dem Jahr 2026 ergaben, dass über 24,000 Geheimnisse in MCP-Konfigurationsdateien auf öffentlichem GitHub gespeichert sind, von denen mehr als 2,000 noch gültig sind. | Geheimniserkennung über Code, Konfigurationen, Container und pipelines |
| 07Vom Agenten hinzugefügte Abhängigkeiten wurden vor dem Vorhandensein einer öffentlichen Signatur gekennzeichnet | Agenten ziehen Pakete schnell ab, und der Name, den Ihr Modell erfunden hat, ist eine leicht angreifbare Angriffsfläche. | Frühwarnung vor Malware, Beweiserkennung mit anschließender KI-Validierung |
| 08Anteil der KI-Ergebnisse, die erreichbar sind und aktiv weiterentwickelt werden | Trennt den unerledigten Arbeitsrückstand von der Arbeit, die Ihre Perspektive verändert. | Der KI-Priorisierungstrichter |
| 09Prozentsatz der vom Agenten verfassten pull requests verschmolzen mit einer menschlichen Zustimmung | Die Kennzahl für gute Unternehmensführung, die eine Aufsichtsbehörde fordern wird, die aber niemand verfolgt. | Pull request Analyse und Zulassungstore |
Wenn Sie nur eine Kennzahl heranziehen, dann nehmen Sie Kennzahl 02. Das Verhältnis von nicht genehmigten zu gesamten KI-Assets ist diejenige Zahl, die auch nach der Übertragung vom Sicherheitsteam in ein Audit noch relevant ist. commitEs ist ein Tee, und es bewegt sich, wenn man tatsächlich etwas tut.
Was muss eine agentenbasierte KI-Strategie abdecken?
Drei Ebenen. Der Fehler, den fast jeder macht, ist, mit der ersten Ebene anzufangen und dort aufzuhören.
- Ebene eins: was der Agent schreibt. Generierter Code weist dieselben Sicherheitslücken auf wie von Menschen geschriebener Code, und Studien seit 2022 belegen immer wieder, dass ein erheblicher Anteil KI-generierter Programme Sicherheitsmängel enthält. Diese Ebene ist uns am vertrautesten, weshalb sie auch die größte Aufmerksamkeit auf sich zieht.
- zweite Ebene: Womit der Agent verbunden ist. Skilldateien, Regeldateien, MCP-Serverkonfigurationen, Tool-Bereiche, die Anmeldeinformationen, unter denen der Agent ausgeführt wird. Diese Ebene bestimmt, wie weit ein erfolgreicher Angriff reicht, und ist für alles, was das Modell über seinen Endpunkt testet, unsichtbar. MITRE ATLAS Dieser Sachverhalt wird direkt dokumentiert: Die Fallstudie zur Rules File Backdoor, AML.CS0041, beschreibt Nullbreitenzeichen in einer Regeldatei, die Dokumentation in Anweisungen umwandeln, denen ein Agent stillschweigend folgt. Ein Gutachter, der die pull request sieht nichts.
- dritte Ebene: was der Agent einbezieht. Abhängigkeiten, Modelle, Datensätze, externe Tools. Eine auf der USENIX Security 2025 vorgestellte Studie generierte 2.23 Millionen Codebeispiele in 16 Modellen und stellte fest, dass 19.7 % der empfohlenen Pakete nicht existierten. Dabei entstanden über 205,000 einzigartige, erfundene Namen. Angreifer müssen nicht länger einen Maintainer kompromittieren. Sie registrieren einfach den von Ihrem Agenten generierten Namen und warten.
Eine agentenbasierte KI-Strategie, die nur die erste Ebene abdeckt, erzeugt einen fehlerfreien Bericht und ein unverändertes KI-Risikoprofil. OWASP Top 10 für LLM-Bewerbungen spiegelt dies in seiner eigenen Struktur wider: Übermäßige Handlungsfähigkeit steht ganz oben auf der Liste.cisEs liegt wahrscheinlich daran, dass es sich um ein Verkabelungsproblem handelt, nicht um ein Modellproblem.
Wie lässt sich das umsetzen, ohne die Agenten zu verlangsamen?
Der Instinkt ist, alles zu sperren. Das scheitert, weil der Hauptzweck des Agenten im Durchsatz liegt, und eine Kontrollmaßnahme, die den Durchsatz halbiert, wird innerhalb eines Vierteljahres wieder entfernt.
Drei bewährte Umsetzungsprinzipien:
- Kontinuierlich messen, selektiv steuern. Alle neun KI-Risikometriken können bei jedem Scan erfasst werden, ohne dass dadurch etwas blockiert wird. Harte Sicherheitsabfragen sollten nur für die wenigen Fälle reserviert werden, in denen ein Fehler nicht behoben werden kann: eine bösartige Abhängigkeit, ein sensibles Geheimnis oder ein nicht genehmigtes Modell, das regulierte Daten verarbeitet.
- Platzieren Sie die Sicherheit dort, wo sich der Agent bereits befindet. Ein über MCP verbundener Agent ruft während der Generierung von Code die Sicherheitsplattform auf, scannt den neu geschriebenen Code und optimiert ihn, bis er die festgelegten Schwellenwerte erfüllt. In dieser Phase ist kein menschlicher Eingriff erforderlich, und es muss keine Software auf dem System installiert werden, auf dem der Agent ausgeführt wird. Dies ist der einzige Eingriffspunkt, der mit dem Durchsatz des Agents skaliert, anstatt gegen ihn.
- Bewahre den Menschen im Mittelpunkt pull request. Alles, was in den Produktionscode gelangt, wird von einer Person freigegeben. Dies ist keine Vorsichtsmaßnahme, sondern entspricht der Designvorgabe, die die EU-KI-Richtlinie ohnehin vorgibt. Es ist deutlich kostengünstiger, dies von Anfang an zu berücksichtigen, als es unter Prüfungsdruck nachträglich anzupassen. Es handelt sich außerdem um Kennzahl 09, weshalb es sich lohnt, diese Kennzahl vom ersten Tag an zu erfassen.
Die zweite Zeile bleibt in den meisten Organisationen unbesetzt. Konfigurationsdateien fallen in die Lücke zwischen Anwendungssicherheit, die sie als Infrastruktur betrachtet, und Plattformentwicklung, die sie als Dokumentation einstuft. Genau in dieser Lücke lauern die interessantesten Angriffsziele.
Wie beginnen Sie in diesem Quartal mit der Messung des KI-Risikos?
Erstellen Sie nicht das vollständige Programm. Ermitteln Sie drei Zahlen. Zählen Sie Ihre KI-Ressourcen. Zählen Sie, wie viele davon niemand genehmigt hat. Zählen Sie, wie viele Geheimnisse in KI-Konfigurationsdateien verborgen sind. Diese drei Zahlen passen auf eine Folie; sie sind alle vertretbar und werden schlimmer sein, als derjenige erwartet, der sie angefordert hat.
Wählen Sie dann den Fehler mit dem größten Problem aus und beheben Sie ihn vor der nächsten Vorstandssitzung. Das ist ein funktionierendes KI-Risikomanagementprogramm. Alles andere ist Ausarbeitung.
Die Organisationen, die 2027 mit KI-Risiken zu kämpfen haben werden, sind nicht diejenigen, die schnell gehandelt haben. Es sind diejenigen, die 2026 KI-Richtlinien verfasst, deren Wirksamkeit aber nie gemessen wurde. Eine Richtlinie, deren Wirksamkeit nicht messbar ist, ist nur ein Dokument. KI-Risikokennzahlen sind das, was sie zu einem Kontrollinstrument macht.
Sehen Sie sich Ihre eigenen Zahlen an. Verbinden Sie ein Repository, und Xygeni liefert Ihnen Ihr KI-Inventar, die nicht genehmigten Assets, die den von Ihren Prüfern verwendeten Frameworks zugeordneten Risiken sowie eine KI-Stückliste, die Sie exportieren können. Kostenlos starten or Demo buchen.
FAQ
Worin besteht der Unterschied zwischen KI-Risiko und KI-Sicherheit?
KI-Sicherheit bezieht sich hauptsächlich auf das Verhalten eines Modells: ob es sich wie vorgesehen verhält, ob seine Ergebnisse schädlich sind und ob es manipuliert werden kann, sodass es etwas ablehnt, was es eigentlich ablehnen sollte. KI-Risiko im Sicherheitskontext hingegen beschreibt, welche Auswirkungen ein kompromittiertes oder fehlerhaftes KI-System auf Ihre Umgebung haben kann. Die beiden Bereiche überschneiden sich zwar, werden aber von unterschiedlichen Teams betreut und mit verschiedenen Instrumenten gemessen. Ein Sicherheitsteam kann bereits heute Maßnahmen gegen das zweite Risiko ergreifen.
Wie viele KI-Risikokennzahlen sollten wir dem Vorstand berichten?
Drei bis fünf. Ein Vorstand kann nicht auf Basis von neun Zahlen handeln, und eine Präsentation mit neun Zahlen neigt dazu, die entscheidende zu verdecken. Berichten Sie über Ihre gesamte Anzahl an KI-Assets, den Anteil der nicht genehmigten Assets und eine Kennzahl zur Auswirkung auf die KI-Entwicklung, z. B. erreichbare KI-Ergebnisse in aktiver Entwicklung. Bewahren Sie die übrigen Daten für die operative Überprüfung auf.
Brauchen wir eine KI-basierte Stückliste, wenn es noch keine gesetzliche Vorschrift dafür gibt?
Derzeit gibt es keine gesetzliche Vorschrift, die eine KI-BOM vorschreibt. Genau deshalb ist ihre Erstellung momentan günstig, später aber teuer. Es existieren zwei maschinenlesbare Formate, die von einem Auditor akzeptiert werden. Der Wert liegt nicht in der Einhaltung von Vorschriften, sondern darin, dass die Erstellung der Datei die Bestandsaufnahme erzwingt. Und genau auf dieser Bestandsaufnahme basiert jede KI-Risikokennzahl.
Unsere Entwickler nutzen KI-Tools, die wir nie genehmigt haben. Wo fangen wir an?
Zählen Sie, bevor Sie Maßnahmen ergreifen. Eine Richtlinie gegen Tools anzukündigen, die Sie nicht einsehen können, treibt deren Nutzung in den Untergrund und zerstört die notwendige Transparenz. Führen Sie zunächst eine Bedarfsanalyse durch, veröffentlichen Sie die Ergebnisse intern ohne Namensnennung und nutzen Sie diese, um eine Liste genehmigter Tools zu erstellen, die den tatsächlichen Bedürfnissen der Nutzer entspricht. Maßnahmen sind deutlich effektiver, wenn sie auf Fakten basieren, als wenn sie ihnen vorausgehen.
