AI, Audited’s Five-Pillar AI Literacy Framework
Article 4 obliges providers and deployers to take measures on AI literacy for the people who operate AI systems on their behalf — but prescribes no syllabus, no checklist, no threshold (§1 sets out what the law now asks). This framework fills the gap — five pillars of competence, depth tiers by role, and the evidence an auditor can actually inspect.
Start with the Commission’s official guidance on Article 4 — the regulator’s own reading of the obligation; §1 links the amended Regulation itself. What follows is ours: a proposed practitioner standard from AI, Audited, written for the people who have to run a literacy program and evidence it.
The Five Pillars — Diagram
Tap a pillar to see what it requires and what proves it.
What the law actually asks for
The Act defines AI literacy as the skills, knowledge and understanding that allow providers, deployers and affected persons to make an informed deployment of AI — with awareness of the opportunities, the risks, and the harm it can cause. As adopted in 2024, Article 4 asked for a “sufficient level” of it, calibrated to each person’s technical knowledge, experience, education and role. The Digital Omnibus amendments have since changed that, and current Commission guidance reflects the change: the obligation to take literacy measures remains, but a specific mandated “sufficient level” no longer does. The original 2024 wording is summarized below, retained as the historical record.
Providers and deployers of AI systems shall 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, taking into account their technical knowledge, experience, education and training, the context in which the AI systems are to be used, and the persons or groups of persons on whom the AI systems are to be used. Article 4 of Regulation (EU) 2024/1689, as originally adopted in 2024 — paraphrased (historical wording; the obligation applied from 2 February 2025)
Start with the primary sources: the Commission’s official guidance on Article 4 and, on EUR-Lex, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI). Guidance explains the obligation in the regulator’s own words; only the Regulation binds. Neither hands you a curriculum, depth tiers by role, or an evidence pack. That practitioner gap is what this framework is written to close: a reasonable, documented program you can actually run — and show.
Who owes it — almost everyone
The most common misreading is that AI literacy is a builder’s problem. It isn’t. Article 4 binds providers and deployers — and a deployer is anyone who uses an AI system under their own authority. Buying an off-the-shelf tool does not outsource the obligation.
You build or brand it
Organisations that develop an AI system, put it on the market under their name, or substantially modify one. Your staff need the deepest technical literacy — and note the trap: fine-tune or white-label a general-purpose model far enough, and a “user” legally becomes a provider, with full provider duties.
You use it in your work
Any organisation running AI in its operations — screening résumés, drafting customer replies, scoring risk. You owe literacy to staff and to anyone operating the system on your behalf, including contractors. “The vendor handles compliance” is the blind spot this framework exists to close.
The five pillars, in full
A program is defensible when every person, at the depth their role requires, can stand on all five pillars. Select each pillar in the diagram above for the detailed breakdown — the same five appear below as the normative text of the framework.
Depth by role, not one-size training
Literacy is proportionate. A single annual click-through course fails everyone: too shallow for the people building systems, pointless for the people merely affected by them. This framework sets three depth tiers; every role maps to one tier per pillar.
Hands on the system
People who operate AI daily — recruiters screening with it, analysts using AI outputs, support agents sending AI drafts. They need all five pillars at working depth: how their tool behaves, where it fails, when to override it, and how to escalate.
Hands in the system
Developers, data scientists, ML and platform engineers. Everything at working depth, plus the technical core of Pillar 4 — training-data provenance, evaluation, drift — and the engineering side of oversight: logging, monitoring, and kill switches.
Hands on the wheel
Executives, legal, risk, compliance, HR leadership. They need the governance reading of every pillar: which use cases sit in which risk tier, who is accountable when the output is wrong, what evidence exists, and what the organisation claims publicly.
The evidence: what you show an auditor
Literacy that leaves no trace is indistinguishable from no literacy. This framework therefore defines the artifacts, not just the teaching. When an auditor, regulator, or customer asks “prove your people are AI-literate,” these five items are the answer.
- 1Role-to-pillar curriculum mapEvery role in scope, mapped to the five pillars at its depth tier. This is the document that turns “sufficient” from an opinion into a position.
- 2Completion and currency recordsWho completed what, when, and when it expires. Named individuals, dated, retrievable — not a screenshot of an LMS homepage.
- 3Assessment results, not attendance Recommended practiceA short scenario-based check per pillar (“the model flags this candidate — what do you do?”) with recorded outcomes. Attendance shows presence; a scenario assessment provides evidence of applied understanding.
- 4System-specific briefingsFor each AI system in production, a one-page briefing: what it does, known failure modes, override and escalation path. Updated when the system changes.
- 5Refresh and incident logEvidence the program is alive: scheduled refreshers, plus literacy actions taken after real incidents — a fabricated citation caught, an override exercised, a near-miss reviewed.
The framework in practice: one worked scenario
The pillars are abstract until somebody pushes back on a machine. Here is the framework working as intended — a recruiter, a screening tool, and one rejection that does not survive a second look.
Expected response
The rejection does not stand by default. The recruiter checks the tool’s one-page briefing — its known failure mode is penalising non-linear careers — then re-reads the CV herself. The gap is a caregiving break followed by contract work the parser had missed. She overrides the rejection, advances the candidate to interview, and records the override in the system rather than working around it.
Evidence recorded
- Tool output, score, and model version captured on the candidate record
- Override logged with reason: “gap mis-parsed; skills verified manually”
- Decision trail visible to the hiring manager and auditable later
- Pattern flagged in the system’s failure-mode register (second occurrence)
Remediation
The monthly review surfaces the pattern. The team queries the vendor on how gaps are scored, re-screens recent auto-rejections with the same profile shape, updates the system briefing, and adds the case — anonymised — to the next refresher as a scenario question. Oversight, monitoring, and acting on what monitoring finds is the deployer’s side of the bargain under Article 26.
Keeping it alive: the refresh cadence
AI literacy decays faster than any other compliance topic because the systems themselves change under people’s feet. A certificate from 2025 says little about a model updated last month. None of the cadence below is in the Act — annual refreshers, scenario assessments, and baseline training before unsupervised use are this framework’s recommended practice: proportionate defaults you can defend, not legal deadlines.
Baseline
Full five-pillar training at the role’s depth tier, with assessment, before unsupervised use of any AI system.
Refresh
A shorter update cycle: what changed in the systems, the law, and the incident log — closed with a fresh scenario assessment.
Event-driven
New system, major model update, new use case, or a real failure triggers a targeted briefing for affected roles — logged in the incident record.
How it anchors to existing frameworks
Monday morning: the first five moves
- Inventory by use case, not by tool. List where AI touches a decision. The same model screening résumés and answering FAQs is two different risk profiles — and two different literacy needs.
- Map roles to the three depth tiers. Hands on, hands in, hands on the wheel. If a role can’t be placed, that’s your first gap.
- Draft the curriculum map. Five pillars across the top, roles down the side, depth in each cell. One page. This is the artifact an auditor asks for first.
- Brief one system properly. Pick your highest-stakes AI tool and write its one-page briefing: behaviour, failure modes, override path. Then do the rest.
- Log it all from day one. Completions, assessments, briefings, refreshers. The evidence trail is what turns “we trained people” into something an auditor can follow.
Static email edition
The diagram above runs on JavaScript; email clients do not. This edition carries the complete framework as plain static HTML — no scripts — ready to paste into an email or newsletter tool.
Read or copy the static email edition
AI, Audited’s Five-Pillar AI Literacy Framework (Newsletter Issue #002)
A proposed practitioner standard for Article 4 of the EU AI Act. Article 4 still obliges providers and deployers to take measures on AI literacy. Under the Digital Omnibus amendments reflected in current Commission guidance, a specific “sufficient level” is no longer mandated — the 2024 position is summarized in the full edition as the historical record. Start with the European Commission’s official Article 4 guidance; what follows is ours.
The five pillars
1. Know Your System. What the AI in front of you actually does — and where its competence ends. In practice: the system’s purpose in one plain sentence, how outputs are produced (probabilistic, not authoritative), the tasks it is not validated for, and version awareness.
2. Know the Failure Modes. Bias from skewed training data, silent drift, and — in generative systems — fluent fabrications; plus automation bias, the human failure to question a confident-looking output. In practice: learn your own tools’ failure patterns before they reach a decision.
3. Exercise Human Oversight. Article 14 requires high-risk systems to be designed for effective human oversight; Article 26 sets the deployer’s duties — use as instructed, assign competent oversight, monitor, report serious incidents. In practice: trigger points for review, how to interrogate an output, override authority, blameless escalation.
4. Respect the Data. Behaviour is set by the data behind the system — training data, and whatever it keeps ingesting. In practice: “bad data in, bad decisions out” at working depth; provenance, lineage, and drift discipline at technical depth.
5. Know the Boundaries. The legal perimeter: prohibited practices, risk tiers set by use case (not by model), deployer duties, and affected persons’ rights to explanation and redress.
Depth by role
- Hands on the system (operators — recruiters, analysts, support agents): all five pillars at working depth.
- Hands in the system (developers, data scientists, engineers): working depth plus technical data provenance and oversight engineering.
- Hands on the wheel (executives, legal, risk, compliance): the governance reading of every pillar.
Worked scenario: the challenged rejection
A screening tool auto-rejects a strong candidate over a two-year employment gap, citing only “profile fit.” The recruiter checks the system briefing (known failure mode: penalising non-linear careers), re-reads the CV, finds contract work the parser missed, and overrides the rejection. Recorded: tool output and model version, the override with its reason, an auditable decision trail, and a failure-mode register entry. Remediation: vendor queried, similar rejections re-screened, briefing updated, the anonymised case added to refresher training.
Evidence checklist
- Role-to-pillar curriculum map
- Completion and currency records
- Assessment results — scenario-based; an assessment provides evidence of applied understanding
- One-page briefing per AI system in production
- Refresh and incident log
Recommended practice (not law)
The Act prescribes no cadence. Our recommendations: baseline training before unsupervised use of any AI system, a refresher every 12 months, event-driven briefings when a system changes or an incident occurs, and scenario assessments at each cycle.
Monday morning: the first five moves
- Inventory by use case, not by tool.
- Map roles to the three depth tiers.
- Draft the one-page curriculum map.
- Brief your highest-stakes system first.
- Log everything from day one.
AI, Audited’s Five-Pillar AI Literacy Framework — published in AI, Audited, Newsletter Issue #002 — a proposed practitioner standard, not legal advice. Offered for adoption and adaptation with attribution.