Designing an AI Literacy Program: Inventory, Tiers, and Curriculum

The common response to an AI literacy requirement is a single sixty-minute e-learning module, assigned to everyone, tracked by completion rate, refreshed annually.

It fails on both counts you might care about.

Pedagogically, it addresses a data scientist and a warehouse supervisor with identical content, which means it is simultaneously too basic to be useful to one and too abstract to be actionable for the other. Neither changes their behaviour, which was the point.

Against the Regulation, it ignores the factors the article itself names. Article 4 asks you to take into account technical knowledge, experience, education and training, the context the systems are used in, and the persons on whom they are used. A uniform module takes none of them into account. Even under the softened obligation of effort, appropriate measures is judged against those factors, and a one-size module is weak evidence of having considered any.

The design that works follows the factors directly. Inventory, then segment, then layer.

You cannot tailor training to the context of use before knowing what is in use. Most organizations cannot answer that question on demand, and the gap is larger than expected because AI has stopped arriving as a distinct purchase.

Four categories to sweep.

Procured AI tools: the assistant, the transcription service, the code completion tool, whether or not IT approved them.

AI features inside existing software: the CRM's lead scoring, the HR platform's CV ranking, the helpdesk's suggested replies. These are the ones inventories miss, because the contract was signed for something else and the feature was switched on later.

Systems your organization builds, which make you a provider rather than merely a deployer, with a heavier set of obligations.

Shadow use: tools staff adopted independently. Amnesty produces a far more accurate picture than policy here.

For each, record what it does, who uses it, what decisions it influences, and whether it touches people in a way that could put it in a high-risk category. That last column is what routes people into the heavier training tier.

Segment by relationship to the systems, not by seniority or department. The question is what someone can do with or to an AI system, because that determines what can go wrong.

Tier 0 is everyone: awareness of what AI is, what the organization permits, and where the boundaries are.

Tier 1 is regular users: staff who use AI outputs in their work but do not decide about the systems themselves.

Tier 2 is decision-makers and operators: people who exercise human oversight, act on outputs affecting others, or choose which systems to buy.

Tier 3 is builders and high-risk operators: those developing systems, and those overseeing high-risk deployments where Article 26's competence requirement bites.

A person can sit in one tier for one system and another tier for a different one. Tiers attach to roles-with-respect-to-a-system, not to job titles, which is why the inventory has to come first.

Short, mandatory, and aimed at the failure modes that do not require anyone to be an operator of anything. Thirty to forty-five minutes is realistic.

What an AI system is, in the Regulation's sense, and the fact that AI now sits inside tools not marketed as AI.

The organization's rules: which tools are approved, what may never be entered into an external system, and how to get something approved rather than route around the policy.

Why outputs can be wrong: that these systems generate plausible text rather than retrieve verified facts, and that fluency carries no information about accuracy. One live demonstration of a confident fabrication in the organization's own domain does more than several paragraphs of explanation.

Confidentiality and personal data: what leaves the organization when text is pasted into a third-party tool.

Who to ask, and how to report something that looked wrong.

The test for this tier is not recall. It is whether someone hesitates before pasting a customer list into a consumer chatbot.

This tier is where most of the workforce lands, and where generic training is most obviously wasted. It should be built per tool and per workflow, not delivered as a lecture on AI.

The content that transfers is specific. What this tool is good at and where it degrades, described with examples from the actual work rather than in the abstract. How to verify an output, with a concrete procedure: check the citation, cross-reference the source system, escalate if the two disagree. Which parts of the workflow must not be delegated, and why. What the failure looks like when it happens, drawn from real incidents where possible.

The most valuable single idea to install here is that the appropriate level of scrutiny scales with the consequence of the output being wrong. A draft internal email needs a glance. A figure entering a customer-facing document needs verification against the source. Staff routinely apply uniform scrutiny, usually calibrated to the lowest-stakes use, and the correction is a matter of practice rather than knowledge.

Delivered as a short module attached to the tool's rollout, this outperforms any amount of general AI education.

People in this tier can cause harm at a scale individual users cannot, because they decide what gets deployed and they act on outputs that affect others.

