Kennzahlen und Reporting | STOP.LI

STOP.LI · AI Security · Governance

KennzahlenKI-Sicherheit messen und berichten.

Wer KI-Sicherheit berichtet, muss zuerst sagen, was sich nicht messen lässt. Die Seite bietet ein Kennzahlenset mit Definition und Nachweis, Frühwarnindikatoren mit Schwellen, ein Beispiel-Befundregister, eine Berichtsseite «KI-Lagebild» für Geschäftsleitung und Verwaltungsrat mit ausgefülltem Beispiel sowie eine Evidenzliste für die Revision. Alle Zielwerte und Beispieldaten sind erfunden.

Rechtsstand: 12. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar. Zielwerte und Schwellen sind Beispiele und aus dem eigenen Risikoappetit abzuleiten.

ISMS-Prozess: 01 Steuerung · 24 Wirksamkeit
Messprobleme

Was sich nicht
messen lässt.

Das NIST AI RMF (AI 100-1, Abschn. 1.2.1) benennt Messprobleme ausdrücklich. Was nicht gemessen wird, ist deshalb weder hoch noch tief, sondern unbekannt: Die Unmöglichkeit, ein KI-Risiko zu messen, sagt nichts darüber, wie hoch es ist. Für das Reporting heisst das: Lücken offen ausweisen, statt sie mit einer Zahl zu füllen. MEASURE 1.1 sieht vor, nicht messbare Risiken zu dokumentieren. Das NIST AI RMF warnt ausserdem, dass Messansätze zu stark vereinfacht oder gezielt ausgenutzt werden können und dass sich Beteiligte unerwartet auf sie verlassen.

Goodhart-Effekt

Wird eine Kennzahl zum Ziel, verliert sie ihre Aussagekraft: Menschen richten ihr Verhalten auf den Wert aus statt auf das, was er anzeigen sollte. Der Effekt ist nach dem Ökonomen Charles Goodhart benannt, die verbreitete Kurzform stammt von Marilyn Strathern. Beispiele: Soll die Zahl der Vorfälle sinken, werden weniger Vorfälle gemeldet. Soll der Anteil offener Befunde sinken, werden Befunde vorschnell geschlossen oder tiefer eingestuft. Soll das Inventar zu 100 % stimmen, werden Systeme ohne geklärten Owner eingetragen. Soll der Test bestanden werden, wählt das Team einfache Testfälle.

Dagegen helfen Kennzahlen im Paar (Menge und Qualität, zum Beispiel geschlossene Befunde und Anteil bestandener Nachprüfungen), Stichproben durch eine unabhängige Stelle, dokumentierte Änderungen der Definitionen und der Verzicht darauf, Zielwerte an die persönliche Vergütung zu koppeln. Das sind fachliche Empfehlungen von STOP.LI.

Gründe

Warum es
so ist.

Die Messgrenzen haben Ursachen. Wer sie kennt, kann im Bericht begründen, warum eine Zahl fehlt oder nur mit Vorbehalt gilt.

