EU AI Act and chat agents: twelve duties your vendor skips

It is Tuesday morning in Eindhoven. The compliance lead at a forty-person SaaS company has two tabs open. One is her chat vendor's "EU AI Act readiness" page: six green checkmarks and a logo wall. The other is the consolidated text of Regulation (EU) 2024/1689. She is counting obligations on a yellow notepad. The vendor got to six. Her notepad is at twelve and still climbing.

Most of the gap is hers to close.

The shape of the sleight of hand

Vendor compliance pages are written by marketing, reviewed by legal, signed off by sales. They are not wrong. They are partial. The pattern across the chat vendors we audit each quarter is consistent: lots of language about what the vendor takes care of, very little about what stays with the customer. The Regulation calls that customer the deployer. The deployer carries roughly half the obligations even when a separate company is the provider, and all of them when the agent is built in-house.

So here is the field guide. Twelve obligations that touch a customer-facing chat agent at a sub-fifty-person Dutch company in June 2026, ranked by how often the vendor compliance page lets them quietly fall through. Article numbers refer to the consolidated AI Act text on EUR-Lex. For dates and scope, the independent AI Act explorer stays current.

Twelve obligations, in order of vendor evasion

1. AI literacy for your staff (Art. 4). In force since 2 February 2025. The vendor cannot do this for you. Anyone who writes prompts, reviews transcripts, designs escalation, or signs off on launches needs documented training proportionate to their role and the risk of the system. Vendor pages mention "AI literacy resources available" and stop. The duty sits with the deployer, every time.

2. Disclosure that the user is talking to an AI (Art. 50(1)). Applies from 2 August 2026, eight weeks out at time of writing. The disclosure must be clear at the start of the interaction, not buried in a footer. A fading "AI Assistant" badge that disappears on scroll fails the test. What passes: a sticky header label, a persistent avatar, and a confirming sentence in the bot's first turn.

3. Synthetic content labelling (Art. 50(2)). When the agent generates text, images, audio, or video that could pass as human-made, the output must be marked in a machine-readable way (provenance metadata, watermark, or equivalent). Few chat vendors watermark output text. C2PA-style provenance on generated images is your responsibility the moment the output leaves the vendor's UI and lands in an email or a PDF.

4. Logging and traceability (Art. 12, with Art. 19 for high-risk systems). Default vendor retention is thirty to ninety days. High-risk systems require logs for at least six months. Even outside high-risk, you want logs long enough to honour a GDPR data-subject request, a regulator question, or a customer dispute. Check the retention setting. Check the export path. Check who else can subpoena it.

5. Human oversight (Art. 14). Vendors list "human handover available". The Regulation requires the human to be competent, instructed, and able to interrupt or override the system, not just receive a transcript afterwards. That means a named rota, a written runbook, a measurable response time, and the authority to roll the agent back. Not a Slack channel that nobody watches on Friday afternoon.

6. GPAI provider documentation (Art. 53). In force since 2 August 2025. Providers of general-purpose models owe deployers a technical summary, a training-data summary, and copyright-policy disclosure. Many wrapper vendors refuse to name the base model behind their chat agent, treating it as a trade secret. Without the model card you cannot complete your own risk file. Push for it in writing before signing.

7. Prohibited manipulation (Art. 5(1)(a) and (b)). In force since February 2025. Dark-pattern upsells, manufactured urgency, exploitation of cognitive vulnerability. Vendor pages tick this with a single sentence. The risk lives in your prompts and conversion goals, not in the vendor's defaults. A system prompt that says "if the user hesitates, emphasise that the offer ends tonight" is a compliance problem authored by you, not by the model.

8. Provider-by-modification rule (Art. 25). If you substantially modify the agent or place it on the market under your own name, you become a provider and inherit the provider's full obligation set. Reselling, white-labelling, or embedding in your own SaaS often crosses this line. Vendor pages bury it because it changes the answer to "who is on the hook?" in a way they would rather you not notice until renewal.

9. Fundamental rights impact assessment (Art. 27). Applies to public bodies, and to private deployers of high-risk systems that provide public services (think healthcare, education, banking essentials, energy). It skips most B2B SaaS. The moment your chat agent triages medical questions, grades coursework, or screens a loan application, the vendor's silence on Art. 27 becomes your gap to fill.

