KI Kompetenz nachweisen: Welche Dokumentation zu Art. 4 sinnvoll ist

Nachweis folgt der Maßnahme, nicht umgekehrt

Der Digital Omnibus beschreibt Art. 4 als Pflicht von Anbietern und Betreibern, angemessene Maßnahmen zur Unterstützung der Kompetenzentwicklung zu treffen. Daraus folgt keine besondere Urkunde und keine unionsrechtliche Standardakte. Dokumentation sollte deshalb nicht mit Zertifikaten beginnen, sondern mit der Frage, welche Personen bei welchen Systemen welche Fähigkeiten benötigen und warum die ausgewählten Maßnahmen passen.

Ein Nachweis ist besonders hilfreich, wenn Leitung, Revision oder Behörde später verstehen müssen, welcher Informationsstand einer Entscheidung zugrunde lag. Er sollte Tatsachen festhalten und keine überhöhten Aussagen wie „vollständig kompetent“ erzeugen. Teilnahme an einem Kurs belegt zunächst Teilnahme; ob Inhalte geeignet waren und im Arbeitsablauf greifen, muss über Konzept, Praxisbezug und Aktualisierung beurteilt werden.

• Bedarfsanalyse vor Teilnahmebescheinigung dokumentieren
• Keine Kompetenzgarantie aus einem Kursabschluss ableiten
• Nachweistiefe am Risiko und Einsatzkontext ausrichten

Quellen: [1] [2] [3]

Eine schlanke Nachweisarchitektur in vier Ebenen

Die erste Ebene ist eine unternehmensweite Leitentscheidung mit Geltungsbereich, Rollen und Verantwortlichkeiten. Die zweite Ebene ordnet Systeme und Tätigkeiten den Zielgruppen und Lernzielen zu. Die dritte Ebene belegt konkrete Maßnahmen, Termine, Inhalte und Bereitstellung. Die vierte Ebene hält Feedback, Vorfälle, Änderungen und daraus folgende Anpassungsentscheidungen fest. So bleibt die Argumentation vom Bedarf bis zur Verbesserung geschlossen.

Nicht jedes Detail gehört in ein zentrales Register. Richtlinienversionen können im Dokumentenmanagement liegen, Zugangsfreigaben im Identity-System und Lernmaterialien in der Lernplattform. Ein schlanker Index verbindet die Fundstellen über stabile Kennungen. Damit lassen sich Doppelablagen, widersprüchliche Versionsstände und unnötige personenbezogene Sammelakten vermeiden, ohne die Prüfbarkeit des Gesamtbildes zu verlieren.

• Governance-Beschluss und Scope referenzieren
• Rollenmatrix und Maßnahmenplan versionieren
• Umsetzungs- und Wirksamkeitsbefunde über Fundstellen verbinden

Quellen: [1] [3]

Welche Felder in den Maßnahmenplan gehören

Für jede Zielgruppe sollten System oder Systemklasse, Nutzungsszenario, zulässiger Zweck, wesentliche Risiken, Vorwissen und Lernziel festgehalten werden. Hinzu kommen Format, Inhalt, Verantwortliche, vorgesehener Zeitpunkt und Wiederholungsanlass. Bei einer Schulung können Version, Dauer, Übungen und Teilnahmestatus erfasst werden; bei einer Leitlinie sind Veröffentlichung, Adressaten, Kenntnisnahme und Änderungsverlauf wichtiger.

Ergänzende organisatorische und technische Schutzmaßnahmen brauchen ebenfalls Belege, wenn sie Teil des Gesamtkonzepts sind. Beispiele sind kontextbezogene Hinweise in der Anwendung, Prompt-Vorlagen, gesperrte Datenfelder, Freigabe-Workflows, Sprechstunden, Checklisten oder eine fachliche Zweitprüfung. Der Nachweis sollte unterscheiden, welche Elemente Kompetenzentwicklung unterstützen und welche vor allem Risiken begrenzen. Eine technische Sperre kann Fehlhandlungen verhindern, vermittelt aber für sich allein kein Verständnis für andere Nutzungssituationen.

• System, Rolle, Lernziel und Risiko zusammenführen
• Format und Inhalt mit Versionsstand erfassen
• Bei technischen Kontrollen den unterstützten Kompetenzbedarf benennen

