KI-Governance für eine private LLM-Plattform: ISO/IEC 42001, NIST AI RMF und die Kontrollen dahinter

ISO/IEC 42001 und NIST AI RMF für eine interne LLM-Plattform

ISO/IEC 42001:2023 legt Anforderungen an ein KI-Managementsystem fest, also an die Richtlinien, Rollen, den Risikoprozess, die Kontrollen und die Überprüfungen, mit denen eine Organisation die KI steuert, die sie entwickelt, bereitstellt oder nutzt. Das AI Risk Management Framework 1.0 des NIST und sein Generative AI Profile, NIST AI 600-1, beschreiben dieselbe Risikoarbeit in vier Funktionen und schlagen konkrete Maßnahmen für generative KI vor. Für ein Unternehmen, das eine eigene LLM-Plattform betreibt, setzen beide die KI-Governance in eine kurze Liste technischer Kontrollen um: einem Inventar der Modelle und Anwendungsfälle, an Rollen gebundenen Zugriffsrechten, einem Query-Log mit Aufbewahrungsregel, Evaluierungsnachweisen für jede Modelländerung, einem Vorfallprozess und Nachweisen über die Lieferanten.

Dieser Leitfaden bildet beide auf diese Kontrollen und ihre Nachweise ab, für eine Plattform, die 500 bis 2.000 Beschäftigte nutzen. ISO/IEC 42001 beschreibt er nur anhand dessen, was die ISO frei zugänglich veröffentlicht.

Was ISO/IEC 42001 festlegt, nach den öffentlichen Seiten der ISO

ISO/IEC 42001:2023 wurde am 18. Dezember 2023 als Ausgabe 1 vom gemeinsamen Komitee ISO/IEC JTC 1/SC 42 veröffentlicht. Nach der Seite der ISO legt die Norm „Anforderungen an die Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung eines Managementsystems für künstliche Intelligenz (AIMS) in Organisationen“ fest. Die FAQ der ISO bezeichnet sie als Managementsystemnorm, die die Plan-Do-Check-Act-Methode nutzt, und grenzt sie von ISO/IEC 22989, 23053 und 23894 ab, die KI-Terminologie und -Konzepte, ein Rahmenwerk für KI-Systeme mit maschinellem Lernen und Leitlinien zum KI-Risikomanagement behandeln.

Der Erklärtext der ISO zur Norm, Stand Oktober 2026 auf iso.org, nennt die Bereiche, in denen ISO/IEC 42001 Anforderungen festlegt. Es sind Führung und Kontext der Organisation, KI-Richtlinie und KI-Ziele, Risikomanagement für KI-Systeme, Data Governance und Kontrollen über den Lebenszyklus des Systems, Transparenz und Bereitstellung von Informationen, Leistungsbewertung und Überwachung sowie fortlaufende Verbesserung.

Die Zertifizierung ist freiwillig. Der Erklärtext der ISO sagt, sie „erfolgt durch unabhängige Zertifizierungsstellen, die von nationalen Akkreditierungsstellen akkreditiert sein können“, und hält fest, dass die ISO keine Organisationen zertifiziert. ISO/IEC 42006:2025, veröffentlicht im Juli 2025, legt die zusätzlichen Anforderungen an Stellen fest, die KI-Managementsysteme nach ISO/IEC 42001 auditieren und zertifizieren, und baut auf ISO/IEC 17021-1 auf. Für das Plattformteam bedeutet das Nachweise, die ein internes Audit oder ein Zertifizierungsaudit prüfen kann, etwa wer einen Anwendungsfall freigegeben hat, welche Modellversion geantwortet hat, was vor einer Änderung getestet wurde und wie ein Vorfall abgeschlossen wurde.

NIST AI RMF 1.0 und das Generative AI Profile

Das NIST veröffentlichte das AI RMF 1.0 am 26. Januar 2023 und beschreibt es als Rahmenwerk, das „freiwillig, rechtewahrend, nicht sektorspezifisch und unabhängig vom Anwendungsfall“ sein soll. Es gliedert die Arbeit in vier Funktionen. Govern „entwickelt und verankert eine Kultur des Risikomanagements in Organisationen“ und zieht sich durch die drei anderen. Map erfasst den Kontext der Risiken eines KI-Systems, Measure bewertet sie, und Manage weist ihnen Ressourcen zu. Jede Funktion gliedert sich in Kategorien und Unterkategorien, etwa GOVERN 1.6: „Es gibt Mechanismen zur Inventarisierung von KI-Systemen, und sie sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.“

