NIST AI RMF: KI-Risiken steuern, Nachweise liefern

Auf die Frage „Arbeiten Sie nach dem NIST AI RMF?“ braucht es Nachweise für ein konkret benanntes KI-System: Wer verantwortet dessen Risiken, was wurde getestet, welche Handlungen sind erlaubt und was passiert bei einem Fehler? Das freiwillige Rahmenwerk umfasst 4 Funktionen. In den ersten 30 Tagen sollte daraus ein funktionierender Risikomanagementprozess entstehen, dessen Lücken klar benannt sind. Die Struktur dafür liefert das Rahmenwerk von NIST.

Das AI Risk Management Framework (AI RMF) des National Institute of Standards and Technology (NIST) unterstützt Organisationen dabei, Risiken für Menschen, Organisationen und Gesellschaft beim Entwurf, der Entwicklung, der Bereitstellung und der Nutzung von KI zu bearbeiten. Dabei geht es um mehr als das Modell: Auch die beteiligten Menschen, Daten, Berechtigungen und Einsatzbedingungen zählen. Diesen umfassenderen Ansatz beschreibt AI RMF 1.0.

Für ein Unternehmen mit 20 bis 200 Beschäftigten, das große Sprachmodelle, kurz LLMs, produktiv einsetzt, lohnt sich ein klar abgegrenzter Einstieg. Zunächst wird ein Feature mit relevanten Auswirkungen ausgewählt. Seine Risiken werden mit Entscheidungen und Nachweisen verknüpft, danach wird der Ansatz ausgeweitet. Der Bezug eines Modells von einem anderen Unternehmen erklärt Kunden noch nicht, wie das darauf aufbauende Feature kontrolliert wird.

Quellen geprüft: 26. Oktober 2026. Rahmenwerk, Playbook und Generative AI Profile wurden anhand der aktuellen NIST-Webseiten und -Publikationen geprüft. Auf der NIST-Seite zum Rahmenwerk steht, dass AI RMF 1.0 überarbeitet wird; verlinkt ist weiterhin diese Version. Daraus lässt sich weder eine bereits veröffentlichte Nachfolgeversion noch deren Erscheinungsdatum ableiten.

Wie funktioniert das NIST AI RMF?

Das Rahmenwerk verbindet Verantwortlichkeit, Kontext, Nachweise und Maßnahmen über den gesamten Lebenszyklus eines Systems. Anschaulich wird das am Brandschutz in einem Gebäude: Es reicht nicht, die Fluchtwege zu kennen. Jemand muss dafür sorgen, dass sie frei bleiben, ihren Zustand prüfen und wissen, was im Ernstfall zu tun ist.

NIST AI 100-1: Das Grundlagendokument

NIST AI 100-1 ist die Publikationskennung von AI RMF 1.0, veröffentlicht am 26. Januar 2023. Der erste Teil erläutert Risiken und Vertrauenswürdigkeit, der zweite enthält den Kern des Rahmenwerks, den sogenannten Core, sowie die Profile. Der Core gliedert das Risikomanagement in Govern, Map, Measure und Manage, jeweils mit Kategorien und Unterkategorien. Diese beschreiben Ergebnisse und Maßnahmen, keine universelle Audit-Checkliste mit einem einfachen Bestanden-oder-nicht-bestanden-Ergebnis. NIST-Rahmenwerk und Angaben zur Veröffentlichung; AI RMF 1.0, Teile 1 und 2.

Die Merkmale der Vertrauenswürdigkeit betreffen folgende Fragen: Ist ein System valide und zuverlässig? Ist es sicher im Betrieb sowie gegen Angriffe geschützt und widerstandsfähig? Lassen sich Verantwortlichkeiten nachvollziehen, und arbeitet es transparent? Ist es erklärbar und interpretierbar? Fördert es den Datenschutz? Ist es fair, und werden schädliche Verzerrungen beherrscht? Eine flüssig formulierte Antwort belegt davon noch nichts. NIST erläutert die Merkmale und ihre Zielkonflikte in AI RMF 1.0, Abschnitt 3.

Ein Supportassistent kann beispielsweise Produktfragen korrekt beantworten und dabei Daten eines anderen Kunden offenlegen. Eine brauchbare Bewertung muss deshalb sowohl die Antwort als auch die Grenzen des Datenzugriffs prüfen. Wer nur die Antwortqualität misst, übersieht möglicherweise den folgenschwereren Fehler.

NIST AI RMF Playbook: Passende Maßnahmen auswählen

