Seit dem 27. Juli 2026 steht in Art. 4 KI-VO ein anderer Text. Am 10. August 2026 zitierten die Themenseite der Bundesnetzagentur zur KI-Kompetenz, das dort verlinkte Hinweispapier und die Handreichung von BMDS und BAköV noch den aufgehobenen Wortlaut. Ein verbindliches Dokumentationsformat nennt allerdings keine der beiden Fassungen.
Die Vorschrift selbst gilt unverändert seit dem 2. Februar 2025. Anbieter und Betreiber müssen Maßnahmen ergreifen, die die Entwicklung der KI-Kompetenz ihrer Beschäftigten und weiterer beauftragter Personen unterstützen. Ein bestimmtes Kompetenzniveau müssen sie nicht garantieren.
Wer seine Dokumentation an diesen Handreichungen ausrichtet, arbeitet also mit dem alten Maßstab. Für Entwicklerteams bleibt dabei eine praktische Frage offen: Welche Unterlagen zeigen bei einer internen Revision oder nach einem Vorfall, dass das Unternehmen angemessene Maßnahmen ergriffen und umgesetzt hat? Dieser Beitrag ordnet die unverbindlichen Hinweise der Bundesnetzagentur, der EU-Kommission sowie von BMDS und BAköV ein.
Kurz gefasst: Für die interne Dokumentation empfiehlt sich eine Kombination aus einer datierten Richtlinie, einem Beleg für die tatsächliche Vermittlung und einer kurzen Begründung, warum Inhalt und Format zur Rolle, zum Werkzeug und zum Einsatzkontext passen. Teilnahmelisten, Zertifikate und Review-Artefakte können diese Dokumentation ergänzen, ersetzen sie aber nicht.
Dieser Beitrag ersetzt keine Rechtsberatung. Quellenstand: 10. August 2026.
Welche Quellen hier welchen Status haben
Die Lage ist unübersichtlich, weil neben dem Verordnungstext mehrere unverbindliche Hinweise und Handreichungen vorliegen. Diese Übersicht gilt für den gesamten Beitrag.
| Quelle | Status |
|---|---|
| KI-VO und Änderungsverordnung (EU) 2026/1744 | verbindlicher Normtext |
| Hinweispapier der Bundesnetzagentur, Juni 2025 | unverbindliche Orientierung zum früheren Wortlaut |
| Q&A der EU-Kommission zur KI-Kompetenz | unverbindliche Praxishilfe |
| Handreichung von BMDS und BAköV | Orientierung für die Bundesverwaltung |
| Empfehlungen zu Repository und Pull Requests | eigene praktische Ableitung |
Was Art. 4 KI-VO verlangt und was nicht
Nach Absatz 1 müssen Anbieter und Betreiber Maßnahmen ergreifen, um die Entwicklung der KI-Kompetenz ihres Personals und anderer Personen zu unterstützen, die in ihrem Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befasst sind. Der zweite Satz zieht die Grenze: Ein bestimmtes Kompetenzniveau müssen Anbieter und Betreiber nicht garantieren. Die Absätze 2 und 3 betreffen Unterstützungsangebote von Kommission und Mitgliedstaaten sowie Empfehlungen des KI-Gremiums.
Die Verordnung (EU) 2026/1744, der sogenannte Digital Omnibus, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Mit Art. 1 Nr. 5 wurde Art. 4 KI-VO vollständig neu gefasst. Die Kommission nennt in ihrer Meldung „AI Omnibus enters into force“ dasselbe Datum.
Die frühere Fassung verlangte, „nach besten Kräften“ ein „ausreichendes Maß“ an KI-Kompetenz sicherzustellen. Auch sie war als Bemühenspflicht ausgestaltet. Die Neufassung verschiebt den Schwerpunkt: Unternehmen müssen die Kompetenzentwicklung unterstützen, aber kein bestimmtes individuelles Niveau garantieren. Für die Dokumentation ändert sich damit der Maßstab. Es geht nicht darum, ein „ausreichendes“ Kompetenzniveau zu belegen, sondern angemessene Maßnahmen nachvollziehbar zu machen. Wie sich diese Dokumentationsfrage in die übrige Governance für Coding Agents einordnet, zeigt die Einordnung der Kompetenzfrage im Coding-Agents-Leitfaden.
Unverändert sind die Faktoren, nach denen sich angemessene Maßnahmen richten: technische Kenntnisse, Erfahrung, Aus- und Fortbildung, Einsatzkontext sowie die betroffenen Personen oder Personengruppen. Auch die Definition der KI-Kompetenz in Art. 3 Nr. 56 KI-VO und Erwägungsgrund 20 blieben unangetastet.
Art. 4 richtet sich an Anbieter und Betreiber. Welche Beschäftigten, Auftragnehmer und Dienstleister erfasst sind, hängt von ihrer konkreten Tätigkeit und Einbindung ab. Eine ausführliche Abgrenzung der beiden Rollen bietet mein Beitrag zu den Anbieter- und Betreiberpflichten beim Einsatz von Coding Agents.
Wie Entwicklerteams ihre Kompetenzmaßnahmen dokumentieren
Die konkreteste in den ausgewerteten Quellen gefundene Empfehlung einer deutschen Behörde steht im Hinweispapier der Bundesnetzagentur vom Juni 2025. Sie bezieht sich auf den früheren Wortlaut und ist ausdrücklich unverbindlich. Die Behörde empfiehlt kein bestimmtes Ergebnis, sondern eine plausible und nachvollziehbare Begründung dafür, welche Maßnahmen eine Organisation für welche Personengruppe wählt.
Konkreter wird das Papier bei der Dokumentation. Empfohlen werden Angaben zur Art der Maßnahme, zu ihrem inhaltlichen und zeitlichen Umfang sowie zu den teilnehmenden Personen. Das ist eine mögliche Struktur, keine verbindliche Mindestliste. Aus den ausgewerteten Quellen lässt sich keine eigenständige Dokumentationspflicht nach Art. 4 ableiten.
Was die einzelnen Unterlagen belegen und was offenbleibt, zeigt diese Übersicht:
| Beleg | Was er zeigt | Was er nicht zeigt |
|---|---|---|
| Teilnahmeliste mit Agenda und Datum | Durchführung, Inhalt, Dauer und Teilnehmende | ob die Maßnahme zur Rolle und zum Einsatzkontext passte |
| Externes Zertifikat | Teilnahme, behandelte Inhalte und gegebenenfalls ein Prüfungsergebnis | ob das Angebot zum eingesetzten Werkzeug und zur internen Konfiguration passte |
| Datierte Richtlinie mit Versionsstand und Verteiler | welche Regeln galten und wem sie mitgeteilt wurden | ob die Regeln erläutert und verstanden wurden |
| Dokumentation einer Einweisung oder eines Workshops | vermittelte Inhalte und teilnehmende Personen | ob die Inhalte später angewendet wurden |
| Verweis auf die Gebrauchsanweisung | welche Produktinformationen verfügbar waren | ob eine konkrete Kompetenzmaßnahme durchgeführt wurde |
| Webinar mit Anmeldung und Programm | Termin, Thema und gegebenenfalls Teilnahme | ob die Inhalte auf Repository, Rolle und Freigaberegeln zugeschnitten waren |
Daraus ergibt sich eine Dokumentation aus vier Bestandteilen. Falls Sie den Beitrag nach einer Checkliste durchsuchen, ist das hier die Stelle.
- Art, Inhalt, Dauer und Teilnehmende der Maßnahme
- eine datierte Richtlinie mit Versionsstand und Verteiler
- eine kurze Begründung, warum die Inhalte zu Vorkenntnissen, Rollen, eingesetzten Werkzeugen und dem jeweiligen Einsatzkontext passen
- bei externen Personen eine klare Verteilung der Zuständigkeiten zwischen Auftraggebern, Auftragnehmern und Dienstleistern
Die Inhalte dürfen je nach Rolle unterschiedlich ausführlich ausfallen.
Art. 4 verlangt kein Zertifikat zur KI-Kompetenz
Die Kommission stellt in ihrem Q&A zur KI-Kompetenz klar, dass ein Zertifikat nicht erforderlich ist. Organisationen können stattdessen interne Aufzeichnungen über Schulungen und andere Maßnahmen zur Anleitung und Orientierung führen. Eine Wissensprüfung verlangt Art. 4 ebenfalls nicht.
Die Bundesnetzagentur zählt auf, was ausdrücklich nicht vorgeschrieben ist: formalisierte oder standardisierte Trainingsmaßnahmen, externe Zertifizierungen, ein KI-Beauftragter und regelmäßige Vorabüberprüfungen. Auch das Living Repository des KI-Büros begründet keinen anerkannten Nachweisstandard. Seine Beispiele arbeiten unter anderem mit Abschlussquoten, Kompetenzmatrizen, Fragebögen, Teilnahmeaufzeichnungen und Zertifikaten. Sie zeigen mögliche Vorgehensweisen, schaffen aber keine Vermutung, dass Art. 4 erfüllt ist.
Die interne KI-Richtlinie als Teil der Dokumentation
Eine datierte Richtlinie mit Versionsstand, Verteiler und klaren Regeln für den Einsatz von Coding Agents kann die interne Dokumentation ergänzen. Das Q&A nennt neben Schulungen ausdrücklich andere Maßnahmen zur Anleitung und Orientierung, zu denen eine solche Richtlinie gehören kann. Gegenüber einer bloßen Teilnahmeliste hat sie einen Vorteil: Sie beschreibt den konkreten Einsatzkontext, an dem sich die Angemessenheit der Maßnahmen bemisst.
Die Handreichung von BMDS und BAköV für die Bundesverwaltung macht zugleich deutlich, was voraussichtlich nicht ausreicht: Der bloße Verweis auf die Gebrauchsanweisung des Systems dürfte regelmäßig zu wenig sein. Ein Schulungsverzeichnis hält sie für sinnvoll, nicht für verpflichtend. Hält ein Unternehmen seine Regeln in einer Betriebsvereinbarung zum Agenten-Rollout fest, kann diese Vereinbarung die für den Agenteneinsatz vereinbarten internen Regeln dokumentieren. Die tatsächliche Vermittlung und der Kreis der Teilnehmenden sollten separat belegt werden.
Ein Verzeichnis der eingesetzten Werkzeuge ist nicht vorgeschrieben, stärkt die Dokumentation aber deutlich. Ohne eine solche Übersicht lässt sich schwer zeigen, dass die Maßnahmen den tatsächlichen Einsatzkontext berücksichtigt haben. Das gilt besonders für eigenständig beschaffte oder nicht zentral freigegebene KI-Werkzeuge, denn später ist kaum nachvollziehbar, ob ihre Nutzung in Schulungen und Richtlinien überhaupt behandelt wurde.
Aufbewahrungsdauer und Form der Dokumentation
Die geprüften Quellen zu Art. 4 nennen weder ein festes Auffrischungsintervall noch eine allgemeine Aufbewahrungsfrist.
Nur für beaufsichtigte Institute: MaRisk AT 6 enthält konkrete Vorgaben zu Form und Dauer bestimmter Unterlagen. Geschäfts-, Kontroll- und Überwachungsunterlagen müssen systematisch und für sachkundige Dritte nachvollziehbar abgefasst werden. Die Aufbewahrungsfrist beträgt fünf Jahre.
Die neunte MaRisk-Novelle trat mit dem BaFin-Rundschreiben 06/2026 (BA) am 30. Juni 2026 in Kraft. Soweit sich im Einzelfall zusätzliche Anforderungen ergeben, gilt eine Übergangsfrist bis zum 1. Januar 2027. MaRisk ist ein Rundschreiben und keine unmittelbar geltende Verordnung, für Institute in ihrem Anwendungsbereich aber ein auf § 25a KWG gestützter Aufsichtsmaßstab, wie ihn auch die BaFin-Aufsicht über Coding Agents anlegt.
Daraus folgt nicht, dass jede Unterlage zu Art. 4 fünf Jahre aufzubewahren wäre. Entscheidend ist, ob sie im konkreten Institut als Geschäfts-, Kontroll- oder Überwachungsunterlage einzuordnen ist. Außerhalb des MaRisk-Anwendungsbereichs dient die Regel allenfalls als Orientierung.
Welche Inhalte eine Kompetenzmaßnahme für Entwicklerteams abdecken sollte
Ein Kurs ist nicht zwingend. Entscheidend ist, dass die Organisation eine angemessene Maßnahme ergreift. Nach dem Q&A der Kommission gibt es weder ein Einheitsmodell noch verpflichtende Trainingsformate. In Betracht kommen eine gemeinsam besprochene interne Leitlinie, ein Onboarding-Modul, ein moderierter Workshop oder ein externer Kurs. Welche Form passt, hängt vom Werkzeug, vom Risiko, von der Rolle und vom Einsatzkontext ab.
Ein verbindlicher Inhaltskatalog existiert nicht. Die folgenden Empfehlungen leite ich aus den Bemessungsfaktoren des Art. 4 ab, insbesondere aus den technischen Vorkenntnissen und dem Einsatzkontext. Zum Einsatzkontext eines Teams, das Coding Agents einsetzt, gehören vor allem das eigene Repository, die konkrete Werkzeugkonfiguration und die internen Freigaberegeln. Das Q&A hält unterschiedliche Schulungs- und Lernansätze je nach Vorkenntnissen, Erfahrung und Einsatzkontext für angemessen. Die BMDS/BAköV-Handreichung unterscheidet ausdrücklich nach Rollen und nennt für technische Beschäftigte insbesondere Architektur, Sicherheit und Monitoring. Beide Papiere legen nahe, dass eine allgemeine Bedienungsanleitung eine auf den konkreten Einsatz zugeschnittene Vermittlung häufig nicht ersetzt.
Für einen Coding-Agent-Rollout ergeben sich daraus vier Themen:
- Was der Agent im Repository tun darf, welche Werkzeuge er aufrufen kann und wo seine technischen Grenzen liegen.
- Welche Daten nicht in den Modellkontext gehören und welche Datenschutzregeln für Repository, Tickets und Protokolle gelten. Die Einzelheiten behandelt Coding Agents und DSGVO: was der Agent sehen darf.
- Wie Teams agentengenerierte Vorschläge prüfen, bevor sie in den Codebestand übernommen werden, und woran sich typische Halluzinationen erkennen lassen.
- Wer die fachliche Verantwortung für agentengenerierten Code trägt und wie bei Fehlern eskaliert wird.
Der Einwand, erfahrene Entwickler benötigten keine zusätzlichen Maßnahmen, ist teilweise berechtigt. Nach dem Q&A kann eine einschlägige Vorqualifikation den Bedarf an zusätzlichen Maßnahmen verringern. Sie ersetzt jedoch nicht die Kenntnis des konkret eingesetzten Werkzeugs, seiner organisationsspezifischen Konfiguration und seiner Risiken. Zusätzliche Maßnahmen können sich deshalb auf die erkennbaren Lücken beschränken, etwa auf interne Freigaberegeln.
Ein Produkttraining deckt die rechtlichen Fragen der eigenen Organisation nicht automatisch ab. Beschäftigte sollten auch verstehen, in welcher Rolle das Unternehmen den Agenten einsetzt und welche Regeln für ihre konkrete Tätigkeit gelten. Eine Wissensprüfung verlangt die Kommission nicht. Das Q&A nennt jedoch als Prüffrage, ob die betroffenen Personen neben dem Produkt auch die rechtlichen und ethischen Fragen des konkreten Einsatzes kennen.
Kein Kursformat erfüllt Art. 4 von sich aus. Angemessen ist eine Maßnahme immer nur im Verhältnis zu Rolle, Werkzeug, Vorkenntnissen und Einsatzkontext, und die Dokumentation darüber bleibt in Ihrer Organisation. Wer die vier Themen nicht selbst moderieren will, findet im Aufbau meines dreitägigen Inhouse-Kurses für Entwicklerteams eine mögliche Form, sie mit dem eigenen Team durchzuarbeiten.
Externe Personen und Hochrisiko-Systeme
Die Pflicht beschränkt sich nicht auf eigene Beschäftigte. Sie kann auch Auftragnehmer und Beschäftigte von Dienstleistern erfassen, wenn diese im Auftrag des Anbieters oder Betreibers mit dem Betrieb oder der Nutzung des KI-Systems befasst sind. Das Q&A nennt je nach Einbindung auch Dienstleister und Kunden als mögliche Zielgruppe. Kunden sind jedoch nicht automatisch erfasst. Entscheidend bleibt, ob sie im Auftrag der Organisation handeln. Auch das Hinweispapier der Bundesnetzagentur nennt Auftragnehmer und Dienstleister.
Eine eigenständige Pflicht des Dienstleisters kommt in Betracht, wenn er im konkreten Einsatz selbst als Anbieter oder Betreiber handelt. Wie die Verantwortung zwischen Auftraggeber und Dienstleister zu verteilen ist, klären die geprüften Quellen nicht. Das Q&A legt an das Personal des Dienstleisters lediglich denselben Maßstab an wie an das eigene Personal. Ob ein Vertrag den Dienstleister zur Mitwirkung an Kompetenzmaßnahmen verpflichten sollte, ist laut BMDS/BAköV-Handreichung eine Frage des Einzelfalls.
Für Betreiber von Hochrisiko-KI-Systemen gilt zusätzlich Art. 26 Abs. 2 KI-VO. Danach darf die menschliche Aufsicht nur natürlichen Personen übertragen werden, die über die erforderliche Kompetenz, Ausbildung, Befugnis und Unterstützung verfügen. Der Digital Omnibus hat diese Anforderung inhaltlich nicht geändert. Sie gilt jedoch erst mit den verschobenen Hochrisikofristen, also ab dem 2. Dezember 2027 für Systeme nach Art. 6 Abs. 2 und Anhang III sowie ab dem 2. August 2028 für Systeme nach Art. 6 Abs. 1 und Anhang I.
Welche Fristen und Zuständigkeiten auseinanderzuhalten sind
Art. 4 steht in Kapitel I der KI-VO und gilt seit dem 2. Februar 2025. Der Digital Omnibus ändert zwar Art. 113 Abs. 3 Buchst. a KI-VO, lässt diesen Geltungsbeginn aber unverändert. Seit dem 27. Juli 2026 gilt Art. 4 in neuer Fassung, sein ursprünglicher Geltungsbeginn bleibt davon unberührt. Die im Frühjahr 2026 diskutierte Verschiebung der Hochrisikopflichten betrifft Art. 4 nicht.
| Datum | Bedeutung |
|---|---|
| 2. Februar 2025 | Art. 4 und die übrigen Vorschriften aus Kapitel I gelten |
| 2. August 2025 | Governance- und Sanktionskapitel gelten |
| 27. Juli 2026 | Neufassung des Art. 4 tritt in Kraft |
| 29. Juli 2026 | Deutsches KI-MIG tritt in Kraft |
| 2. August 2026 | Allgemeiner Geltungsbeginn nach Art. 113 Abs. 1 und Beginn der von der Bundesnetzagentur genannten nationalen Marktüberwachung |
| 2. Dezember 2027 und 2. August 2028 | Verschobene Pflichten für Hochrisiko-KI-Systeme |
Die Daten zu Governance und Aufsicht ergeben sich aus der konsolidierten Fassung der KI-VO.
In Deutschland trat am 29. Juli 2026 zusätzlich das KI-Marktüberwachungs- und Innovationsförderungs-Gesetz in Kraft (KI-MIG, BGBl. 2026 I Nr. 223). § 2 Abs. 1 KI-MIG weist der Bundesnetzagentur eine Auffangzuständigkeit als Marktüberwachungsbehörde zu. Für Produkte nach Anhang I Abschnitt A bleiben die sektoralen Behörden zuständig, im Finanzsektor die BaFin.
Auch das aktualisierte Q&A der Kommission enthielt am 10. August 2026 noch widersprüchliche Angaben zum Wortlaut. Für die rechtlichen Eckdaten ist deshalb der konsolidierte Verordnungstext maßgeblich, aus den Praxishinweisen übernehme ich nur Aussagen, die dazu passen.
Welche Sanktionen bei Verstößen gegen Art. 4 in Betracht kommen
Art. 4 gehört nicht zu den besonderen Bußgeldtatbeständen in Art. 99 Abs. 3 bis 5 KI-VO. Diese Absätze betreffen verbotene Praktiken, einzeln aufgezählte Pflichten sowie unrichtige Angaben gegenüber Behörden, und der Digital Omnibus hat Art. 4 nicht in die Aufzählung aufgenommen. Aus dem Fehlen eines besonderen Bußgeldtatbestands folgt jedoch nicht, dass Verstöße zwingend folgenlos bleiben. Art. 99 Abs. 1 verpflichtet die Mitgliedstaaten, Sanktionen und andere Durchsetzungsmaßnahmen für Verstöße gegen die Verordnung vorzusehen. Für Akteure unter unmittelbarer Aufsicht des KI-Büros ermöglicht Art. 75c Abs. 4 zudem Geldbußen wegen Verstößen gegen Pflichten, die Art. 99 Abs. 4 nicht ausdrücklich nennt. Für Organe und Einrichtungen der Union gilt Art. 100.
Im deutschen KI-MIG ist Art. 4 weder als eigener Bußgeldtatbestand in § 15 aufgeführt noch über § 16 erfasst. § 15 KI-MIG verweist auf die KI-VO in der Fassung vom 13. Juni 2024 und übernimmt damit einen festen, später nicht automatisch aktualisierten Stand. § 16 erklärt das Ordnungswidrigkeitengesetz nur für Verstöße nach Art. 99 Abs. 3 bis 5 für anwendbar.
Für private Anbieter und Betreiber außerhalb der unmittelbaren Aufsicht des KI-Büros enthalten §§ 15 und 16 KI-MIG damit keinen speziellen Bußgeldtatbestand für Art. 4. Ob eine Geldbuße auf einer anderen unionsrechtlichen oder nationalen Grundlage in Betracht kommt, lässt sich aus diesen beiden Vorschriften allein nicht beantworten. Die in Art. 99 Abs. 3 bis 5 genannten Bußgeldhöhen beziehen sich jedenfalls auf andere Pflichten und lassen sich nicht ohne Weiteres auf Art. 4 übertragen.
Näher liegen andere Folgen. Nach Einschätzung der Kommission könnte eine Sanktion wahrscheinlicher werden, wenn ein Vorfall nachweislich auf unzureichende Schulung oder Anleitung zurückgeht. Das Q&A beschreibt damit eine mögliche Aufsichtspraxis, keinen eigenen Sanktionstatbestand. Die Bundesnetzagentur verweist in ihrem Hinweispapier auf mögliche Haftungsfolgen: Fehlende KI-Kompetenz könne eine Verletzung der Sorgfaltspflicht darstellen, insbesondere wenn dadurch ein Schaden entsteht.
Nach einem Vorfall gewinnt die vorhandene Dokumentation deshalb besondere Bedeutung. Möglicherweise muss die Organisation rekonstruieren, welche Maßnahmen galten, wem sie vermittelt wurden und wie sie umgesetzt wurden. Dafür kommen auch Tickets, Commits und Review-Kommentare aus dem Zeitraum in Betracht, in dem der beanstandete Code entstand. Eine Teilnahmeliste vom letzten Quartal dürfte allein selten genügen.
Pull-Request-Reviews ergänzen die Dokumentation, ersetzen sie aber nicht
Keine der ausgewerteten Orientierungshilfen nennt die Review-Spur eines Pull Requests als eigenständigen Nachweis. Das gilt für das Q&A der Kommission, das Hinweispapier der Bundesnetzagentur und das Living Repository des KI-Büros. Wertlos ist sie deshalb nicht. Tickets, Commits und Review-Kommentare können eine dokumentierte Kompetenzmaßnahme ergänzen und helfen, einen konkreten Vorgang später nachzuvollziehen. Sie belegen jedoch nicht, welche Maßnahme für welche Personen durchgeführt wurde. Die folgende Einordnung ist eine praktische Ableitung, keine dokumentierte Aufsichtspraxis.
Ein dokumentiertes Review-Protokoll kann zwei Dinge zeigen:
- Zuordnung: Welche Aufgabe erhielt der Agent und welche nicht? Wird der Agent in der Commit-Historie als Autor oder Mitautor ausgewiesen, oder wird sein Beitrag unter einem gemeinsamen technischen Konto verbucht?
- Prüfung: Enthalten die Kommentare fachliche Einwände gegen generierten Code oder nur Freigaben? Ist erkennbar, wer geprüft hat und ob Erstellung und Review personell getrennt waren?
Wie sich diese Konstellationen ordnen lassen, zeigt die Aufstellung dazu, wer bei Coding Agents wen prüft. Die Review-Spur ersetzt jedoch keine Dokumentation über Art, Inhalt, Dauer und Teilnehmende der Kompetenzmaßnahme. Ob eine prüfende Stelle sie ergänzend berücksichtigt, ist offen.
Welche Unsicherheiten bleiben
Ein ergänzender Vermerk sollte die offenen Punkte festhalten. Die Empfehlungen der Bundesnetzagentur sind unverbindlich. Zertifikate und Wissenstests sind nicht vorgeschrieben. Ob Dienstleister vertraglich einzubeziehen sind, hängt vom Einzelfall ab. Weder für Auffrischungen noch für die Aufbewahrung nennt Art. 4 feste Fristen. Die Organisation sollte deshalb selbst festlegen und begründen, welche Änderungen an Werkzeug, Rolle oder Einsatzkontext eine Aktualisierung auslösen.
Ein Punkt lässt sich durch keinen Vermerk schließen: welche Unterlagen eine Behörde im Nachhinein tatsächlich anerkennt. In den bis zum 10. August 2026 geprüften EU- und deutschen Behördenquellen fand sich keine veröffentlichte Entscheidung und keine dokumentierte Prüfpraxis zu Art. 4. Das beschreibt den Stand der Recherche und schließt Fälle in anderen Mitgliedstaaten nicht aus. Wer heute dokumentiert, dokumentiert gegen einen Maßstab, den öffentlich noch niemand angewendet hat.