Am 26. Juli 2024 veröffentlichte das NIST die Publikation NIST AI 600-1, das Generative Artificial Intelligence Profile. Sie nennt 12 Risiken, die generativer KI eigen sind oder durch sie verschärft werden, darunter Konfabulation, Datenschutz, Informationssicherheit sowie Wertschöpfungskette und Integration von Komponenten, und schlägt Maßnahmen mit Kennungen wie GV-1.6-003 vor. Stand Oktober 2026 heißt es auf der AI-RMF-Seite des NIST, das AI RMF 1.0 werde „im Rahmen des White House AI Action Plan überarbeitet“; das Rahmenwerk selbst sieht spätestens 2028 eine Überprüfung mit formellen Beiträgen der KI-Community vor. ISO/IEC 42001 ist die Norm, nach der sich eine Organisation zertifizieren lassen kann; die Unterkategorien und empfohlenen Maßnahmen des NIST ergeben eine brauchbare Checkliste für ihre Kontrollen.

Anforderungen der KI-Governance, abgebildet auf Kontrollen der Plattform

Die meisten Governance-Anforderungen werden im Verzeichnisdienst, im Gateway vor den Modellen, in der Serving-Schicht, im Retrieval-Index und im Ticketsystem umgesetzt. Die Tabelle ordnet jeder Anforderung ihre Kontrolle und den Nachweis zu, den ein Prüfer einsehen kann.

ISO-Anforderungsbereiche aus dem Erklärtext der ISO zu ISO/IEC 42001 (iso.org); Unterkategorien aus NIST AI 100-1 (AI RMF 1.0, Januar 2023); Kennungen der Maßnahmen aus NIST AI 600-1 (Juli 2024). Kontrollen und Nachweise sind unsere Beispiele.

Unser Leitfaden zu Prompt Injection und LLM-Sicherheit behandelt die Sicherheitstests, die in die Zeilen zu Evaluierung und Vorfällen gehören.

Unsere Leistung Private AI/ML baut die Plattform mit Query-Log sowie Daten- und Berechtigungsverwaltung, sodass Security und Legal sehen, wer worauf zugreift. Beschreiben Sie Ihre Modelle, Anwendungsfälle und die Zahl der Nutzer im Formular unten.

Inventar der Modelle und Anwendungsfälle: ein Beispiel für 1.500 Nutzer

Angenommen, ein Unternehmen mit 1.500 Beschäftigten betreibt eine private LLM-Plattform auf zwei GPU-Servern on-premise, mit drei Open-Weight-Modellen hinter einem Gateway. Sechs Anwendungsfälle sind freigegeben: Entwürfe und Übersetzungen für alle Beschäftigten, Suche in internen Richtlinien mit RAG, Vertragszusammenfassungen für die Rechtsabteilung, ein Code-Assistent für 80 Entwickler, die Klassifizierung von Tickets im Service Desk und ein HR-FAQ für die Beschäftigten.

Jeder Anwendungsfall erhält einen Eintrag im Inventar. Er enthält den Zweck, den fachlich Verantwortlichen, die Verzeichnisgruppe seiner Nutzer, die Datenklassen, die in Prompts und im Retrieval-Index zulässig sind, das Modell und seine genaue Version, die Version der Serving-Engine, das Evaluierungsset und sein letztes Ergebnis, eine Risikoeinstufung und den nächsten Prüftermin. GV-1.6-003 des NIST ergänzt die Datenherkunft und die „zugrunde liegenden Foundation Models, Versionen der zugrunde liegenden Modelle und Zugriffsarten“. Erfassen Sie den Checkpoint und seine Revision, die Quantisierung, die Version des System-Prompts und die Version des Index, denn jedes davon verändert die Antworten.

