EU AI Act: How to Prepare for the Transparency Deadline

The EU AI Act is the European Union’s rulebook for artificial intelligence. It ranks AI systems by the risk they carry and sets duties to match, from a light duty to be open about AI up to strict controls on high-risk uses. If you run AI near a regulated process in banking or insurance, or anywhere in the public sector, some of those duties are already yours.

Those duties don’t apply to the AI system itself. They apply at the moment it reaches someone: a chatbot answering a customer, a letter your system helped draft going out under your name. That moment is a step inside one of your processes, and it’s the step where the law is complied with or violated.

So we will start where the confusion is greatest.

Most of what’s been written about the Act this summer covers the parts that got pushed back. The high-risk obligations now apply from 2027 and 2028, following the Digital Omnibus the Council adopted in June. Read that news and the whole Act can start to feel like next year’s problem.

But, Article 50 didn’t move. The duty to be open about AI still takes effect on 2 August 2026, and enforcement and penalties take effect alongside it. It’s the obligation most people have stopped watching, and it’s the first one due.

What it asks is simple: when someone deals with your AI, are they informed, and could you show a regulator exactly where and when they were told? That’s a question your processes will need to answer in a matter of weeks.

The Digital Omnibus on AI, adopted by the Council on 29 June 2026, set the new dates for high-risk obligations. Standalone high-risk systems now have until 2 December 2027. AI built into regulated products has until 2 August 2028. For the heaviest compliance work, that’s a genuine two-year window.

One date didn’t move. Article 50 takes effect on 2 August 2026, along with enforcement and penalties. Market surveillance, the checks and inspections authorities use to confirm compliance, keeps that date too.

Article 50 itself breaks into two parts that matter most for customer-facing organizations.

The first is informing people they are dealing with an AI system, unless that’s already obvious. A chatbot, a voice agent, an automated reply that reaches a customer: whoever is on the other end should be told at the first interaction and in a way they can actually notice.

The second is flagging AI-generated content so it can be detected as artificial. For systems you put on the market from 2 August 2026, this applies immediately. Generative systems already running before that date get a short transitional window, with the marking due by 2 December 2026.

The difference between the two is where many organizations often get confused. A machine-readable mark tucked into a file’s metadata can tick the marking box for one duty while doing nothing for the other, since a customer in a live chat never sees metadata. One duty is aimed at software that scans content later and the other is aimed at a person reading their screen right now. You have to satisfy both, and usually in different ways.

A policy statement saying your organisation is transparent about AI doesn’t answer what a regulator asks after a complaint. A regulator wants to see the specific step where the disclosure happened, in the channel the customer actually used. They also want to see that it appeared in the right language, at the moment the customer needed it.

A policy describes intent. A regulator wants a record tied to one specific point in your process. Building that record into the process from the start is far easier than reconstructing it after a complaint.

A chatbot conversation or a drafted letter is a point you can name. Either you can show what happened there, or you can’t.

The Act splits its duties between two roles, provider and deployer, and knowing which one applies to you determines which duty is actually yours to fulfil.

Most organizations in banking, insurance, or in the public sector, are deployers rather than providers. If you build or brand the AI system yourself, you take on the provider duties, which include designing the interaction notice and flagging the content. If you use a third-party system instead, you’re usually a deployer. That role still carries duties at the moment content reaches someone, such as disclosing deepfakes and certain published text.

A single system can put you in both roles at once. Before drafting any disclosure text, work out which role applies at each AI touchpoint.

Knowing your role tells you what to check next: whether a given touchpoint carries a duty at all. Not every one does, and overstating the duty wastes effort and creates a false sense of security.

You don’t have to label everything. If an AI only helps with routine editing, such as a grammar checker, or doesn’t meaningfully change the input or its meaning, the flagging duty falls away.

Human review changes the picture too. If a named person takes editorial responsibility for publishing AI-generated text, that flagging duty doesn’t apply either. For content which is plainly artistic or satirical, the disclosure only has to appear in a way that does not spoil the work.

There’s also a limit built around obviousness. If the AI is already obvious to your audience, you don’t owe an interaction notice. Regulators read “obvious” narrowly though, so a polished chatbot won’t clear that bar on its own.

Mapping your AI touchpoints against Article 50 is straightforward, especially if you already model your processes.

• Review your customer-facing and employee-facing processes, and tag every step where an AI shapes what a person reads or receives.
• At each of those steps, decide whether you’re the provider or the deployer, and which Article 50 duty applies, if any.
• For each duty that applies, record the notice or flagging, where it appears, who owns it, and where the evidence is stored.

That evidence is what matters most, because Article 50 has no formal conformity assessment. Nobody checks your work in advance. If a complaint arrives, the record you kept is what shows compliance. The same map also covers what the 2027 obligations will ask for, so the work carries forward instead of being redone.

Reviewing every process and tagging each touchpoint takes real effort, and it multiplies fast across an organization with many AI-facing processes. Tracking who owns the evidence behind each one adds another layer on top. ADONIS won’t make you compliant, and it won’t make you transparent. Transparency happens at the touchpoint, in front of a real person, and compliance is an outcome your whole organization is responsible for.

What ADONIS gives that review is a place to live. It models each touchpoint on the process it belongs to, records who owns each disclosure, and points to the exact step when someone asks for proof. The disclosure itself stays yours to make. ADONIS holds the map, the ownership record, and the evidence trail behind them.