Grund Was dahintersteckt Folge für das Reporting
Probabilistisches Verhalten Dieselbe Eingabe kann unterschiedliche Ausgaben ergeben. Ein Test zeigt ein Verhalten, nicht alle möglichen. Das NIST AI RMF nennt inhärente Unsicherheiten von KI-Systemen als Quelle von Intransparenz. Ergebnisse als Häufigkeit mit Anzahl Versuchen angeben, nicht als «bestanden».
Fehlende Grundgesamtheit und Basisrate Die Zahl aller Angriffsversuche, Fehlausgaben oder nicht gemeldeten KI-Nutzungen ist unbekannt. Gemessen wird nur, was erkannt wird. «Keine Vorfälle» kann heissen: keine bemerkt. Wo KI Menschen ersetzt, fehlt zudem ein Vergleichswert (NIST: Human baseline). Erkannte Fälle nie als Anteil «aller» Fälle darstellen; Erkennungsfähigkeit als eigene Aussage ausweisen.
Unbekanntes bleibt unbekannt Neue Angriffsarten und Fehlerbilder lassen sich erst messen, wenn jemand sie kennt. Das NIST AI RMF empfiehlt, neu auftretende Risiken zu erkennen, zu verfolgen und Techniken zu ihrer Messung zu erwägen (Tracking emergent risks). Szenarioübungen und externe Lageberichte ergänzen die Zahlen.
Testabdeckung ist nicht Sicherheit Eine Quote getesteter Systeme sagt, dass geprüft wurde, nicht dass das System sicher ist. Ein Test findet nur, wonach gesucht wird. Labormessungen weichen zudem von Risiken im Betrieb ab (NIST: Risk in real-world settings). Abdeckung und Befunde zusammen berichten; Testumfang und Methode nennen.
Verzögerte Schäden Manche Risiken sind zum Zeitpunkt der Messung latent und wachsen, wenn sich das System verändert (NIST: Risk at different stages of the AI lifecycle). Vergiftete Daten oder schleichender Qualitätsverlust zeigen sich spät. Frühindikatoren (KRI) und Drift-Überwachung statt nur Schadenszahlen; Messung in festen Abständen wiederholen.
Kontextabhängigkeit Dasselbe Modell hat je nach Aufgabe, Daten und betroffenen Personen andere Risiken. Das NIST AI RMF hält fest, dass der Kontext zählt und Schäden Gruppen unterschiedlich treffen können. Werte nicht über Systeme mit anderem Einsatz mitteln; Kontext in der Definition festhalten.
Dritte und Intransparenz Anbieter und Betreiber verwenden unterschiedliche Methoden, und der Anbieter legt seine nicht zwingend offen. Bei kaum erklärbaren Systemen bleibt auch die Messung unscharf. Herkunft jeder Zahl angeben; Nachweise vom Anbieter vertraglich einfordern.

Die Spalte «Folge für das Reporting» ist eine fachliche Empfehlung von STOP.LI. Die Gründe stützen sich auf die Messherausforderungen in AI 100-1, Abschn. 1.2.1, soweit der Text sie nennt; die Beispiele zu Häufigkeit, Basisrate und Testabdeckung sind Einordnung.

Kennzahlenset

Acht Kennzahlen,
je mit Nachweis.

Das Set ist klein gehalten. Jede Kennzahl hat eine eindeutige Definition, eine Datenquelle und einen Verantwortlichen. Die Spalte «Beispielziel» zeigt eine mögliche Grössenordnung; sie ist keine Vorgabe und kein Branchenwert. Das NIST AI RMF (MEASURE 1.1) empfiehlt, mit den bedeutendsten Risiken zu beginnen, und MEASURE 1.2, die Eignung der Kennzahlen regelmässig zu prüfen.

Kennzahl Definition Quelle und Nachweis Beispielziel
Abdeckung Inventar Anteil der erkannten KI-Systeme und -Funktionen, die im Inventar mit Owner und Klasse stehen, an allen erkannten (inkl. Funde aus Netzwerk, Einkauf, Abrechnung) Inventar, Fundlisten; siehe Inventar und Klassifizierung 100 % der Funde erfasst, Schatten-KI binnen 30 Tagen geklärt
Anteil beurteilter Use Cases Anteil der Use Cases im Betrieb mit gültiger Risikobeurteilung (nicht älter als der festgelegte Zyklus, nach Auslösern aktualisiert) Beurteilungsblätter; siehe Risikobeurteilung 100 % für hohe Klassen, 90 % für übrige
Testabdeckung Anteil der Systeme der oberen Risikoklassen mit Test oder Red-Team-Übung im definierten Zeitraum Testberichte; siehe Testing und Red Teaming Alle hohen Klassen jährlich
Offene Befunde Anzahl und Alter offener Befunde aus Tests, Audits und Vorfällen, nach Schweregrad Befundregister Kritische Befunde nicht älter als 30 Tage
Vorfälle Anzahl KI-Vorfälle nach Klasse, Zeit bis Erkennung und bis Eindämmung Ticketsystem; siehe Monitoring und Incident Response Trend statt Absolutwert; jeder Vorfall mit Auswertung
Drift und Qualität Anteil der Systeme im Betrieb, deren Qualität und Eingabeverteilung gegen die Basislinie überwacht werden, und Anzahl Überschreitungen (Driftarten: Monitoring und Incident Response) Evaluations-Pipeline, Beobachtungsprotokolle Alle Systeme mit Basislinie; Überschreitungen binnen 5 Arbeitstagen bewertet
Anbieter mit Nachweis Anteil der KI-Anbieter mit aktuellem Sicherheitsnachweis und vertraglich geregelten Pflichten Lieferantenregister; siehe Lieferanten und Modelle 100 % der Anbieter mit Zugriff auf vertrauliche Daten
Kontrollwirksamkeit Anteil der Kontrollen aus dem Kontrollkatalog, die im Berichtszeitraum mit Evidenz geprüft und als wirksam beurteilt wurden Kontrollprüfungen Plan je Kontrolle; Abweichungen mit Massnahme