Das NIST AI RMF Playbook ergänzt den Core um vorgeschlagene Maßnahmen, Quellen und Hinweise, mit denen sich dessen Ziele erreichen lassen. NIST lässt ausdrücklich zu, dass Organisationen die für ihren Bedarf passenden Vorschläge nutzen; nicht jede Organisation soll alles umsetzen. Das Playbook ist keine Checkliste, die der Reihe nach abzuarbeiten wäre. NIST Playbook; häufige Fragen zum NIST Playbook.

Sein Nutzen zeigt sich, wenn ein Risiko eine konkrete Reaktion verlangt. Kann ein Supportassistent vertrauliche Datensätze offenlegen, sind Maßnahmen zu Daten, Zugriffsrechten, Messung und Vorfallbearbeitung gefragt. Dokumentiert werden sollte, welche Maßnahmen ausgewählt wurden, warum sie passen und woran ihre tatsächliche Anwendung erkennbar ist. Jeden Vorschlag in eine Tabelle zu kopieren erzeugt Aufwand, beantwortet aber noch nicht die Frage, ob das Feature freigegeben werden sollte.

Die vier Funktionen: Welche Nachweise braucht ein kleines Team?

Die Funktionen müssen miteinander verbunden bleiben. Govern wirkt übergreifend in Map, Measure und Manage, und die Arbeit wird über den KI-Lebenszyklus hinweg wiederholt und angepasst. Deckt ein Test ein neues Risiko auf, kann eine erneute Betrachtung des Kontexts nötig sein; nach einem Vorfall muss womöglich eine Richtlinie geändert werden. NIST schreibt keine Abfolge vor, die nur in eine Richtung verläuft. NIST AI RMF Core.

Die folgende Zuordnung von Nachweisen ist unser Umsetzungsvorschlag für kleine Teams. NIST definiert die angestrebten Ergebnisse. Die hier vorgeschlagenen Dokumentationsformen und Zuständigkeiten sollen helfen, diese Ergebnisse nachzuweisen. Ein Dokument kann mehrere Funktionen unterstützen.

Die Kennungen und Ergebnisbeschreibungen stammen aus den Funktionstabellen des NIST Core. Sie dienen als ausgewählte Bezugspunkte; die Tabelle beansprucht nicht, jede Unterkategorie abzudecken.

Govern: Jemand muss den Betrieb stoppen dürfen

Govern schafft die Richtlinien, Verantwortlichkeiten und Unternehmenskultur, die für das Risikomanagement nötig sind. NIST ordnet dieser Funktion dokumentierte Rollen, Verantwortung der Unternehmensleitung, Mitarbeiterschulung und menschliche Aufsicht zu. NIST Core, Govern.

In einem beispielhaften Softwareunternehmen mit 40 Beschäftigten könnte die Gründungsperson die Risikorichtlinie verantworten, die Supportleitung den Assistenten und eine Fachkraft aus der Entwicklung dessen Zugriffskontrollen. Dafür brauchen sie Befugnisse, nicht nur einen Namenseintrag. Es muss feststehen, wer das Feature pausieren darf und wer das nach Schutzmaßnahmen verbleibende Risiko akzeptieren kann: das sogenannte Restrisiko.

Eine praktisch umsetzbare Regel zur menschlichen Aufsicht könnte lauten: „Der Assistent darf Antwortentwürfe auf Basis freigegebener Supportunterlagen erstellen. Vor dem Versand muss eine Person aus dem Support Quelle und Empfänger prüfen. Der Assistent darf weder Erstattungen auslösen noch Kontozugriffsrechte ändern. Die Supportleitung kann ihn deaktivieren; für die Wiederaufnahme ist die Zustimmung der verantwortlichen Person aus der Entwicklung und der Supportleitung erforderlich.“

Diese Regel ist ein Gestaltungsbeispiel. Ein anderer Arbeitsablauf kann andere Berechtigungen rechtfertigen. Entscheidend ist, dass die tatsächlichen Zugriffsrechte und Prüfabläufe der Regel entsprechen.

Map: Das Feature beschreiben, nicht nur das Modell

Map schafft den Kontext, in dem sich Risiken und Auswirkungen verstehen lassen, einschließlich Systemkomponenten und Drittanbietern. Die Funktion hilft auch bei der grundsätzlichen Entscheidung, ob eine KI-Lösung überhaupt geeignet ist. NIST Core, Map.

Der Supportassistent erhält einen eigenen Inventareintrag. Darin stehen Zweck, Zuständigkeit, Zielgruppe, Datenkategorien, Quellen für den Informationsabruf, angebundene Systeme, Modell- oder Dienstkennung, erlaubte Handlungen und Freigabestatus. Erfasst werden auch Personen, die von Fehlern betroffen sein können, darunter Kunden, die nie direkt mit dem Assistenten interagieren.

