KI-Kompetenz ist kein einmaliges Training

Eine Teilnahmebestätigung zeigt, dass jemand anwesend war. Sie zeigt nicht, ob diese Person eine falsche KI-Ausgabe erkennt, sensible Daten schützt, eine Entscheidung wirksam überstimmt oder im richtigen Moment stoppt.

Viele Organisationen beantworten KI-Kompetenz mit einem allgemeinen Webinar: Funktionsweise großer Sprachmodelle, einige Prompt-Tipps, Risiken, kurze Abschlussfrage. Danach gilt das Thema als erledigt. Doch die Personen arbeiten anschließend mit unterschiedlichen Systemen, Daten und Entscheidungsrechten. Eine Entwicklerin, ein Servicemitarbeiter, eine Führungskraft und eine Kontrollfunktion benötigen nicht dieselbe Kompetenz.

Artikel 4 des EU AI Act folgt genau dieser Kontextlogik. Anbieter und Betreiber sollen nach besten Kräften ein ausreichendes Niveau der KI-Kompetenz ihrer Beschäftigten und weiterer Personen sicherstellen, die in ihrem Auftrag mit Betrieb und Nutzung von KI-Systemen umgehen. Berücksichtigt werden Vorwissen, Erfahrung, Bildung, Training, Einsatzkontext und betroffene Personen. Das ist kein Lehrplan von der Stange, sondern ein Auftrag zur begründeten Gestaltung.

KI-Kompetenz ist Handlungsfähigkeit

Die Definition des AI Act verbindet Fähigkeiten, Wissen und Verständnis mit informierter Bereitstellung und Nutzung sowie dem Bewusstsein für Chancen, Risiken und mögliche Schäden. Kompetenz erschöpft sich daher nicht in Begriffswissen. Sie zeigt sich in einer konkreten Handlungssituation.

Kann eine Person erkennen, wann die Quelle fehlt? Weiß sie, welche Daten nicht in ein externes System gehören? Versteht sie, ob eine Ausgabe nur Entwurf oder Entscheidungsgrundlage ist? Kann sie Unsicherheit markieren, eine Ausnahme eskalieren und eine Aktion stoppen? Kennt sie die Folgen für Menschen, die das System gar nicht selbst bedienen?

Ein Kompetenzziel wird deshalb beobachtbar formuliert. Nicht „kennt Halluzinationen", sondern: „prüft bei extern verwendeten Tatsachenbehauptungen Quelle, Aktualität und Geltungsbereich und blockiert die Veröffentlichung, wenn der Nachweis fehlt."

Eine gemeinsame Basis – mehrere Rollenprofile

Alle Beteiligten brauchen ein gemeinsames Fundament: Welche KI-Systeme nutzt die Organisation? Wofür sind sie freigegeben? Welche typischen Grenzen, Chancen und Schäden existieren? Welche Daten-, Sicherheits- und Transparenzregeln gelten? Wo werden Vorfälle gemeldet?

Darauf folgen Rollenprofile.

Anwender brauchen sichere Eingabe, Quellenprüfung, Outputinterpretation, Kennzeichnung und Eskalation. Prozessverantwortliche definieren Zweck, Akzeptanzkriterien, menschliche Kontrolle, Kennzahlen und Stop-Regeln. Entwickler und Integratoren benötigen Datenherkunft, Evaluation, Security, Logging, Versions- und Änderungsmanagement. Führungskräfte entscheiden über Risikoakzeptanz, Ressourcen, Anbieter, Verantwortlichkeit und Einsatzgrenzen. Kontrollfunktionen brauchen Zugriff auf Systemkarten, Tests, Logs, Beschwerden und Entscheidungsnachweise. Dienstleister benötigen dieselbe aufgabenbezogene Befähigung, wenn sie im Auftrag der Organisation mit dem System arbeiten.

Rollenprofile verhindern zwei Fehler: Unterweisung bleibt nicht zu allgemein, und technische Expertise wird nicht mit vollständiger Einsatzkompetenz verwechselt. Auch erfahrene Entwickler können die internen Datenregeln oder die Auswirkungen auf Betroffene nicht kennen.

Fünf Ebenen einer belastbaren Kompetenzmatrix

Eine Kompetenzmatrix verbindet Rolle und System mit fünf Ebenen.

1 · Orientierung: Grundprinzipien, Möglichkeiten, Grenzen und verwendete Systeme.

2 · Systempraxis: freigegebener Zweck, Bedienung, Quellen, Schnittstellen und bekannte Fehlermodi.