Eine Kennzahl ist erst brauchbar, wenn Datenquelle, Stichtag und Verantwortliche feststehen. Dazu gehören auch die Angaben, wie ein «Use Case» gezählt wird (Funktion, System oder Anwendung); sonst sind Zeitreihen nicht vergleichbar.

Frühwarnung

KRI mit
Schwellen.

Eine Kennzahl (Key Performance Indicator, KPI) zeigt, wie gut etwas läuft oder wie weit ein Ziel erreicht ist. Ein Key Risk Indicator (KRI) zeigt, wie nahe die Organisation an die Grenze ihres Risikoappetits kommt, und soll warnen, bevor ein Schaden eintritt. Ein KRI hat deshalb immer eine Schwelle und eine vereinbarte Reaktion. Das Wort «KRI» ist ein Begriff der Risikopraxis; das NIST AI RMF verwendet ihn nicht. Es sieht aber vor, bekannte, unerwartete und neu auftretende Risiken regelmässig zu erkennen und zu verfolgen (MEASURE 3.1) und die Funktion und das Verhalten der Systeme im Betrieb zu überwachen (MEASURE 2.4).

KPI (Kennzahl) KRI (Frühwarnindikator)
Frage Wie gut funktioniert die Kontrolle? Wie nah sind wir an einem unannehmbaren Risiko?
Blick Zustand oder Ergebnis, meist rückblickend Vorläufer und Entwicklung, vorausschauend
Massstab Zielwert Schwelle (Gelb, Rot) aus dem Risikoappetit
Folge Verbesserung planen Vorab festgelegte Reaktion und Eskalation
Beispiel Testabdeckung 92 % Hochrisiko-System mit Test älter als 12 Monate

Ein guter KRI misst eine Ursache oder einen Vorläufer, nicht den Schaden selbst, und lässt sich ohne Aufwand regelmässig erheben. Die Schwellen unten sind Beispiele. Sie gehören zum Risikoappetit, siehe Risikobeurteilung.

KRI Beispiel Gelb Beispiel Rot Reaktion bei Rot
Nicht inventarisierte KI-Nutzung Mehr als 0 Funde offen über 30 Tage Fund mit vertraulichen Daten Sperren bis zur Beurteilung
Überfällige Neubeurteilung nach Auslöser Auslöser seit mehr als 30 Tagen unbearbeitet Modellwechsel im Betrieb ohne Beurteilung Änderung zurücknehmen oder Freigabe nachholen
Ungeprüfte Hochrisiko-Systeme Test älter als 12 Monate Test älter als 18 Monate oder nie Entscheid der Geschäftsleitung über Weiterbetrieb
Kritische Befunde offen Mehr als 30 Tage Mehr als 60 Tage Eskalation an die Geschäftsleitung, Kompensation
Guardrail-Treffer und Ablehnungen Anstieg gegenüber Basislinie Anstieg mit Hinweis auf erfolgreiche Umgehung Vorfall eröffnen
Drift der Qualität Abweichung über der tolerierten Grenze Abweichung über der Vorfallschwelle Fallback oder Rollback
Drift der Eingaben Verteilungsabstand zur Basislinie über der tolerierten Grenze Neue Eingabeart im Betrieb ohne Referenzfragen Referenzfragen ergänzen, Qualität nachmessen, bis dahin menschliche Prüfung
Modellwechsel ohne Regressionstest Wechsel der Modellversion erkannt, Test ausstehend Neue Version länger als 5 Arbeitstage ohne Test im Betrieb Auf geprüfte Version zurück oder Test nachholen
Abhängigkeit von einem Anbieter Kein Ausstiegsplan Kritischer Prozess ohne Alternative Plan für Wechsel oder Ersatz
Befundregister

Ein Beispiel
aus der Praxis.

Das Befundregister führt alle Feststellungen aus Tests, Audits und Vorfällen an einer Stelle, mit Schwere, Verantwortlichem, Massnahme, Frist und Status. Es speist die Kennzahl «Offene Befunde» und das KRI «Kritische Befunde offen». Die Tabelle zeigt einen Auszug. Alle Einträge sind erfundene Beispiele, Stand 30.09.2026. Die Spalten «Massnahme» und «Frist» sind die Zeilen der Gelb- und Rot-Punkte im Beispiel-Lagebild unten.

