Ada Under the EU AI Act: Autonomous Support and the Deployer's Duties

Limited risk. Ada (ada.cx) is an AI customer-service agent that resolves support conversations end to end — and when you run it on your own help centre, your deployment sits at limited risk under the EU AI Act. The autonomy is the selling point; the obligations are transparency, AI literacy, and governing what the agent reads. Because Ada closes tickets without a human in the loop, the practical burden on accuracy and escalation is heavier than the light legal tier implies. This page is written for the deployer — the company running Ada on its own support channels.

---

What Ada is, in EU AI Act terms

Ada is an autonomous customer-service agent. It sits on top of an existing help desk, understands intent, and resolves issues — including multi-step actions like troubleshooting or refunds — across chat, email, and voice, without routing every query to a human. It runs its generative responses on third-party general-purpose AI models.

Under Regulation (EU) 2024/1689, Ada meets the Article 3(1) definition of an AI system: a machine-based system that infers from inputs to produce outputs — customer-facing answers and resolution actions. The model is one layer; the Ada agent you configure is the deployed system on top of it. That split decides who carries which obligation.

---

What risk tier does Ada fall into?

Classification follows function and context, never the product name or how autonomous the agent feels (Article 6). An Ada agent that answers product, billing, and policy questions, takes routine actions, and routes the rest is limited-risk under Article 50. No Annex III category attaches, so the high-risk stack does not: no Article 9–15 requirements, no Article 43 conformity assessment, no Annex IV documentation, no CE marking.

Article 6(3) only comes into play if a use does land in Annex III: even then, a system performing a narrow procedural task that poses no significant risk to health, safety, or fundamental rights can stay outside high-risk (it must still be registered). The carve-out — if the system profiles natural persons, the filter falls away and the system is high-risk.

---

Your core duty: Article 50 transparency

Article 50(1) requires that natural persons be informed they are interacting with an AI system, at the latest when the interaction starts. The exception — where it is obvious to a reasonably well-informed person — is narrow for Ada, since an agent that resolves queries convincingly can be mistaken for a human, so assume a disclosure is needed.

Designing that disclosure in is a provider duty, so it sits with Ada Support; as the deployer, you control where and how the agent appears, so make sure it is switched on and visible in the Ada interface itself — a visible label in the chat or messaging surface, an audible statement on the re-engineered voice channel — not a line buried in your terms of service. Keep hand-offs clear: where Ada escalates to a human or a human hands back, the transition should be visible. Article 50 transparency has applied since 2 August 2026 and was not moved by the Digital Omnibus. The Article 50(2) machine-readable marking duty for synthetic content has applied since the same date; it is also a provider duty, so confirm Ada Support's approach in vendor due diligence.

---

What changes when the agent resolves without a human in the loop

This is where Ada differs from a suggest-and-assist copilot. Because Ada resolves and closes queries autonomously, there is often no human gate between the AI output and the customer: a wrong, fabricated, or out-of-date answer reaches them directly. The legal tier usually stays limited-risk, but the deployer carries a heavier burden for accuracy, escalation rules, and monitoring.

Watch the narrow edge. If an autonomous answer effectively decides access to an essential service — gates eligibility, denies a benefit, locks an account — reassess against Annex III point 5. Function, not form, governs: a conversational wrapper does not exempt a system that is, in substance, deciding something consequential about a person. The same applies if Ada were ever wired into an employment or creditworthiness decision.

---

Data governance over what Ada reads

Ada answers from a configured knowledge base — help-centre articles, internal documents, connected systems. Their quality and lawfulness is a core deployer responsibility, because they directly determine what Ada tells customers: stale, contradictory, or unauthorised content produces wrong autonomous answers. Record which sources Ada can draw on, who approves them, and how outdated content is retired — that record supports both accuracy and an Article 50 due-diligence trail.

The formal Article 10 data-governance duties bind high-risk providers, not a limited-risk deployer, but the underlying discipline — clean, current, authorised sources — is the practical equivalent and worth adopting voluntarily. Where knowledge sources or conversation logs contain personal data, GDPR applies alongside the AI Act as a separate, parallel framework; clearing one does not clear the other.

