EU AI Act Compliance Checklist for Customer-Support Chatbots (2026): Article 50 Transparency, Risk Tiers, and the Digital Omnibus Deadlines

Table of Contents

• What you'll achieve

• What changed since 2025

• Prerequisites

• Step 1: Build your AI system inventory

• Step 2: Classify your chatbot's risk tier

• Step 3: Decide whether you are a provider or a deployer

• Step 4: Write and place your Article 50 disclosure

• Step 5: Handle synthetic content labeling and watermarking

• Step 6: Close the AI literacy gap

• Step 7: Reconcile GDPR work with AI Act work

• Step 8: Run vendor due diligence on your chatbot platform

• Step 9: Build the evidence pack regulators actually ask for

• Step 10: Prepare for high-risk obligations before December 2027

• Common mistakes teams make

• How to measure whether the program worked

• Where to start this quarter

What you'll achieve

By the end of this guide you will have classified your customer-support chatbot against the EU AI Act's risk tiers, confirmed whether you are a provider or a deployer, drafted a compliant AI disclosure, and assembled the evidence pack that satisfies a national competent authority. The EU AI Act (Regulation (EU) 2024/1689) is a risk-tiered law: obligations scale with what an AI system does, not with how much attention it gets. A customer-support chatbot that answers questions, checks order status, and hands off to a human is a limited-risk system whose primary duty is telling users they are talking to AI.

That single sentence is where most compliance content goes wrong, including the earlier version of this page. If your chatbot also scores creditworthiness, decides eligibility for essential public or private services, or screens job candidates, it crosses into Annex III high-risk territory and the obligation set changes completely.

The work below is genuinely modest for a limited-risk bot: a disclosure, a documented classification decision, a training record, a vendor file, and a logging policy. It gets substantial only if an Annex III function is in scope.

Important: this is not legal advice. It is an operational checklist written for CX, support ops, and platform teams. Have counsel confirm your classification before you sign off.

What changed since 2025

Three things changed between mid-2025 and July 2026, and all three affect what you should be doing right now. General-purpose AI (GPAI) model obligations took effect on 2 August 2025, not 2026 as many older articles claimed (artificialintelligenceact.eu implementation timeline). The AI Digital Omnibus, a simplification package proposed by the European Commission on 19 November 2025, then moved the high-risk deadlines back substantially. The Council of the EU gave the package its final green light on 29 June 2026, after the European Parliament formally endorsed it on 16 June 2026 (Council of the European Union).

Under the Omnibus agreement reached on 6 and 7 May 2026, Annex III standalone high-risk obligations move from 2 August 2026 to 2 December 2027, and Annex I embedded high-risk systems move from 2 August 2027 to 2 August 2028 (Gibson Dunn). Crucially for anyone running a chatbot, Article 50 transparency obligations were not delayed. They apply from 2 August 2026, roughly three weeks from the date of this article.

The one narrow exception is Article 50(2) machine-readable watermarking of synthetic content, which gets a grace period to 2 December 2026 for systems already on the market (Gibson Dunn). The Omnibus also adds a new Article 5 prohibition covering AI generation of non-consensual intimate imagery and child sexual abuse material, with a transitional period to 2 December 2026.

As of 2026-07-09 the amending regulation is adopted by both co-legislators and awaits publication in the Official Journal, entering into force on the third day after publication. Cite the OJ number once it lands; the substantive dates below are settled.

Corrected EU AI Act timeline for chatbot teams

Prerequisites

Before you start, you need three things: a complete list of every AI system touching your customers, an owner with authority to change what the chatbot says on first contact, and access to your vendor's security and compliance documentation. None of this requires a specific software tier, but it does require someone who can approve a change to your widget's greeting copy without a two-month design review.

Practically, gather the following:

• Access to your chatbot's front-end configuration. Whoever can edit the greeting message, the widget header, and the voice call opening script.

• Your vendor's trust or compliance page. You will need their certification list, sub-processor register, and data residency options.

• Your existing GDPR records. Records of processing activities (Article 30 GDPR) and any Data Protection Impact Assessments already completed for the chatbot.

• A named accountable owner. One person, typically the Head of Support Operations or a Data Protection Officer, who signs the classification decision.

• A place to store evidence. A shared drive folder is enough. Regulators ask for documents, not dashboards.

If you use a third-party AI agent platform, you also need your Data Processing Agreement and, in regulated sectors, a Business Associate Agreement or equivalent. Fini provides both, and the platform ships with SOC 2 Type II, ISO 27001, HIPAA-compliant operations with BAA eligibility, GDPR, and CCPA coverage.

Step 1: Build your AI system inventory