3 · Daten und Schutz: Vertraulichkeit, personenbezogene Daten, Berechtigungen, Protokollierung und sichere Werkzeuge.

4 · Urteil und Aufsicht: Ergebnisprüfung, Automation Bias, Entscheidungsspielraum, Widerspruch und wirksames Stoppen.

5 · Vorfall und Lernen: Fehler melden, Evidenz sichern, eskalieren, korrigieren und Erkenntnisse zurückführen.

Nicht jede Rolle braucht dieselbe Tiefe. Wer Texte entwirft, muss keine Modellpipeline programmieren. Wer einen Agenten mit Schreibrechten betreibt, braucht dagegen Toolberechtigungen, Rücknahmewege und Incident-Verhalten. Das Niveau folgt der Aufgabe und möglichen Konsequenz.

Lesen reicht nicht – Szenarien machen Kompetenz sichtbar

Die offiziellen Erläuterungen des AI Office betonen, dass das bloße Lesen einer Bedienungsanleitung in vielen Fällen unwirksam und unzureichend sein kann. Lernen muss an realen Systemen und Zielgruppen ausgerichtet werden.

Ein Szenario beginnt mit einer typischen Aufgabe und enthält eine kontrollierte Störung: veraltete Quelle, prompt injection in einem Dokument, sensible Information im Eingabetext, widersprüchliche Evidenz, voreingenommene Empfehlung, unzulässiger Toolaufruf oder fehlende Freigabe. Die Person muss das Problem erkennen, den richtigen Pfad wählen und ihre Entscheidung dokumentieren.

Bewertet wird nicht nur die richtige Antwort. Beobachtet werden Prüfung, Begründung, Datenhygiene, Nutzung von Kontrollen, Eskalation und Stop. Fehler im sicheren Übungsraum liefern wertvollere Lerninformationen als ein Multiple-Choice-Test über Definitionen.

Kompetenz und Berechtigung gehören zusammen

Schulung ohne technische Grenze verlagert Verantwortung auf Einzelne. Ein unerfahrener Nutzer sollte kein produktives Löschwerkzeug erhalten, nur weil eine Folie vor Fehlbedienung warnt. Umgekehrt darf eine qualifizierte Kontrollperson nicht ohne Zugriff auf Quellen, Logs und Stop-Funktion bleiben.

Das Kompetenzprofil wird daher mit Berechtigungen verknüpft. Read-only-Zugriff erfordert andere Nachweise als Veröffentlichung, Personenauswahl, Datenexport oder autonome Toolausführung. Höhere Wirkung führt zu stärkerer Übung, engerem Scope, zusätzlichem Gate und kürzerem Review-Zyklus.

Kompetenz ist dabei kein dauerhaftes Etikett. Sie gilt für Rolle, Systemversion und Geltungsbereich. Ein bestandener Kundensupport-Fall autorisiert nicht automatisch HR-Entscheidungen oder administrativen Datenbankzugriff.

Es gibt keine allgemeine Zertifikatspflicht

Nach den Q&A des AI Office verlangt Artikel 4 kein bestimmtes Zertifikat. Interne Aufzeichnungen über Trainings und andere Leitmaßnahmen können genutzt werden. Ebenso ist keine spezielle Governance-Struktur allein für Artikel 4 vorgeschrieben.

Das bedeutet nicht, dass Nachweise unwichtig sind. Eine Organisation sollte zeigen können, wie sie Zielgruppen, Systeme, Risiken und Vorwissen ermittelt, welche Maßnahmen daraus abgeleitet, wann sie durchgeführt und wie ihre Wirksamkeit überprüft wurden. Teilnahme ist ein Datumspunkt, nicht der gesamte Nachweis.

Ein Kompetenzdatensatz kann Rolle, System, Lernziel, Methode, Szenario, Ergebnis, offene Lücke, Freigabestatus und nächsten Review enthalten. Er speichert nur notwendige personenbezogene Daten und folgt klaren Zugriffs- und Löschregeln.

Wissen muss mit dem System altern

KI-Systeme verändern sich schnell: Modellwechsel, neue Tools, andere Datenquellen, zusätzliche Autonomie, geänderte Benutzeroberflächen und neue Richtlinien. Ein Kurs von gestern kann eine falsche Sicherheit von heute erzeugen.

