¶ KI-Freigabe und menschliche Aufsicht – entscheiden, eingreifen und stoppen können
Kurz gesagt: Eine KI-Anwendung ist erst freigegeben, wenn Zweck, Scope, Daten, Risiken, Auswirkungen, Kontrollen, Kompetenz und Überwachung nachvollziehbar geprüft wurden und eine befugte Stelle die Nutzung schriftlich entschieden hat. Der Eintrag in einem Register, ein erfolgreicher Funktionstest oder die Zustimmung eines Lieferanten sind noch keine Freigabe.
Menschliche Aufsicht ist eine Fähigkeit – kein Häkchen: Die zuständige Person benötigt verständliche Informationen, ausreichende Zeit, fachliche Kompetenz, echte Entscheidungsfreiheit und technische wie organisatorische Möglichkeiten, Ergebnisse abzulehnen, zu korrigieren, die Nutzung einzuschränken oder das System zu stoppen.
Musterstatus: Die folgenden Rollen, Schwellenwerte und Beispiele sind fiktiv. Sie müssen an Organisation, Rechtslage, KI-Rolle, Kritikalität und tatsächliche Anwendung angepasst und formal freigegeben werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | AIMS-VA-03-01 |
| Dokumentenart | Verfahren zur Freigabe, Aufsicht, Änderung, Aussetzung und Außerbetriebnahme von KI-Anwendungen |
| Wiki.js-Pfad | /ISO-42001/03-KI-Lebenszyklus-und-Kontrollen/KI-Freigabe-und-menschliche-Aufsicht |
| Prozesseigner | KI-Managementbeauftragte/r / AIMS-Verantwortliche/r |
| Operativ verantwortlich | Fachlicher Owner und technischer Owner des jeweiligen KI-Anwendungsfalls |
| Fachlich beteiligt | Informationssicherheit, Datenschutz, Recht/Compliance, Qualitätsmanagement, IT, Entwicklung, Einkauf, Personal, Betriebsrat und betroffene Fachbereiche |
| Freigabeinstanzen | Gemäß Risikoklasse Fachbereichsleitung, AIMS-Verantwortung oder Geschäftsführung; erforderliche Fachfreigaben bleiben bestehen |
| Status | Entwurf – organisationsbezogene Befugnisse, Schwellenwerte, Vertretungen und Systemunterstützung sind festzulegen |
| Version | 0.5 |
| Stand | 10.08.2026 |
| Prüfung | Mindestens jährlich sowie vor wesentlichen Änderungen, Scope-Erweiterungen und erneuter Aktivierung ausgesetzter Anwendungen |
| Schutzklasse | Öffentliches Muster; reale Freigabeakten und technische Details 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-, Mitbestimmungs-, Urheber-, Geheimnis-, Produkt- und Branchenrecht |
Eine wirksame Freigabe verbindet Voraussetzungen, klare Grenzen, befugte menschliche Aufsicht und jederzeitige Eingriffsmöglichkeiten. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Freigabe und menschliche Aufsicht sind nicht dasselbe
| Element | Zweck | Zeitpunkt | Ergebnis |
|---|---|---|---|
| Freigabeentscheidung | Zulässigkeit und Vertretbarkeit eines definierten Einsatzes entscheiden | vor Pilot, Produktion und wesentlicher Änderung | freigegeben, mit Auflagen, abgelehnt oder ausgesetzt |
| menschliche Aufsicht | einzelne Ergebnisse und das Systemverhalten im Betrieb sachgerecht überwachen und beeinflussen | während Nutzung und Monitoring | bestätigen, korrigieren, ablehnen, eskalieren oder stoppen |
| Wirksamkeitsprüfung | feststellen, ob Kontrollen und Aufsicht tatsächlich funktionieren | vor Freigabe und wiederkehrend | Nachweis, Abweichung oder Korrekturmaßnahme |
| Managementaufsicht | Trends, kritische Risiken, Ressourcen und systemische Schwächen steuern | regelmäßig und anlassbezogen | Prioritäten, Ressourcen, Einschränkungen und Verbesserungen |
Eine Person, die jede Ausgabe lediglich bestätigt, ohne Kriterien oder Zeit zur Prüfung zu besitzen, ist keine wirksame Aufsicht. Umgekehrt ersetzt eine gute manuelle Prüfung nicht die formale Entscheidung, ob der gesamte Anwendungsfall zulässig und vertretbar ist.
¶ 2. Der Freigabegegenstand muss eindeutig sein
Die Freigabe gilt nicht allgemein für einen Produktnamen. Sie bezeichnet mindestens:
- KI-ID und verständliche Bezeichnung des Anwendungsfalls,
- fachlichen Zweck und ausdrücklich ausgeschlossene Zwecke,
- Anbieter, Produkt, Tarif, Modell oder relevante Version,
- zugelassene Nutzergruppen, Rollen, Organisationseinheiten und Standorte,
- zulässige Datenarten und Informationsklassen,
- Eingabe-, Ausgabe-, Speicher-, Trainings- und Löschbedingungen,
- Schnittstellen, automatisierte Aktionen und Empfänger,
- Betroffenengruppen und Bedeutung der Ergebnisse,
- menschliche Aufsicht, Kontrollpunkte und Eskalationsweg,
- Auflagen, Gültigkeitsdauer, Reviewdatum und Änderungsereignisse.
Praxisregel: Ändert sich einer dieser Punkte wesentlich, gilt die alte Freigabe nicht automatisch weiter. Der Owner dokumentiert die Änderung und löst eine erneute Bewertung aus.
¶ 3. Freigabestufen über den Lebenszyklus
| Stufe | Zweck | Zulässiger Umgang mit Daten | Mindestentscheidung |
|---|---|---|---|
| ⚪ Idee | Nutzen und Machbarkeit beschreiben | keine realen Unternehmens- oder Personendaten | Owner und Prüfumfang festlegen |
| 🔵 Technische Prüfung | Funktion in isolierter Umgebung verstehen | synthetische oder freigegebene Testdaten | Testplan und Sicherheitsgrenzen bestätigen |
| 🟡 Pilot mit Auflagen | reale Eignung in begrenztem Scope prüfen | nur ausdrücklich erlaubte Daten und benannte Nutzer | befristete Pilotfreigabe mit Stop-Kriterien |
| 🟢 Produktive Freigabe | kontrollierte Regelverwendung ermöglichen | gemäß Schutz-, Rechts- und Zweckvorgaben | Restrisiko, Kontrollen, Aufsicht und Monitoring freigeben |
| 🟠 Eingeschränkt | Abweichung, überfällige Auflage oder Änderung kontrollieren | nur erlaubte Restnutzung | Umfang begrenzen, Maßnahme und Termin entscheiden |
| 🔴 Ausgesetzt | kritisches Risiko, Vorfall oder fehlende Grundlage beherrschen | keine produktive Nutzung | Zugänge/Schnittstellen sperren und Untersuchung starten |
| ⚫ Außer Betrieb | System kontrolliert beenden | Rückgabe, Export, Aufbewahrung und Löschung regeln | Exit- und Lösch-/Deaktivierungsnachweis bestätigen |
Eine Pilotfreigabe ist keine produktive Freigabe. Sie enthält eine kleine Nutzergruppe, einen klaren Zeitraum, begrenzte Daten, messbare Lernziele und einen sicheren Rückfallweg.
¶ 4. Mindestvoraussetzungen vor jeder Freigabe
| Prüfblock | Mindestinhalt | Nicht ausreichend |
|---|---|---|
| Register | vollständige KI-ID, Zweck, Owner, Status und Verweise | reine Produktliste |
| Rolle und Recht | datierte Erstindikation, erforderliche Fachprüfungen und offene Punkte | ungeprüfte Herstellerangabe |
| Risiko und Folgen | Szenarien, Ausgangsrisiken, Kontrollen, Restrisiko und Betroffene | pauschal „geringes Risiko“ |
| Daten | Quellen, Zulässigkeit, Qualität, Schutzklasse, Speicherung, Training und Löschung | „keine sensiblen Daten“ ohne Analyse |
| Sicherheit | Zugriff, Mandant, Protokollierung, Schnittstellen, Schwachstellen und Notfallmaßnahmen | allgemeines Sicherheitszertifikat ohne Anwendungsbezug |
| Qualität | Sollwerte, Testfälle, Grenzfälle, Fehlerraten und bekannte Grenzen | erfolgreiche Demo |
| Aufsicht | Rolle, Kompetenz, Information, Zeit, Befugnis, Vertretung und Stop-Möglichkeit | „Human in the Loop“ als Werbeaussage |
| Lieferant | Vertrag, Unterauftragnehmer, Änderungen, Vorfälle, Audit, Datenrückgabe und Exit | Testkonto oder AGB ohne Prüfung |
| Kompetenz | rollenbezogene Schulung und bestätigte Nutzungsregeln | allgemeiner Awareness-Hinweis |
| Monitoring | Kennzahlen, Schwellenwerte, Owner und Reaktion | Prüfung nur nach Beschwerden |
Ein fehlender Pflichtblock wird als Abweichung oder Stop-Kriterium geführt; er verschwindet nicht durch eine höhere Entscheidungsebene.
¶ 5. Entscheidungslogik mit Ja/Nein-Abzweigungen
Die Entscheidung wird mit Begründung dokumentiert. Ein grüner Risikowert erzeugt keine automatische Freigabe, und eine Managemententscheidung heilt keine verbotene oder sonst rechtswidrige Nutzung.
¶ 6. Was wirksame menschliche Aufsicht ausmacht
¶ 6.1 Verstehen
Die aufsichtführende Person kennt Zweck, Funktionsweise auf angemessenem Niveau, Datenquellen, Qualitätsgrenzen, relevante Fehlermuster, Unsicherheiten, mögliche Verzerrungen und die Bedeutung der Ausgabe im Geschäftsprozess. Sie kann erkennen, wann das System außerhalb seines freigegebenen Scopes eingesetzt wird.
¶ 6.2 Prüfen
Es bestehen konkrete Prüfkriterien. Je nach Anwendung umfasst dies Quellenabgleich, Plausibilitätsprüfung, Vier-Augen-Prinzip, Stichprobe, Vergleich mit Originaldaten, Schwellenwerte oder vollständige Einzelfallkontrolle. Die Prüfung wird nicht durch Zeitdruck, ungeeignete Benutzeroberflächen oder zu viele Fälle faktisch unmöglich.
¶ 6.3 Entscheiden
Die Person darf ein Ergebnis ablehnen, korrigieren oder eine alternative Bearbeitung wählen, ohne automatisch der KI-Empfehlung folgen zu müssen. Verantwortlichkeit und Haftung werden nicht unklar auf „die KI“ verschoben.
¶ 6.4 Eingreifen und stoppen
Es gibt erreichbare technische oder organisatorische Funktionen zum Pausieren, Sperren, Zurücksetzen oder Umgehen. Für kritische Fälle sind Reaktionszeiten, Vertretung, Kommunikation, Beweissicherung und Rückfallverfahren festgelegt.
¶ 6.5 Lernen
Übersteuerungen, Fehler, Beschwerden und Beinahe-Vorfälle werden erfasst und ausgewertet. Häufige manuelle Korrekturen sind kein Erfolgsnachweis menschlicher Kontrolle, sondern können auf ungeeignete Daten, ein schlechtes Modell oder einen falsch gestalteten Prozess hinweisen.
¶ 7. Aufsichtsmodell nach Bedeutung der Ausgabe
| Bedeutung der KI-Ausgabe | Geeignetes Aufsichtsmodell | Beispiel |
|---|---|---|
| Entwurf ohne unmittelbare Außenwirkung | stichprobenartige Qualitätskontrolle plus verantwortliche Endredaktion | interner Textentwurf |
| Empfehlung für einen Fachprozess | fachliche Einzelprüfung vor Übernahme | Wartungsempfehlung |
| Inhalt mit Kunden- oder Rechtswirkung | Vier-Augen-Freigabe und Quellen-/Regelprüfung | Vertrags- oder Kundenkommunikation |
| Entscheidungsvorbereitung über Menschen | unabhängige, qualifizierte Einzelprüfung mit dokumentierter Begründung und Anfechtungsmöglichkeit | Personal- oder Leistungsentscheidung |
| Sicherheits- oder gesundheitsrelevante Steuerung | validierte Grenzwerte, Echtzeitüberwachung, Fail-safe und sofortige Abschaltung | Maschinen- oder Medizinbezug |
| rein automatisierte Aktion | nur wenn fachlich und rechtlich zulässig, technisch begrenzt, überwacht und sicher rücksetzbar | eng begrenzte Systemklassifikation |
Die Bezeichnung „menschliche Aufsicht“ beschreibt somit keine einheitliche Kontrollstufe. Tiefe, Häufigkeit und Unabhängigkeit richten sich nach möglicher Wirkung und Fehlerfolgen.
¶ 8. Freigabematrix als Muster
| Risiko-/Wirkungslage | Entscheidungsebene | Zusätzliche Bedingungen |
|---|---|---|
| 🟢 niedrig, keine Stop-Kriterien | fachlicher Owner innerhalb delegierter Befugnis | dokumentierte Mindestkontrollen und Review |
| 🟡 mittel oder begrenzter Pilot | Fachbereichsleitung plus AIMS-Verantwortung | Auflagen, Termin, Pilotgrenze und Wirksamkeitsnachweis |
| 🟠 hoch oder erhebliche Betroffenenwirkung | Geschäftsführung plus zuständige Fachfunktionen | vertiefte Prüfung, dokumentierte Alternativen und enges Monitoring |
| 🔴 kritisch oder Stop-Kriterium | keine produktive Freigabe | vermeiden, neu gestalten oder bis zur belastbaren Klärung aussetzen |
| rechtlich besonders geregelter Fall | zuständige Rechts-/Compliance- und gegebenenfalls externe Fachprüfung | gesetzlich erforderliche Dokumentation und Verfahren zusätzlich erfüllen |
Die Organisation legt schriftlich fest, wer welche Restrisiken akzeptieren darf. Vertreter benötigen dieselbe fachliche und formale Befugnis wie die reguläre Rolle.
¶ 9. Zulässige Entscheidungsarten
| Entscheidung | Mindestinhalt |
|---|---|
| Freigegeben | Zweck, Scope, Nutzer, Daten, Kontrollen, Aufsicht, Gültigkeit und Reviewtermin |
| Freigegeben mit Auflagen | zusätzlich Auflage, Owner, Termin, Zwischenkontrolle und Folge bei Nichterfüllung |
| Pilot freigegeben | Lernziele, Zeitraum, Fallzahl, erlaubte Daten, Nutzer, Stop-Kriterien und Abschlussbewertung |
| Abgelehnt | fachliche oder rechtliche Gründe und gegebenenfalls zulässige Alternative |
| Ausgesetzt | Sofortmaßnahme, Sperrumfang, Untersuchung, Kommunikation und Voraussetzung für Reaktivierung |
| Außer Betrieb | Abschaltdatum, Datenrückgabe/-löschung, Zugänge, Schnittstellen, Verträge und Nachweisaufbewahrung |
Mündliche Zustimmungen und Chat-Nachrichten werden nicht als dauerhafte Freigabeakte verwendet. Die Entscheidung liegt versioniert im kontrollierten System und ist mit dem Register verknüpft.
¶ 10. Praxisbeispiel: KI-Protokollassistent
Zweck: Aus angekündigt aufgezeichneten internen Besprechungen einen Protokollentwurf erzeugen. Personalgespräche, Aufsichtsratsinhalte, besonders vertrauliche Kundenthemen und automatische Aufgabenverteilung sind ausgeschlossen.
| Freigabebaustein | Dummy-Festlegung |
|---|---|
| Scope | zehn benannte Nutzende, drei Monate, interne Regeltermine |
| Daten | Schutzklasse Intern; keine besonderen Kategorien ohne Einzelfallprüfung |
| Aufsicht | Sitzungsleitung prüft Sprecherzuordnung, Beschlüsse, Aufgaben, vertrauliche Inhalte und Auslassungen |
| Eingriff | Veröffentlichung nur nach manueller Freigabe; Aufzeichnung und Verarbeitung können sofort beendet werden |
| Auflagen | Anbietertraining deaktiviert, AVV bestätigt, Löschfrist 30 Tage, monatlicher Löschtest |
| Kennzahlen | Fehlzuordnungen, wesentliche Inhaltsfehler, Korrekturquote, Beschwerden, Löschtestergebnis |
| Stop-Kriterien | heimliche Aufzeichnung, Datenabfluss, ungeklärte Speicherung, wiederholte wesentliche Fehlzuordnung |
| Entscheidung | 🟡 Pilot mit Auflagen; Erweiterung erst nach dokumentierter Abschlussbewertung |
Die Sitzungsleitung darf den Entwurf nicht ungeprüft versenden. Eine dokumentierte Stichprobe stellt zusätzlich fest, ob die manuelle Prüfung Fehler zuverlässig erkennt oder nur formal bestätigt.
¶ 11. Gegenbeispiel: Aufsicht nur auf dem Papier
Ein System priorisiert Bewerbungen. Die Personalabteilung kann theoretisch von der Rangliste abweichen, sieht jedoch weder verwendete Merkmale noch Unsicherheiten, hat pro Bewerbung nur wenige Sekunden und muss Abweichungen gegenüber der Führungskraft rechtfertigen. Dieses Modell ist nicht wirksam:
- fehlende Information verhindert eine sachkundige Prüfung,
- Zeitdruck begünstigt Automationsbias,
- organisatorischer Druck reduziert Entscheidungsfreiheit,
- gruppenbezogene Fehler bleiben unsichtbar,
- Betroffene besitzen keinen klaren Prüf- und Beschwerdeweg.
Der Anwendungsfall bleibt ausgesetzt, bis Recht, Folgenbewertung, Daten- und Testqualität, Aufsichtsdesign, Mitbestimmung und Anfechtbarkeit belastbar geklärt sind.
¶ 12. Änderungen und erneute Freigabe
| Änderung | Erforderliche Reaktion |
|---|---|
| neuer Zweck oder neue Betroffenengruppe | neuer Registereintrag oder vollständige Neubewertung |
| Modell-, Anbieter- oder Hostingwechsel | technische, vertragliche, Datenschutz-, Risiko- und Qualitätssicht neu prüfen |
| neue Datenquelle oder höhere Schutzklasse | Zulässigkeit, Datenqualität, Schutzmaßnahmen und Folgen neu bewerten |
| neue Schnittstelle oder automatisierte Aktion | Berechtigungen, Fehlerszenarien, Rücksetzbarkeit und Aufsicht vertiefen |
| wesentliche Qualitäts- oder Driftänderung | Nutzung begrenzen, Ursachenanalyse und erneute Wirksamkeitsprüfung |
| Vorfall oder schwere Beschwerde | sofortige Triage; gegebenenfalls aussetzen und meldepflichtige Prozesse starten |
| abgelaufene Auflage oder Review | Status auf eingeschränkt setzen; Nutzung nicht stillschweigend fortführen |
Änderungen werden nicht allein nach Anbieterbezeichnung beurteilt. Auch Promptvorlagen, Wissensdatenbanken, Schwellenwerte, Nutzeroberflächen oder Arbeitsanweisungen können die Wirkung wesentlich verändern.
¶ 13. Aussetzung und Notfallstopp
Der Notfallweg beantwortet vorab:
- Wer darf die Nutzung sofort stoppen?
- Welche Konten, Schlüssel, Schnittstellen oder Automationen werden gesperrt?
- Wie wird auf eine sichere manuelle Bearbeitung gewechselt?
- Welche Daten, Protokolle und Versionen werden beweissicher erhalten?
- Wer bewertet Datenschutz-, Sicherheits-, Produkt- oder sonstige Meldepflichten?
- Wer informiert Nutzende, Betroffene, Kunden, Lieferanten und Leitung?
- Welche Voraussetzungen müssen vor einer Reaktivierung erfüllt sein?
Ein Stop darf nicht an der Abwesenheit einer einzelnen Person scheitern. Vertretung, Kontaktliste und technische Berechtigung werden getestet.
¶ 14. Qualitätsampel der menschlichen Aufsicht
| Prüffeld | 🔴 Rot | 🟡 Gelb | 🟢 Grün |
|---|---|---|---|
| Rollenverständnis | niemand verantwortlich | Rolle benannt, Grenzen offen | Aufgabe, Befugnis und Vertretung bestätigt |
| Information | nur Ergebnis sichtbar | Zusatzinformationen teilweise vorhanden | Quellen, Unsicherheit, Grenzen und Kontext verständlich |
| Kompetenz | keine Schulung | allgemeine KI-Schulung | anwendungs- und rollenbezogene Befähigung mit Wirksamkeitsnachweis |
| Zeit und Arbeitslast | Prüfung faktisch unmöglich | Kapazität nicht gemessen | realistische Fallzahl, Priorisierung und Eskalation |
| Unabhängigkeit | Abweichung unerwünscht | soziale Hürden vorhanden | Ergebnis darf ohne Nachteil abgelehnt werden |
| Eingriff | keine technische Möglichkeit | manueller Umweg | ablehnen, korrigieren, pausieren und stoppen erreichbar |
| Kriterien | „Plausibilität prüfen“ | einzelne Checkpunkte | klare Prüfkriterien, Grenzfälle und Dokumentation |
| Nachweis | keine Aufzeichnung | Freitext ohne Ergebnislogik | Entscheidung, Abweichung, Ursache und Wirkung nachvollziehbar |
| Lernen | Fehler bleiben im Einzelfall | gelegentliche Auswertung | Trends führen zu Maßnahmen, Neubewertung und Systemverbesserung |
| Betroffenenweg | kein Ansprechpartner | allgemeine Kontaktadresse | verständliche Information, Beschwerde und wirksame menschliche Prüfung |
Ein rotes Feld bei Eingriffsfähigkeit, Kompetenz, Entscheidungsfreiheit oder sicherheitskritischer Information verhindert die produktive Freigabe.
¶ 15. Nachweise und Kennzahlen
¶ Mindestnachweise
- datierter Freigabeantrag und verknüpfte KI-ID,
- freigegebene Risiko- und Folgenbewertung,
- Prüf- und Testbericht mit Sollwerten und Ergebnissen,
- Rollen-, Kompetenz- und Vertretungsnachweis der Aufsicht,
- technische Konfigurations-, Berechtigungs- und Stop-Nachweise,
- Freigabeentscheidung mit Scope, Auflagen, Restrisiko und Gültigkeit,
- Monitoring-, Übersteuerungs-, Fehler-, Beschwerde- und Änderungsprotokolle,
- gegebenenfalls Aussetzungs-, Reaktivierungs- und Exitentscheidung.
¶ Managementkennzahlen
| Kennzahl | Aussage |
|---|---|
| Anwendungen ohne gültige Freigabe | kritische Governance-Abweichung |
| überfällige Auflagen und Reviews | Risiko einer stillschweigenden Scope-Ausweitung |
| manuelle Übersteuerungsquote | möglicher Qualitäts- oder Prozessmangel |
| Fehler trotz manueller Freigabe | tatsächliche Wirksamkeit der Aufsicht |
| mittlere Zeit bis Sperrung | Reaktionsfähigkeit bei kritischen Ereignissen |
| Anwendungen ohne getesteten Rückfallweg | Betriebs- und Sicherheitsrisiko |
| Beschwerden und Anfechtungen | Betroffenenwirkung und Transparenzqualität |
| Änderungen ohne Neubewertung | Schwäche des Lifecycle- und Change-Prozesses |
Das öffentliche Wiki enthält keine frei bearbeitbare Freigabevorlage. Kundenspezifische Formulare und Register werden kontrolliert erstellt und über geschützte Ablagen bereitgestellt.
¶ 16. Interne Verknüpfungen
- ISO/IEC 42001 – KI-Managementsystem
- KI-Anwendungsregister
- KI-Risiko- und Folgenbewertung
- Datenmanagement und Datenqualität
- KI-Systemlebenszyklus und Änderungsmanagement
- KI-Transparenz, Kennzeichnung und Kommunikation
- KI-Kompetenz, Schulung und Befähigungsnachweise
- Einsatz von KI im Unternehmen
- KI und automatisierte Verarbeitung
- Datenschutz-Folgenabschätzung
- Dokumentenlenkung
- Lieferanten und Dienstleister
- Incident Response
- Wirksamkeitsmessungen
¶ 17. Offizielle Quellen und Abgrenzung
- ISO: ISO/IEC 42001:2023 – AI management systems
- ISO: ISO/IEC 23894:2023 – Guidance on risk management
- ISO: ISO/IEC 42005:2025 – AI system impact assessment
- EUR-Lex: Verordnung (EU) 2024/1689, insbesondere die anwendbaren Anforderungen an menschliche Aufsicht im jeweiligen Fall
- EU-Kommission: Orientierung zu Rollen, Pflichten und Anwendungszeitpunkten
Diese Musterseite beschreibt eine organisatorische Methode in eigenen Worten. Sie ersetzt weder lizenzierte Normtexte noch eine Rechtsberatung. Ob und welche gesetzlichen Anforderungen an menschliche Aufsicht gelten, wird anhand von Rolle, System, Zweck, Risikokategorie und aktuellem Rechtsstand fachlich geprüft.
¶ 18. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Erstfassung mit Lifecycle-Stufen, Mindestvoraussetzungen, Entscheidungslogik, Aufsichtsmodell, Freigabematrix, Praxisbeispielen, Stop-Prozess, Qualitätsampel und Nachweisen | Musterredaktion | Ausstehend | – |
| 0.2 | 10.08.2026 | Datenmanagement und Datenqualität als vorgelagerten Freigabe- und Wirksamkeitsnachweis verknüpft | Musterredaktion | Ausstehend | – |
| 0.3 | 10.08.2026 | Systemlebenszyklus und Änderungsmanagement als Freigabe-, Änderungs- und Rollback-Schnittstelle verknüpft | Musterredaktion | Ausstehend | – |
| 0.4 | 10.08.2026 | Transparenz-, Kennzeichnungs- und Kommunikationsverfahren als Voraussetzung wirksamer Aufsicht verknüpft | Musterredaktion | Ausstehend | – |
| 0.5 | 10.08.2026 | Rollenbezogene Befähigung und Autorisierung als Voraussetzung für menschliche Aufsicht und Freigabe verknüpft | Musterredaktion | Ausstehend | – |
Seite 1 von 1 · AIMS-VA-03-01 · Version 0.5