How to Build an AI Literacy Programme That Fits Your Organisation
A defensible programme is built in a fixed order, and most failed programmes went wrong by starting in the middle. This lesson gives the order and the design decisions at each step.
The first step is to find out what is actually in use. Run a discovery exercise across single sign-on logs, expense claims, browser extension inventories, procurement records and a short amnesty survey in which people can declare tools without being punished. The amnesty matters, because a register built only from procurement records describes the organisation you think you have. Discovery typically finds three categories, which are sanctioned tools, features that arrived inside software you already own, and personal tools people brought themselves. The second category is the one that surprises people, since assistants now appear inside office suites, customer relationship systems, design tools and code editors without a separate purchase.
The second step is to define populations by task. Group people by what they do with AI rather than by department, because that is what determines their risk and their duties. A workable set for most organisations is everyone who touches any AI tool, people who use AI in decisions affecting individuals, people who publish or communicate externally with AI assistance, people who configure or build with AI, and people who buy AI. A person can sit in several groups, and the groups should be small in number, since a design with fourteen populations will not survive contact with a training calendar.
The third step is to write outcomes before content. For each population, state what a competent person must be able to do, in language specific enough to be assessed. “Understands AI risks” is not an outcome. “Can identify which of five draft customer emails contains a claim that must be verified before sending, and can name the source they would check it against” is an outcome, and it can be built into an exercise and a record.
The fourth step is to build a tiered structure. A baseline module for everyone who touches AI, taking perhaps forty-five to sixty minutes, covers what these systems are, the four risk classes, the tool rules, the disclosure rules and the reporting route. Role modules of twenty to forty minutes each cover the specific duties in Lesson 7. A deeper technical track serves developers, data teams and anyone who could trigger Article 25 by fine-tuning or repurposing a system. Executives and board members need their own short session, because they approve budgets and set risk appetite and are frequently the least trained people in the building.
The fifth step is delivery, and format follows purpose. Baseline content works well as short structured e-learning with assessment, since it is repeatable, dated and evidenced. Role content works better with live sessions using the organisation’s own examples, because the discussion surfaces practices nobody had documented. Technical content works best as workshops with real systems. Whatever the format, use your own tools and your own scenarios, since generic examples produce generic behaviour and, on the evidence side, a module that never names your systems is hard to defend as calibrated to context.
The sixth step is to check understanding rather than attendance. Assessment can be a scored quiz, a scenario exercise with a written judgement, a practical task reviewed by a manager, or a spot check of real work. Set a pass threshold and record the result. This is what turns a completion list into evidence of a sufficient level.
The seventh step is to make the behaviour easy outside the training room. Publish a one-page rule set people can find in the moment. Put the approved tool list where people look for tools rather than in a policy library. Give an easy route to ask for a new tool and answer within days, because a slow route is the main cause of unapproved use. Name people in each function who can answer questions locally, and give them slightly deeper training so the answers are consistent.
The eighth step is measurement that says something. Completion percentage is necessary but tells you nothing about competence. Better indicators include assessment scores by population over time, the number of tool approval requests received, the number of incidents and near misses reported, the results of periodic spot checks on AI-assisted work, and the proportion of new joiners trained before access was granted. A programme with rising reports and falling repeat errors is working, even though the reports look worse on a dashboard.
The ninth step is governance. Name an owner, give them a review cycle, and put AI use and literacy coverage on a committee agenda with minutes. Review at least annually and whenever a trigger fires. The European Commission’s living repository of AI literacy practices is a reasonable place to compare your design against what peers have published, provided you remember that nothing in it confers a presumption of compliance and that a practice which suits a hospital may be wrong for a software firm.