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