GV-1.6-002 fordert Organisationen auf, in ihrer Richtlinie etwaige Ausnahmen vom Inventar für generative KI-Systeme festzulegen, die in Anwendungssoftware eingebettet sind; unser Leitfaden zu Schatten-KI, Richtlinie und Kontrollen behandelt diese Werkzeuge. Möchte die Personalabteilung später Bewerbungen mit der Plattform vorab prüfen, ist das ein neuer Anwendungsfall mit einem neuen Risikoeintrag, denn das Sichten und Filtern von Bewerbungen ist in Anhang III Nummer 4 Buchstabe a des AI Act aufgeführt.

Zugriffsrechte, Protokollierung der Anfragen und Aufbewahrung

Der Zugriff folgt dem Verzeichnis. Jeder Anwendungsfall hat eine Verzeichnisgruppe, das Gateway vergibt Schlüssel je Anwendung und Team, und der RAG-Abruf prüft zum Zeitpunkt der Anfrage die Dokumentberechtigungen des Nutzers, sodass eine Antwort nur auf Dateien beruht, die der Nutzer öffnen darf. Administratorrechte auf dem Gateway, dem Log-Speicher und der Modell-Registry erhalten namentlich benannte Personen, im Einklang mit GOVERN 2.1, das die Dokumentation von Rollen und Verantwortlichkeiten verlangt.

Das Query-Log erfasst je Anfrage den Nutzer oder die Anwendung, die Uhrzeit, den Anwendungsfall, das Modell und seine Version sowie Prompt und Antwort oder nur deren Metadaten, je nachdem, was die Richtlinie festlegt. Protokollierte Prompts können personenbezogene Daten enthalten, deshalb wird die Aufbewahrungsfrist je Anwendungsfall gemeinsam mit dem Datenschutz festgelegt. Für Betreiber von Hochrisiko-KI-Systemen verlangt Artikel 26 Absatz 6 des AI Act, dass die Protokolle, die das System automatisch erzeugt, soweit sie der Kontrolle des Betreibers unterliegen, mindestens sechs Monate aufbewahrt werden, sofern geltendes Unionsrecht oder nationales Recht, insbesondere das Datenschutzrecht der Union, nichts anderes vorsieht; für Nutzungen nach Anhang III gilt das ab dem 2. Dezember 2027. Beschränken Sie den Lesezugriff auf das Log selbst und protokollieren Sie auch diesen Zugriff. Die Technik von Schlüsseln, Budgets und Protokollierung beschreibt unser Leitfaden zu einem LLM-Gateway für ein Unternehmen.

Das Engineering von unserem Engineering-Partner Vixen.UNO deckt Zugriffsrechte, die Protokollierung von Anfragen und den Schutz vor Prompt Injection auf der Plattform ab. Schicken Sie uns die Kontrollen, die Ihr ISO/IEC-42001-Projekt verlangt, über das Formular unten, zusammen mit Ihrem heutigen Aufbau.

Evaluierungsnachweise, Vorfälle und Lieferantennachweise

MEASURE 2.1 verlangt: „Testsets, Metriken und Details zu den während TEVV verwendeten Werkzeugen sind dokumentiert“, und GV-1.5-003 empfiehlt eine Richtlinie zur Aufbewahrung von Dokumenten, die die Historie von Test, Evaluierung, Validierung und Verifizierung festhält. Auf der Plattform bedeutet das ein festes Regressionsset je Anwendungsfall, das vor jeder Änderung von Modell, Prompt oder Serving-Engine läuft, mit Ergebnissen und freigebender Person, die mit dem Release abgelegt werden. Unser Leitfaden zur Evaluierung von LLMs vor Modell-Upgrades behandelt die Metriken und das Release-Verfahren.

Für Vorfälle ergänzen Sie das Ticketsystem, das Sie bereits betreiben, um eine KI-Kategorie. Typische Fälle sind eine falsche Antwort, die in eine Entscheidung eingeflossen ist, ein Dokument, das dem falschen Nutzer angezeigt wurde, eine eingeschleuste Anweisung in einem abgerufenen Dokument und schädliche Ausgaben. GV-4.3-002 fordert Organisationen auf, den Mindestumfang an Kriterien für eine Vorfallmeldung festzulegen, etwa System-ID, Titel, meldende Person und Datum des Vorfalls, und GV-1.5-002 empfiehlt Nachbesprechungen der Vorfallreaktion.

