Building a Role-Based AI Literacy Matrix Under EU AI Act Article 4 for Healthcare Staff
Article 4 requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and others operating AI on their behalf. It prescribes no curriculum, so the defensible approach is a matrix that links each role to the AI systems and contexts it encounters, the literacy expected, an accountable owner, refresh triggers, and the evidence you retain. Pair it with runtime policy enforcement, because literacy shapes what people understand, not what an AI system is permitted to do.
What Article 4 requires and what it leaves open
Article 4 of Regulation (EU) 2024/1689 applies to providers and deployers of AI systems. They must take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. The measures must take into account those persons' technical knowledge, experience, education and training, and the context in which the AI systems are used. The Commission states that the AI literacy obligations have applied since 2 February 2025.
The Regulation also defines AI literacy in Article 3(56) as the skills, knowledge and understanding that allow an informed deployment of AI systems and awareness of the opportunities, risks and possible harm of AI. That definition is useful for design. It points the matrix at how each role uses, relies on or oversees AI output, not at general AI knowledge.
Keep three layers of authority separate in your documentation. The Article text is binding. Recital 20 is interpretive: it says the notions needed vary with context and gives examples such as measures applied during use and ways to interpret system output. The Commission also publishes an AI literacy Q&A, which describes the duty in terms of supporting the development of AI literacy; the Regulation remains the primary reference. The matrix itself, including its role categories and proficiency levels, is common practice. Article 4 sets no certification, fixed proficiency levels or specific record format, so the organization has to justify its own structure.
Worked example: healthcare roles
The rows below are illustrative organizational choices, not categories defined by the Regulation. The differentiating question for each is the same: what does this person do with AI output, and what could go wrong if they misjudge it?
- Clinicians: Use decision support or documentation assistance. Emphasis: limits of the system, interpreting output, when to override, handling patient data, and reporting unexpected behavior.
- Clinical informatics: Configure, validate fit for the use context, and monitor. Emphasis: intended use, performance changes, and incident escalation.
- Administrative and revenue cycle staff: Use AI for coding, summarization or correspondence. Emphasis: data handling, approved tools only, and escalating doubtful output.
- Data and engineering teams: Build, integrate and use coding assistants. Emphasis: data boundaries, tool and agent permissions, and change control.
- Procurement: Select and contract for AI. Emphasis: reading instructions for use, deployer duties, and what vendors must supply.
- Executives: Accountable for risk appetite and oversight authority. Emphasis: risks and possible harm, and the authority to stop or restrict use.
Evidence an auditor would reasonably ask for
Because no record format is prescribed, retain evidence as a defensible demonstration of a sufficient level of literacy, not as a mandated artifact. It helps to separate three record types.
The first is what each person was expected to know: the matrix, its version history and the rationale per role. The second is what they completed or were assessed on: training and assessment records held wherever your organization manages them. The third is what the AI was permitted to do and did: system-level records of permissions and interactions. The first two show intent and preparation. Only the third shows actual behavior, and it is the one that lets you test whether role expectations and real AI use match.
For US-regulated healthcare operations, the third record type also supports HIPAA 164.312(b) audit controls, which concern recording and examining activity in systems that handle electronic protected health information. One set of interaction-level records can serve both the EU AI Act and HIPAA review questions if it is designed with both in mind.
Where training alone is not enough
A recital on human oversight says deployers should ensure that people assigned to oversight have the necessary competence, in particular an adequate level of AI literacy, training and authority. Literacy is one attribute in that list. Authority and the technical boundaries around a system matter too, and a well-trained clinician can still paste patient data into an unapproved tool under time pressure.
That is where technical controls complement the matrix. Reading the matrix as a permissions model, roles with lower literacy expectations or higher-risk contexts can have narrower AI actions, and certain actions can require human approval regardless of training completion. This is a design suggestion, not a legal requirement.
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions can be allowed, redacted, blocked, rate limited or escalated for human approval at the level of individual interactions and tool calls. Role-based permissions are enforced at runtime, not reviewed after the fact, and the enforcement produces audit-ready evidence mapped to the EU AI Act and HIPAA, among other frameworks. Trussed runs in production with healthcare organizations. The matrix remains your responsibility, and training delivery sits outside what Trussed does.
Carrying the approach to insurance and banking, and keeping it current
For payer, insurance or financing operations, keep the same structure and change the rows. Typical additions are claims handlers, underwriters, credit analysts, fraud and operations staff, model owners and customer service teams, each mapped to the systems and decision contexts they encounter. The columns, owners, triggers and three evidence record types stay as they are. Any sector-specific obligations should be added from their own legal sources, not inferred from Article 4.
To keep the matrix current, treat it as a controlled document with a named compliance owner. As of November 2026, the Digital Omnibus on AI, proposed by the Commission on 19 November 2025, is pending, with a provisional agreement announced on 7 May 2026. Add a standing trigger to review the matrix when the amending act is finalized, and assign someone to monitor it. Revisit role rows whenever a new AI system, vendor or use context enters the organization.
Anatomy of the literacy matrix
Roles
Clinicians, informatics, administrative and revenue cycle, data and engineering, procurement, executives, contractors.
Systems and context
The AI systems each role operates, relies on or oversees, and where they are used.
Expectations and ownership
Proficiency, content, named owner and refresh triggers per role.
Evidence
Expected knowledge, completed training, and what the AI was permitted to do and did.
Pair your literacy matrix with enforced policy
See how enforcement in the execution path produces audit-ready evidence of what your AI was allowed to do and what it did.
Request a DemoHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.