---

The deployer's actual to-do list

Four things, none of them a high-risk programme.

Confirm the Article 50 disclosure is live

A clear AI disclosure inside the Ada surface, visible or audible at the start of the interaction, with clear hand-off signalling — built by Ada Support, enabled and checked by you.

Confirm Article 4 AI literacy for staff

Article 4 AI literacy has been in force since 2 February 2025; since 27 July 2026 it requires deployers to take measures to support their staff's AI literacy rather than guarantee a set level. Staff who configure Ada, manage its knowledge, or handle escalations should get a role-appropriate understanding of what it does and where it fails.

Govern the knowledge sources and set escalation rules

Approve and retire sources deliberately, and set escalation thresholds so genuinely consequential queries reach a human rather than being auto-resolved. Screen Ada's conversational design against Article 5 prohibitions — no manipulative or deceptive techniques causing harm, especially where the agent is incentivised to retain or up-sell.

Document the classification and reassess on scope change

Keep a short written classification record and rerun it if Ada's role expands toward any Annex III function. Missing these duties falls in the €15,000,000 or 3% of total worldwide annual turnover, whichever is higher, tier under Article 99(4), with Article 99(6) capping SMEs and start-ups at the lower of the two.

---

Who is the provider and who is the deployer?

Ada Support places Ada on the market under its own name, which makes it the provider of the Ada system under Article 16. The company switching Ada on for its own support channel is the deployer under Article 26 — you classify and govern the deployed agent by what it does; you do not build it.

The general-purpose AI model obligations under Articles 51–55 stay with the upstream model provider that developed the underlying model. They have applied since 2 August 2025 and do not transfer to a company deploying an agent built on the model.

The boundary can move. Under Article 25, a deployer becomes a provider if it puts its own name or trademark on the system, makes a substantial modification, or changes the intended purpose so the system becomes high-risk — repurposing Ada into a tool that autonomously decides service eligibility could be such a change. Record the intended purpose precisely.

---

Worked example: a 150-person SaaS company turns on Ada

Talvio Cloud OÜ, a ~150-employee EU SaaS company with ~€24M turnover, deploys Ada to autonomously resolve subscription, billing, and onboarding questions across its help centre.

Classification result: limited-risk. Ada answers and resolves support queries, and no Annex III category is engaged, so the Article 6(3) filter is not even needed.

Their duties: make sure the Article 50 AI disclosure is enabled in the Ada widget (required since 2 August 2026); confirm Article 4 literacy for the five-person support-ops team now; govern which billing and policy documents Ada can draw on; log the classification.

The edge to watch: one Ada flow can suspend an account for non-payment automatically. Because that decision gates access to a service the customer relies on, Talvio reassesses it against Annex III point 5 and routes suspension queries to a human — keeping the deployment cleanly limited-risk.

Outcome: a short, defensible workplan rather than a high-risk programme. Honest classification kept the burden proportionate.

---

One timeline caveat on the high-risk deadline

Under the Digital Omnibus — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026 — the stand-alone high-risk Annex III deadline is now 2 December 2027 (originally 2 August 2026). For a limited-risk Ada deployment this rarely bites; if you ever push Ada into an Annex III function, plan against 2 December 2027.

---

How Confir helps

Add Ada to your AI register and Confir's classification engine asks how you use it — what Ada answers, whether it resolves autonomously, what data its knowledge base touches, and whether any flow gates access to a service. It runs the Article 5 prohibited-practice check first, then the Article 6 and Annex III scoping, and returns your tier with the rule that fired written in plain language. A standard support deployment produces the short limited-risk checklist; a flow that decides eligibility surfaces the Annex III reassessment. The engine is deterministic and rule-based — no model inference, no hallucination — so the same intake always yields the same finding any reviewer can check.

Related guides

• EU AI Act Article 50: transparency and disclosure
• limited-risk AI systems and what Article 50 requires
• customer-support chatbots under the EU AI Act
• Intercom Fin under the EU AI Act
• Zendesk AI under the EU AI Act
• the full AI tool inventory