AI Literacy under Art. 4 AI Act: Roles, Records

Article 4 of the AI Act requires AI literacy from providers and deployers. Four roles around a website assistant, and the records that evidence them.

In plain language

The European law on AI asks something of firms that use AI. They must build up their staff's knowledge of AI. This usually applies to you too if you use a ready-made assistant on your website. So the duty does not only fall on the maker. The law does not demand a set level of knowledge from each single person. In daily work, this knowledge shows in four places: keeping the knowledge base up to date, reading refusals, taking over handovers and approving changes. Keep records of what you do for it.

September 3, 2026 13 min read By XICBOT

What Article 4 requires - and what it does not

Article 4 sits in Chapter I of the AI Act, the chapter of general provisions. That is not a footnote but the reason for its early date: under Article 113, point a, Chapters I and II have applied since 2 February 2025. While the obligations for high-risk systems still lie years ahead, the literacy duty has been applicable for some time - and it applies regardless of the risk class the deployed system falls into. A chat window on a tradesperson's website is not a high-risk system, yet the duty under Article 4 still bites.

In substance the provision requires providers and deployers to take measures fostering the development of AI literacy among their staff and among other persons dealing with the operation and use of AI systems on their behalf. Their technical knowledge, experience, education and training, the context in which the system is used and the persons or groups of persons it is used on must all be taken into account. The yardstick is therefore explicitly a moving one: a two-person business owes something different from an insurer with its own legal department.

This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.

Regulation (EU) 2024/1689, Article 4(1), as amended by Regulation (EU) 2026/1744

Provider or deployer: which role is yours

The duty attaches to a role, and the role is set out in the definitions. Under Article 3(3), a provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge. Under Article 3(4), a deployer uses an AI system under its own authority - excluding purely personal, non-professional use. A company running an assistant on its website therefore falls under the second definition, even if it never wrote a line of code.

Role	Who that is	What follows for the chat
Provider (Article 3(3))	Develops the system or has it developed and places it on the market under its own name	Trains its own people and hands the deployer material they can actually read
Deployer (Article 3(4))	Uses the system under its own authority, outside purely private use	Makes sure the people operating it know what the system can do and where it stops
Affected person	Types into the chat window and talks to the assistant	Must be able to tell that a machine is answering (Article 50)
Both roles at once	Anyone who adapts an assistant and passes it on under their own name	Carries both sets of duties; the dividing line belongs in writing

The distinction is not a play on words. A provider who leaves its customers with unreadable instructions makes their own duty harder. A deployer who never opens those instructions fails theirs. In practice it is enough to record in writing at the outset who holds which role and which documents come from whom. That single paragraph in the project folder saves a long discussion later - and it is the first piece of evidence you can show. What such a dividing line looks like in a contract is covered in the article on data processing agreements. At XICBOT these instructions take the form of the documentation: knowledge base, tool approvals, embedding and analytics, section by section.

What AI literacy means in the Regulation

The term is not left to intuition; it is defined in Article 3(56). And the definition is remarkably practical: it speaks of skills, knowledge and understanding, not of degrees or hours. What is meant is the ability to deploy a system in an informed way and to be aware of its opportunities, risks and possible harms. So anyone who can say what the assistant in their own company is responsible for, where its knowledge base ends and what to do when an answer is wrong already meets the core of the definition.

skills, knowledge and understanding that allow providers, deployers and affected persons, taking into account their respective rights and obligations in the context of this Regulation, to make an informed deployment of AI systems, as well as to gain awareness about the opportunities and risks of AI and possible harm it can cause

Regulation (EU) 2024/1689, Article 3(56), definition of “AI literacy”

Three things stand out in this definition. First, it names affected persons in the same breath as providers and deployers - literacy is not a purely internal matter. Second, it demands awareness of harm, not only of features; knowing the user interface alone does not make someone literate by this yardstick. Third, it ties understanding to the respective rights and obligations. For a website assistant that means, concretely, that whoever operates it should also know that users must be able to tell they are writing to a machine - the disclosure duty in Article 50 is part of the required knowledge.

Literacy is a responsibility, not a piece of paper

Do not ask who attended a course; ask who reads the weekend's refusals on Monday morning. If that question has no name attached to it, literacy is missing exactly where it takes effect.

The four roles around the assistant

A website assistant does not need a department. It needs four named responsibilities, which in a small company may well sit with the same person - as long as that person is named. The four below cover the life cycle, from the source of an answer to the release of a change. Filling them means Article 4 is substantially implemented without having bought a single training format.

Curating the knowledge base

Keeps prices, opening hours, services and exclusions current, resolves contradictions between two sources and dates every revision. This person is the first to notice when an answer rests on an outdated document.
Reading the refusals