Ein Risiko lässt sich anschließend als Ursache, Ereignis und Folge beschreiben: „Ein fehlerhafter Kontofilter ruft das Ticket eines anderen Kunden ab; der Assistent übernimmt dessen Inhalt in einen Entwurf; die prüfende Person versendet vertrauliche Informationen an den falschen Kunden.“ Die bloße Bezeichnung „Datenschutzrisiko“ sagt der Entwicklung noch nicht, was zu beheben ist.

Neben das Szenario gehören die vorgesehenen Schutzmaßnahmen mit Zuständigkeit, Status und einem Link zum Nachweis. Ein veränderter Zweck oder eine neue Berechtigung verlangt eine erneute Bewertung, auch wenn das zugrunde liegende Modell unverändert bleibt.

Measure: Das benannte Risiko gezielt testen

Measure bewertet Risiken und Vertrauenswürdigkeit mit quantitativen, qualitativen oder kombinierten Methoden. Dazu gehören bei NIST Tests unter einsatznahen Bedingungen, die Dokumentation von Grenzen sowie die Bewertung von Bereichen wie Sicherheit, Datenschutz und schädlichen Verzerrungen. NIST Core, Measure.

Für den Supportassistenten sollten Testfälle zu einer gewöhnlichen Frage, fehlendem Quellenmaterial, widersprüchlichen Richtlinien, Datensätzen eines anderen Kunden und einer bösartigen Anweisung in abgerufenem Text vorliegen. Bei Prompt Injection schleust ein Angreifer Anweisungen ein, um das Verhalten des Systems umzulenken. NIST behandelt im Generative AI Profile, Abschnitt 2.9 sowohl direkte Angriffe als auch Angriffe über Material, das das System abruft.

Jedes Evaluationsprotokoll sollte die getestete Konfiguration, Eingaben des Testfalls, erwartetes Verhalten, tatsächliche Ausgabe oder Handlung, prüfende Person und Ergebnis festhalten. Ein fehlgeschlagener Test wird mit dem dadurch sichtbar gewordenen Risiko verknüpft. Sensible Nachweise gehören unter angemessene Zugriffskontrollen; Kundendaten sollten nicht in einen allgemein zugänglichen Bericht kopiert werden.

Die Abnahmekriterien müssen feststehen, bevor Ergebnisse bewertet werden. In diesem Beispiel verhindert die Offenlegung von Daten eines anderen Kunden die Freigabe, selbst wenn die übrigen Antworten gut aussehen. Das ist eine vorgeschlagene Freigaberegel, kein NIST-Grenzwert. Schon wenige Testfälle können einen Fehler aufdecken. Ihr Bestehen beweist aber nicht, dass Fehler ausgeschlossen sind.

Manage: Aus Befunden Entscheidungen ableiten

Manage priorisiert Risiken und weist ihrer Bearbeitung Ressourcen zu. Bei NIST umfasst das Entscheidungen über die Fortsetzung von Entwicklung oder Bereitstellung, Optionen wie die Minderung oder Akzeptanz von Risiken, Möglichkeiten zur Deaktivierung von Systemen sowie die laufende Überwachung und Reaktion auf Vorfälle. NIST Core, Manage.

Scheitert der Test zur Trennung von Kundenkonten, wird der betroffene Datenabruf deaktiviert, die Berechtigungsprüfung korrigiert und vor der Wiederfreigabe erneut getestet. Bei einem weniger folgenschweren Fehler wird dokumentiert, warum eine begrenzte Freigabe mit Überwachung vertretbar ist und wer das entschieden hat. Ein Eintrag „akzeptiert“ ohne Begründung und verantwortliche Freigabe ist ein schwacher Nachweis.

Ein Vorfallprotokoll erfasst den Zeitpunkt der Entdeckung, betroffenes System und Konfiguration, bekannte Auswirkungen, Eindämmung, Ablageort der Nachweise, Kommunikation, Korrekturmaßnahmen und Freigabe zur Wiederaufnahme. Auch Beinahevorfälle gehören hinein. Ist noch nichts passiert, ist ein leeres Protokoll ehrlich. Ergänzt werden sollte es um eine klar als solche gekennzeichnete Übung, die zeigt, dass jemand den vorgesehenen Ablauf ausführen kann.

NIST AI 600-1: Was ergänzt das Generative AI Profile?

NIST AI 600-1, das Generative Artificial Intelligence Profile, überträgt das Rahmenwerk auf Risiken, die durch generative KI neu entstehen oder verstärkt werden. Es wurde am 26. Juli 2024 veröffentlicht und ergänzt AI RMF 1.0. Es ist weder ein Ersatz für das Rahmenwerk noch eine eigenständige Zertifizierung. NIST-Publikationsseite.

