Preparing a company for the EU AI Act, technically

Three terms run through the whole text. A provider is a company that places a system on the market under its own name or brand. A deployer is a company that uses a system in its own operations. The same company is often both - for different systems.

A third term is the high-risk system. It is, among other things, a system that acts as a safety component of a regulated product, or one used in an area listed in Annex III to the AI Act, such as recruiting staff and assessing candidates, decisions on access to essential services, or certain biometric uses. What decides is the intended purpose of the system and the way it is used, not the model it runs on.

One example runs through the article: a small service business offers a chatbot on its website to answer customer questions about its services and lead times. The chatbot runs on a ready-made tool bought on subscription. At each step we show what the example means in practice. A chatbot like this is, as a rule, not a high-risk system. That could change if a similar system were used to assess job candidates.

The EU AI Act places obligations on systems, but checking whether a company meets them takes material: a description of the system, a trace of its decisions and a statement of who is accountable for them. A lawyer cannot prepare it alone, because they do not know how the system behaves in practice. An auditor cannot reconstruct logs that were never switched on.

In the example company, that material is a handful of plain facts: which tool the chatbot runs on, what customer data passes through it, at which point a conversation is handed to a person, and whether transcripts are kept for longer than a few days. It is the company that has to gather and write those facts down - nobody else can do it for them.

That is why the technical work makes sense whatever the classification turns out to be. If the system falls outside the high-risk requirements, the company still gains a list of its AI tools, clear decision boundaries and a record from which it can explain why the model answered as it did. If it falls inside them, the same work shortens the road to compliance instead of starting it from zero.

The roles matter here in practice, because the transparency obligations in Article 50 are split between roles and types of system. The provider of a system meant to interact directly with people designs it so the user knows they are talking to an AI - unless that is obvious. The provider of a system that generates synthetic content - text, images, audio or video - has a separate duty: to mark that content in a machine-readable format. The deployer discloses deepfakes and labels AI-generated text published to inform the public on matters of public interest. Only two conditions together lift that last duty: the text went through human review or editorial control, and a person or company holds editorial responsibility for the publication. A spell-check or a quick read-through is not enough.

The company in our example buys its chatbot on subscription, so the notice about talking to an AI belongs to the vendor. What stays on the company's side is checking that the tool actually shows it, and not switching that notice off - quite apart from the fact that a chatbot like this is, as a rule, not a high-risk system.

The deferral of the remaining duties is not a reason to wait. Documentation, logs and a description of oversight take months to produce, and the material for them only accumulates while the system is recording it. A company that switches event logging on only when asked will not reconstruct a decision made a year earlier.

The four items below are the requirements for high-risk systems and, in practice, set out what a person assessing the system looks for. The common thread is simple: what the team holds in its head has to end up somewhere it can be read a year later, by someone who was not there at rollout.

The main responsibility for meeting them sits with the provider - whoever builds the system and places it on the market under their own brand. A company that bought a ready-made high-risk system is a deployer, with narrower duties set out in Article 26: among other things, it must use the system according to the instructions, provide the required oversight and keep the logs available to it. On the Polish market that distinction decides how much work there is - the national statistics office puts AI use at 8.7% of companies in 2025, most often through buying a ready commercial product rather than building one.

A company using a ready-made tool therefore does not write all of this documentation itself - it should obtain the relevant information from the vendor and settle the vendor's duties in the contract. The most common mistake is treating the four items as separate documents. In a running system they are linked: the log shows what data the model acted on, the description of oversight says who approved the result, and the documentation explains why the system makes that kind of decision at all. When one link is missing, the others lose their value as evidence.

The order matters. The inventory comes first, because you cannot describe or limit a system you do not know about. Decision boundaries come second, because only then is it clear what to log. Logs and documentation come third, because without boundaries they record everything or nothing. The review closes the loop, because a description that never changes stops matching a system that does.

There is no need to launch a separate, elaborate project - which is just as well, because few companies have the resources for one: in the EFL AI Barometer for the first half of 2026, only 7% of Polish SMEs rated their readiness for AI deployments as high, and 43% rated their own competence as low. In the example company the whole set is one table, one conversation about when the chatbot should hand the customer over to a person, and one setting in the vendor's panel. Trying to describe every possible scenario up front usually ends in a document nobody updates.

The four actions are: an inventory of the AI tools in use, setting decision boundaries, turning on logs along with the system documentation, and booking a periodic review. Each one is below, in that order.

The EU AI Act timetable has already been changed once since the regulation came into force, and it may change again. Before a decision that turns on a date, check the current text at the source rather than in an article - this one included.