Automation bias is the central topic, and Article 14 names it directly for high-risk systems. It is the documented tendency to over-trust an automated recommendation, to stop looking for disconfirming evidence once a system has produced an answer, and to defer to it more than its accuracy warrants. Meaningful human oversight requires knowing this about oneself. A reviewer who approves ninety-eight percent of what a system proposes is not providing oversight; they are providing a signature.

Alongside it: what genuine oversight requires, including the authority to override and the time to actually look. Oversight without authority is theatre.

The AI Act's risk tiers, enough to recognize when a proposed use might be high-risk and needs escalation rather than a purchase order.

Procurement questions: what to ask a vendor about training data, evaluation, known limitations, and their own obligations as provider.

And the human consequence: what someone affected by a decision is entitled to, and how to explain a decision the system influenced.

This tier is where the obligation stops being one of effort. Article 26 requires deployers of high-risk systems to assign human oversight to natural persons who have the necessary competence, training and authority, which is a requirement of result. Supporting the development of literacy does not satisfy it.

For people overseeing a specific high-risk deployment, the training is system-specific: what this system does and how, its documented accuracy and its known failure modes, the populations where it performs worse, what the instructions for use actually say, how to intervene and stop it, and the logging and record-keeping duties attached.

For people building systems, it extends into the provider obligations: risk management, data governance, technical documentation, accuracy and robustness testing, and post-market monitoring.

Two practical notes. Competence here should be demonstrable, because the standard is competence rather than exposure, which makes this the one tier where assessment is genuinely warranted. And it has to be refreshed when the system changes, since competence on last year's version of a model is not competence on this one.

Two of the factors Article 4 names get consistently skipped, and both change the content rather than merely the depth.

Context of use means the sector and the stakes. AI literacy for a hospital is not AI literacy for a marketing agency wearing different examples. The clinical setting brings patient safety, the limits of decision support, and documented failure modes in medical imaging. The recruitment setting brings discrimination law and proxy variables. Generic training with the logo changed is the most common form of this failure.

Persons on whom the systems are used is the clause that points outward. A system used on patients, candidates, students, or benefit claimants creates duties toward people who are not in the room and did not choose to be subject to it. Training for staff operating such systems should cover what those people are entitled to: to know a system was involved, to a meaningful explanation, and to a route to challenge the outcome.

This is the clause that distinguishes AI literacy in the Regulation's sense from tool training. Tool training asks how do I use this. AI literacy asks what happens to the person on the other end.

Concretely, for a mid-sized insurer running a claims triage model and a general assistant, the map falls out of the inventory.

SYSTEM                    TIER 0  TIER 1  TIER 2  TIER 3
General assistant         all     all     -       -
  (drafting, summarising) staff   users

CRM lead scoring          all     sales   sales   -
                          staff   reps    leaders

Claims triage model       all     -       claims  claims
  (likely high-risk:              -       managers handlers
   affects individuals)                            + ML team

Read the last row. Claims handlers exercising oversight of a system that decides how a person's claim is routed sit in Tier 3, not Tier 1, even though they are neither senior nor technical. Their sales colleagues, using a lead-scoring model of comparable technical sophistication, sit in Tier 1, because being wrongly ranked as a sales lead is not a harm of the same kind.

The tier follows the consequence to the affected person, not the complexity of the model. That single principle resolves most segmentation arguments.

Six patterns, each of which produces a program that exists without working.

The uniform module, covered at the start. It ignores every factor the article names.

Instructions for use as the program. The Commission's guidance says directly that pointing staff at the documentation is likely insufficient on its own.

Teaching the Regulation instead of the practice. Staff do not need Article numbers. They need to know what to do on Tuesday. Compliance teams need the Article numbers.

Prohibition without provision. A policy that bans AI tools without offering an approved alternative produces shadow use, and shadow use is unmonitored use.

Training only at onboarding. The systems change faster than the workforce does, and a joiner from two years ago was trained on a tool that has since been replaced.

Excluding contractors. The article covers other persons acting on the organization's behalf, and outsourced operations teams are often the heaviest users of the systems in question.

The common root is treating this as a training deliverable rather than an ongoing operational practice, which is the subject of the final lesson.