ID Quelle Beschreibung System Schwere Owner Massnahme Frist Status
B-26-011 Red-Team-Übung (20.07.2026) Indirekte Prompt Injection über ein hochgeladenes PDF überschreibt Anweisungen des Assistenten Kundenservice-Assistent Kritisch AI-Owner Kundenservice Eingabe- und Ausgabefilter, Schreibrechte der Tools entziehen, Nachtest 31.10.2026 (ursprünglich 15.09.2026) In Arbeit, Frist verpasst
B-26-012 Test (Red-Team-Übung, 20.07.2026) Systemprompt lässt sich durch gezieltes Nachfragen auslesen; enthält keine Geheimnisse Wissensassistent Vertrieb Tief AI-Owner Vertrieb Risiko akzeptiert, Prüfung bei der nächsten Änderung 31.12.2026 Akzeptiert (Entscheid Risk Owner)
B-26-013 Audit (interne Revision, 05.08.2026) Keine Löschfrist für Gesprächsprotokolle des Assistenten festgelegt Dokumenten-Zusammenfassung Hoch Datenverantwortliche Aufbewahrungsregel beschliessen und technisch umsetzen 30.11.2026 Offen
B-26-014 Change-Prozess (26.08.2026) Neue Datenquelle im Wissensassistenten ohne Neubeurteilung eingebunden Wissensassistent Vertrieb Mittel AI-Owner Vertrieb Herkunfts- und Qualitätsprüfung, Beurteilung aktualisieren 31.10.2026 Offen
B-26-015 Test (Regressionstest, 02.09.2026) Qualität bei italienischen Texten fällt gegenüber der Basislinie ab Übersetzungsdienst Mittel AI-Owner Kommunikation Rückfall auf die vorherige Modellversion bis zum Nachtest 20.10.2026 Wartet auf Anbieter
B-26-016 Audit (Lieferantenprüfung, 10.09.2026) Kein aktueller Sicherheitsnachweis des Anbieters der Transkriptionsfunktion Transkription Hoch Leitung Einkauf Nachweis anfordern, sonst Vertragsänderung oder Ersatz prüfen 14.11.2026 Offen
B-26-017 Audit (Lieferantenprüfung, 15.09.2026) Kein Ausstiegsplan für den Hauptanbieter; Kundenservice ohne Alternative Kundenservice-Assistent Hoch Leitung IT Ausstiegsplan erstellen, Alternative testen 31.01.2027 Offen, Mittel beantragt
B-26-018 Jahresplanung Tests (15.09.2026) Letzter Test des Systems vor 14 Monaten; Nachtest fehlt Bonitätsvorprüfung Mittel Leitung Security Nachtest durchführen 30.11.2026 Offen
B-26-019 Vorfall (22.09.2026) Antwort nannte eine veraltete Vertragsbedingung; Quelle war ein nicht mehr gültiges Dokument im Index Wissensassistent Vertrieb Mittel AI-Owner Vertrieb Index automatisch aktualisieren, Quellenangabe in der Antwort 15.11.2026 In Arbeit
B-26-020 Netzwerkanalyse (24.09.2026) Browser-Erweiterung mit KI-Funktion sendet Kundendaten an einen nicht inventarisierten Dienst Nicht inventarisiert Hoch Leitung Security Beurteilen, Liste freigegebener Erweiterungen einführen 30.10.2026 Gesperrt, Beurteilung offen

Lesehilfe: B-26-011 ist seit 72 Tagen offen und damit im Beispiel-KRI «Kritische Befunde offen» auf Rot (über 60 Tage). Ein akzeptierter Befund bleibt mit Begründung und Ablaufdatum im Register, damit er nicht stillschweigend verschwindet. Sinnvolle Pflichtfelder: eindeutige ID, Quelle mit Datum, Schwere nach festgelegter Skala, namentlich benannter Owner, Frist, Nachweis des Abschlusses. Die Spalten sind eine Empfehlung von STOP.LI.

Berichtsseite

Das KI-Lagebild
für das Board.

Eine Seite, quartalsweise, im Format des bestehenden Sicherheitsberichts. Das Board Security Briefing und der CISO-Monatsbericht liefern das Gefäss. Das KI-Lagebild ergänzt sie um diese Blöcke:

