¶ KI-Anwendungsregister – KI-Systeme transparent und kontrolliert steuern
Kurz gesagt: Das KI-Anwendungsregister ist die zentrale Übersicht aller geplanten, getesteten, eingesetzten und außer Betrieb genommenen KI-Anwendungsfälle. Es beantwortet nicht nur, welches Produkt vorhanden ist, sondern wer es wofür, mit welchen Daten, in welcher Rolle, unter welchen Bedingungen und mit welchen Nachweisen nutzen darf.
Wichtiger Grundsatz: Ein Werkzeug kann mehrere Registereinträge benötigen. Wird derselbe KI-Dienst beispielsweise für Marketingtexte, Bewerberauswahl und Vertragsprüfung verwendet, unterscheiden sich Zweck, Daten, Auswirkungen, Rechtslage, Kontrollen und Freigabe erheblich.
Musterstatus: Die nachfolgenden Einträge und Bewertungen sind fiktive Beispiele. Sie bestätigen weder eine rechtliche Einstufung noch die Freigabe, Konformität oder Wirksamkeit eines realen KI-Systems.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | AIMS-REG-02-01 |
| Dokumentenart | Methodik und Muster eines KI-Anwendungsregisters |
| Wiki.js-Pfad | /ISO-42001/02-KI-Risiken-und-Auswirkungen/KI-Anwendungsregister |
| Prozesseigner | KI-Managementbeauftragte/r / AIMS-Verantwortliche/r |
| Eintragspflicht | Fachliche Owner, IT, Entwicklung, Einkauf und Projektverantwortliche vor Test, Beschaffung oder produktiver Nutzung |
| Fachlich beteiligt | Informationssicherheit, Datenschutz, Recht/Compliance, Qualitätsmanagement, Personal, Betriebsrat und betroffene Fachbereiche |
| Freigabe | Nach Kritikalität durch Fachverantwortung, AIMS-Verantwortung, Informationssicherheit, Datenschutz, Recht/Compliance und gegebenenfalls Geschäftsführung |
| Status | Entwurf – organisationsbezogene Ausgestaltung und Freigabe ausstehend |
| Version | 0.8 |
| Stand | 10.08.2026 |
| Prüfung | Mindestens jährlich sowie ereignisbezogen bei wesentlichen Änderungen, Vorfällen, neuen Zwecken, Daten, Modellen, Lieferanten oder Rechtsanforderungen |
| Schutzklasse | Öffentliches Muster; das betriebliche Register ist regelmäßig Intern bis Streng vertraulich |
| Normbezug | ISO/IEC 42001:2023; ergänzend ISO/IEC 23894:2023 und ISO/IEC 42005:2025 |
| Rechtliche Schnittstellen | Verordnung (EU) 2024/1689, DSGVO, BDSG, Arbeits-, Urheber-, Geheimnis-, Produkt- und Branchenrecht |
Das Register begleitet jeden KI-Anwendungsfall von der ersten Idee bis zur Außerbetriebnahme. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Warum eine Produktliste nicht genügt
Eine reine Liste mit Bezeichnungen wie „ChatGPT“, „Copilot“ oder „Bewerbertool“ ist für Governance und Audit nicht ausreichend. Der Risikokontext entsteht erst aus der tatsächlichen Verwendung. Entscheidend sind insbesondere:
- der konkrete geschäftliche Zweck und die erwartete Entscheidung,
- die Rolle der Organisation in der KI-Wertschöpfungskette,
- Eingabe-, Trainings-, Referenz- und Ausgabedaten,
- betroffene Personen, Prozesse und Schutzgüter,
- mögliche Fehlanwendungen und vernünftigerweise vorhersehbare Auswirkungen,
- menschliche Aufsicht und wirksame Eingriffsmöglichkeiten,
- technische, organisatorische, vertragliche und rechtliche Kontrollen,
- Tests, Freigaben, Auflagen, Änderungen und Überwachungsnachweise.
Das Register ist damit kein Selbstzweck. Es verbindet KI-Governance, Risiko- und Folgenbewertung, Datenschutz, Informationssicherheit, Lieferantensteuerung, Kompetenz, Vorfallmanagement und Audit zu einer nachvollziehbaren Nachweiskette.
¶ 2. Abgrenzung: System, Modell und Anwendungsfall
| Ebene | Beispiel | Registerlogik |
|---|---|---|
| KI-Modell | Sprachmodell eines externen Anbieters | Als technische Grundlage und Version erfassen; nicht automatisch eigener Anwendungsfall |
| KI-System oder Dienst | Cloud-Assistent mit Benutzerverwaltung und Schnittstellen | Anbieter, Betriebsmodell, Verträge, technische Konfiguration und Änderungen dokumentieren |
| KI-Anwendungsfall | Zusammenfassung interner Besprechungen | Eigener Eintrag mit Zweck, Daten, Owner, Risiken, Freigabe und Aufsicht |
| Weitere Verwendung desselben Dienstes | Vorauswahl von Bewerbungen | Separater Eintrag, weil Betroffene, Auswirkungen, Rechtslage und Kontrollen wesentlich abweichen |
Praxisregel: Ein neuer oder wesentlich veränderter Zweck führt regelmäßig zu einem neuen Eintrag oder mindestens zu einer erneuten Bewertung und Freigabe. Sammelbezeichnungen wie „allgemeine Büro-KI“ verhindern eine belastbare Risikosteuerung.
¶ 3. Steuerungsprozess des Registers
| Schritt | Verantwortliche Aktivität | Ergebnis und Nachweis |
|---|---|---|
| 1. Erfassen | Anwendungsfall vor Test, Beschaffung, Entwicklung oder produktiver Nutzung melden | eindeutige KI-ID, Zweck, Owner, System, Daten und vorläufiger Status |
| 2. Einstufen | Rolle, Betroffene, Schutzbedarf, Kritikalität und rechtliche Prüfbedarfe bestimmen | dokumentierte Erstindikation mit offenen Prüfpunkten |
| 3. Bewerten | KI-Risiken, Auswirkungen, Datenschutz, Sicherheit, Qualität und Lieferanten beurteilen | verknüpfte Bewertungen und geplanter Kontrollsatz |
| 4. Freigeben | Restrisiko, Auflagen, Nutzungsgrenzen, Kompetenz und Nachweise entscheiden | datierte Entscheidung mit Befugnis, Gültigkeit und Reviewtermin |
| 5. Überwachen | Leistung, Fehler, Beschwerden, Vorfälle, Änderungen und Auflagen verfolgen | Monitoring-, Änderungs-, Vorfall- und Reviewnachweise |
| 6. Beenden | Daten, Zugänge, Schnittstellen, Verträge und Abhängigkeiten kontrolliert zurückbauen | Ausstiegsentscheidung und Lösch-/Rückgabenachweis |
Eine Nutzung ohne Registereintrag wird organisationsbezogen als nicht freigegebene KI-Nutzung behandelt. Ein vorhandener Eintrag ist umgekehrt noch keine Freigabe: Maßgeblich ist der dokumentierte Status.
¶ 4. Vollständiges Feldmodell
¶ 4.1 Identität und Verantwortung
| Feld | Erwarteter Inhalt | Qualitätskriterium |
|---|---|---|
| KI-ID | dauerhaft eindeutige Kennung, z. B. KI-ANW-0007 |
nicht wiederverwenden, auch nicht nach Stilllegung |
| Bezeichnung | verständlicher Name des Anwendungsfalls | Zweck erkennbar; keine reine Produktbezeichnung |
| Fachlicher Zweck | gewünschter Nutzen, Prozess und Ergebnis | konkret, überprüfbar und von unerwünschten Zwecken abgegrenzt |
| Fachlicher Owner | verantwortliche Person oder Rolle | besitzt Entscheidungskompetenz und kennt den Prozess |
| Technischer Owner | Betrieb, Konfiguration, Integration und Änderungen | interne oder externe Zuständigkeit eindeutig |
| Organisationseinheit und Standort | nutzende Bereiche und räumlicher Scope | Pilotbereiche von freigegebenem Scope unterscheiden |
| Lebenszyklusstatus | Idee, Prüfung, Pilot, freigegeben, ausgesetzt oder beendet | Statusänderung datiert und begründet |
¶ 4.2 System, Anbieter und Betriebsmodell
| Feld | Erwarteter Inhalt | Qualitätskriterium |
|---|---|---|
| Anbieter und Produkt | juristische Einheit, Produkt, Tarif und Version | Marketingname allein reicht nicht |
| Modell oder technische Grundlage | Modellfamilie, Version oder dokumentierte Unbekannte | Änderungen und fehlende Transparenz sichtbar machen |
| Betriebsmodell | lokal, private Cloud, SaaS, API oder eingebettete Funktion | Mandant, Region und Datenflüsse benennen |
| Schnittstellen | Quell-, Ziel- und Drittsysteme | automatisierte Aktionen und Schreibrechte hervorheben |
| Unterauftragnehmer | wesentliche Unterauftragnehmer und Modellanbieter | Vertrags- und Änderungsprozess verknüpfen |
| Vertrags-/Lizenzbezug | Vertrag, Nutzungsbedingungen, AVV und Leistungsbeschreibung | gültige Fassung und verantwortliche Ablage referenzieren |
¶ 4.3 Daten und betroffene Personen
| Feld | Erwarteter Inhalt | Qualitätskriterium |
|---|---|---|
| Eingabedaten | Datenarten, Quellen, Format und Herkunft | personenbezogene, vertrauliche und urheberrechtlich geschützte Inhalte kennzeichnen |
| Ausgabedaten | erzeugte Inhalte, Prognosen, Empfehlungen oder Entscheidungen | Weiterverwendung und Empfänger beschreiben |
| Betroffenengruppen | Beschäftigte, Bewerbende, Kunden, Lieferanten oder Öffentlichkeit | indirekt Betroffene und vulnerable Gruppen berücksichtigen |
| Speicher- und Trainingsnutzung | Protokollierung, Aufbewahrung, Anbietertraining und Löschung | vertragliche Aussage mit technischer Konfiguration abgleichen |
| Informationsklassifizierung | Schutzklasse und CIA-Bedarf | Vertraulichkeit, Integrität und Verfügbarkeit begründet bewerten |
| Datenqualität | Relevanz, Vollständigkeit, Aktualität und Repräsentativität | für den konkreten Zweck messbare Kriterien festlegen |
¶ 4.4 Recht, Risiko und Auswirkungen
| Feld | Erwarteter Inhalt | Qualitätskriterium |
|---|---|---|
| Organisationsrolle | z. B. Anbieter, Betreiber, Importeur oder Händler | tatsächliche Tätigkeit statt Selbstdarstellung des Lieferanten bewerten |
| AI-Act-Erstindikation | verboten, hochriskant, Transparenzfall, GPAI-Bezug oder sonstiger Fall | Ergebnis datieren, begründen und als Erstindikation kennzeichnen |
| Datenschutzprüfung | Zweck, Rechtsgrundlage, Verantwortlichkeit, AVV, DSFA-Screening | Verweis auf freigegebenen Datenschutzprozess |
| KI-Risikobewertung | Ursachen, Ereignisse, Auswirkungen, Kontrollen und Restrisiko | Informationssicherheit, Qualität, Recht, Menschen und Gesellschaft einbeziehen |
| Folgenbewertung | beabsichtigte und unbeabsichtigte Wirkungen | Perspektive der Betroffenen und vernünftigerweise vorhersehbare Nutzung einbeziehen |
| Menschliche Aufsicht | prüfende Rolle, Befugnisse, Information, Eingriff und Eskalation | Aufsicht muss Ergebnis verstehen, ablehnen, stoppen oder korrigieren können |
| Freigabeentscheidung | freigegeben, mit Auflagen, abgelehnt oder ausgesetzt | Entscheider, Datum, Scope, Auflagen, Gültigkeit und Restrisiko dokumentieren |
¶ 4.5 Betrieb, Überwachung und Nachweise
| Feld | Erwarteter Inhalt | Qualitätskriterium |
|---|---|---|
| Zulässige und untersagte Nutzung | konkrete Use Cases, Daten und Handlungen | für Nutzende verständlich und technisch soweit möglich durchgesetzt |
| Testkriterien | Qualität, Robustheit, Sicherheit, Bias, Datenschutz und Aufsicht | Sollwert, Testdaten, Ergebnis und Entscheidung nachvollziehbar |
| Monitoring | Leistung, Fehler, Drift, Beschwerden, Missbrauch und Vorfälle | Schwellenwerte und Eskalation festgelegt |
| Änderungsereignisse | Modell-, Daten-, Prompt-, Schnittstellen-, Anbieter- oder Zweckänderung | Auslöser für erneute Bewertung definiert |
| Reviewtermin | reguläre und ereignisbezogene Prüfung | überfällige Einträge sichtbar und eskaliert |
| Nachweislinks | Bewertungen, Verträge, Tests, Freigaben, Schulungen und Protokolle | kontrollierte Ablage statt ungeschützter Anlagen im öffentlichen Wiki |
¶ 5. Status- und Freigabelogik
| Status | Bedeutung | Zulässige Nutzung |
|---|---|---|
| ⚪ Idee | Bedarf oder Möglichkeit wurde gemeldet | keine Nutzung mit realen Unternehmens- oder Personendaten |
| 🔵 In Prüfung | Owner und Prüfteam bearbeiten Einstufung und Bewertungen | nur kontrollierte Prüfung in freigegebener Testumgebung |
| 🟡 Pilot mit Auflagen | begrenzter Scope, Zeitraum und Nutzerkreis sind genehmigt | ausschließlich innerhalb dokumentierter Pilotbedingungen |
| 🟢 Freigegeben | Kontrollen, Kompetenz, Nachweise und Restrisiko wurden entschieden | Nutzung innerhalb des benannten Zwecks und Scopes |
| 🟠 Freigabe eingeschränkt | Auflagen verletzt, Änderung offen oder Review überfällig | nur ausdrücklich erlaubte Restnutzung; Eskalation erforderlich |
| 🔴 Ausgesetzt oder abgelehnt | Risiko, Vorfall oder fehlende Grundlage verhindert Nutzung | Nutzung stoppen; Zugänge und Schnittstellen sichern |
| ⚫ Außer Betrieb | Anwendung wurde kontrolliert beendet | keine aktive Nutzung; Nachweise nach Aufbewahrungsregel erhalten |
Keine automatische Freigabe: Eine grüne Ampel darf nur aus einer dokumentierten Entscheidung entstehen. Vollständige Felder oder ein niedriger technischer Risikowert ersetzen keine rechtliche, fachliche oder unternehmerische Freigabe.
¶ 6. Beispielregister mit Dummy-Daten
| KI-ID | Anwendungsfall | Rolle / Erstindikation | Daten und Auswirkung | Owner | Status | Nächste Aktion |
|---|---|---|---|---|---|---|
| KI-ANW-0001 | Website-Chatbot für allgemeine Produktfragen | Betreiber; Transparenzpflicht prüfen | öffentliche Produktdaten; Interaktion mit Interessenten | Marketingleitung | 🟢 Freigegeben mit Zweckgrenze | Kennzeichnung und Antwortqualität quartalsweise prüfen |
| KI-ANW-0002 | Besprechungen transkribieren und zusammenfassen | Betreiber; Datenschutz-/Mitbestimmungsprüfung offen | Stimmen, Namen, Gesprächsinhalte und mögliche Geschäftsgeheimnisse | Bereichsleitung Vertrieb | 🟡 Pilot mit Auflagen | Einwilligungs-/Rechtsgrundlagenkonzept, Löschung und Anbietertraining nachweisen |
| KI-ANW-0003 | Bewerbungen bewerten und priorisieren | mögliche Hochrisiko-Konstellation; vertiefte Prüfung erforderlich | Bewerberdaten; mögliche Auswirkung auf Zugang zu Beschäftigung | Personalleitung | 🔴 Nutzung ausgesetzt | Rechts-, DSFA-, Bias- und Human-Oversight-Prüfung durchführen |
| KI-ANW-0004 | Wartungsbedarf von Maschinen prognostizieren | Betreiber; Produkt-/Sicherheitsbezug prüfen | Maschinensensorik; mögliche Auswirkung auf Verfügbarkeit und Arbeitssicherheit | Produktionsleitung | 🟢 Freigegeben mit Auflagen | Fehlalarmrate, Ausfälle und manuelle Gegenprüfung überwachen |
Die Einstufungen sind bewusst als Erstindikation formuliert. Ob gesetzliche Pflichten greifen, hängt von der tatsächlichen Funktion, Rolle, Verwendung, technischen Ausgestaltung und jeweils geltenden Rechtslage ab.
¶ 7. Muster eines Detaildatensatzes
| Feld | Dummy-Beispiel KI-ANW-0002 |
|---|---|
| Zweck | Interne Besprechungen nach vorheriger Information der Teilnehmenden transkribieren und Entwürfe für Ergebnisprotokolle erstellen |
| Nicht zulässig | heimliche Aufzeichnung; Leistungs- oder Verhaltensbewertung; automatische Personalentscheidung; Eingabe besonders geschützter Inhalte ohne Einzelfreigabe |
| Anbieter/Betrieb | Beispiel Cloud GmbH, EU-Mandant, SaaS; konkrete Unterauftragnehmer noch zu verifizieren |
| Daten | Audio, Namen, Rollen, Gesprächsinhalte; Schutzklasse abhängig vom Termin, mindestens Intern |
| Menschliche Aufsicht | Sitzungsleitung prüft Vollständigkeit, Fehlzuordnungen und sensible Inhalte; Veröffentlichung erst nach Freigabe |
| Wesentliche Risiken | fehlende Einwilligung/Information, Offenlegung vertraulicher Inhalte, falsche Zuordnung, unzulässiges Anbietertraining, unkontrollierte Speicherung |
| Kontrollen | definierte Terminarten, Teilnehmendeninformation, Aufzeichnungsanzeige, EU-Konfiguration, Training deaktiviert, Rollenrechte, Löschfrist, manuelle Protokollfreigabe |
| Pilotgrenze | zehn benannte Nutzer, drei Monate, keine Personalgespräche oder Kundengeheimnisse |
| Nachweise | DSFA-Screening, AVV, Konfigurationsnachweis, Pilotfreigabe, Schulungsnachweise, Testprotokoll und Löschtest |
| Reviewauslöser | neuer Anbieter/Modellversion, geänderter Zweck, automatische Aufgabenverteilung, Vorfall, Beschwerde oder Ablauf der Pilotfrist |
¶ 8. Rollen und Verantwortlichkeiten
| Rolle | Mindestverantwortung |
|---|---|
| Fachlicher Owner | Zweck, Nutzen, Nutzungsgrenzen, Prozessintegration, fachliche Tests und laufende Überwachung |
| Technischer Owner | Architektur, Konfiguration, Zugriffe, Schnittstellen, Protokollierung, Änderungen und Ausstieg |
| AIMS-Verantwortung | Registermethodik, Vollständigkeit, Koordination, Statuslogik, Reviews und Managementbericht |
| Informationssicherheit | Schutzbedarf, Bedrohungen, Kontrollen, Lieferanten- und Vorfallanforderungen |
| Datenschutz | Rollen, Rechtsgrundlage, Transparenz, Betroffenenrechte, AVV, Drittland und DSFA |
| Recht/Compliance | AI-Act-Rolle, Risikokategorie, weitere Rechtsgebiete, Vertrags- und Freigabeauflagen |
| Personal/Betriebsrat | Beschäftigtendaten, Mitbestimmung, Kompetenz und faire Verwendung im Arbeitskontext |
| Geschäftsführung | Politik, Ressourcen, Risikokriterien und Entscheidungen oberhalb definierter Schwellen |
Der Lieferant ist keine interne Freigabestelle. Zertifikate, Sicherheitsinformationen und Vertragszusagen sind Eingaben für die Bewertung, ersetzen aber nicht die organisationsbezogene Prüfung des konkreten Einsatzes.
¶ 9. Qualitätsampel für einen Registereintrag
| Prüfkriterium | 🔴 Rot | 🟡 Gelb | 🟢 Grün |
|---|---|---|---|
| Zweck | allgemein oder nachträglich konstruiert | Zweck benannt, Grenzen unklar | konkreter Prozess, Ergebnis und Ausschlüsse dokumentiert |
| Owner | unbekannt | Rolle benannt, Befugnis offen | verantwortliche und vertretende Rolle bestätigt |
| Daten | „keine sensiblen Daten“ ohne Analyse | Datenarten teilweise bekannt | Quellen, Schutzklasse, Betroffene, Speicherung und Training geklärt |
| Rolle/Recht | Lieferantenaussage übernommen | Erstindikation ohne Abschluss | datierte, begründete Prüfung mit Verweisen und offenen Punkten |
| Risiko/Wirkung | nicht bewertet | Einzelbewertungen ohne Verbindung | Risiko, Folgen, Datenschutz und Sicherheit konsistent verknüpft |
| Aufsicht | „Mensch prüft“ | Rolle vorhanden, Kriterien fehlen | kompetente Person mit Information, Zeit, Befugnis und Eskalation |
| Tests | Demo war erfolgreich | technische Funktion geprüft | Sollwerte, Grenzfälle, Sicherheit und Auswirkungen nachweisbar getestet |
| Freigabe | Nutzung faktisch gestartet | mündliche oder undatierte Zustimmung | Scope, Auflagen, Entscheider, Restrisiko und Gültigkeit dokumentiert |
| Monitoring | nur bei Beschwerden | Kennzahlen ohne Schwellenwerte | Kriterien, Verantwortliche, Schwellen und Maßnahmen festgelegt |
| Änderung/Ausstieg | nicht geregelt | manuelle Einzelfallreaktion | Trigger, Neubewertung, Sperrung, Export, Löschung und Exit definiert |
Entscheidungsregel: Ein rotes Feld verhindert die produktive Freigabe, wenn es Verantwortung, rechtliche Zulässigkeit, verbotene Verwendung, Schutz vertraulicher Daten, menschliche Aufsicht oder wesentliche Sicherheitskontrollen betrifft. Gelbe Felder werden als Auflage mit Termin und Verantwortlichkeit geführt.
¶ 10. Verknüpfte Register und Nachweise
| Verknüpfung | Warum erforderlich |
|---|---|
| Asset-Inventar | KI-Dienst, Datenbestände, Schnittstellen und Verantwortungen in der Informationssicherheit verankern |
| ISMS- und Datenschutz-Risikoregister | gemeinsame Ursachen und Maßnahmen synchronisieren, ohne Risiken doppelt und widersprüchlich zu führen |
| Verzeichnis von Verarbeitungstätigkeiten | personenbezogene Verarbeitung, Zwecke, Empfänger, Fristen und TOM konsistent halten |
| DSFA und KI-Folgenbewertung | Datenschutzrisiken und weitergehende Auswirkungen getrennt, aber verknüpft bewerten |
| Lieferantenregister | Verträge, Unterauftragnehmer, Leistungsänderungen, Vorfälle, Audit- und Exitrechte steuern |
| Schulungsregister | Kompetenz der Nutzenden, Owner, Aufsicht und Prüfenden nachweisen |
| Freigabe- und Änderungsregister | Entscheidungen, Versionen, Auflagen und Neubewertungen nachvollziehbar halten |
| Vorfallregister | Fehler, Missbrauch, Beschwerden, Datenschutz- und Sicherheitsereignisse dem Anwendungsfall zuordnen |
¶ 11. Aufbewahrung und Schutz des betrieblichen Registers
Das vollständige Register kann Sicherheitsarchitektur, Geschäftsgeheimnisse, Beschäftigtendaten, Verträge, Schwachstellen und noch nicht veröffentlichte Projekte enthalten. Deshalb gilt:
- Im öffentlichen Wiki stehen nur Methodik, leere Feldmodelle und eindeutig bezeichnete Dummy-Beispiele.
- Das betriebliche Register wird in einem geschützten System mit Rollenrechten, Versionierung und Sicherung geführt.
- Nachweise werden verlinkt statt unkontrolliert in einzelne Registerzellen kopiert.
- Berechtigte Änderungen erzeugen eine nachvollziehbare Historie; Status und Freigaben dürfen nicht still überschrieben werden.
- Aufbewahrung und Löschung richten sich nach Rechts-, Vertrags-, Beweis- und Managementsystemanforderungen.
- Eine exportierbare Notfallfassung unterstützt Verfügbarkeit, Audit und Anbieterwechsel.
¶ 12. Kennzahlen für das Management-Cockpit
| Kennzahl | Aussage und mögliche Eskalation |
|---|---|
| Anteil erfasster KI-Anwendungsfälle | Abgleich mit Softwarebestand, Beschaffung, Projekten und Umfragen zeigt mögliche Schatten-KI |
| Einträge ohne bestätigten Owner | fehlende Verantwortung; kurzfristig zu schließen |
| Nutzung ohne gültige Freigabe | kritische Governance-Abweichung |
| Überfällige Reviews | Risiko veralteter Einstufungen und Kontrollen |
| Offene rote Qualitätsfelder | produktive Nutzung grundsätzlich zu stoppen oder zu eskalieren |
| Auflagen nach Fälligkeit | Wirksamkeit und Verantwortlichkeit fraglich |
| Wesentliche Änderungen ohne Neubewertung | Änderungsmanagement funktioniert nicht zuverlässig |
| Vorfälle und Beschwerden je Anwendungsfall | Häufung, Trend und Wirksamkeit der Maßnahmen bewerten |
| Geschulte Personen in kritischen Rollen | Kompetenzlücken bei Ownern, Nutzenden und menschlicher Aufsicht erkennen |
Kennzahlen werden nicht nur gezählt. Für Abweichungen werden Ursache, Verantwortlichkeit, Termin, Maßnahme und Wirksamkeitsprüfung dokumentiert.
¶ 13. Interne Verknüpfungen
- ISO/IEC 42001 – KI-Managementsystem
- KI-Risiko- und Folgenbewertung
- KI-Freigabe und menschliche Aufsicht
- Datenmanagement und Datenqualität
- KI-Systemlebenszyklus und Änderungsmanagement
- KI-Transparenz, Kennzeichnung und Kommunikation
- KI-Lieferanten und Drittanbietersteuerung
- KI-Kompetenz, Schulung und Befähigungsnachweise
- Einsatz von KI im Unternehmen
- KI und automatisierte Verarbeitung
- Asset-Inventar
- ISMS-Risikoregister
- Datenschutz-Risikoregister
- Datenschutz-Folgenabschätzung
- Lieferanten und Dienstleister
- Informationsklassifizierung
- Dokumentenlenkung
¶ 14. Offizielle Quellen und Abgrenzung
- ISO: ISO/IEC 42001:2023 – AI management systems
- ISO: ISO/IEC 42005:2025 – AI system impact assessment
- ISO: ISO/IEC 23894:2023 – Guidance on risk management
- EUR-Lex: Verordnung (EU) 2024/1689
- EU-Kommission: Orientierung zu Rollen, Pflichten und Anwendungszeitpunkten
Diese Seite gibt Norminhalte in eigenen Worten wieder und ersetzt weder die lizenzierte Norm noch eine Rechtsberatung. Gesetzliche Einstufungen werden anhand der tatsächlichen Anwendung und des jeweils aktuellen Rechtsstands fachlich geprüft.
¶ 15. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Erstfassung mit Feldmodell, Statuslogik, Dummy-Register, Detaildatensatz, Qualitätsampel, Rollen, Nachweisen und Kennzahlen | Musterredaktion | Ausstehend | – |
| 0.2 | 10.08.2026 | KI-Risiko- und Folgenbewertung als methodische Folgeseite verknüpft | Musterredaktion | Ausstehend | – |
| 0.3 | 10.08.2026 | Freigabe- und Aufsichtsverfahren als nächste Lifecycle-Seite verknüpft | Musterredaktion | Ausstehend | – |
| 0.4 | 10.08.2026 | Datenmanagement und Datenqualität als Daten-Nachweis des Anwendungsfalls verknüpft | Musterredaktion | Ausstehend | – |
| 0.5 | 10.08.2026 | Systemlebenszyklus und Änderungsmanagement als technische Lifecycle-Akte verknüpft | Musterredaktion | Ausstehend | – |
| 0.6 | 10.08.2026 | Transparenzprofil, Kennzeichnung und Kommunikation als anwendungsbezogene Nachweisschnittstelle verknüpft | Musterredaktion | Ausstehend | – |
| 0.7 | 10.08.2026 | KI-Lieferanten- und Drittanbietersteuerung als führende Anbieter-, Service- und Kettenschnittstelle verknüpft | Musterredaktion | Ausstehend | – |
| 0.8 | 10.08.2026 | Kompetenzrollen, Lernpfade und Befähigungsstatus als personelle Nachweisschnittstelle des KI-Anwendungsfalls verknüpft | Musterredaktion | Ausstehend | – |
Seite 1 von 1 · AIMS-REG-02-01 · Version 0.8