Goes through the conversations in which the assistant gave no answer. Every refusal is a question the company has not yet answered in writing - and therefore the cheapest source of improvement.
Receiving handovers

Takes over the conversations the assistant hands off, reads the transcript rather than asking again, and reports back what triggered the handover. Without that feedback the same case recurs the following week.
Approving changes

Decides what the assistant may say in future and what it may not, signs off test cases before go-live and records who changed what and when. This role carries the responsibility outwards.

What is missing from this list is notable: model knowledge. Nobody in the company has to be able to explain how a language model computes. Article 3(56) requires informed deployment and awareness of risk, not technical depth. The four roles are therefore deliberately tied to work that happens anyway - they merely give it a name and a place where it is recorded.

Who curates the knowledge base

An assistant answers from what it has been given. The knowledge base is therefore where subject-matter competence and legal duty meet: whoever curates it decides the content of every answer. The role needs no technical skill, but it does need knowledge of the business - and a willingness to resolve contradictions rather than leave both versions in place. Two documents giving different figures for the same service are the most common cause of answers that sound plausible and are nonetheless wrong.

Every source carries a date and a name, so it stays visible who stands behind it.
Prices, deadlines and exclusions live in exactly one place; every other document points there.
Contradictions are resolved rather than filed side by side - otherwise chance decides which version answers.
Topics without a source are explicitly marked as unanswerable, so the assistant declines instead of guessing.
After every price or service change, the knowledge base is reviewed before the website is.
One fixed slot a month is enough in a small company; that it happens and is noted matters more than how often.

Reading the refusals rather than skipping them

A well-configured assistant declines when it lacks a basis. That is the desired behaviour and at the same time a signal that is lost when nobody owns it. Every refusal says two things: a person had a question, and the company has no dependable answer to it on file. Why declining is the safer route than guessing is covered in detail in declining instead of guessing.

For Article 4 this role is valuable precisely because it makes literacy visible. Whoever reviews a week of refusals learns more about the limits of their own system in twenty minutes than in half a day of training. They see which questions recur, which phrasings throw the assistant off and where the knowledge base is thin. Conversation analytics groups these cases so they do not have to be hunted down one by one.

Recurring question without a source - the answer belongs in the knowledge base, not in a one-off email.
Question outside the remit - the refusal is correct; the only check is whether the referral to a human is clean.
Question with a legal edge - complaints, contracts and health matters belong in a handover as a rule.
Question the assistant misreads - usually a synonym or an example phrasing is missing, not a document.
Attempt to push the assistant into a commitment - such conversations deserve a separate note and a look.

Spotting a wrong answer

The hardest of the four abilities is recognising a wrong answer as wrong. Wrong answers from a language model are rarely obvious; they are phrased like correct ones. That is exactly what the definition in Article 3(56) targets with its awareness of possible harm. Someone who knows which signs justify a doubt checks in the right place - and someone who does not skims past the error with the same goodwill as the customer.

Suspicion	How it shows	What to do then
Answer without a source	The assistant states a figure or deadline without pointing to a document	Look for the statement in the knowledge base; if it is not there, it belongs there or nowhere
Suspiciously smooth reply	An unusual question gets a frictionless, generic answer	Follow up with a question only real knowledge can answer
Outdated detail	The answer matches an earlier version of a price, service or opening hour	Check the source date and remove the old version rather than adding to it
Commitment on the company's behalf	The assistant promises a date, a discount or an outcome	Preserve the conversation, tighten the boundary in the system instruction, add a test case

Evidence: records and logs

Article 4 prescribes no form of evidence. That is both an advantage and a trap: there is no mandated template, but equally no excuse when nothing at all exists. The GDPR sets the right posture for a related case: under Article 5(2) the controller must be able to demonstrate compliance with the principles - accountability. Applying that logic to Article 4 means collecting from the outset what a supervisory authority or a court will want to see anyway.

Role list: who curates the knowledge base, who reads refusals, who receives handovers, who approves changes - with dates and deputies.
Briefing sheet: one page explaining what the assistant does, where its knowledge comes from and where its limit lies.
Attendance note: who was briefed and when, signed or evidenced by a calendar entry.
Upkeep log: every pass through the knowledge base with date, person and change.
Release note: which test cases were signed off before a go-live, and by whom.
Incident note: every wrong answer found, with date, cause and the correction that followed.

None of these records is laborious. Together they produce something an assurance in a meeting never does: a trail over time. It shows not merely that something was done once, but that it is being continued - which is exactly what the amended wording, speaking of fostering a development, is after. How sign-off before go-live works in practice is covered in the article on test cases and acceptance.