Block Inhalt Entscheidung
1. Gesamtbild Ampel je KRI, Trend zum Vorquartal, ein Satz Einschätzung Keine; Kenntnisnahme
2. Bestand Anzahl KI-Systeme nach Risikoklasse, Veränderung, Abdeckung Inventar Ist der Bestand vollständig genug?
3. Abweichungen vom Risikoappetit Rote KRI mit Massnahmenblock (Ursache, Massnahme, Owner, Frist, Erfolgskriterium) Mittel freigeben, befristet akzeptieren, einschränken oder stoppen
4. Vorfälle und Beinahe-Vorfälle Anzahl, Schwere, gemeldete Fälle, Erkenntnisse Zusätzliche Mittel oder Vorgaben?
5. Anbieter und Konzentration Kritische Anbieter, Ausstiegspläne, Änderungen bei Modellen Strategische Abhängigkeit tragbar?
6. Messgrenzen Welche Risiken werden nicht gemessen und warum Ist die Lücke tragbar?
7. Regulatorischer Ausblick Nur Änderungen mit Wirkung auf das Unternehmen; Fristen im Fristenkalender Budget und Priorität

Regel für die Seite: höchstens eine Seite, Zahlen mit Stichtag und Definition, jede rote Zeile mit Entscheid. Zahlen ohne Quelle gehören nicht ins Lagebild.

Ampel Pflicht im Lagebild Wer entscheidet
Rot Massnahmenblock mit allen Pflichtfeldern und ein Entscheid. Grundsatz: kein Rot ohne Massnahme und Entscheid. Board
Gelb Eine Zeile mit Massnahme, Owner und Frist; Details im Befundregister. Management
Grün Nur der Wert. Keine Entscheidung nötig

Der Massnahmenblock hat feste Felder: Ursache, Sofortmassnahme (bereits erledigt), Massnahme, Owner und Frist, Erfolgskriterium (an welchem KRI-Wert die Wirkung gemessen wird), Entscheid ans Board, Eskalation und Befund-ID. Der Entscheid ist genau eine von drei Optionen: Mittel freigeben, Risiko befristet akzeptieren (mit Ablaufdatum und Akzeptant) oder Nutzung einschränken oder stoppen. Wird eine Frist verpasst, ist der Punkt automatisch Traktandum der nächsten Sitzung. Das ist eine Empfehlung von STOP.LI.

Ausgefülltes Beispiel

Das folgende KI-Lagebild ist ein erfundenes Beispiel für ein fiktives Unternehmen, die «Beispiel Handels AG». Stichtag 30.09.2026, Bericht Oktober 2026. Die Werte sind plausibel gewählt, aber keine Branchenwerte und keine Messungen. Die Ampeln folgen den Schwellen der KRI-Tabelle oben.

Bereich Ampel Kernzahl
Inventar Rot 23 von 25 erkannten Systemen erfasst (92 %); 2 Funde offen, einer davon mit vertraulichen Daten
Befunde Rot 11 offen, davon 1 kritisch seit 72 Tagen (Schwelle Rot: über 60), 4 hoch
Anbieter Rot 3 von 4 hohen Systemen beim selben Modellanbieter; der Kundenservice-Assistent hat keine Alternative. 6 von 7 Anbietern mit Zugriff auf vertrauliche Daten mit aktuellem Nachweis
Risikobeurteilung Gelb Hohe Klassen 4 von 4, übrige 17 von 19 (89 %); ein Auslöser seit 35 Tagen unbearbeitet (Schwelle Gelb: über 30)
Tests Gelb 3 von 4 Systemen der hohen Klassen in den letzten 12 Monaten getestet; das vierte vor 14 Monaten
Drift und Qualität Gelb 19 von 23 Systemen mit Basislinie (83 %); 2 Überschreitungen der tolerierten Grenze
Vorfälle Grün 3 Vorfälle (tief bis mittel), 1 Beinahe-Vorfall; Eindämmung im Median nach 5 Stunden
Kontrollwirksamkeit Grün 34 von 36 geprüften Kontrollen wirksam (94 %)

Rot: Massnahmenblöcke. Die drei roten Punkte sind zugleich die Top-3-Risiken des Quartals.