Das Profil benennt 12 Risikobereiche und schlägt Maßnahmen vor, die dem Rahmenwerk zugeordnet sind. Bei seiner Entwicklung standen Governance, die Herkunft von Inhalten, Tests vor dem Einsatz und die Offenlegung von Vorfällen im Mittelpunkt. Inhaltsprovenienz bezeichnet die Herkunft und Entstehungsgeschichte von Inhalten. Diese Aspekte helfen, generierte Ausgaben mit nachvollziehbaren Verantwortlichkeiten im Betrieb zu verbinden. NIST AI 600-1, Einleitung, Abschnitt 2 und Anhang A.

Für den Supportassistenten werden die relevanten Risiken zunächst in konkrete Fehlerszenarien übersetzt:

• Konfabulation: Eine überzeugend formulierte, aber falsche Antwort erfindet einen Erstattungsanspruch. Die erwartete, richtlinienkonforme Antwort wird festgehalten und geprüft, ob das vom System angeführte Material sie stützt.
• Datenschutz und Informationssicherheit: Kundendaten werden offengelegt, oder bösartige Inhalte aus abgerufenen Quellen lenken den Assistenten um. Getestet werden sowohl die Grenzen des Datenzugriffs als auch das Verhalten bei gezielt schädlichen Eingaben.
• Zusammenspiel von Mensch und KI: Eine prüfende Person vertraut einem ausgefeilten Entwurf zu sehr. Sie braucht die zugrunde liegende Quelle, Kriterien für eine Ablehnung und die Befugnis, die Handlung zu stoppen.
• Schädliche Verzerrungen oder Homogenisierung: Die Servicequalität unterscheidet sich zwischen relevanten Nutzergruppen oder Sprachen. Untersucht werden die tatsächlich bedienten Kontexte; die Grenzen der Nachweise werden dokumentiert.
• Wertschöpfungskette und Komponentenintegration: Ein Modell, eine Datenquelle oder eine Integration ändert sich, ohne dass die Auswirkungen verstanden werden. Abhängigkeiten und Änderungen werden dokumentiert und betroffene Risiken anschließend neu bewertet.

Das sind Umsetzungsbeispiele aus den Risikobeschreibungen des Profils, keine verkürzte offizielle Checkliste. Die weiteren benannten Bereiche sind CBRN-Informationen oder -Fähigkeiten (chemisch, biologisch, radiologisch oder nuklear), gefährliche, gewalttätige oder hasserfüllte Inhalte, Umweltauswirkungen, Informationsintegrität, geistiges Eigentum sowie obszöne, erniedrigende und/oder missbräuchliche Inhalte. Ihre Relevanz für das jeweilige System sollte geprüft und die Begründung dokumentiert werden. Die vollständigen Definitionen stehen in NIST AI 600-1, Abschnitt 2.

Praktisch lässt sich das Profil bearbeiten, indem für jedes anwendbare Risiko die gewählte Maßnahme, die Zuständigkeit und der Nachweis festgehalten werden. Wesentliche Ausschlüsse brauchen eine Begründung. Bei einem Agenten, der über angebundene Software handeln kann, muss neben dem erzeugten Text auch der Weg bis zur Handlung bewertet werden. Ein korrekter Entwurf belegt nicht, dass eine Kontoänderung autorisiert war.

Die ersten 30 Tage: Ein Vorschlag für die Umsetzung

Das Ziel ist ein nachweisbarer Prozess für einen klar definierten Umfang. Dieser Zeitplan ist unsere Empfehlung, keine NIST-Frist, kein Reifegrad und keine Zusage, dass danach alles abgeschlossen ist. Governance bleibt währenddessen durchgehend aktiv. Der Kalender hilft, den ersten Monat zu organisieren; er bildet keine vom Rahmenwerk vorgeschriebene Reihenfolge ab.

1. 1

   Tage 1-5: Umfang und Zuständigkeiten festlegen

   Eine verantwortliche Führungskraft und eine systemverantwortliche Person werden benannt. Bestehende KI-Nutzungen kommen ins Inventar, einschließlich KI-Funktionen in bereits eingekaufter Software. Für die erste vertiefte Bewertung wird ein produktiv eingesetztes Feature ausgewählt, das relevante Risiken für Kunden, Daten oder ausgeführte Handlungen mit sich bringt.

   Zweck und Grenzen werden beschrieben, betroffene Personen identifiziert und bestehende Verfahren für Freigaben, Zugriffe und Vorfälle zusammengetragen. Noch nicht erfasste Bereiche werden als Lücken dokumentiert; ohne Nachweis wird das Inventar nicht für vollständig erklärt.

   Festhalten: Das erste Inventar, benannte Verantwortlichkeiten und eine Regel zur menschlichen Aufsicht, die mit den tatsächlichen Berechtigungen des Features abgeglichen wurde.

