If your team uses artificial intelligence systems, it is not enough to give them access and hope each person learns on their own. The European AI Act provides for AI literacy measures for those who develop or use these systems on behalf of an organisation. Training must fit the context, the risks and the real work; it does not mean buying a generic certificate.
What exactly is AI literacy in a company?
In this context, literacy means having the knowledge and judgement to use AI systems aware of their possibilities and risks. It does not require a shop manager to become a model engineer. It does mean understanding what the tool can do, when it can fail and which actions need review.
The European Commission explains Article 4 of the AI Act. The obligation concerns providers and deployers of systems, and must be assessed taking into account knowledge, experience and context of use. Its FAQ also covers the changes introduced in 2026; check the updated text before turning recommendations into formal requirements.
The situation of someone using an assistant to summarise meetings is not the same as that of someone reviewing applications with health or employment data. It is not about giving everyone the same talk, but about identifying decisions and risks by role.
For example, in a small firm, staff may need guidelines on not entering personal data into unauthorised tools, checking legal claims against current sources and recognising invented answers. In a shop, it may matter more to check stock, price or returns information before replying to customers.
Useful training leaves an observable ability: identify an authorised task, apply a safe procedure, spot a doubtful answer and know who to turn to. If it only delivers a nice presentation, it may not change the work.
Which companies does it affect, and from when should you act?
The European AI Act is Regulation (EU) 2024/1689. The Commission states that Article 4 started to apply on 2 February 2025 and that the supervision and enforcement regime began to apply in August 2026, with later regulatory changes that must be read against the text in force. It is not wise to present a single course as a universal requirement, because the rule asks for measures suited to the use.
A microbusiness that uses AI tools for administrative tasks also needs to think about who uses them and how. Proportionality matters: an organisation with a simple application and non-sensitive data does not have the same risk profile as one that automates decisions affecting people.
Before approving a plan, take a real inventory of tools and uses: general assistants, marketing tools, meeting transcription, document screening and agents connected to internal software. Include tools used informally, not only those that appear on a company invoice.
Tell apart being a provider of a system from deploying it for your own use. Obligations differ by role and risk, and data protection, employment, consumer or sector-specific rules may also apply. A checklist written for a software company cannot be applied unchanged to a physiotherapy centre.
This article offers general information, not legal or professional advice. For specific compliance decisions, review the text in force and seek specialist advice when needed.
What should the team learn to work with AI tools?
Start with four practical skills. The first is recognising which tasks are authorised: drafting a text may be allowed, while uploading complete case files to a public tool may not be. The second is understanding errors: a well-written answer can contain a wrong date, quote or rule.
The third skill is protecting information. Explain what personal data, confidential documents, trade secrets and credentials are. Set approved tools, permissions and guidelines for anonymising where appropriate. Deleting a name does not always anonymise a document if combinations of data that identify a person remain.
The fourth is supervising results. Teach people to check sources, handle uncertainty and decide when a person must step in. If an agent answers about commercial terms, check the current catalogue. If it summarises employment documents, a different caution is required because errors have a bigger impact.
Adapt the examples to specific roles. For customer service, use ambiguous messages, complaints and requests outside policy. For marketing, assess image rights, advertising claims and campaign data. For administration, go over documents with tax data and customer records.
Do not forget the incident procedure: who to tell about an inappropriate output, how to withdraw a problematic automation and how to recover the manual process. Training is not just teaching people to ask a chatbot for things; it is also teaching them to stop it when needed.
How do you organise a proportionate plan without paralysing the business?
Hold a first session to identify tasks. Each manager describes the tools used, the decisions they support and the data they handle. With that information, classify what can be automated, what needs review and what requires further analysis. A simple sheet with owners is enough to begin.
Prepare a short, readable policy. It should set out authorised tools, document handling, human review and support channels. Avoid pages of prohibitions nobody reads. A protocol with real examples and clear criteria for unforeseen cases works better.
Then rehearse scenarios. Ask the team to spot a plausible but wrong answer, a request that exceeds permissions and a case with insufficient information. Collect mistakes and update procedures. A memory quiz on technical terms does not by itself show that someone can handle everyday risks.
Assign owners for updates. Products change, the company adds new flows and some instructions stop being useful. A periodic review can add new training activities; there is no need to start from scratch every time as long as the process is traceable and new needs are addressed.
Document which measures you have adopted and why they are appropriate. The regulation is not a universal recipe of certifications. Keeping records of use assessments, training and controls makes it easier to review decisions and show a serious approach, without pretending that a signature on a sheet proves full safety.
How have we approached it at meiika?
At meiika we design self-management agents and custom systems with the task, the permissions and the involvement of people in mind. In a serious project, the team must know both the intended use and the situations in which a decision should not be delegated.
Our S.A.R.A. demonstration is a bounded example of an interface: it identifies itself as an automatic assistant and audio recording is switched off in that demo. It does not prove deployments with clients or training results; it serves to explain the type of interaction, not to replace a review of the rules.
We can study which processes you want to automate and which points need instructions, human review or access limits. The aim is not for the whole company to learn to code, but for people to use technology with judgement. General information, not legal or professional advice.