How to build an AI literacy programme at work: a 30-day plan

An effective AI literacy programme helps employees use AI tools safely, critically, and productively in the work they already do. The fastest way to build one is to start with a usage inventory, group employees by role and risk, practise realistic scenarios, and keep an evidence file that records what the organisation has done.

The EU AI Act gives this work a clear compliance context. Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff and other people dealing with AI systems on their behalf. The provision has applied since 2 February 2025. Supervision and enforcement of the AI Act rules began on 2 August 2026. This article is not legal advice. Your organisation should assess its own obligations with qualified legal and compliance advisers.

What should an AI literacy programme cover?

AI literacy is more than knowing how to write a prompt. Employees need enough knowledge and practical judgement to understand what an AI system does, where it can fail, what information it may process, and when a human must review its output.

A workplace programme should cover five areas:

1. Basic understanding: What generative AI, predictive systems, recommendation tools, and automated decision systems do.
2. Use boundaries: Which approved tools and use cases employees may use, and which activities require approval.
3. Data handling: How to avoid exposing personal data, confidential business information, credentials, source code, or regulated records.
4. Output review: How to check accuracy, relevance, bias, copyright risk, and unsupported claims before using an output.
5. Escalation: How to report an incident, questionable output, suspected data exposure, or a new use case.

The level of training should match the employee's role, the system being used, and the possible impact of mistakes. A marketing employee drafting social copy does not face the same risks as a recruiter screening applications, a finance team summarising sensitive records, or an engineer connecting an AI assistant to internal systems.

How do you start with a usage inventory?

Days 1 to 5 should focus on finding out how AI is already used. Do not begin with a long course catalogue. Begin with the work.

Ask each department to list the AI tools, features, and workflows employees use or are considering. Include public chatbots, office-suite assistants, meeting transcription tools, coding assistants, customer support features, document search systems, and AI features embedded in software the company already buys.

For every use case, record:

Field	Question to answer
Tool	Which product or built-in feature is involved?
Owner	Which team is responsible for the workflow?
Users	Which roles use it, and how often?
Input	What information goes into the system?
Output	What decision, document, or action does it support?
Review	Who checks the output before it is used?
Risk	What could go wrong if the output is wrong or exposed?
Status	Approved, restricted, under review, or unknown?

Use short interviews, a staff survey, and a review of procurement records. Ask employees about unofficial use as well. People may already be copying text into public tools, using browser extensions, or asking an AI assistant to analyse files. The purpose is to understand the current state, not to punish people for revealing it.

By the end of day 5, classify each use case into three groups. Low-risk uses can usually proceed with basic guidance and human review. Medium-risk uses need a named owner, approved tool, and documented checks. High-risk or unclear uses should pause until security, legal, compliance, or senior business owners review them.

If the inventory includes an AI assistant that needs to work with existing applications, review the integration path, permissions, and audit trail before expanding the use case. See How can an AI assistant connect to existing systems? for a practical framework.

How should you divide employees into learning groups?

Days 6 to 10 should turn the inventory into a role-based learning plan. A single two-hour presentation rarely changes workplace behaviour because it gives everyone the same examples, regardless of their responsibilities.

Create groups based on both job function and exposure to risk. A useful structure is:

• All employees: Approved tools, prohibited inputs, fact checking, safe prompting, and incident reporting.
• Managers and process owners: Use-case approval, accountability, review standards, and staff support.
• Data and security teams: Access control, retention, vendor assessment, logging, and incident response.
• People teams: Recruitment, performance, employee records, workplace monitoring, and fairness concerns.
• Developers and technical teams: Code privacy, secrets management, model access, testing, and system permissions.
• Customer-facing teams: Accuracy, disclosure, escalation, and protection of customer information.

Give each group a small set of outcomes. For example, all employees should be able to identify sensitive information before entering a prompt. Managers should be able to approve or reject a proposed use case with reasons. Developers should be able to explain what data an AI assistant can access and how that access is logged.

Prepare a one-page rule sheet before the sessions begin. It should name approved tools, restricted data, required human review, reporting channels, and the person responsible for questions. Keep the wording operational. Employees need to know what they can do on Monday morning.

A policy is easier to use when it is connected to training. If the organisation is developing a broader corporate AI training programme, align the rule sheet with that programme rather than publishing competing instructions. See How to structure corporate AI training for the wider training context.

What should happen during role-based sessions?

Days 11 to 18 are for practical sessions. Keep them short enough for teams to attend and specific enough to affect daily work. Each session should include a brief explanation, a live or simulated workflow, and a review exercise.

A session for sales staff could compare a safe customer-email draft with an unsafe prompt containing confidential account details. A session for HR could examine a candidate summary and ask participants to identify unsupported inferences or unfair criteria. A session for developers could show how a coding assistant handles a repository containing secrets. A session for finance could use a fictional document and focus on data classification, calculation checks, and approval records.