2. 2

   Tage 6-10: Fehlerszenarien erfassen und Maßnahmen wählen

   Das ausgewählte Feature wird gemeinsam mit seiner Entwicklung und der Person durchgegangen, die den Arbeitsablauf betreut. Hinzu kommt jemand, der Annahmen über die Auswirkungen auf Kunden kritisch hinterfragen kann. Dabei werden Eingaben, abgerufenes Material, Ausgaben und angebundene Handlungen nachvollzogen.

   Schadensszenarien werden im Risikoregister erfasst und mithilfe des Generative AI Profile auf Lücken geprüft. Priorisiert wird nach möglicher Auswirkung und Eintrittswahrscheinlichkeit, einschließlich der jeweiligen Unsicherheit. Für die Risikobehandlung wird eine Zuständigkeit festgelegt. Es wird entschieden, welche Fehler die Freigabe verhindern und welche eine Einschränkung des Einsatzumfangs verlangen.

   Festhalten: Systembeschreibung, Risikoregister, ausgewählte Maßnahmen, fehlende Nachweise und vorgeschlagene Abnahmekriterien.

3. 3

   Tage 11-20: Die vorgesehene Systemkonfiguration evaluieren

   Repräsentative Fälle, Fehlerfälle und gezielte Angriffsfälle werden mit der für den Einsatz vorgesehenen Konfiguration getestet. Modell- oder Dienstkennungen, Prompts, Einstellungen zum Informationsabruf und Tool-Berechtigungen werden dokumentiert, soweit sie verfügbar sind. Legt ein Anbieter ein relevantes Detail nicht offen, bleibt diese Einschränkung in der Bewertung sichtbar.

   Auch die Übergabe an Menschen wird geprüft: Kann die prüfende Person eine fehlerhafte Antwort erkennen, die Quelle finden und die Antwort ablehnen? Fehler werden behoben und erneute Tests dokumentiert. Wenn möglich, prüft eine andere Person als diejenige, die das Feature entwickelt hat. Ein sehr kleines Unternehmen kann für folgenreiche Entscheidungen eine entsprechend qualifizierte externe Person hinzuziehen.

   Festhalten: Versionierte Evaluationsprotokolle, offene Befunde und Verknüpfungen mit den zugehörigen Risiken. Eine ungeprüfte Annahme darf nicht als bestandener Test erscheinen.

4. 4

   Tage 21-30: Entscheiden, den Ernstfall üben und berichten

   Auf Basis der Nachweise wird das Feature freigegeben, eingeschränkt oder pausiert. Es wird benannt, wer das verbleibende Risiko akzeptiert. Änderungen an Daten, Modellen, Zweck oder Berechtigungen erhalten festgelegte Anlässe für eine erneute Prüfung.

   Ein Vorfall wird geprobt: Ein Kunde meldet, dass eine Antwort Informationen aus einem anderen Konto enthält. Dabei wird geklärt, wer den Zugriff sperren, Nachweise sichern, Auswirkungen bewerten, die Kommunikation koordinieren und die Wiederaufnahme genehmigen kann. Die Übung wird ausdrücklich als solche gekennzeichnet.

   Festhalten: Eine dokumentierte Freigabeentscheidung, Zuständigkeit für die Überwachung, ein Vorfallprotokoll und eine kurze Erklärung für Kunden oder das Aufsichtsgremium, die wirksame Kontrollen von noch offenen Arbeiten unterscheidet.

NIST AI RMF in der Schulung: Entscheidungen üben

Schulungen sollten Menschen auf die Entscheidungen vorbereiten, die sie verantworten. GOVERN 2.2 behandelt Risikomanagementschulungen für Beschäftigte und Partner. Das angestrebte Ergebnis ist, dass sie ihre Aufgaben wahrnehmen können. NIST Core, Govern.

Für die Supportleitung heißt das, eine unzulässige Offenlegung zu erkennen, den Assistenten zu pausieren und den Vorfall zu eskalieren. Für die Entwicklung bedeutet es zu wissen, welche Berechtigungsänderung eine erneute Bewertung verlangt. Szenario, Teilnehmende, Entscheidungen und Folgemaßnahmen einer Übung werden dokumentiert. Eine Teilnahmebescheinigung allein zeigt noch nicht, dass die Reaktion im Produktivbetrieb funktioniert.

NIST beschreibt außerdem Current Profiles und Target Profiles, die bestehende und angestrebte Ergebnisse des Risikomanagements erfassen. Ihr Vergleich macht offene Arbeit sichtbar. Ein kleines Unternehmen kann diese Unterscheidung in seinem Nachweisverzeichnis aufgreifen: umgesetzt, teilweise umgesetzt, geplant oder mit Begründung nicht anwendbar. Diese Statusbezeichnungen sind unser Vorschlag. AI RMF 1.0, Abschnitt 6.