Quellen: [1] [3] [4]

Teilnahme, Bereitstellung und Anwendung unterscheiden

Für verpflichtende Einweisungen kann der Teilnahmestatus zweckmäßig sein. Bei Nachschlagewerken oder Systemhinweisen ist dagegen eher zu dokumentieren, wann und für wen sie bereitgestellt wurden. Wo der sichere Einsatz besondere praktische Fähigkeiten verlangt, können Fallübungen oder eine bestätigte Einweisung geeigneter sein. Art. 4 schreibt jedoch weder Prüfung noch Mindestpunktzahl als allgemeines Format vor.

Die Dokumentation sollte offen zwischen Input und Ergebnis unterscheiden. Ein versandtes Merkblatt ist ein Bereitstellungsnachweis, kein Beweis richtigen Verhaltens. Auditbefunde, Rückfragen, Fehlermeldungen und Stichproben können Hinweise auf Verständlichkeit und Anwendung liefern. Sie müssen im Kontext bewertet werden: Wenige Meldungen können gute Beherrschung bedeuten, aber ebenso einen unbekannten oder schlecht zugänglichen Meldeweg.

• Nachweisart passend zum Maßnahmenformat wählen
• Teilnahme nicht mit Wirksamkeit gleichsetzen
• Kennzahlen vor Interpretation mit qualitativen Befunden verbinden

Quellen: [1] [3]

Datenschutz und Zugriff von Anfang an begrenzen

Kompetenznachweise können Namen, Rollen, Testergebnisse oder Fehlerfälle enthalten und damit personenbezogene Daten sein. Die DSGVO verlangt unter anderem Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung und angemessene Sicherheit. Deshalb sollte vorab feststehen, welche Daten für Steuerung oder Nachweis wirklich erforderlich sind, wer sie sehen darf und wann sie gelöscht oder anonymisiert werden.

Detaillierte individuelle Leistungsprofile sind regelmäßig nicht für jede Maßnahme nötig. Oft genügt die Zuordnung zur Rolle, ein Teilnahmestatus und ein dokumentierter Unterstützungsbedarf. Offene Fehlerkultur wird geschwächt, wenn jede Rückfrage als personenbezogene Minderleistung gespeichert wird. HR, Datenschutz, Informationssicherheit und Arbeitnehmervertretung sollten Auswertungszwecke und Zugriffe transparent festlegen; arbeitsrechtliche Anforderungen bleiben gesondert zu prüfen.

• Nur erforderliche Personendaten erfassen
• Rollenbasierte Zugriffe und Aufbewahrungsfristen festlegen
• Lernunterstützung von Leistungs- und Verhaltenskontrolle abgrenzen

Quellen: [5] [1]

Prüfpfad und Aktualisierung praktisch organisieren

Ein jährlicher Governance-Termin kann die Vollständigkeit prüfen, ohne eine gesetzliche Jahrespflicht zu behaupten. Zusätzlich lösen neue Systeme, Funktionen, Zwecke, Rollen, Vorfälle oder Rechtsänderungen eine anlassbezogene Überprüfung aus. Das Protokoll hält fest, welche Unterlagen betrachtet wurden, welche Lücken bestehen und weshalb Inhalte geändert oder bewusst beibehalten wurden. So wird Aktualität begründet statt nur behauptet.

Für eine interne Stichprobe wählt die Revision einige Systeme mit unterschiedlichem Risiko und verfolgt den Pfad vom Inventar über Rollen und Lernziele bis zu Zugriff und Aktualisierung. Festgestellte Lücken führen zu verantwortlichen Maßnahmen und Fristen. Der Prüfpfad unterstützt die Umsetzung ausgewählter Anforderungen, bietet aber keine Gewähr für Rechtskonformität und ersetzt keine Prüfung anderer Pflichten.

• Regelmäßigen Governance-Prüfpunkt mit Ereignistriggern kombinieren
• Stichproben vom System bis zum Umsetzungsbeleg durchführen
• Lücken mit Owner, Frist und Abschlussnachweis verfolgen

Quellen: [1] [2] [3] [5]

Häufige Fragen