Feld Inventar Befunde Anbieter
Ursache Mitarbeitende installierten eine Browser-Erweiterung mit KI-Funktion; eine Meldepflicht war nicht bekannt Das Entwicklungsteam war bis September durch ein Release gebunden; die Massnahme wurde erst spät begonnen Das Modell wurde ohne Ausstiegsanforderung beschafft; der Vertrag enthält keine Rückfalloption
Sofortmassnahme (erledigt) Erweiterung am 24.09.2026 per Richtlinie gesperrt; betroffene Datenarten festgestellt Schreibrechte der Tools des Assistenten am 18.09.2026 entzogen; Aktionen nur noch mit Handfreigabe Modellversion vertraglich festgelegt; manuelles Rückfallverfahren beschrieben
Massnahme Beurteilung durch Security und Datenschutz; Liste freigegebener KI-Erweiterungen; Meldeweg bekannt machen Eingabe- und Ausgabefilter produktiv schalten, Nachtest durchführen Ausstiegsplan erstellen und mit einem zweiten Modell für den Kundenservice testen
Owner, Frist Leitung Security, 30.10.2026 AI-Owner Kundenservice, 31.10.2026 (ursprüngliche Frist 15.09.2026 verpasst) Leitung IT, 31.01.2027
Erfolgskriterium KRI «Nicht inventarisierte KI-Nutzung»: kein offener Fund mit vertraulichen Daten (Rot aufgehoben) KRI «Kritische Befunde offen»: kein kritischer Befund über 30 Tage (Grün) KRI «Abhängigkeit von einem Anbieter»: Plan vorhanden und Alternative benannt (Gelb), Alternative getestet (Grün)
Entscheid ans Board Nutzung einschränken oder stoppen: Die Erweiterung bleibt gestoppt; KI-Erweiterungen sind nur über die freigegebene Liste zulässig Risiko befristet akzeptieren: Weiterbetrieb mit Handfreigabe bis 31.10.2026; Akzeptant: CEO; danach Abschaltung, falls offen Mittel freigeben: 25 Personentage für Ausstiegsplan und Test (Aufwandschätzung im Beispiel)
Befund-ID B-26-020 B-26-011 B-26-017

Gelb: eine Zeile je Punkt. Das Management entscheidet.

Bereich Massnahme Owner Frist Befund-ID
Risikobeurteilung Herkunfts- und Qualitätsprüfung der neuen Datenquelle, Beurteilung aktualisieren AI-Owner Vertrieb 31.10.2026 B-26-014
Tests Nachtest des vierten Hochrisiko-Systems Leitung Security 30.11.2026 B-26-018
Drift und Qualität Rückfall auf die vorherige Modellversion bis zum Nachtest; Anbieter-Antwort einfordern AI-Owner Kommunikation 20.10.2026 B-26-015

Grün: Vorfälle und Kontrollwirksamkeit, nur der Wert (siehe oben).

Nachverfolgung der Massnahmen aus dem Vorquartal.

Massnahme aus dem Bericht Juli 2026 Status Hinweis
Meldeweg für KI-Vorfälle einführen Erledigt und wirksam Im Quartal 3 Vorfälle und 1 Beinahe-Vorfall gemeldet
Basislinien für Qualität und Drift ergänzen Erledigt, Wirkung offen 19 von 23 Systemen erfasst; Wirkung zeigt sich frühestens im nächsten Quartal
Nachtest des vierten Hochrisiko-Systems Verspätet, eskaliert Frist 30.09.2026 verpasst; neu 30.11.2026; Traktandum im Board (heutige Register-ID B-26-018)
Zentrale Protokollierung aller KI-Eingaben Verworfen Begründung: Datenschutz; ersetzt durch Protokollierung der Metadaten, Entscheid Risk Owner

Messgrenzen in diesem Beispiel: Die Zahl der Vorfälle sagt nichts über nicht bemerkte Vorfälle; die Inventarquote bezieht sich nur auf erkannte Systeme. Beide Hinweise gehören ins Lagebild (Block 6).

Evidenz

Was die Revision
sehen will.