You cannot classify what you have not catalogued. Before touching risk tiers, list every AI system that interacts with customers or handles customer data, including systems nobody formally approved. This inventory is the foundational artifact for every subsequent step and the first thing an auditor asks to see.

Adoption has moved fast enough that most inventories are already out of date. According to Digital Applied's 2026 analysis citing Salesforce State of Service from November 2025, 66% of customer service organizations are using AI agents in 2026, up from 39% in 2025 (Digital Applied). The jump means many organizations added agents faster than they added governance.

For each system, record:

Then hunt for the systems that are not on the list. Agents pasting customer emails into a consumer chatbot, a marketing team running a summarizer on transcripts, a browser extension drafting replies: these are unsanctioned AI systems processing customer data outside your governance perimeter, and our analysis of unsanctioned AI tooling in support teams covers how to find them. Treat any consumer-grade AI tool touching customer PII as an immediate GDPR issue first and an AI Act issue second.

Finish the inventory before the next step. Classification applied to an incomplete inventory produces confident, wrong answers.

Step 2: Classify your chatbot's risk tier

Most customer-support chatbots are limited-risk under the EU AI Act, subject to Article 50 transparency obligations and nothing more. High-risk classification is triggered by function, not by industry or by how much data the bot sees. A fintech chatbot that explains how to reset a PIN is limited-risk; the same company's model that scores a loan application is high-risk under Annex III.

Run these three questions in order. Any single "yes" moves you up a tier.

Question 1: Does the system perform a prohibited practice under Article 5?
Social scoring, emotion inference in the workplace, untargeted facial-image scraping, certain manipulative techniques, and, post-Omnibus, generation of non-consensual intimate imagery or CSAM. If yes, the system cannot be deployed at all. Prohibitions have applied since 2 February 2025.

Question 2: Does the system perform an Annex III function?
Concretely: evaluating creditworthiness or establishing credit scores; determining eligibility for essential public assistance benefits or essential private services; screening or filtering job applications; evaluating students; risk-scoring individuals for law enforcement or migration purposes. If yes, you are high-risk, and obligations apply from 2 December 2027 (Gibson Dunn).

Question 3: Does the system interact directly with natural persons?
If the answer to 1 and 2 was no, and this is yes, you are limited-risk. Article 50 requires you to inform people they are interacting with an AI system, unless that is obvious to a reasonably well-informed person (artificialintelligenceact.eu, Article 50).

Where the boundary actually sits

The nuance in the last two rows is real. An identity verification workflow that gathers documents and hands a human the file behaves differently from one that auto-rejects applicants. Similarly, a bot that answers questions about insurer authorization workflows is not the same as one that approves or denies the authorization.

Document the answer. Write a one-page classification memo naming the system, the three answers, the reasoning, the date, and the person who signed it. That memo is the single most useful compliance artifact you will produce this year.

Step 3: Decide whether you are a provider or a deployer

The AI Act splits obligations between providers (who develop an AI system and place it on the market under their own name or trademark) and deployers (who use an AI system under their own authority in a professional capacity). If you buy a chatbot platform and configure it with your knowledge base, you are almost always the deployer, and your vendor is the provider. That split determines who writes the technical documentation and who writes the disclosure.

Two things complicate this. First, if you white-label a system, substantially modify it, or put your own trademark on it and place it on the market, you can become a provider for that system. Second, for limited-risk chatbots, Article 50(1) places the disclosure duty on the provider of the system, while Article 50 also imposes deployer-facing duties for deepfakes and certain generated content. In practice, for a limited-risk support bot, both parties have skin in the game: the vendor must build disclosure capability, you must switch it on and keep it visible.

Obligation split at a glance

Note the correct article numbers. Older guidance, including the previous version of this page, cited "Article 52" for chatbot disclosure, "Article 29" for the FRIA, and "Article 61" for post-market monitoring. Those are pre-final draft numbers. In Regulation (EU) 2024/1689 they are Articles 50, 27, and 72 respectively. If a consultant's deck still says Article 52, ask what else in it is from 2023.

Write your role down in the classification memo from Step 2. Ambiguity here is what produces a two-week email chain with your vendor at exactly the wrong moment.

Step 4: Write and place your Article 50 disclosure

Article 50 requires that AI systems intended to interact directly with natural persons are designed so those persons are informed they are interacting with an AI system, unless it is obvious to a reasonably well-informed, observant and circumspect person given the circumstances (artificialintelligenceact.eu). The information must be provided at the latest at the time of the first interaction or exposure. This applies from 2 August 2026, and the Digital Omnibus did not move it.