Was lässt sich gegenüber Kunden, Prüfern und Aufsichtsgremien belegen?

Bevor eine Orientierung am Rahmenwerk behauptet wird, sollten Umfang und Reife der Umsetzung beschrieben werden. Ein Kunde, der einen Supportassistenten bewertet, muss erkennen können, ob die Nachweise dieses Feature, seine aktuelle Konfiguration und die erlaubten Handlungen abdecken.

Läuft die Umsetzung noch, sollte das ausdrücklich gesagt werden. Zum Beispiel:

Wir setzen derzeit Verfahren des NIST AI RMF für unseren Kundensupportassistenten um. Zuständigkeiten, Systeminventar und Risikobewertung sind vorhanden. Die Evaluation und eine Übung zur Vorfallreaktion stehen noch aus. Bis die entsprechenden Entscheidungen getroffen sind, bleibt das Feature innerhalb seines bisherigen eingeschränkten Einsatzumfangs.

Werden die Verfahren bereits angewendet und durch Aufzeichnungen belegt, könnte eine ausführlichere Antwort lauten:

Wir nutzen NIST AI RMF 1.0, um das Risikomanagement für unseren Kundensupportassistenten zu strukturieren, ergänzt um relevante Maßnahmen aus dem Generative AI Profile. Wir pflegen Zuständigkeiten und Aufsichtsregeln, System- und Risikodokumentation, Evaluationsnachweise und Verfahren für Vorfälle. Unsere Beschreibung des Geltungsbereichs nennt die bewerteten Konfigurationen, bekannte Grenzen, offene Maßnahmen und die nächste Überprüfung. Damit beschreiben wir unsere Umsetzung; es handelt sich nicht um eine NIST-Zertifizierung.

Diese Formulierungen sind Beispiele und müssen zu den tatsächlich vorhandenen Nachweisen passen. Die weitergehende Aussage darf nicht übernommen werden, solange die dafür nötigen Kontrollen erst geplant sind.

Ein kurzes Nachweisverzeichnis sollte Dokumentverantwortliche, Datumsangaben und zugriffsgeschützte Links enthalten. Für jede Aussage muss erkennbar sein, was eine Richtlinie vorgibt und welches Protokoll ihre Anwendung belegt. Die Aufsichtsregel beschreibt den vorgesehenen Ablauf; ein geprüftes Freigabe- oder Genehmigungsprotokoll zeigt, dass er stattgefunden hat. Enthalten die zugrunde liegenden Nachweise Kundendaten oder sensible Sicherheitsdetails, wird eine entsprechend geschwärzte Bewertung geteilt.

Für das Aufsichtsgremium stehen folgenreiche offene Risiken, nötige Entscheidungen und die jeweiligen Zuständigkeiten im Vordergrund. Ein prozentualer Erledigungsstand von Tabellenzeilen kann genau den einen offenen Punkt verdecken, der eine Bereitstellung verhindern müsste.

Was Entwicklung, Betrieb und Einkauf jeweils tun sollten

Entwicklung: Neue Befugnisse sind eine Änderung am Systemdesign. Erhält ein Assistent, der bislang nur Entwürfe erstellt, die Möglichkeit zu Erstattungen, verändert sich das Risiko auch bei unverändertem Modell und Prompt. Vor der Aktivierung müssen Systembeschreibung, Berechtigungstests und Freigabeentscheidung aktualisiert werden.

Betrieb: Rückmeldungen müssen mit dem Risikoregister verbunden bleiben. Wiederkehrende Beschwerden über erfundene Richtlinien sollten als Fehlermuster untersucht, in einen Testfall überführt und bei der Entscheidung über den weiteren Einsatz berücksichtigt werden. Jemand muss dafür verantwortlich sein, diesen Kreislauf zu schließen.

Einkauf und Gründungsteam: Gefragt sind der bewertete Geltungsbereich, aktuelle Evaluationsnachweise und verbleibende Einschränkungen. Wenn ein Anbieter angibt, sich am Rahmenwerk zu orientieren, sollte er erklären, was er selbst kontrolliert und was der Kunde konfigurieren oder überwachen muss.

Sofort handeln, wenn ein Feature sensible Informationen verarbeitet, eine folgenreiche Entscheidung beeinflusst, Inhalte an Kunden versendet oder externe Datensätze ändern kann. Ein schlankerer Prozess genügt für ein begrenztes Experiment mit öffentlichen oder synthetischen Informationen, das keine externen Handlungen ausführt. Mehr Autonomie muss warten, solange sich Berechtigungsgrenzen, Prüfablauf oder Stoppmechanismus nicht nachweisen lassen. Das sind vorgeschlagene Priorisierungsregeln, keine NIST-Risikoklassen.

