An employee can follow every line of an AI policy and still put a made-up statistic into a sales deck. The tool was approved, and the draft was reviewed. The problem? Nobody had defined what “ready to use AI” meant for that job.
A policy can tell employees which tools they may use and what information must stay out of a prompt. The real test comes when the output looks convincing. At that point, someone has to know what to verify—and when to bring in another pair of eyes.
The timing matters. Supervision and enforcement tied to the EU AI Act’s AI-literacy rules began in early August 2026. For small businesses, the practical question is simple: Who can use which AI tools without supervision, and when should someone else step in?
Build Your Business. Get Grant Ready.
Take free expert-led courses and unlock access to tools, mentorship, networking, and Verizon grant opportunities for small businesses.
We earn a commission if you make a purchase, at no additional cost to you.
Take free expert-led courses and unlock access to tools, mentorship, networking, and Verizon grant opportunities for small businesses.
What AI readiness actually means
Permission is the simplest part of AI use. An employee either has access to a tool or doesn’t. Readiness goes further.
A person who’s ready for a particular AI task understands what the tool is supposed to do and where it tends to fail. They know what information can go into it, how closely its output needs to be checked, and who makes the final call. They also know when the task has moved beyond their authority.
Consider a marketer who uses AI to draft a social post. That calls for brand judgment, source checking, and a final human edit. Generating customer segments or writing a product-performance claim involves different data and consequences. Approval for the first task doesn’t prove readiness for the others.
The same distinction applies across a small company. A developer may understand how a model works and still miss licensing or security concerns in generated code. An HR manager may follow the acceptable-use policy carefully yet struggle to catch bias or a made-up citation. Technical confidence isn’t the same as sound workplace judgment.
The text of Article 4 of the EU AI Act reflects this context. It tells providers and deployers to consider people’s technical knowledge, experience, education, training, the setting in which an AI system is used, and the people affected by that use. The amended rule doesn’t require a company to guarantee a particular level of AI literacy for every employee, so the readiness map is a practical management tool rather than a prescribed compliance format.
Why a policy and one training session fall short
Policies answer questions such as “May I use this?” and “What information is off limits?” They rarely answer “Can I handle this task without supervision?”
Training records have a similar limit. A completion box shows that somebody attended a session or finished a module. It doesn’t show what they’ll do when an AI assistant invents a case citation, exposes confidential code, or produces a polished answer that’s wrong.
Generic awareness training still has a place. Everyone should understand the company’s basic rules and the common weaknesses of the tools they use. Role-specific work needs another layer, though. People in marketing, support, HR, software development, and management make different decisions with different consequences.
The European Commission’s current AI-literacy guidance makes room for that difference. Article 4’s obligation entered into application on February 2, 2025. The Commission says supervision and enforcement rules apply from August 3, 2026, while national market-surveillance authorities began supervising and enforcing from August 2. The guidance also says organizations can use different levels and learning approaches based on the people, systems, and context involved.
Build a role-to-use-case readiness map
Start with work people already do. Don’t begin by trying to list every possible “AI skill.”
For each use case, record:
- the role and the specific use case
- the approved tool
- the data that may and may not be entered
- the expected output and its likely failure modes
- the level of human review
- the knowledge or behavior the employee needs
- the evidence you currently have of that readiness
- the owner and the trigger for reassessment
Don’t try to score the entire company on a vague concept like “AI skills.” Pick one task where AI is already being used and ask a narrower question: What would convince you to let someone do this without review?
Write that standard down, then record who has met it. A competency matrix for AI-assisted work gives you somewhere to keep those decisions, so the next assignment doesn’t depend on a manager’s memory or best guess.
Keep the first version small. A marketing row might cover draft copy, source checks, and approval for claims. A support row could address customer data and escalation. HR may focus on sensitive information, bias, and human responsibility for employment decisions. Developers may need code testing, security checks, and licensing requirements.
This exercise works best when expectations for each role are already clear. StartupNation’s guide to defining success for each role offers a useful foundation. If nobody agrees on what good work looks like without AI, measuring readiness to use AI will get messy fast.
Decide how much oversight each task needs
People won’t all be ready to use AI in the same way, and they don’t need to be. The level of oversight should match the risk of the task.
Someone new to a tool may only need to understand the rules and recognize the main risks. Once they begin using it, keep a reviewer involved until they’ve shown they can catch bad output and follow the right escalation path.
The consequences of the task should drive the level. So should data sensitivity, the amount of autonomy the tool receives, and the people affected by the output.
A support rep might use AI to draft a routine reply independently, for example, while a refund decision or a message to a vulnerable customer still needs review. A developer may use a coding assistant but remain responsible for testing the code and following security controls. A manager can ask AI to summarize meeting notes, yet decisions about an employee’s performance stay with the manager.
Training should follow the same logic. Short guidance, a checklist, a live scenario, peer review, or a supervised trial may teach more than another general presentation. When a gap is broader, targeted upskilling can connect the missing capability to the employee’s actual work.
Test judgment, not memory
The most useful readiness check puts a realistic problem in front of the employee. You don’t need a long exam.
Give a marketer an AI-generated paragraph containing a market statistic with no traceable primary source.
Give a support rep a draft that includes private account details in a prompt. Ask what went wrong before discussing tone. Give a developer AI-generated code that appears to work, and ask which checks must happen before it can be used.
The point is to observe judgment in context. A short supervised pilot, a sample-output critique, or a few scenario questions can reveal whether somebody can apply the rules when the answer isn’t printed in the policy.
Keep the record proportionate. You may only need the scenario used, the result, any follow-up training, and who approved independent use. Don’t collect extra employee data simply because a matrix has empty columns to fill.
NIST’s voluntary AI Risk Management Framework supports this practical split between policy and responsibility. Its Govern function calls for clear AI-risk roles and lines of communication, training that lets people perform their assigned duties, and defined responsibilities for human oversight. It isn’t a law or a ready-made checklist. It is a useful reminder that accountability needs names attached to it.
Assign an owner and revisit the map
AI readiness has a short shelf life. Tools change, models are updated, roles expand, and a harmless-looking workflow starts handling data it never touched before.
Name an owner for each part of the process. Someone should approve tools, someone should maintain the expectations for each role, and someone should update training after an incident. In a very small company, one person may hold several of those responsibilities. That’s fine as long as the team knows who decides what.
Revisit a use case when the tool changes, a new kind of data enters the process, an employee takes on more authority, or a failure exposes a gap. A quarterly review may suit a fast-moving team, while a more stable use case may need less attention. The calendar matters less than the triggers.
Suppose a false AI-generated answer reaches a customer. Correcting the message isn’t enough. The owner should ask why it passed review, update the checklist, and decide whether the support team needs another scenario before resuming independent use.
Start with one real workflow
You don’t need to map the whole company next Monday. Choose one team and three AI-assisted tasks. Set the review level for each one, run a practical scenario, and write down the gaps you find. Two weeks is enough for a useful pilot.
Then look at what changed. Perhaps the policy was clear, but the escalation path wasn’t. Maybe people understood privacy rules yet trusted polished output too quickly. Those are fixable problems once they’re visible.
Responsible AI use becomes part of daily work when people can see what they’re allowed to do, what they’re ready to do, and when somebody else needs to step in.
Image by DC Studio on Magnific
