BLUF: Generic company-wide AI training produces attendance records, not control. A defensible approach treats role-based AI competence as an input to authorisation: a person receives the entitlement to operate, approve or change a sensitive AI workflow only while a time-bound, role-specific competence claim is valid. That turns AI literacy from an annual campaign into an enforceable access-control property with an expiry date, an owner and an audit trail.
Why training records do not answer the operational question
The question an incident review actually asks is narrow: who was permitted to approve this output, on what basis, and was that basis still valid at the time of the decision? A completion certificate from an e-learning platform cannot answer it. It records that a person watched a module, usually a generic one, at some point in the past — not that the person held the specific competence needed for this system, in this context, with these consequences.
The gap is structural. Learning-management systems model courses and completions. Identity systems model groups and entitlements. In most organisations the two never meet, so the AI platform enforces access based on job title or department, while competence lives in a spreadsheet export that nobody reads at authorisation time.
Article 4 of the AI Act sets the direction. Since Regulation (EU) 2026/1744 (the Digital Omnibus on AI) entered into force on 27 July 2026, Article 4(1) requires providers and deployers to take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the systems are used in. The Commission Q&A is explicit that this does not oblige you to measure individual knowledge and that no specific individual literacy level is mandated.
Legal question for counsel versus engineering recommendation
Legal question for counsel: whether your organisation is a provider or a deployer for a given system, which literacy measures are adequate for your sector and risk profile, whether a specific workflow falls under the high-risk regime, and how works-council co-determination and data-protection law constrain any competence or telemetry data you collect. Those answers depend on role, sector and use case, and they require a lawyer.
Engineering recommendation: whatever the legal floor turns out to be, build the mechanism so competence is a machine-readable, expiring claim that the authorisation path can evaluate. The Act does not require you to gate access on training. But two adjacent obligations make a competence-aware entitlement model the natural design. Article 26(2) requires deployers of high-risk AI systems to assign human oversight to natural persons who have the necessary competence, training and authority as well as the necessary support. Article 14 requires that those persons can understand the system’s capacities and limitations, remain aware of automation bias, interpret output correctly, decide not to use the system, and interrupt it. Article 14(5) goes further for certain biometric identification systems: no action may be taken on the basis of the identification unless it has been separately verified by at least two natural persons with the necessary competence, training and authority.
You cannot demonstrate "necessary competence, training and authority" for a named oversight role with a company-wide completion rate. You can demonstrate it with a per-role claim that is issued, scoped, dated and revocable.
The capability matrix: separate what a person may do from who they are
Start by decomposing AI work into capabilities, not job titles. A capability is a specific permitted action on a specific class of AI workflow, with a defined consequence if performed badly. Typical capabilities in an enterprise AI estate: use a general assistant on internal data; submit a new use case for intake; approve an AI-assisted decision affecting a customer; override or reverse a model output; change a production prompt or retrieval configuration; promote a model version; and act as the named human overseer for a high-risk workflow.
Each capability then gets three properties: the competence evidence required to hold it, a validity period, and an escalation path when the claim is missing or expired. This is the artefact that makes the whole system operational — not the training catalogue.
Capability, expiry and escalation matrix
Assistant use on internal data — Evidence: baseline AI literacy module plus acknowledged acceptable-use policy. Validity: 24 months. Missing/expired: access to the governed workspace suspended; self-service renewal.
Use-case intake submission — Evidence: baseline literacy plus intake-process training covering classification triggers. Validity: 24 months. Missing/expired: submission blocked; routed to the AI governance function.
Approving an AI-assisted customer-affecting decision — Evidence: role-specific module on the system’s capacities, limitations and automation bias, plus a passed scenario exercise on the actual system. Validity: 12 months. Missing/expired: approval action disabled; queued to a qualified approver.
Production prompt, retrieval or configuration change — Evidence: platform-change training plus release-process training plus rollback drill participation. Validity: 12 months. Missing/expired: change request rejected at the deployment gate.
Model promotion — Evidence: evaluation-interpretation training plus segment-threshold training plus a completed supervised promotion. Validity: 12 months. Missing/expired: promotion gate fails closed.
Named human overseer, high-risk workflow — Evidence: system-specific oversight training covering interpretation, override and stop procedures, plus a documented practical interruption exercise. Validity: 6 months. Missing/expired: the workflow reverts to a lower-autonomy or advisory-only mode, or is paused; escalation to the accountable owner.
Dual-verification role, where required — Evidence: as above, for two independent individuals with separate reporting lines. Validity: 6 months. Missing/expired: the action cannot be executed; no single-person override exists.
Identity-to-entitlement architecture
The mechanism has five components and one strict rule: the AI platform never reads the learning system directly.
1. Competence registry. Records competence events: which module or exercise, which system scope, who assessed it, when it was issued, when it expires. It is an evidence store, not a training catalogue. It accepts inputs from the learning platform, from supervised practical exercises, and from documented prior experience recognised by the accountable owner — the Article 4 wording covers technical knowledge, experience, education and training, so an experienced control engineer should not be forced through a beginner module to hold a capability.
2. Claim issuance. A scheduled job converts valid competence events into capability claims and pushes them to the identity provider as group memberships or attributes. Claims carry a validity window. Expiry is the default, not an exception.
3. Identity provider. Holds the claims and issues tokens containing them. This is the single source of truth the runtime trusts. Nothing downstream re-derives entitlement from job title.
4. Enforcement points. The AI gateway, the workflow engine, the approval UI and the deployment pipeline each check the specific claim required for the specific action, at the moment of the action. An expired claim behaves exactly like a revoked permission.
5. Contextual acknowledgement. At the point of a consequential action, the interface states the concrete limitation that matters here and requires an explicit acknowledgement, which is recorded with the decision. This is the only "training" that reliably lands, because it is delivered at the moment of use rather than eleven months earlier.
Data flow: competence event → competence registry → claim issuance job → identity provider claim with expiry → token → enforcement point evaluates action-specific claim → decision record contains user, claim ID, claim version, acknowledgement and timestamp. The decision record is the artefact you will need in an incident review; store it with the same discipline you apply to a model release manifest.
Recertification as a control, not a calendar ritual
Quarterly or semi-annual recertification is only useful if it is triggered by change rather than by the calendar alone. Three triggers matter more than the date: a material change to the AI system (new model version, new retrieval scope, changed autonomy level), a change in the person’s role or scope, and an incident or near-miss in that workflow class. A model promotion that changes output behaviour should invalidate overseer claims for that workflow and require a short delta exercise on the new behaviour — not a full repeat of the original course.
Design the renewal to be short and specific. A six-month overseer claim renewed through a fifteen-minute delta exercise on what actually changed produces better oversight than an annual ninety-minute generic module, and it generates evidence that maps to a specific system version.
Learning telemetry: aggregate by default
The temptation is to instrument everything: who failed which question, who took longest, who repeatedly ignored a warning. Resist it. In Germany, performance and behaviour monitoring of employees engages works-council co-determination and data-protection constraints, and an individual-level competence dashboard is very likely to require both a legal basis and a negotiated agreement. Involve the works council and your data protection officer before you build it, not after.
A defensible default: the authorisation path uses individual claim status, because a binary valid/expired entitlement is necessary to enforce the control. Everything else — module effectiveness, error patterns, acknowledgement rates, capability coverage per workflow — is aggregated to a group large enough to prevent re-identification, with a documented retention period. Aggregate signals are also what you actually need for improvement: if 40 percent of approvers acknowledge a limitation warning in under two seconds, the warning is the defect, not the individuals.
Failure modes
1. Claims are granted but never expire. The registry fills with permanent entitlements and the control silently becomes a one-time gate. Mitigation: make validity a required field with a maximum ceiling per capability class; run a scheduled report on claims approaching expiry and reject issuance requests without an expiry.
2. Role inflation. Because the fast path to unblocking someone is to grant a broader capability, the highest-privilege claims spread. Mitigation: separate the person who requests a claim from the person who approves it, review high-consequence capability holders quarterly against actual usage, and revoke unused claims.
3. The enforcement point checks the wrong thing. A UI hides an approve button but the underlying API still accepts the call, so the control is cosmetic. Mitigation: enforce server-side at the gateway and workflow engine; test the control by attempting the action with an expired claim as part of the release test suite.
4. Acknowledgement fatigue. A generic modal appears on every interaction and is dismissed reflexively. Mitigation: reserve contextual acknowledgement for genuinely consequential actions, make the text system-specific and short, and measure dismissal latency in aggregate as a warning-quality signal.
5. Training completion is treated as competence. Someone completes a module about generative AI in general and is granted an overseer claim for a specific industrial workflow. Mitigation: require system-scoped practical evidence for oversight and change capabilities; a generic module can only ever satisfy a baseline capability.
6. Contractors and service providers are missed. The Commission Q&A treats "other persons dealing with the operation and use of AI systems on your behalf" as covering people under your organisational remit who are not employees, and names contractors, service providers and clients as examples. If they authenticate through a federated identity or a shared service account, the competence claim usually does not follow them. Mitigation: eliminate shared accounts on consequential paths, extend claim issuance to external identities, and make the claim requirement contractual.
How this connects to the rest of the control estate
Competence claims are only meaningful if the workflow they gate is itself inventoried and classified. The AI use-case intake and applicability graph provides that foundation: it tells you which workflows exist, which are consequential, and who owns them, which is exactly the input the capability matrix needs. Without it you will be issuing claims against systems you cannot name.
Two adjacent controls complete the picture. The identity-first pattern in RAG access control that enforces permissions before retrieval is the same principle applied to data: entitlement is evaluated before the system acts, not after. And where a competence claim gates a model promotion or configuration change, the shared FRIA–DPIA evidence platform is where the resulting assessment evidence should live, so that the person, the claim, the assessment and the release all reference the same objects.
What this does not solve
A competence-aware entitlement model does not make a person competent, does not establish that an AI system is accurate or lawful, and does not substitute for risk management, evaluation or human-oversight design. It cannot prevent a qualified, well-trained person from making a poor decision under time pressure. It does not determine your legal obligations: whether you are a provider or a deployer, whether a system is high-risk, and what literacy measures are adequate are questions for counsel with your sector context. Article 4 itself does not require access gating, and the Digital Omnibus amendment removed the reference to a "sufficient" level, so treat this as a control-design pattern that happens to produce Article 4 and Article 26(2) evidence — not as a compliance product.
It also adds real operational cost: a registry to maintain, claims that expire at inconvenient moments, escalation paths that must actually be staffed, and a works-council conversation. If your AI estate is three low-consequence assistants, this is over-engineering. It earns its cost when consequential approvals, production changes and named oversight roles exist.
Start with the two capabilities that carry real consequence
Do not model the whole estate. Pick the two capabilities where a wrong action has a real external effect — typically approving a customer-affecting AI-assisted decision, and changing a production prompt or retrieval configuration. Define the evidence, the validity period and the escalation path for those two. Wire one enforcement point server-side and test it with an expired claim. Then measure how often the escalation path fires; that number tells you whether your capability coverage is real or aspirational.
If you are designing this for a German or EU organisation with high-risk or industrial workflows, I run an implementation workshop that turns your existing use-case inventory into a capability matrix, an identity-to-entitlement design and a recertification trigger model, with the works-council and data-protection boundaries mapped before anything is built.
Sources
Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Article 4 of the AI Act
European Commission: AI Literacy — Questions & Answers
Regulation (EU) 2024/1689 (AI Act), Article 26: obligations of deployers of high-risk AI systems