10. Serious incident reporting (Art. 73). For high-risk systems the deployer reports serious incidents to the national market surveillance authority within fifteen days. In the Netherlands the coordinating body is the Rijksinspectie Digitale Infrastructuur (RDI), with the Autoriteit Persoonsgegevens for biometric and certain other carve-outs. Vendor pages list "security incident notification". They rarely list the regulatory reporting path.

11. Sub-processor and data-provenance disclosure. Sits in the joint reading of AI Act Art. 53(1)(d) and GDPR Art. 28. You need the full chain (vendor, infrastructure provider, model provider, evaluator, fine-tuning party) in writing. Most vendor pages link to the upstream provider's own policy and call it a day. That is a redirect, not a flow-down.

12. GDPR Art. 22 overlap. Not AI Act, technically, but inseparable in practice. A chat agent that decides a refund, modifies a contract, approves credit, or closes an account triggers the customer's right not to be subject to solely automated decision-making, and the right to a meaningful explanation. Vendor pages mark this "out of scope". It is in your scope, and it is the most common complaint route a regulator will reach you through.

What vendors usually do cover

For balance: vendor compliance pages tend to be solid on three things. The Art. 5 prohibited-practices list copied near-verbatim. Data residency for hosted models, usually in Frankfurt or Dublin. SOC 2 or ISO 27001 evidence. These are necessary and you should not skip them. They are also the easiest items to lift from a template, which is why they show up first. Treat them as the table stakes they are, not as the field guide.

What changes on 2 August 2026

Two months from this post, the Art. 50 transparency duties switch on, alongside the bulk of the high-risk regime described in Annex III. Most customer-facing chat agents are not Annex III high-risk on their own (the Annex is narrowly drawn around employment, education, essential services, biometrics, law enforcement, and migration). But the Art. 50 disclosure and content-labelling duties apply broadly to any AI system that interacts with a person or generates content, and the supervisory machinery (notified bodies, the AI Office, national authorities) will be live across the Union. The window for "we will get to it after summer" closes on the first working day of August.

A five-step Monday-morning audit

You do not need a consultant to start. You need an hour, the vendor page, the Regulation, and a willingness to write the gap down.

1. Open the vendor's compliance page. Print it, or paste it into a document.
2. Number each commitment. Most pages have between four and eight.
3. Put the twelve obligations above in the left column of a sheet. Put the vendor commitments in the right column. Draw the lines between them.
4. Mark each row: covered by vendor, shared, or yours alone. The third bucket is usually where the work is.
5. For every yours alone row, assign an owner and a date. Even "we will decide by 30 June" counts as progress.

By Friday you will have a defensible answer to the question every regulator and large-customer procurement team is about to start asking: who is responsible for which obligation under the AI Act, and where is the evidence?

Why the gap exists

It is not malice. Most vendors are early-stage themselves, navigating the same Regulation, and their compliance pages reflect what they can credibly promise on their own. The split-responsibility logic of the Act (provider, deployer, importer, distributor, plus the provider-by-modification rule) is genuinely complicated, and a marketing surface is the wrong place to render it. The right surface is your own internal register, written in the language of your own use case, updated every time the agent's prompt set or model changes.

The other reason: until early 2026 there was no real enforcement momentum at national level. The RDI was still hiring. The AI Office was still publishing guidance drafts. The vendors were not pressed. They are now, and procurement teams at larger customers are the ones doing the pressing, because they need the flow-down to satisfy their obligations.

When we built a customer-support chat agent for a Dutch fintech last quarter, the obligation that nearly delayed go-live was item 6 on the list above. The upstream vendor would not name the base model, which left a hole in our Art. 53 file. We solved it by adding a self-hosted fallback with a documented model card, so the deployer's risk register was complete regardless of which path served the request. The hardest part of that project was not engineering. It was getting the contract language to flow down. If you are building or buying AI agents in this regulatory window, expect the legal-vendor loop to be the long pole.

Print the twelve. Highlight the ones your vendor page does not name. That is your week.