Eine Überarbeitung des Rahmenwerks lässt bekannte Risiken nicht verschwinden. Sie müssen weiter bearbeitet werden; zugleich sollte in der Dokumentation ausdrücklich stehen, welche Version verwendet wird.

Wie passen ISO/IEC 42001 und der EU AI Act dazu?

Die Dokumente erfüllen unterschiedliche Zwecke. ISO/IEC 42001:2023 legt Anforderungen an ein organisatorisches KI-Managementsystem fest. Organisationen können dieses Managementsystem unabhängig zertifizieren lassen; ISO selbst stellt keine Zertifikate aus. ISO-Übersicht zur Norm; ISO-Erläuterung zur Zertifizierung.

Der EU AI Act begründet rechtliche Pflichten abhängig von der jeweiligen Rolle, dem System und dessen Nutzung. Nachweise aus dem AI RMF können diese Arbeit unterstützen. Eine Orientierung am Rahmenwerk belegt aber noch keine Einhaltung des Gesetzes. Zu den geltenden Regeln und Fristen geben die Hinweise der Europäischen Kommission zum AI Act Auskunft. Weitere Beiträge auf dieser Website bündelt unsere Seite zum EU AI Act.

Unser Rahmenwerk für KI-Governance ergänzt die unternehmensweiten Zuständigkeiten; die Richtlinie zur zulässigen KI-Nutzung liefert Regeln für Beschäftigte. Diese Vorgaben sollten mit Nachweisen zum jeweiligen System verbunden werden, statt für jedes Rahmenwerk isolierte Richtlinien zu pflegen.

Überzogene Versprechen: Zertifikate, Erledigungsquoten und sichere Modelle

Die größte Übertreibung ist die Behauptung, die Übernahme des Rahmenwerks belege bereits die Sicherheit eines Systems. NIST strukturiert damit das Risikomanagement. Aussagekräftige Nachweise bleiben an das konkrete System, seinen Kontext und die getroffenen Entscheidungen gebunden. Der Core ist ausdrücklich flexibel und auf wiederholte Überprüfung und Anpassung ausgelegt. NIST AI RMF Core.

Gibt es eine NIST-Zertifizierung für das AI RMF?

NIST zertifiziert keine Organisationen nach dem AI RMF. Beschrieben werden sollten die Umsetzung, ihr Umfang und die vorhandenen Nachweise; die Bezeichnung „NIST-zertifiziert“ ist dafür unangebracht. Eine unabhängige Bewertung kann sinnvoll sein. Ihr Bericht sollte jedoch nennen, wer was anhand welcher Kriterien geprüft hat. Daraus wird kein von NIST ausgestelltes Zertifikat. Der offizielle Ausgangspunkt ist das freiwillige AI RMF von NIST.

Eine ausgefüllte Checkliste ist noch keine Risikoentscheidung. NIST gibt keine universelle Risikotoleranz vor, und das Playbook verlangt nicht die Umsetzung jedes Maßnahmenvorschlags. Abnahmekriterien müssen zum möglichen Schaden passen und begründet werden. AI RMF 1.0, Abschnitt 1.2.2; Hinweise zum Playbook.

Die Nachweise eines Anbieters decken nicht die gesamte eigene Anwendung ab. Die für den Abruf verwendeten Daten, Zugriffskontrollen, Integrationen und Nutzenden schaffen zusätzlichen Kontext. NIST behandelt ausdrücklich Komponenten von Drittanbietern und deren laufendes Management. Anbieterunterlagen bleiben relevant; die eigene Betriebskonfiguration muss dennoch getestet werden. NIST Core, Map und Manage.

Menschliche Prüfung ist kein automatischer Schutz. Die prüfende Person braucht die Quelle, ausreichend Zeit, das nötige Fachwissen und die Befugnis einzugreifen. Führt der Arbeitsablauf in der Praxis zum bloßen Durchwinken, muss er geändert werden, bevor von wirksamer Aufsicht gesprochen werden kann.

Häufige Fragen

Wozu braucht es ein Rahmenwerk für KI-Risikomanagement?

KI-Risiken entstehen im Zusammenspiel von Technik, Menschen und Einsatzkontext. Das Rahmenwerk hilft Organisationen, dieses Zusammenspiel über den gesamten Lebenszyklus zu steuern. Dazu zählen auch Auswirkungen auf Menschen, die das System nicht selbst nutzen. Es ist ein freiwilliges Hilfsmittel; seine Übernahme ist keine gesetzliche Pflicht. NIST AI RMF 1.0.