Lieferanten einer On-Premise-Plattform sind die Herausgeber der Modelle, die Open-Source-Projekte hinter der Serving-Engine und der Vektordatenbank, die Hardwarehersteller, der Engineering-Partner und jeder externe API-Anbieter. GV-6.1-007 empfiehlt ein Inventar aller Dritten mit Zugriff auf Inhalte der Organisation und Listen freigegebener Technologien und Dienstleister für generative KI. GV-6.2-002 verlangt, Vorfälle mit Daten und Systemen generativer KI von Dritten zu dokumentieren, „einschließlich Open Data und Open-Source-Software“. Halten Sie für jeden Lieferanten die Komponente, ihre Version und Herkunft, ihre Lizenz und den Kanal fest, über den er Sicherheitshinweise veröffentlicht.

Rollen in der KI-Governance für eine LLM-Plattform

GOVERN 2.3 legt die Verantwortung für Entscheidungen über KI-Risiken bei der Geschäftsleitung, und GOVERN 2.1 verlangt die Dokumentation von Rollen und Kommunikationswegen. Ein Unternehmen mit 200 bis 2.000 Beschäftigten kann Rollen zusammenlegen, solange jede einen benannten Inhaber hat.

Beispielhafte Verteilung; Verantwortung und Dokumentation von Rollen aus NIST AI 100-1, GOVERN 2.1 und 2.3; Führung als Anforderungsbereich aus dem Erklärtext der ISO zu ISO/IEC 42001.

Wie sich ISO/IEC 42001 zum EU AI Act verhält

Der AI Act legt rechtliche Pflichten nach Rolle und nach Nutzung fest, während ISO/IEC 42001 eine freiwillige Norm dafür ist, wie eine Organisation KI steuert. Für einen internen Assistenten, der für Entwürfe, Suche und Zusammenfassungen genutzt wird, gelten heute zwei Pflichten: Maßnahmen, um die Entwicklung der KI-Kompetenz des Personals zu unterstützen, das ihn nutzt (Artikel 4, anwendbar seit dem 2. Februar 2025), und, soweit die Nutzung darunter fällt, die Transparenzpflichten des Artikels 50 (anwendbar seit dem 2. August 2026). Die Hochrisiko-Vorschriften mit den Betreiberpflichten des Artikels 26 knüpfen nur an Nutzungen an, die in Anhang III aufgeführt sind. Nach dem AI Act in der Fassung der Verordnung (EU) 2026/1744, die seit dem 27. Juli 2026 in Kraft ist, gelten sie für diese Nutzungen ab dem 2. Dezember 2027. Das Inventar zeigt, welcher Anwendungsfall in welche Kategorie fällt. Welche Pflichten für einen bestimmten Anwendungsfall gelten, ist eine rechtliche Bewertung für die Rechtsabteilung des Unternehmens, und unser Leitfaden zu den Betreiberpflichten nach dem EU AI Act nennt die Artikel und Termine.

Was wir tun

Unsere Leistung Private AI/ML baut private LLM-Plattformen on-premise oder in einem Tier-3-Rechenzentrum in Litauen in der EU, mit Engineering von unserem Engineering-Partner Vixen.UNO. Die Leistung umfasst den Schutz vor Prompt Injection, die Daten- und Berechtigungsverwaltung und die Protokollierung von Anfragen und Antworten, sodass Security und Legal sehen, wer worauf zugreift und wie. Externe APIs werden nur nach Ihrer ausdrücklichen Entscheidung freigeschaltet und sind im Query-Log sichtbar. Wir liefern den technischen Teil und schulen Ihr Team für den Betrieb der Plattform; die rechtliche Bewertung der Compliance macht Ihre Rechtsabteilung, und eine Zertifizierung erfolgt durch eine unabhängige Zertifizierungsstelle. Wie wir während eines Projekts mit Daten umgehen und welche Zertifikate die Rechenzentren haben, in denen gehostete Lösungen laufen, beschreibt unsere Seite Sicherheit & Compliance.

FAQ