Anleitungen
NIST AI RMF und OSFI E-23
Welche Evidenz Oloproof für die Measure-Funktion des NIST AI RMF und die Guideline E-23 der OSFI festhält, Punkt für Punkt, und welche nicht. Die Ausgaben sind das NIST AI Risk Management Framework 1.0 (NIST AI 100-1, Januar 2023) und die Guideline E-23, Model Risk Management (endgültige Fassung vom 11. September 2025, in Kraft ab dem 1. Mai 2027 für bundesrechtlich regulierte Finanzinstitute in Kanada).
Dies ist keine Zertifizierung, keine Bewertung Ihrer Compliance und keine Rechtsberatung. Ein Rahmenwerk verlangt Praktiken in einer ganzen Organisation; Oloproof erzeugt Evidenz über KI-Systeme, die ein Teil dieser Praktiken ist. NIST hat erklärt, dass das AI RMF 1.0 überarbeitet wird; prüfen Sie daher, an welche Ausgabe Sie gebunden sind.
Wie die Tabellen zu lesen sind
- Erfasst: Oloproof hält Evidenz für den Punkt so fest, wie er formuliert ist, in jedem Lauf oder jedem Protokoll, das er nennt.
- Teilweise: Oloproof hält einen Teil dessen fest, was der Punkt verlangt; der Rest steht daneben.
- Nicht abgedeckt: Der Punkt verlangt etwas, das Oloproof nicht tut.
Die Punkte sind sinngemäß wiedergegeben. Lesen Sie den Text des Rahmenwerks selbst, bevor Sie sich auf eine Zeile verlassen.
NIST AI RMF 1.0: Measure
| Punkt | Was er verlangt, kurz gesagt | Was Oloproof festhält | Status |
|---|---|---|---|
| MEASURE 1.1 | Metriken, gewählt für die Risiken, die die Map-Funktion gefunden hat | Die Metrikspezifikationen, Regeln und Release-Policy jedes Laufs, per Digest. Sie zu wählen ist Ihre Sache | Teilweise |
| MEASURE 1.2 | Metriken und Kontrollen, die im Lauf der Zeit neu bewertet werden | Trendmarkierungen, wo sich der Judge oder die Fälle geändert haben; eine Entscheidung sagt, wann ihre Evidenz veraltet ist (Gating in der CI) | Teilweise |
| MEASURE 1.3 | Bewertung durch Personen, die das System nicht gebaut haben | Ein Workspace, der auf seiner eigenen Evidenz entscheidet, Labelnde, gezählt nach Konto, und ein Entscheidungsprotokoll, das eine zweite Partei offline prüft. Wer diese Personen sind, ist Ihre Sache | Teilweise |
| MEASURE 2.1 | Testsätze, Metriken und Werkzeuge dokumentiert | Jeder Lauf nennt seine Suite-, System- und Evaluator-Versionen, Metriken und Methoden per Inhaltsadresse sowie die Version der Analyse | Erfasst |
| MEASURE 2.2 | Schutz menschlicher Versuchspersonen | Nichts | Nicht abgedeckt |
| MEASURE 2.3 | Leistung gemessen und nachgewiesen | Jede Regel wird anhand eines Intervalls entschieden: PASS, FAIL, INSUFFICIENT_EVIDENCE oder MANUAL_REVIEW. Ob die Suite dem Einsatz ähnelt, ist Ihre Sache | Teilweise |
| MEASURE 2.4 | Verhalten in der Produktion überwacht | Menschen prüfen eine Stichprobe, die der Workspace aus echtem Verkehr zieht (Produktion evaluieren) | Teilweise |
| MEASURE 2.5 | Validität und Zuverlässigkeit nachgewiesen | Intervalle mit ihren Nennern, und Judges, die an Menschen gemessen werden, bevor sie entscheiden dürfen (Judges) | Teilweise |
| MEASURE 2.6 | Sicherheitsrisiken (Safety) regelmäßig bewertet | Obergrenzen für das, was schiefgeht, auf Ihren Fällen entschieden, und die Bewertungen eines Red-Teaming-Werkzeugs, gelesen, wenn Sie sie haben (Risiko-Obergrenzen). Oloproof schreibt keine Angriffe | Teilweise |
| MEASURE 2.7 | Informationssicherheit und Resilienz bewertet | Nur über Obergrenzen auf Fällen, die Sie schreiben oder importieren | Teilweise |
| MEASURE 2.8 | Transparenz und Rechenschaftspflicht geprüft | Abzeichnungen und Freigaben durch zwei namentlich genannte Personen, in einer Kette gehalten und im Entscheidungsprotokoll mitgeführt | Teilweise |
| MEASURE 2.9 | Das Modell erklärt und seine Ausgabe interpretiert | Diagnosen per Intervention benennen den an Fehlschlägen beteiligten Teil; sie erklären kein Modell | Teilweise |
| MEASURE 2.10 | Datenschutzrisiko geprüft | Die Egress-Policy hält Inhalte auf Ihrer Seite; ein Datenschutzrisiko wird nicht bewertet | Nicht abgedeckt |
| MEASURE 2.11 | Fairness und Verzerrung bewertet | Deklarierte Slices, gemessen mit Multiplizitätskontrolle; was einen Slice fair macht, ist Ihre Sache | Teilweise |
| MEASURE 2.12 | Umweltauswirkungen bewertet | Kosten werden festgehalten, Energie nicht | Nicht abgedeckt |
| MEASURE 2.13 | Die Messung selbst bewertet | Judges, validiert an den Labels von Menschen, und jede statistische Methode, zugelassen durch eine Notiz, ein Abdeckungsraster und ein Audit | Teilweise |
| MEASURE 3.1 | Risiken im Zeitverlauf verfolgt | Trend, Aktualität und Prüfung der Produktion | Teilweise |
| MEASURE 3.2 | Risiken, die schwer zu messen sind | Eine Regel, die die Evidenz nicht entscheiden kann, sagt es (INSUFFICIENT_EVIDENCE, MANUAL_REVIEW), und ein unentschiedenes Intervall sagt, wie viele weitere Fälle es entscheiden würden | Teilweise |
| MEASURE 3.3 | Rückmeldungen von Endnutzern | Nichts | Nicht abgedeckt |
| MEASURE 4.1 | Messung, die an den Einsatzkontext gebunden ist | Labels von Ihren eigenen Prüfenden; der Kontext ist Ihre Sache | Teilweise |
| MEASURE 4.2 | Ergebnisse, die von Fachleuten der Domäne geprägt sind | Die Labels der Prüfenden entscheiden, was ein Judge wert ist | Teilweise |
| MEASURE 4.3 | Verbesserungen und Verschlechterungen dokumentiert | Vergleiche einer Änderung mit dem, was live ist, gepaart, mit Intervallen (Vergleichen) | Erfasst |
OSFI Guideline E-23 (2027)
| Grundsatz | Was er verlangt, kurz gesagt | Was Oloproof festhält | Status |
|---|---|---|---|
| 1.1 bis 1.3 | Berichtslinien, ein Rahmenwerk für das Modellrisiko, Modelle, die für ihren Zweck geeignet sind | Evidenz der Eignung für einen Zweck: die Regeln einer Release-Policy, anhand von Intervallen entschieden. Das Rahmenwerk und seine Governance sind Ihre Sache | Teilweise |
| 2.1 | Ein Inventar der eingesetzten Modelle | Die Systemversionen jedes Projekts, so wie die Läufe, die sie evaluiert haben, sie festgehalten haben. Kein unternehmensweites Inventar | Teilweise |
| 2.2 | Eine Einstufung des Modellrisikos | Nichts | Nicht abgedeckt |
| 2.3 | Aufwand im Verhältnis zum Risiko | Eine Policy je Projekt: ihre Schwellen, ihr Konfidenzniveau, ob ein bestandenes Release die Freigabe zweier Personen braucht | Teilweise |
| 3.1 | Richtlinien für den Lebenszyklus, dokumentiert | Die Release-Policy ist eine Datei, per Digest mit jedem unter ihr entschiedenen Gate festgehalten | Teilweise |
| 3.2 | Daten, die für ihre Verwendung geeignet sind | Suites, nach Inhalt versioniert; ob sie für die Verwendung geeignet sind, ist Ihre Sache | Teilweise |
| 3.3 | Entwicklungsstandards für Leistung und Dokumentation | Regeln mit Schwellenwerten und das Protokoll jedes Laufs | Teilweise |
| 3.4 | Unabhängige Prüfung von Solidität und Leistung | Ein Workspace-Gate, das auf Evidenz entscheidet, die es selbst verifiziert hat, Läufe, signiert von einem Runner, den Ihr Plattform-Team registriert, und ein Entscheidungsprotokoll, das ein Prüfender offline prüft. Die Prüffunktion ist Ihre Sache | Teilweise |
| 3.5 | Einsatz mit Qualitäts- und Änderungskontrolle | Nichts: Ein signierter Lauf bescheinigt, was ein Runner ausgeführt hat, nicht, was die Produktion bedient | Nicht abgedeckt |
| 3.6 | Überwachung und Außerbetriebnahme | Prüfung der Produktion und Aktualität für die Überwachung; die Außerbetriebnahme ist nicht abgedeckt | Teilweise |
| Freigabe | Freigabe vor dem Einsatz, mit bestätigtem Restrisiko | Ein bestandenes Release kann auf die Freigabe zweier namentlich genannter Personen warten, festgehalten und verkettet (Gating in der CI) | Teilweise |
Wie es weitergeht
- Gating in der CI: die Release-Policy, Freigaben und das Entscheidungsprotokoll.
- Risiko-Obergrenzen: was eine Obergrenze entscheidet und was sie nicht aussagt.
- Was heute funktioniert: alles, was gebaut ist, und was nicht.