There is no prescribed wording. There is a prescribed outcome: nobody should finish the conversation unsure whether they spoke to a machine.

Disclosure copy that works

• Web and in-app chat. Put it in the opening message, not only the widget footer. "Hi, I'm an AI assistant. I can help with orders, returns, and account questions. Type agent any time to reach a person."

• Voice. Disclose in the first utterance, before collecting any information. "Hi, this is an automated AI assistant from [Company]. This call may be recorded. How can I help?" Do not rely on natural-sounding speech patterns to imply humanity, and do not use a human name that suggests a person is on the line.

• Email and asynchronous. Include a persistent signature line identifying the responder as an AI system.

• WhatsApp and SMS. Disclose on the first outbound or first inbound reply of each new conversation thread, not once per customer lifetime.

What fails an audit

Then screenshot every channel with the disclosure visible, date the screenshots, and file them. When a regulator asks how you complied, the answer is a folder, not a Slack thread.

Fini's agent surfaces the AI disclosure as part of the greeting on chat, voice telephony, email, and messaging channels, with the copy under your control so it matches your legal team's wording rather than the vendor's.

Step 5: Handle synthetic content labeling and watermarking

Article 50(2) requires providers of AI systems that generate synthetic audio, image, video, or text content to mark the outputs in a machine-readable format detectable as artificially generated or manipulated. Under the Digital Omnibus, systems already placed on the market get a grace period until 2 December 2026 to meet this requirement (Gibson Dunn). For most support chatbots this obligation sits with your platform vendor, not you.

Your job as a deployer is narrower and easier to get wrong.

• Do not strip provenance metadata. If your vendor embeds machine-readable markers in generated audio or images, do not run outputs through a pipeline that removes them.

• Identify synthetic voice. A cloned or synthesized brand voice is generated audio. Disclose it and check that markers survive your telephony stack.

• Flag generated media in transcripts. If your bot produces images, diagrams, or audio summaries, note in the conversation record that the artifact was AI-generated.

• Ask your vendor, in writing, which marking standard they implement and whether it survives your export and archival formats.

Text-only support bots that retrieve and paraphrase existing documentation carry a lighter burden here. If your bot generates voice, images, or long-form content that could be mistaken for human authorship, put the watermarking question on your vendor's roadmap call before December.

Step 6: Close the AI literacy gap

Article 4 of the AI Act requires providers and deployers to ensure a sufficient level of AI literacy among staff and other people dealing with the operation and use of AI systems on their behalf. This obligation has applied since 2 February 2025, which means most organizations are already more than a year late. It is also the cheapest item on this checklist to fix.

Literacy is proportionate to role. Nobody expects a tier-1 agent to explain transformer architecture. They do need to know when to override the bot, what the bot cannot see, and what happens to a customer's data.

Role-based training minimums

Run it as one 45-minute session per role, once a year, plus a one-page onboarding module. Keep the attendance list. Executive attention is not the constraint: according to Gartner data published in February 2026 and summarized by Digital Applied, 91% of customer service and support leaders report executive pressure to implement AI in 2026 (Digital Applied). Pressure to deploy without matching literacy is exactly the condition that produces the gaps in Step 11.

Step 7: Reconcile GDPR work with AI Act work

The AI Act does not replace the GDPR; it stacks on top. A Data Protection Impact Assessment (DPIA) under GDPR Article 35 and a Fundamental Rights Impact Assessment (FRIA) under AI Act Article 27 are different documents with overlapping inputs. Most limited-risk support chatbots need the DPIA and do not need the FRIA.

The FRIA under Article 27 applies to specific deployers of high-risk systems: bodies governed by public law, private entities providing public services, and deployers of certain credit-scoring and insurance-pricing systems. It is Article 27 in the final Regulation, not Article 29 as pre-final drafts numbered it.

DPIA vs FRIA

Practical work that serves both regimes: map exactly which fields the chatbot reads and writes, decide retention periods and enforce them, document your lawful basis, verify that subject access requests can surface chat transcripts, and confirm where the data physically sits. That last point matters more than teams expect, which is why where data is stored and processed belongs in the same file as your classification memo. Fini supports EU data residency and can restrict processing to EU regions.

If you operate in financial services, this work also intersects with operational resilience obligations under DORA, which imposes its own ICT third-party register and incident reporting duties. Do the mapping once, file it three ways.

Step 8: Run vendor due diligence on your chatbot platform

As a deployer, you inherit your provider's failures in practice even when you do not inherit them in law. If your vendor cannot produce a data flow diagram, a sub-processor list, and a written position on Article 50 and Article 50(2), you carry the risk of finding out in August what they have not built. Ask these ten questions in writing and keep the answers.