Was sind 5 Risiken von KI?

Für ein Feature mit generativer KI sind fünf anschauliche Beispiele: selbstsicher formulierte Falschaussagen, die Offenlegung privater Daten, schädliche Verzerrungen, übermäßiges Vertrauen durch Menschen und Angriffe, die das Systemverhalten umlenken. Sie entsprechen Bereichen aus dem Generative AI Profile, bilden aber nicht dessen vollständige Risikoliste ab. NIST AI 600-1, Abschnitt 2.

Was ist der Hauptzweck des NIST Risk Management Framework (RMF)?

Das hier behandelte AI RMF soll Organisationen helfen, KI-Risiken zu steuern und Vertrauenswürdigkeit in Entwicklung und Nutzung zu verankern. In einer Antwort an Kunden sollte ausdrücklich „AI RMF“ stehen, damit klar ist, welches Rahmenwerk gemeint ist. NIST-Übersicht zum Rahmenwerk.

Ist das NIST AI RMF verpflichtend?

Das Rahmenwerk selbst ist freiwillig. Gesonderte vertragliche, beschaffungsbezogene oder gesetzliche Verpflichtungen des Unternehmens müssen separat geprüft werden. Die Übernahme eines freiwilligen Rahmenwerks klärt diese Pflichten nicht automatisch. NIST-Übersicht zum Rahmenwerk.

Wodurch wird das RMF ersetzt?

Zum AI RMF erklärt die am 26. Oktober 2026 geprüfte NIST-Seite, dass Version 1.0 überarbeitet wird; sie verlinkt diese Version weiterhin. Der Hinweis belegt keine bereits veröffentlichte Nachfolgeversion. NIST AI 600-1 ist ein ergänzendes Generative AI Profile. NIST-Seite zum Rahmenwerk.

Wird Finanzrisikomanagement (FRM) durch KI ersetzt?

Aus dem AI RMF lässt sich nicht ableiten, ob Tätigkeiten im Finanzrisikomanagement ersetzt werden. Das Rahmenwerk behandelt den Umgang von Organisationen mit KI-Risiken, einschließlich menschlicher Verantwortlichkeiten und Aufsicht. Es liefert keine Prognose darüber, ob ein Beruf ersetzt wird. NIST Core, Govern.

Welche sind die 3 wichtigsten Cybersicherheitsrahmenwerke?

Eine universelle Rangliste der drei wichtigsten Rahmenwerke für jede Organisation gibt es nicht. Die Auswahl sollte sich nach den eigenen Systemen, Verpflichtungen und Anforderungen an die Absicherung richten. Hier dient das AI RMF dazu, KI-spezifische Risiken ergänzend zum bestehenden Sicherheitsprogramm zu bearbeiten. Seine Ziele zu Sicherheit und Widerstandsfähigkeit decken nicht die gesamte Cybersicherheit ab. NIST AI RMF 1.0.

Ist Cybersicherheit ein aussterbendes Berufsfeld?

Mit der Einführung von KI entfällt die Sicherheitsarbeit nicht. Das AI RMF umfasst die Bewertung von Sicherheit und Widerstandsfähigkeit, das Management von Drittanbieterrisiken und die Reaktion auf Vorfälle. Im Produktivbetrieb müssen diese Aufgaben weiterhin zugewiesen und ihre Erfüllung nachgewiesen werden. Das ist eine betriebliche Konsequenz, keine Arbeitsmarktprognose. NIST Core.

Was ist derzeit die Cyberbedrohung Nr. 1?

Keine einzelne Bedrohung verdient diesen Rang für jedes Unternehmen. Vorrang hat, was im jeweiligen Einsatz Schaden anrichten kann. Beim beispielhaften Supportassistenten sollten unberechtigter Datenzugriff und Prompt Injection ausdrücklich getestet werden. Ihre Priorität hängt von den betroffenen Daten und Berechtigungen ab. NIST Generative AI Profile, Abschnitt 2.9.

Der nächste Schritt am Montag

Gemeinsam mit der verantwortlichen Person für das folgenreichste KI-Feature wird das Inventar geöffnet. Ein plausibler Fehler wird ausgewählt und geklärt, wer dadurch Schaden nehmen könnte. Von dort führt der Weg zu einem Test, einer Freigabeentscheidung und einem Stoppverfahren. Reißt diese Verbindung ab, wird genau diese Lücke zur nächsten Aufgabe mit klarer Zuständigkeit.

So bekommt die nächste Antwort an einen Kunden eine konkrete Grundlage: das betrachtete System, die vorhandenen Nachweise und die noch ausstehende Arbeit.

Praktische Hinweise zum produktiven KI-Einsatz gibt es im Newsletter.