¶ Datenmanagement und Datenqualität für KI – geeignet, nachvollziehbar und beherrscht
Kurz gesagt: Gute Daten sind nicht Daten ohne Fehler, sondern Daten, deren Herkunft, Bedeutung, Rechte, Grenzen und Qualität für einen konkret festgelegten KI-Zweck bekannt und ausreichend sind. Derselbe Datenbestand kann für eine Aufgabe geeignet und für eine andere ungeeignet sein.
Freigabegrundsatz: Daten werden erst für Entwicklung, Test, Wissensabruf oder produktive Nutzung freigegeben, wenn Owner, Herkunft, zulässiger Zweck, Schutzbedarf, Qualitätskriterien, Betroffenengruppen, Version und Lösch- beziehungsweise Aufbewahrungsregeln dokumentiert sind.
Musterstatus: Alle Werte und Datensätze dieser Seite sind fiktiv. Sie belegen weder Datenqualität noch Nutzungsrechte, Rechtmäßigkeit, Repräsentativität oder Freigabe eines realen Datenbestands.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | AIMS-VA-03-02 |
| Dokumentenart | Verfahren und Arbeitsbeispiel für KI-Datenmanagement und Datenqualität |
| Wiki.js-Pfad | /ISO-42001/03-KI-Lebenszyklus-und-Kontrollen/Datenmanagement-und-Datenqualitaet |
| Prozesseigner | Data Owner / KI-Managementbeauftragte/r |
| Operativ verantwortlich | Data Steward, fachlicher KI-Owner und technischer Owner |
| Fachlich beteiligt | Informationssicherheit, Datenschutz, Recht/Compliance, Qualitätsmanagement, IT, Entwicklung, Einkauf und betroffene Fachbereiche |
| Freigabe | Data Owner und fachlicher KI-Owner; zusätzliche Freigaben gemäß Schutzbedarf, Rechtslage und Risikoklasse |
| Status | Entwurf – organisationsbezogene Qualitätsgrenzen, Rollen und Werkzeuge sind festzulegen |
| Version | 0.3 |
| Stand | 10.08.2026 |
| Prüfung | Vor erstmaliger Nutzung, vor wesentlichen Änderungen und regelmäßig anhand von Qualitäts-, Drift- und Vorfallkriterien |
| Schutzklasse | Öffentliches Muster; reale Datenblätter, Stichproben und technische Details regelmäßig Intern bis Streng vertraulich |
| Normbezug | ISO/IEC 42001:2023; ergänzend ISO/IEC 5259-2:2024, ISO/IEC 5259-3:2024, ISO/IEC 5259-4:2024 und ISO/IEC 5259-5:2025 |
| Rechtliche Schnittstellen | Verordnung (EU) 2024/1689, DSGVO, BDSG, Urheber-, Datenbank-, Geheimnis-, Vertrags-, Arbeits- und Branchenrecht |
Daten werden nicht einmalig geprüft, sondern über Herkunft, Freigabe, Nutzung, Monitoring und Änderung beherrscht. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Datenqualität ist immer zweckbezogen
Ein vollständiger und technisch fehlerfreier Datensatz kann ungeeignet sein, wenn er die spätere Nutzergruppe nicht abbildet, zeitlich veraltet ist, eine andere Bedeutung besitzt oder für den beabsichtigten Zweck nicht verwendet werden darf. Deshalb beginnt jede Qualitätsbewertung mit fünf Fragen:
- Welche fachliche Aufgabe soll die KI unterstützen?
- Welche Entscheidung oder Ausgabe entsteht daraus?
- Wer oder was kann von Fehlern betroffen sein?
- Welche Eigenschaften müssen die Daten für genau diesen Zweck besitzen?
- Welche Grenzen und Unsicherheiten bleiben trotz Kontrollen bestehen?
Eine pauschale Aussage wie „Datenqualität: gut“ ist nicht auditfähig. Qualitätsziele werden messbar oder zumindest anhand nachvollziehbarer Akzeptanzkriterien beschrieben.
¶ 2. Datenarten im KI-Lebenszyklus
| Datenart | Zweck | Typisches Risiko |
|---|---|---|
| Trainingsdaten | Modellparameter oder Regeln beeinflussen | Verzerrung, unklare Rechte, Kontamination, veraltete Muster |
| Validierungsdaten | Varianten und Parameter vergleichen | unzulässige Optimierung auf Validierungsdaten |
| Testdaten | unabhängige Leistungsbewertung | Überschneidung mit Training erzeugt zu gute Ergebnisse |
| Eingabedaten | konkreten produktiven Fall bearbeiten | falsches Format, Manipulation, Geheimnisse oder unzulässige Personendaten |
| Referenz-/Wissensdaten | Antworten oder Entscheidungen fachlich erden | veraltete, widersprüchliche oder nicht freigegebene Dokumente |
| Ausgabedaten | Ergebnis, Empfehlung, Klassifikation oder Inhalt | Halluzination, Fehlzuordnung, unangemessene Weiterverwendung |
| Feedbackdaten | Verbesserung und Korrektur ermöglichen | unrepräsentatives oder manipuliertes Feedback |
| Protokoll- und Monitoringdaten | Nachvollziehbarkeit, Sicherheit und Drift erkennen | zu wenig Nachweis oder unverhältnismäßige Überwachung |
| synthetische Daten | reale Daten ergänzen oder ersetzen | künstliche Muster, geringe Realitätsnähe oder verdeckte Ursprungsfehler |
Jede Datenart erhält eine eigene Zweck-, Qualitäts- und Schutzbetrachtung. Testdaten werden nicht nachträglich als Training verwendet, ohne Trennung und Aussagekraft neu zu bewerten.
¶ 3. Rollen und Verantwortlichkeiten
| Rolle | Mindestverantwortung |
|---|---|
| Data Owner | Zweck, zulässige Nutzung, Qualitätsziel, Freigabe und Ressourcen verantworten |
| Data Steward | Datenbeschreibung, Herkunft, Regeln, Qualitätsprüfungen, Abweichungen und Pflege koordinieren |
| fachlicher KI-Owner | Eignung für den Anwendungsfall, Folgen von Fehlern und fachliche Akzeptanz bestimmen |
| technischer Owner | Pipelines, Versionierung, Zugriff, Verarbeitung, Monitoring, Wiederherstellung und Löschung steuern |
| Datenschutz | Personenbezug, Rechtsgrundlage, Transparenz, Zweckbindung, Betroffenenrechte und DSFA prüfen |
| Informationssicherheit | Klassifizierung, CIA-Schutzbedarf, Bedrohungen, Zugriff, Übertragung und Protokollierung bewerten |
| Recht/Compliance | Nutzungsrechte, Lizenzen, Geheimnisse, vertragliche und regulatorische Grenzen prüfen |
| Qualitätsmanagement | Kriterien, Stichproben, Messmittel, Abweichungen und Wirksamkeit unterstützen |
Der technische Besitz einer Datei begründet weder fachliches Eigentum noch Nutzungsrechte. „Im Internet verfügbar“ bedeutet nicht „für Training oder KI-Nutzung freigegeben“.
¶ 4. Datenlebenszyklus und Kontrollpunkte
| Phase | Kernkontrollen | Nachweis |
|---|---|---|
| Beschaffen/Erheben | Quelle, Einwilligung oder andere Grundlage, Vertrag, Lizenz, Zweck und Transparenz | Herkunfts- und Rechtebeleg |
| Übernehmen | Format, Integrität, Schadcode, Dubletten, Klassifizierung und Quarantäne | Importprotokoll und Prüfergebnis |
| Beschreiben | Datenschema, Bedeutung, Population, Zeitraum, Ausschlüsse und bekannte Grenzen | versioniertes Datenblatt |
| Bereinigen/Aufbereiten | Regeln, Transformationen, Kennzeichnung, fehlende Werte und Ausreißer | reproduzierbare Pipeline und Änderungslog |
| Teilen/Trennen | Training, Validierung und Test unabhängig bilden | Split-Logik, Hashes und Leakage-Prüfung |
| Prüfen/Freigeben | Qualitätsziele, Stichproben, Gruppenwirkung, Schutz und Zweckbezug | datierte Freigabeentscheidung |
| Nutzen | zulässige Systeme, Nutzer, Schnittstellen und Verarbeitung kontrollieren | Zugriffs- und Nutzungskonfiguration |
| Überwachen | Drift, Aktualität, Fehler, Beschwerden und neue Gruppen erkennen | Kennzahlen, Schwellen und Reviewprotokoll |
| Archivieren/Löschen | Aufbewahrung, Sperrung, Rückgabe, Löschung und Nachweis regeln | Lösch- oder Archivprotokoll |
¶ 5. Herkunft und Nutzungsrechte
Für jede Quelle werden mindestens dokumentiert:
- Datenlieferant oder interner Ursprung,
- Erhebungszeitraum, Population und ursprünglicher Zweck,
- Lizenz, Vertrag, Einwilligung oder andere Nutzungsgrundlage,
- erlaubte und verbotene Nutzungen, Weitergaben und Modellverwendungen,
- personenbezogene Daten, besondere Kategorien und mögliche Rückschlüsse,
- Geschäftsgeheimnisse, Urheber-, Datenbank- oder Leistungsschutzrechte,
- Unterauftragnehmer, Drittlandbezug und Rückgabe-/Löschpflichten,
- bekannte Bearbeitungen, Filter, Ausschlüsse und Qualitätsprobleme.
Unklare Herkunft ist ein Stop-Kriterium, wenn Rechte, Vertraulichkeit, Integrität oder wesentliche Folgen nicht zuverlässig beurteilt werden können.
¶ 6. Qualitätsdimensionen und Leitfragen
| Dimension | Leitfrage | Beispielkennzahl |
|---|---|---|
| Richtigkeit | Entsprechen Werte und Labels dem tatsächlichen Sachverhalt? | bestätigte Fehler je Stichprobe |
| Vollständigkeit | Sind erforderliche Felder, Fälle und Gruppen vorhanden? | Anteil vollständiger Pflichtfelder |
| Gültigkeit | Entsprechen Werte Format, Typ, Bereich und Geschäftsregel? | Regelverletzungen je 1.000 Datensätze |
| Konsistenz | Sind gleiche Sachverhalte widerspruchsfrei dargestellt? | widersprüchliche Schlüssel oder Klassifikationen |
| Aktualität | Sind Daten für den Zweck zeitlich ausreichend aktuell? | Alter seit letzter fachlicher Bestätigung |
| Eindeutigkeit | Werden identische Fälle unkontrolliert mehrfach geführt? | Dublettenquote |
| Repräsentativität | Bilden Daten relevante Nutzungssituationen und Gruppen angemessen ab? | Abdeckung je Gruppe, Sprache, Gerät oder Kontext |
| Ausgewogenheit | Sind Klassen oder Gruppen so verteilt, dass Leistung fair bewertet werden kann? | Verteilung und Fehlerrate je Teilgruppe |
| Rückverfolgbarkeit | Lassen sich Quelle, Bearbeitung, Version und Freigabe rekonstruieren? | Anteil mit vollständiger Lineage |
| Integrität | Sind unbefugte oder unbeabsichtigte Änderungen erkennbar? | Hash-/Signatur- und Änderungsnachweis |
| Zugänglichkeit | Können berechtigte Prozesse Daten rechtzeitig und zuverlässig nutzen? | Verfügbarkeit und Wiederherstellungszeit |
| Verständlichkeit | Sind Bedeutung, Einheiten, Codes und Grenzen dokumentiert? | Anteil definierter Felder und Klassen |
Nicht jede Dimension erhält dasselbe Gewicht. Für sicherheitskritische Sensordaten können Aktualität und Integrität dominieren; für eine Textsuche sind Quellenfreigabe, Vollständigkeit und Aktualität zentral.
¶ 7. Qualitätsziele und Akzeptanzkriterien
Ein Kriterium enthält Messgegenstand, Methode, Stichprobe, Schwelle, Owner, Häufigkeit und Reaktion.
| Qualitätsziel | Dummy-Schwelle | Messung | Reaktion bei Abweichung |
|---|---|---|---|
| Pflichtfelder vollständig | ≥ 99,0 % | automatischer Importcheck | Import stoppen und Quelle korrigieren |
| bestätigte Labelrichtigkeit | ≥ 97,0 % | geschichtete Doppelprüfung | Nachkennzeichnung und Ursachenanalyse |
| Dubletten | ≤ 0,5 % | Schlüssel- und Ähnlichkeitsprüfung | Dublettenregeln prüfen und bereinigen |
| Quellenalter | ≤ 90 Tage für aktive Anweisungen | Dokumentenstatus abgleichen | Quelle sperren oder erneut freigeben |
| Test-/Trainingsüberschneidung | 0 kritische Überschneidungen | Hash- und Ähnlichkeitsprüfung | Datensplit neu erzeugen; Ergebnisse verwerfen |
| Gruppenabdeckung | alle im Scope relevanten Gruppen ausreichend vertreten | Verteilungsanalyse | Daten ergänzen oder Scope begrenzen |
| Lineage vollständig | 100 % für freigegebene Quellen | Metadatenprüfung | keine Freigabe ohne Herkunftsnachweis |
Schwellen sind keine universellen Normwerte. Sie werden aus Zweck, Risiko, Wirkung, Datenmenge, Messunsicherheit und akzeptiertem Restrisiko begründet.
¶ 8. Datenqualitätsampel
| Prüffeld | 🔴 Rot | 🟡 Gelb | 🟢 Grün |
|---|---|---|---|
| Herkunft | unbekannt oder nicht belegbar | Quelle bekannt, Nachweis lückenhaft | Quelle, Zeitraum, Erhebung und Lineage belegt |
| Rechte/Zweck | Nutzung ungeklärt oder widersprochen | Einschränkungen noch offen | zulässige Nutzung, Grenzen und Weitergabe bestätigt |
| Owner | niemand entscheidet | Rolle benannt, Befugnis offen | Owner und Vertretung bestätigt |
| Beschreibung | Datei ohne Datenblatt | Kerndaten beschrieben | Schema, Population, Zeitraum, Grenzen und Version vollständig |
| Qualität | keine Kriterien | einzelne Kennzahlen ohne Reaktion | zweckbezogene Ziele, Schwellen, Owner und Maßnahmen |
| Repräsentativität | relevante Gruppen unbekannt | Verteilung bekannt, Wirkung offen | Abdeckung und Leistung je relevanter Gruppe geprüft |
| Testtrennung | Überschneidung unbekannt | einfache ID-Prüfung | Leakage- und Ähnlichkeitsprüfung nachvollziehbar |
| Schutz | frei zugänglich oder falsch klassifiziert | Kontrollen teilweise | Klassifizierung, Zugriff, Übertragung, Logging und Löschung wirksam |
| Änderung | stilles Überschreiben | Version vorhanden, Freigabe offen | Version, Ursache, Auswirkung und erneute Freigabe dokumentiert |
| Monitoring | nur bei Beschwerden | Kennzahlen ohne Schwellen | Drift, Fehler, Aktualität und Reaktion laufend gesteuert |
Ein rotes Feld bei Herkunft, Nutzungsrecht, vertraulichen Daten, Integrität oder Testkontamination verhindert die Freigabe.
¶ 9. Muster-Datenblatt mit Dummy-Werten
| Feld | Beispiel |
|---|---|
| Daten-ID | KI-DAT-0012 |
| Bezeichnung | Freigegebene interne Arbeitsanweisungen für Wissensassistent |
| Zweck | Antworten zu aktuellen internen Prozessanweisungen vorbereiten; keine rechtsverbindliche Beratung |
| Owner/Steward | Prozessmanagement / Dokumentenlenkung |
| Quelle | gelenktes Dokumentenmanagement; ausschließlich freigegebene PDF-Fassungen |
| Population/Zeitraum | 184 aktive Dokumente, Stand 01.08.2026 |
| Ausschlüsse | Entwürfe, abgelaufene Fassungen, Personalakten, Kundengeheimnisse und externe Normvolltexte |
| Personenbezug | Namen und dienstliche Kontaktdaten einzelner Freigabeverantwortlicher; Minimierung vorgesehen |
| Schutzklasse | Intern; einzelne Quelldokumente Vertraulich und deshalb nicht im Scope |
| Rechte | interne Nutzung gemäß Dokumentenzweck; keine Nutzung für allgemeines Modelltraining |
| Aufbereitung | Texterkennung, Abschnittsbildung, Metadaten für Dokument-ID, Version, Status und Gültigkeit |
| Qualitätsziele | 100 % freigegebener Status, 100 % Quellenverweis, Aktualität ≤ 7 Tage nach neuer Freigabe |
| bekannte Grenzen | Tabellen und gescannte Anhänge können unvollständig extrahiert werden |
| Freigabe | 🟡 Pilot; nur Antwortentwürfe mit sichtbarem Quellenlink und manueller Prüfung |
| Monitoring | nicht gefundene Quellen, veraltete Antwort, Widerspruch zwischen Dokumenten und Nutzerfeedback |
| Reviewtrigger | neue Dokumentklasse, anderes Sprachmodell, geänderte Berechtigung oder wesentlicher Fehler |
| Löschung/Exit | Index bei Widerruf oder Dokumentablauf innerhalb eines Arbeitstages aktualisieren |
Das Datenblatt wird mit KI-Anwendungsregister, Risiko-/Folgenbewertung und Freigabeakte verknüpft. Es enthält keine vertraulichen Rohdaten im öffentlichen Wiki.
¶ 10. Train-, Validierungs- und Testtrennung
Wenn ein Modell mit seinen späteren Testfällen trainiert wurde, ist die Leistungsmessung nicht unabhängig. Die Trennung berücksichtigt deshalb mehr als identische IDs:
- identische oder nahezu identische Inhalte,
- Ableitungen desselben Ursprungsfalls,
- gleiche Person, Maschine, Kunde oder Zeitreihe in mehreren Splits,
- Vorlagen, Serienbilder oder Textvarianten mit gleichem Kern,
- spätere Rückführung von Testergebnissen in das Training,
- öffentlich bekannte Benchmark-Daten, die bereits Modellwissen sein können.
Split-Logik, Zufallsseed, Gruppierungsregel, Hashes, Version und Ergebnis werden dokumentiert. Bei Kontamination werden betroffene Leistungsnachweise verworfen und mit unabhängigem Material wiederholt.
¶ 11. Kennzeichnung und Ground Truth
Labels sind fachliche Aussagen und können falsch, mehrdeutig oder vom Kontext abhängig sein. Ein Kennzeichnungsprozess regelt:
- Definition jeder Klasse mit Positiv-, Negativ- und Grenzbeispielen,
- Qualifikation und Unabhängigkeit der Kennzeichnenden,
- Umgang mit Unsicherheit, Enthaltung und Mehrdeutigkeit,
- Doppelkennzeichnung und Konfliktentscheidung,
- Messung der Übereinstimmung und Fehlerstichprobe,
- Versionierung geänderter Regeln und Nachkennzeichnung,
- Schutz der Personen, die sensible Inhalte bearbeiten.
„Ground Truth“ wird nicht als absolute Wahrheit behandelt, wenn sie aus menschlicher Bewertung, historischen Entscheidungen oder unvollständigen Messungen stammt.
¶ 12. Repräsentativität, Bias und seltene Fälle
Gesamtgenauigkeit kann erhebliche Unterschiede zwischen Gruppen verdecken. Deshalb werden fachlich relevante Teilgruppen und Nutzungssituationen vor der Messung festgelegt. Dazu können Sprache, Standort, Gerät, Umgebung, Produktvariante, Altersgruppe oder andere rechtlich und fachlich zulässige Merkmale gehören.
Fehlen Daten für eine Gruppe, bestehen vier ehrliche Möglichkeiten:
- Daten kontrolliert ergänzen,
- Zweck oder Zielpopulation begrenzen,
- zusätzliche menschliche oder technische Kontrollen einführen,
- Anwendung nicht freigeben.
Seltene, aber schwerwiegende Fälle werden nicht allein wegen geringer Häufigkeit ignoriert. Tests und Stop-Kriterien berücksichtigen ihre mögliche Wirkung.
¶ 13. Schutz, Datenschutz und Datenminimierung
| Schutzthema | Praktische Kontrolle |
|---|---|
| Vertraulichkeit | Klassifizierung, Rollenrechte, Mandantentrennung, Verschlüsselung und Geheimnisfilter |
| Integrität | signierte oder gehashte Versionen, Vier-Augen-Freigabe, unveränderbares Änderungsprotokoll |
| Verfügbarkeit | gesicherte Pipelines, Wiederherstellung, exportierbare Datenbeschreibung und Fallback |
| Datenschutz | Zweckbindung, Datenminimierung, Rechtsgrundlage, Transparenz, Rechte und Löschkonzept |
| Prompt-/Retrieval-Schutz | Quellenberechtigung bis zur Ausgabe durchsetzen; keine Berechtigungsumgehung durch Indexierung |
| Test- und Entwicklungsumgebung | reale Daten nur nach Freigabe; Maskierung oder synthetische Daten bevorzugen |
| Protokollierung | ausreichend für Nachweis und Vorfallanalyse, aber ohne unverhältnismäßige Vollerfassung |
Eine technische Kopie in einem Vektorindex, Cache, Feature Store oder Trainingsartefakt wird im Lösch- und Berechtigungskonzept berücksichtigt.
¶ 14. Datenänderung und erneute Freigabe
Wesentliche Änderungen sind unter anderem neue Quelle, neue Population, anderes Labelschema, neue Transformation, geänderte Schutzklasse, neue Lizenz, größere zeitliche Verschiebung oder bemerkbarer Drift. Der Änderungsdatensatz enthält:
- alte und neue Version,
- Anlass und verantwortliche Person,
- betroffene Anwendungen und Modelle,
- Auswirkung auf Qualität, Rechte, Risiko und Betroffene,
- erforderliche Wiederholungsprüfungen,
- Freigabe, Rückfalloption und Wirksamkeitskontrolle.
Produktivdaten werden nicht still überschrieben. Anwendungen müssen erkennen können, welche Datenversion einer Ausgabe oder Entscheidung zugrunde lag.
¶ 15. Lieferanten- und externe Daten
Bei externen Daten werden vertraglich und fachlich geprüft:
- Beschreibung, Herkunft, Erhebungs- und Qualitätsprozess,
- Rechte zur KI-, Trainings-, Test- und Weiterverwendung,
- Aktualisierungsfrequenz und Änderungsmitteilung,
- bekannte Lücken, Ausschlüsse und Verzerrungen,
- Unterlieferanten und Herkunftsnachweise,
- Fehlerkorrektur, Support, Audit- und Nachweisrechte,
- Rückgabe, Löschung, Portabilität und Exit.
Ein Qualitätssiegel des Lieferanten ersetzt keine Prüfung der Eignung für den eigenen Zweck.
¶ 16. Monitoring, Drift und Korrektur
| Signal | Bedeutung | Reaktion |
|---|---|---|
| Datenverteilung ändert sich | Population oder Prozess hat sich verschoben | Auswirkung analysieren, Modell und Kriterien neu prüfen |
| Fehlerrate steigt | Qualität, Modell oder Anwendungskontext verändert | Scope begrenzen und Ursache untersuchen |
| Quellen werden ungültig | Wissensbasis enthält veraltete Inhalte | Quelle sperren, Index aktualisieren und betroffene Ausgaben prüfen |
| Gruppenunterschied wächst | mögliche Benachteiligung | vertiefte Folgenbewertung und gegebenenfalls Aussetzung |
| unbekannte Kategorien häufen sich | Schema oder Taxonomie reicht nicht aus | Klassenmodell und Kennzeichnungsregel überarbeiten |
| manuelle Korrekturen steigen | Daten- oder Workflowproblem | Trend, Ursache und Wirksamkeit der Aufsicht bewerten |
Schwellenwerte, Beobachtungszeitraum, Owner und Reaktionszeit werden vor der produktiven Freigabe festgelegt.
¶ 17. Nachweise und Managementkennzahlen
¶ Mindestnachweise
- Dateninventar und versioniertes Datenblatt,
- Herkunfts-, Rechte- und Vertragsnachweise,
- Schema, Datenwörterbuch und Transformationslogik,
- Qualitätsplan, Messprotokolle und Stichprobenergebnisse,
- Repräsentativitäts- und Gruppenanalyse,
- Split-, Leakage- und Kontaminationsprüfung,
- Schutz-, Zugriffs-, Übertragungs- und Löschkonzept,
- Freigabe, Auflagen, Abweichungen und Korrekturmaßnahmen,
- Drift-, Fehler-, Beschwerde- und Änderungsnachweise.
¶ Kennzahlen
| Kennzahl | Steuerungsaussage |
|---|---|
| Datenbestände ohne Owner oder Datenblatt | fehlende Verantwortung und Transparenz |
| Quellen ohne belegte Rechte | mögliches Stop-Kriterium |
| Qualitätsziele außerhalb Schwelle | Eignung und Freigabe neu bewerten |
| überfällige Aktualisierung | steigendes Risiko veralteter Ergebnisse |
| Datenabweichungen ohne Maßnahme | schwacher Korrekturprozess |
| produktive Anwendungen ohne Lineage | Entscheidungen nicht rekonstruierbar |
| Drift-Alarme bis Reaktion | Wirksamkeit des Monitorings |
| Löschungen innerhalb Sollfrist | Datenlebenszyklus tatsächlich beherrscht |
¶ 18. Interne Verknüpfungen
- ISO/IEC 42001 – KI-Managementsystem
- KI-Anwendungsregister
- KI-Risiko- und Folgenbewertung
- KI-Freigabe und menschliche Aufsicht
- KI-Systemlebenszyklus und Änderungsmanagement
- KI-Transparenz, Kennzeichnung und Kommunikation
- Informationsklassifizierung
- Asset-Inventar
- Sichere Entwicklung
- Datenschutz-Folgenabschätzung
- Technische und organisatorische Maßnahmen
¶ 19. Offizielle Quellen und Abgrenzung
- ISO: ISO/IEC 42001:2023 – AI management systems
- ISO: ISO/IEC 5259-2:2024 – Data quality measures
- ISO: ISO/IEC 5259-3:2024 – Data quality management requirements and guidelines
- ISO: ISO/IEC 5259-4:2024 – Data quality process framework
- ISO: ISO/IEC 5259-5:2025 – Data quality governance framework
- EUR-Lex: Verordnung (EU) 2024/1689
Diese Seite beschreibt eine eigene organisatorische Methode und ersetzt weder lizenzierte Normtexte noch eine Rechtsberatung. Qualitätsmerkmale, Schwellenwerte und gesetzliche Anforderungen werden für den konkreten Zweck und aktuellen Rechtsstand fachlich festgelegt.
¶ 20. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Erstfassung mit Datenlebenszyklus, Rollen, Qualitätsdimensionen, Messkriterien, Ampel, Dummy-Datenblatt, Split-/Label-/Bias-Kontrollen, Schutz, Drift und Nachweisen | Musterredaktion | Ausstehend | – |
| 0.2 | 10.08.2026 | Systemlebenszyklus und Änderungsmanagement als technische Änderungs- und Baseline-Schnittstelle verknüpft | Musterredaktion | Ausstehend | – |
| 0.3 | 10.08.2026 | Transparenz-, Kennzeichnungs- und Kommunikationsverfahren als Schnittstelle für Datenherkunft, Grenzen und Ausgaben verknüpft | Musterredaktion | Ausstehend | – |
Seite 1 von 1 · AIMS-VA-03-02 · Version 0.3