1. What is your Article 50 disclosure implementation, and on which channels? Web, voice, email, and messaging should all be covered, not just the web widget.

2. Do you consider yourself the provider of the AI system we deploy? Get a yes or no, and a rationale.

3. Which foundation models do you use, from which providers, and can we restrict them? GPAI obligations sit with model providers, but you should know whose model answers your customers.

4. Where is our data stored and processed, and can you guarantee EU-only processing?

5. What is your retention default for conversation logs, and can we set it?

6. List your certifications and their audit dates. SOC 2 Type II and ISO 27001 are baseline. Note that ISO/IEC 42001 is an AI management system standard, not a certificate of AI Act conformity.

7. What is your sub-processor register, and how are we notified of changes?

8. How do you test for harmful, biased, or manipulated outputs? Ask whether they run structured adversarial testing and what the cadence is.

9. What is your serious-incident notification SLA to us, and what do you log?

10. Will you sign a DPA, and a BAA where applicable?

Fini answers all ten with documentation: SOC 2 Type II, ISO 27001, HIPAA-compliant with BAA eligibility, GDPR, and CCPA. Fini does not hold ISO/IEC 42001 certification, and no vendor should tell you that any certification makes you AI Act compliant. Certification evidences management-system maturity. Compliance is a legal conclusion about your specific system and its use.

Pricing transparency belongs in due diligence too, because usage-based AI billing shapes how aggressively teams throttle or expand the bot. Intercom prices its Fin AI Agent at $0.99 per outcome, charged once per conversation, where an outcome includes a confirmed resolution, no further help requested, or a completed workflow including handoffs (Intercom). Salesforce runs parallel models: $2 per conversation for customer-facing Agentforce agents, or Flex Credits at roughly $0.10 per action, with standard actions at 20 credits and voice actions at 30 credits (Salesforce). HubSpot meters its Breeze Customer Agent at 50 HubSpot Credits per conversation, with 500 credits included on Starter, 3,000 on Professional, and 5,000 on Enterprise, and extra credits at $0.010 each (HubSpot). Zendesk bundles AI into Suite tiers, with EU list prices of €19 per agent per month for Support Team up to €115 for Suite Professional, plus €50 per agent per month add-ons, and usage billing on builder and voice features beyond plan credits (Zendesk).

Fini bundles the platform, implementation, and a monthly resolution allowance with no per-seat fees. Growth is $3,600/mo ($3,000/mo billed yearly) with 2,000 resolutions and $0.89 per resolution beyond that. Scale is $9,000/mo ($7,500/mo billed yearly) with 8,000 resolutions plus 500 answered voice calls and $0.69 per resolution beyond that. Enterprise pricing is custom; contact Fini. Voice on every plan is $0.89 per answered call for the first 10,000. Paying annually gives two months free, and unused allowance rolls forward one month.

Step 9: Build the evidence pack regulators actually ask for

Compliance is demonstrated with documents, not intentions. Assemble a single folder, dated, versioned, and owned by a named person, containing the artifacts below. For a limited-risk chatbot this is a half-day of work once the earlier steps are done.

The pack:

• AI system inventory (Step 1), reviewed within the last quarter

• Risk classification memo per system, signed and dated (Step 2)

• Provider/deployer determination with rationale (Step 3)

• Dated screenshots of the AI disclosure on every channel (Step 4)

• Vendor's written statement on Article 50 and 50(2) implementation (Steps 4, 5, 8)

• AI literacy training records by role, with dates and attendance (Step 6)

• DPIA for the chatbot, and FRIA only if Article 27 applies to you (Step 7)

• Data flow diagram, retention policy, and residency confirmation (Step 7)

• Vendor due-diligence file: DPA, sub-processor list, certifications with audit dates (Step 8)

• Incident log with dates, severity, remediation, and reporting decisions

• Human handover policy: how customers reach a person, and typical wait

• Change log for prompt, model, and knowledge-base changes that materially alter behavior

Two of these deserve emphasis. The incident log is the artifact most teams skip and most regulators open first, because it reveals whether the other documents are alive or theatrical. And the change log matters because a model swap can change behavior more than a policy rewrite.

Keep the pack boring. A regulator reading a tidy, dated, unglamorous folder concludes you run a process. A regulator reading a designed PDF with no dates concludes you ran a project.

Step 10: Prepare for high-risk obligations before December 2027

If Step 2 put any system in Annex III, you have until 2 December 2027 for standalone high-risk systems and 2 August 2028 for high-risk AI embedded in regulated Annex I products (Gibson Dunn). That is more runway than the original 2 August 2026 date, and considerably less than it sounds once conformity assessment enters the picture. Start the gap analysis now, not in 2027.