A folder with six files is enough

Role list, briefing sheet, attendance note, upkeep log, release notes, incident notes. Keep those and every question about AI literacy in your company is answered with a document instead of a recollection.

What Article 4 is not

Article 4 requires no examination, no course and no attestation from any body. It names neither a number of hours nor a format nor a cycle. Anyone offered an official confirmation of AI literacy should check the text of the Regulation: no basis for that is in there. What the provision asks for is proportionate fostering, adjusted to prior knowledge and deployment context - and therefore something a company may shape itself.

The fines are worth a close look too. Article 99(4) lists the infringements that can attract up to 15 million euro or three per cent of worldwide annual turnover, naming among others the provider obligations in Article 16, the deployer obligations in Article 26 and the transparency obligations in Article 50. Article 4 does not appear in that list. It does not follow that the provision is without consequence: it remains applicable law, market surveillance can request records, and in a dispute about a wrong statement the question of how staff were briefed comes up quickly.

Finally, Article 4 must be distinguished from human oversight of high-risk systems. For those, Article 26(2) requires oversight to be assigned to natural persons who have the necessary competence, training and authority and who receive the necessary support. That is a narrower and sharper duty - it does not reach an ordinary website assistant. Anyone deploying an assistant in candidate selection or credit decisions, however, should have the classification clarified professionally before relying on Article 4 alone.

A practical plan for a small company

The following sequence can be worked through in a morning and kept up in a few minutes a month afterwards. It is deliberately lean: a procedure nobody sustains produces a gap in the evidence after three months and is then worse than none. It does not replace a case-by-case review by a lawyer, but it covers the points usually asked about.

Settle the role: are you a deployer, a provider or both? One dated sentence in the project folder is enough.
Fill the four responsibilities with names, add deputies, file it in one place.
Write a briefing sheet: what does the assistant do, where does its knowledge come from, where does it stop, who is to be asked?
Hold the briefing and have the attendance note signed - even with two people.
Set a fixed slot for reviewing the knowledge base and the refusals, and log it.
Record test cases for the sensitive topics and run them again before every change.
Once a year, check the role list and briefing sheet against the actual situation and re-date them.

Going this route achieves something beyond the provision itself: the assistant turns from a tool running somewhere into a part of the business with an owner. That lowers the number of wrong answers because somebody sees them, and it makes the handover to a human more dependable because somebody receives it. How that handover is designed is described in the article on handover to human agents. Which building blocks an assistant brings for this, from source binding to handover to people, is summarised on the features page.

Frequent questions

Does Article 4 apply to a small company with a simple website chat?

Yes. Article 4 draws no distinction by company size or by the risk class of the system. It does, however, expressly require technical knowledge, experience, education and the deployment context to be taken into account. A three-person business therefore meets the duty with a readable briefing sheet, named responsibilities and a short note of who was briefed and when.

Do we need a course with a certificate of attendance?

The Regulation prescribes neither a format nor a certificate. Article 4 speaks of measures fostering AI literacy, not of a course. An internal briefing with a written document and an attendance note meets the provision just as well, provided it fits the deployment context and is repeated when something substantial changes about the assistant.

Since when has the duty applied, and what changed in 2026?

Article 4 sits in Chapter I of the AI Act and, under Article 113, point a, has applied since 2 February 2025. Regulation (EU) 2026/1744, in force since 27 July 2026, softened the wording: instead of ensuring a sufficient level of literacy to one's best extent, the development of that literacy must now be fostered, and it is clarified that no specific level is owed in any single individual. The duty itself remains.

Are we a provider or a deployer when the assistant comes from a service company?

Anyone using an AI system under their own authority, and not purely privately, is a deployer under Article 3(4). That covers the usual case of a company running a finished assistant on its website. A provider under Article 3(3) develops the system or has it developed and places it on the market under its own name or trademark. Anyone passing a bought-in assistant on under their own name may end up in both roles.

What fine applies to an infringement of Article 4?

Article 99(4) of the AI Act lists the infringements punishable by up to 15 million euro or three per cent of worldwide annual turnover, naming among others Article 16, Article 26 and Article 50. Article 4 is not in that list. The provision nonetheless remains applicable law, market surveillance can request records, and a missing briefing tells in a dispute about a wrong statement.

How do we evidence AI literacy while nobody is asking?

That is precisely when the evidence is cheap to produce. Six records are usually enough: role list, briefing sheet, attendance note, knowledge-base upkeep log, release notes before changes, and notes on wrong answers found. Each carries a date and a name. Together they form a trail over time that a later reconstruction never matches.

Ask it yourself, Assistant of this website

Automated assistant

Settings