Deshalb gibt es Refresh-Trigger: neue Systemversion, neuer Use Case, geänderte Rolle, kritischer Vorfall, wiederholter Fehler, neue Rechts- oder Sicherheitsanforderung und längere Nutzungspause. Die Aktualisierung konzentriert sich auf die Veränderung; nicht jede Person muss den gesamten Kurs wiederholen.

Betriebsdaten schließen den Lernkreis. Häufige Fehlermeldungen, überstimmte Empfehlungen, Beschwerden, riskante Eingaben und Beinahe-Vorfälle werden anonymisiert oder angemessen geschützt ausgewertet. Daraus entstehen neue Übungen, Hilfetexte, technische Kontrollen oder Prozessänderungen.

Shadow AI ist auch ein Kompetenzproblem

Verbote allein verhindern nicht, dass Beschäftigte frei verfügbare KI-Werkzeuge nutzen. Oft entsteht Shadow AI, weil freigegebene Alternativen fehlen, Regeln unverständlich sind oder Menschen den Datenfluss nicht einschätzen können.

Kompetenzmaßnahmen erklären nicht nur „Was ist verboten?", sondern „Warum, welche sichere Alternative existiert und wie wird ein legitimer Bedarf gemeldet?" Die Organisation beobachtet Nutzungsmuster, ohne pauschale Überwachung zu etablieren, und verbessert Freigaben sowie Werkzeuge.

Eine offene Fehlerkultur ist entscheidend. Wer eine riskante Eingabe sofort meldet, ermöglicht Schadensbegrenzung. Wer Sanktion ohne Lernpfad erwartet, verschweigt den Vorfall.

Betroffene Personen gehören in die Perspektive

AI Literacy richtet sich organisatorisch vor allem an Personen, die Systeme bereitstellen oder im Auftrag nutzen. Die Definition und Erwägungsgründe beziehen aber auch betroffene Menschen und deren informierte Entscheidungen ein. Je nach Risiko kann es sinnvoll sein, Kunden oder andere Gruppen verständlich zu befähigen.

Das ist mehr als ein Transparenztext. Betroffene müssen gegebenenfalls verstehen, dass KI beteiligt ist, welche Bedeutung eine Ausgabe hat, welche Grenzen bestehen und wie sie Fragen, Korrektur oder menschliche Prüfung verlangen können. Fachjargon und versteckte Hinweise erzeugen keine Handlungsfähigkeit.

Aus Training wird ein Betriebssystem

Ein nachhaltiges Kompetenzsystem besteht aus einem Kreislauf:

1. Systeme, Rollen, Betroffene und Risiken erfassen.

2. Beobachtbare Kompetenzziele definieren.

3. Basiswissen und rollenspezifische Module bereitstellen.

4. Reale Normal- und Störfälle simulieren.

5. Kompetenz mit Scope und Berechtigung verbinden.

6. Anwendung, Vorfälle und Kontrollnutzung beobachten.

7. Lücken durch Lernen, Prozess- oder Technikänderung schließen.

8. Bei Triggern Inhalte und Freigaben aktualisieren.

So wird KI-Kompetenz Teil von Governance und Betrieb. Sie schützt nicht nur vor Fehlern, sondern erhöht die Qualität der Nutzung: Menschen formulieren bessere Aufgaben, erkennen Grenzen früher und wissen, wann Automatisierung hilft – und wann Verantwortung nicht delegiert werden darf.

Übungsblatt: Baue eine rollenbezogene Kompetenzmatrix

Wähle einen konkreten KI-Use Case.

1. Liste Rollen, Aufgaben, Systeme und betroffene Gruppen.

2. Definiere je Rolle drei beobachtbare Handlungen.

3. Ordne die fünf Kompetenzebenen und erforderliche Tiefe zu.

4. Entwickle einen Normalfall und zwei Störszenarien.

5. Lege Bewertung, Stop-Kriterium und Eskalation fest.

6. Verknüpfe Kompetenzstatus mit Berechtigungen und Scope.

7. Definiere interne Nachweise mit Datenminimierung.

8. Bestimme Refresh-Trigger und verantwortliche Eigentümer.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Dieser Artikel beschreibt ein organisatorisches Umsetzungsmuster und keine verbindliche Einheitslösung. Artikel 4 schreibt weder ein bestimmtes Zertifikat noch eine bestimmte Governance-Struktur oder ein einheitliches Schulungsformat vor. Das passende Niveau hängt von Rolle, Vorwissen, System, Einsatzkontext, Risiko und betroffenen Personen ab. Stand der redaktionellen Prüfung: 17. Juli 2026.