The high-risk obligation set, with the correct final-Act article numbers:

Note what is missing from that table: the previous version of this page mapped "corrective actions" to Article 16 based on draft numbering. Provider obligations are consolidated in Article 16 in the final Act, but the specific corrective-action duty and its article location should be verified against the Regulation text with counsel before you build a control around it. Do not build a compliance program on a number you cannot open the source for.

Penalties, by the correct tier

Article 99 sets three tiers, and the €35M figure is not the chatbot tier (artificialintelligenceact.eu, Article 99):

A missing disclosure banner is a 3% exposure, not a 7% exposure. That distinction matters because overstating the number destroys your credibility with the finance team you need in the room. It also matters because the third tier, misleading a regulator, is the one you can trigger by improvising an answer during an inquiry rather than reading from the evidence pack.

Common mistakes teams make

The failures are consistent, and none of them are exotic. In an internal Fini review of customer-support chatbot deployments, the most common readiness gaps were absent AI disclosure on at least one channel, raw transcript logging without PII redaction, and no documented path for a customer to reach a human. These are internal Fini benchmarking observations rather than externally audited figures, and they should be read as such.

Here are the mistakes worth naming.

Assuming your bot is high-risk because your industry is regulated. Being a bank does not make your password-reset bot Annex III. The function does. Over-classifying wastes six months of engineering time on a conformity assessment you do not owe.

Assuming your bot is limited-risk because it "just answers questions." Then discovering it quietly tells customers whether they pre-qualify for a credit product. Read the actual intent list, not the marketing description.

Disclosing on the web widget and forgetting the phone line. Article 50 does not distinguish by channel. Voice deployments are the single most common gap because they are usually built by a different team.

Treating a certification as compliance. ISO/IEC 42001 is a management-system standard. SOC 2 Type II is a controls attestation. Neither is a conformity assessment under the AI Act, and no auditor will accept one in place of the other. Our primer on AI compliance program design explains where certifications help and where they stop.

Copying deadlines from 2025 articles. GPAI obligations landed 2 August 2025, not 2026. Annex III high-risk is now 2 December 2027, not 2 August 2026. Article 50 is still 2 August 2026. Half the compliance content on the open web has at least one of these three wrong.

Citing draft article numbers. Article 52 became Article 50. Article 29 became Article 27. Article 61 became Article 72. If your internal policy cites the old ones, someone copied a 2023 blog post into a governance document.

Letting the human-handover path decay. A "talk to an agent" command that routes to a queue with a three-day SLA is not meaningful human contact. It also destroys the operational safety net that makes limited-risk classification defensible.

Ignoring the systems nobody bought. Consumer AI tools in the support workflow process customer data outside every control you documented. In regulated verticals, that same exposure pattern is why handling protected health information requires vendor-level controls rather than agent-level policy.

How to measure whether the program worked

Compliance programs fail quietly, so instrument them. The metrics below distinguish between a program that exists on paper and one that is operating. Review them monthly for the first quarter and quarterly after that.

Then separate compliance metrics from performance metrics, because conflating them produces bad decisions. On the performance side, be skeptical of headline deflection numbers. Zendesk CX Trends 2026 data summarized by Digital Applied puts median tier-1 ticket deflection across enterprise CX programs at 41.2%, with the top quartile at 58.7%, well below the 70% to 90% deflection figures vendors commonly advertise (Digital Applied).

Fini reports 99% accuracy and a 90% resolution rate, and customers go live in 30 days. Those are the numbers to hold any vendor to, alongside the compliance metrics above, because a bot that resolves less is a bot whose human-handover path carries more load and whose disclosure gets read more often.

Where to start this quarter

With Article 50 applying on 2 August 2026, the sequence for the next three weeks is short: finish the inventory, sign one classification memo per system, ship the disclosure on every channel including voice, and screenshot it. Everything else on this checklist has runway; the disclosure does not. Teams that stop there are compliant with the obligation that actually binds them, and they have the memo to prove why the rest does not.

The longer arc is different. If any system in your inventory touches creditworthiness, eligibility for essential services, or employment screening, you have until 2 December 2027, and conformity assessment work should start in the next two quarters rather than the last one.

If you are choosing or replacing a support AI platform while this deadline runs, the vendor questions in Step 8 are the ones worth asking first. To see how Fini handles Article 50 disclosure across chat, voice, email, and messaging, how EU data residency is configured, and what the audit export actually contains for your specific channel mix, book a walkthrough with the Fini team and bring your inventory.