Berichte stützen sich auf Nachweise, die sich ohne Rückfrage prüfen lassen. Das NIST AI RMF sieht vor, dass Test- und Messverfahren, Testdaten und Werkzeuge dokumentiert sind (MEASURE 2.1) und dass interne Fachleute, die nicht an der Entwicklung beteiligt waren, oder unabhängige Prüfer an regelmässigen Beurteilungen mitwirken (MEASURE 1.3). Auf der Ebene des AI Act müssen Anbieter von Hochrisiko-KI-Systemen ein System zur Beobachtung nach dem Inverkehrbringen einrichten, das Leistungsdaten über die gesamte Lebensdauer aktiv und systematisch erhebt, dokumentiert und analysiert (Art. 72 Abs. 1 und 2). Betreiber informieren den Anbieter bei Bedarf (Art. 26 Abs. 5). Kennzahlen aus dem Betrieb sind eine natürliche Quelle für diese Daten. Zu den Werkzeugklassen gehören integrierte GRC-Plattformen; die Klasse Control und Evidence Management führt Kontrollen und Nachweise.

  • Definitionsblatt: jede Kennzahl mit Formel, Quelle, Stichtag, Verantwortlichem.
  • Rohdaten und Abzüge: unveränderte Exporte mit Datum, damit Werte nachrechenbar sind.
  • Versionierte Berichte: jedes Lagebild mit Protokoll der Behandlung und der Entscheide.
  • Befund- und Massnahmenregister: Status, Frist, Nachweis des Abschlusses.
  • Änderungsprotokoll der Kennzahlen: wer wann eine Definition oder Schwelle geändert hat und warum.
  • Unabhängige Prüfung: Bericht der zweiten oder dritten Linie zur Wirksamkeit der Kontrollen (ISMS-Prozess 24).
Einführung

In vier Schritten
zum ersten Lagebild.

  • Schritt 1: Fünf bis acht Kennzahlen wählen, Definition und Verantwortliche festlegen. Messlücken aufschreiben.
  • Schritt 2: Datenquellen anbinden. Zuerst manuell erheben, dann automatisieren, wenn die Definition stabil ist.
  • Schritt 3: Schwellen mit dem Risikoappetit abstimmen und von der Geschäftsleitung genehmigen lassen.
  • Schritt 4: Erstes Lagebild einem Quartal lang parallel führen, danach Kennzahlen anpassen. Die Eignung der Kennzahlen regelmässig prüfen, etwa jährlich (NIST AI RMF, MEASURE 1.2; der Rhythmus ist ein Vorschlag von STOP.LI).
Zusätzlich für Finanzinstitute

Schweiz: Die FINMA-Aufsichtsmitteilung 08/2024 hielt unter Kap. 2.4 (Tests und laufende Überwachung) fest, dass sie bei den Beaufsichtigten teilweise Schwächen bei der Auswahl von Performance-Indikatoren, Tests und laufender Überwachung beobachtete. Sie beurteilte, ob vorab festgelegte Performance-Indikatoren gesetzt wurden, um zu bewerten, wie gut eine KI-Anwendung ihre Ziele erreicht, ob für regelmässige Kontrollen Schwellenwerte oder andere Validierungsmethoden definiert waren und ob Veränderungen der Eingabedaten (Datendrift) überwacht wurden. Zur Überwachung gehört nach der FINMA auch die Analyse von Fällen, in denen Anwender die Ausgabe ignorierten oder änderten. Die Kennzahlen Drift und Qualität sowie die KRI zur Drift sind darauf ausgerichtet.

Kap. 2.7 (Unabhängige Überprüfung): Die FINMA beobachtete keine klare Abgrenzung zwischen Entwicklung und unabhängiger Überprüfung in allen Fällen und nur bei wenigen Beaufsichtigten eine unabhängige Prüfung des gesamten Modellentwicklungsprozesses durch qualifiziertes Personal. Bei wesentlichen Anwendungen beurteilte sie, ob die Prüfung eine objektive, versierte und unvoreingenommene Meinung zur Angemessenheit und Zuverlässigkeit des Verfahrens umfasst und ob die Ergebnisse in die Entwicklung einflossen. Im Reporting heisst das: Ergebnisse der unabhängigen Prüfung getrennt von den Kennzahlen der Entwicklung ausweisen.

EU: Für Anhang-III-Nr.-5-Systeme von Finanzinstituten kann der Plan zur Beobachtung nach dem Inverkehrbringen in bestehende Systeme integriert werden, sofern ein gleichwertiges Schutzniveau erreicht wird (Art. 72 Abs. 4 UAbs. 2 AI Act).

AI Act Framework für Finanzinstitute

Unterstützung

Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt beim Aufbau eines Kennzahlensets und einer Berichtsseite für KI-Sicherheit. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.