Ask participants to explain why an output is acceptable, not only whether they like it. Useful review questions include:

• What source supports this statement?
• Which parts require confirmation?
• What information did the tool receive?
• Could the output disadvantage a person or group?
• Who is accountable for the final decision?
• What should happen if the system produces a confident but incorrect answer?

Record attendance, the role group, the topics covered, and any questions that require follow-up. Do not record real confidential data in training examples unless the organisation has a documented reason and suitable controls. Synthetic or redacted examples are usually enough for early exercises.

How can scenario drills test whether training worked?

Days 19 to 24 should test behaviour under pressure. Scenario drills are more useful than a final quiz because they show whether employees can apply the rules during normal work.

Run at least four scenarios:

1. Sensitive information request: An employee wants to paste a customer document into an unapproved chatbot to save time. The participant must identify the risk, choose an approved alternative, and report the question if the policy is unclear.
2. Confidently wrong output: An AI assistant produces a polished summary with a false figure. The participant must find the error, identify the source, correct the document, and record the review.
3. Unclear automated recommendation: A system suggests rejecting an applicant or prioritising a customer case. The participant must decide whether the recommendation can be used, what human review is required, and what evidence should be retained.
4. New integration request: A team wants an AI assistant to access a shared drive or business application. The participant must identify the owner, permissions, data categories, logging needs, and approval steps.

Use fictional data and define the expected actions in advance. Score the exercise against observable behaviours: recognising restricted data, refusing an unsafe action, checking an output, escalating uncertainty, and documenting the decision.

The security portion deserves particular attention. AI projects often involve internal documents, customer records, source code, or credentials. A practical review should cover access boundaries, retention, vendor terms, authentication, logging, and the consequences of a compromised account. See How to protect internal data in an AI project for a focused checklist.

What should go into the evidence file?

Days 25 to 30 should turn the programme into a repeatable operating process. Create one evidence file with a clear owner and a simple folder structure. It can contain:

• The AI usage inventory and its review date.
• The approved, restricted, and paused use-case lists.
• The role-based training plan and attendance records.
• The rule sheet and version history.
• Training materials and scenario exercises.
• Drill results, common errors, and corrective actions.
• Questions raised by employees and the answers provided.
• Escalation records for incidents or unclear use cases.
• The names of system and process owners.
• The next review date and planned refresher topics.

The file should show how the organisation identified relevant staff, matched learning to actual work, and responded to issues. Avoid collecting more personal information than necessary. Access to the file should follow the sensitivity of its contents.

At the end of day 30, hold a review with business, security, legal or compliance, and people representatives. Decide which use cases can continue, which require controls, and which should stop. Assign owners and deadlines for open actions. Publish a short update that tells employees what changed and where to ask questions.

How do you keep the programme current after 30 days?

AI literacy is an ongoing operating practice. Review the inventory when a new tool is purchased, a major feature changes, a workflow expands, or an incident occurs. Include a short AI safety section in onboarding and provide refreshers when teams adopt new systems.

Track practical signals rather than vanity metrics. Useful measures include the percentage of identified use cases with an owner, attendance by role group, completion of scenario drills, unresolved policy questions, reported near misses, and the time taken to review a new use case. These measures help leaders see where the programme needs attention without pretending that a single test proves competence.

Ask employees which rules are difficult to follow. If staff repeatedly ask whether a tool may process a certain type of data, the policy may need a clearer decision tree. If teams bypass an approved workflow because it is too slow, improve the workflow or explain the trade-off. Training should reflect how work is actually done.

Frequently asked questions about workplace AI literacy

Does every employee need the same AI training?

No. Everyone needs basic rules for approved tools, sensitive data, output review, and escalation. Employees who manage higher-impact workflows need deeper training tied to their systems and decisions.

Is an AI literacy programme the same as an AI policy?

No. A policy states requirements. An AI literacy programme helps people understand and apply those requirements in real work. The two should be maintained together.

How often should employees repeat the training?

Set a baseline programme and review it whenever tools, workflows, risks, or applicable requirements change. Include refreshers in onboarding and after significant incidents or policy updates.

What if employees are already using unapproved AI tools?

Add those uses to the inventory, assess the data and workflow risks, and provide a safe approved route where possible. Clear reporting channels are more useful than assuming unofficial use does not exist.

Is this article legal advice?

No. It is a practical implementation plan. The AI Act obligations and the organisation's wider legal duties should be assessed with qualified advisers who understand the relevant systems, data, and jurisdictions.

Sources

• European Commission: AI literacy questions and answers
• European Commission: Commission starts enforcing AI Act rules and new transparency requirements on 2 August