Beyond the Headlines: What Mandatory AI Disclosure Rules Really Means for Enterprise IT Teams in Europe

Direct answer: Chatbots and other interactive AI systems operating in Europe now have to tell users, clearly and up front, that they are talking to AI rather than a human. For enterprise IT teams this is not a copywriting tweak — it is a compliance requirement that touches system architecture, logging, vendor contracts, and every customer-facing AI surface the organization runs.

Digital Strategy EC reported in August 2026 that chatbots and other interactive AI systems are now legally required to disclose to users that they are interacting with AI, not a human. This closes a gap that many organizations had been quietly operating in: AI-driven support widgets, virtual assistants, and voice agents that gave no clear signal of their non-human nature. For enterprise IT teams in Europe, this is the kind of rule that looks small in a headline and large in a project backlog, because it does not just affect one chatbot on one page — it affects every conversational AI touchpoint across web, app, and voice channels, and it requires proof that disclosure actually happened, not just a policy saying it should. We are not going to guess at enforcement dates, penalty amounts, or specific enforcement bodies beyond what has been reported, because a precise figure for those specifics is not publicly available yet — but the direction is unambiguous, and IT teams that treat it as a documentation footnote rather than an engineering requirement are the ones who will scramble later.

What the Disclosure Requirement Actually Is

The rule, as reported, is straightforward in intent: when a user is interacting with a chatbot or an interactive AI system, that system must make it clear the user is talking to AI, not a person. That sounds simple until you map it against how conversational AI actually gets built inside a large organization.

Most enterprise chatbots did not start as a single, centrally governed product. They accumulated. A customer support widget from one vendor, a sales qualification bot from another, an internal HR assistant built on a different stack, a voice IVR system layered with AI routing, and increasingly, autonomous agents that hand off between systems without a human ever entering the loop. Each of these was likely built by a different team, at a different time, with different assumptions about disclosure. Some may already show "AI Assistant" in a chat header. Others — especially voice-based systems, or agents that operate behind an API rather than a visible UI — may have no disclosure mechanism at all.

Why This Is a Real Trend, Not a One-Off Rule

This sits inside a broader pattern that has been building for two years: regulators moving from "AI should be safe" as a vague principle toward specific, checkable, engineering-relevant obligations. Disclosure requirements are attractive to regulators precisely because they are auditable — a screenshot or a call recording either shows the disclosure or it doesn't. That auditability is exactly what makes this different from softer AI governance guidance. It is not a best practice. It is a control that can be tested.

It also reflects a shift in what "AI governance" means in practice. For a long time, governance conversations inside large organizations centered on model risk — accuracy, bias, hallucination — because those were the visible failure modes that made headlines. Disclosure is a different category of obligation entirely: it isn't about whether the AI gives a good answer, it's about whether the user was ever told they were talking to a machine in the first place. That is a much lower bar to clear technically, but a much higher bar to clear organizationally, because it requires knowing, with certainty, every place AI is currently talking to a human on the company's behalf. Plenty of IT leaders can tell you their model accuracy benchmarks. Far fewer can produce a complete list of every AI-driven conversational surface running across their web properties, mobile apps, and voice systems today.

Why Regulators Are Starting Here

Disclosure is also a logical first step for regulators because it doesn't require judging the quality or safety of an AI system — only whether a specific, checkable fact was communicated. That makes it enforceable without the harder work of auditing model behavior, and it explains why this kind of rule tends to arrive earlier than deeper AI accountability requirements. Enterprise IT teams should read that as a signal: if disclosure is the opening move, deeper requirements around AI decision logging, explainability, and human oversight are a reasonable thing to prepare architecture for now, rather than treating each new rule as an isolated, unrelated project.

Why This Matters Specifically to Enterprise IT Teams in Europe

For enterprise IT teams, the immediate question is not "do we agree with this" — it's "where do we currently violate it, and how would we know." That second half is the harder problem. Most organizations do not have a single inventory of every AI-driven conversational surface they operate. Marketing may have stood up a chat widget through a SaaS tool. Support may run a separate AI layer inside the ticketing platform. Product may have shipped an in-app assistant. Sales may use an AI-powered scheduling bot. Each of these is a separate disclosure surface, and each may be owned by a different budget line, with IT having partial visibility at best.

There is also a technical dimension that is easy to underestimate: disclosure has to survive handoffs. A conversation that starts with an AI agent and escalates to a human agent needs the disclosure state to be tracked and communicated at the point of transition — and, just as importantly, the reverse case, where a human-initiated conversation gets routed into an AI agent for follow-up, needs the same clarity. If your architecture treats "who is on the other end" as an implementation detail rather than a stateful, loggable fact, this requirement forces a redesign of that layer, not just a UI label.

For organizations operating across multiple European markets, there is an additional wrinkle: disclosure needs to be understandable in the user's language and context, which means it is not enough to hardcode a single English-language string into a chat widget and call the requirement met. Localization, accessibility (a disclosure buried in tiny text or a tooltip a screen reader skips is a weak disclosure), and consistency across channels all become part of the engineering scope, not just legal sign-off.

The Organizational Blind Spot

There is a second, less obvious reason this matters specifically to IT rather than to legal or compliance alone: IT is the only function with the technical visibility to actually answer the question "where does AI talk to our users." Legal can write a policy. Compliance can define a standard. Neither can enumerate every API integration, every embedded widget, every low-code automation a regional marketing team stood up last quarter, without pulling in the people who own the infrastructure. That makes this, structurally, an IT-led initiative even though the requirement originates from a regulatory source outside IT's usual remit. Enterprise IT teams in Europe that get ahead of this will be the ones setting the technical standard the rest of the organization has to follow, rather than reacting to a compliance request they can't fully scope.

There is also a scale dimension specific to large European enterprises: many operate across several countries, each with its own regional website, support desk, and sometimes its own chatbot vendor selected independently by a local team. A disclosure standard that works for the headquarters website does nothing for a regional site running a completely different chat platform under a different contract. Centralizing visibility across those regional deployments — even before centralizing the technology itself — is often the single highest-leverage step an IT team can take in the first month of this work.

What Changes in Practice for Your Website, App, or Product

Concretely, IT teams should expect four categories of work to open up.

First, an inventory and audit. Every chatbot, voice assistant, in-app agent, and AI-driven support flow needs to be catalogued, along with who owns it, what platform it runs on, and whether it currently discloses its AI nature at the start of a session — not just somewhere in a terms-of-service link. This is unglamorous work, and it is exactly the kind of work that reveals shadow AI deployments teams didn't know existed.

Second, a standard disclosure pattern implemented at the platform level rather than per-bot. Rather than each team writing its own disclosure string and hoping it's compliant, the more defensible approach is a shared component or middleware layer that every conversational AI surface is required to route through, so disclosure logic, wording, and logging are consistent and centrally maintained. This is where a proper AI Agents & Automation architecture pays for itself: agents built with clear, auditable state — including who or what is speaking at every turn — make this a configuration change instead of a rebuild.

Third, logging and evidence. If a regulator or auditor asks "can you show that disclosure was presented to this user, in this session, in a form they could reasonably notice," the organization needs an answer that isn't "we believe so." That means session logs capturing the disclosure event itself, not just the chat transcript.

Fourth, vendor accountability. Many enterprise chatbots run on third-party platforms. IT teams need to confirm, in writing, whether the vendor's product natively supports compliant disclosure or whether that burden falls back on the internal team to bolt on. This is a procurement and contract review task as much as a technical one, and it is worth doing before renewal cycles rather than after an incident.

There is a fifth category worth calling out separately because it tends to get missed: testing and monitoring after launch. Disclosure isn't a one-time implementation you ship and forget. Chat platforms get updated by vendors, UI redesigns happen, and new agent flows get added by teams outside IT's direct control — any of these can silently break a previously compliant disclosure pattern. Building a lightweight, recurring check, even a simple automated scan that flags any conversational AI endpoint missing its expected disclosure event in the logs, turns this from a one-off project into a maintained control, which is what regulators and auditors will actually expect to see over time.

Handling the Legacy Systems Problem

Older systems present a particular challenge here. A voice IVR system that was built years ago, running on infrastructure that predates modern AI tooling, may not have been designed with any concept of a "disclosure event" at all — it just routes calls. Retrofitting disclosure into systems like this sometimes requires more than a script change; it can mean introducing a new layer of call handling logic specifically to insert, log, and confirm the disclosure step before anything else happens on the line. IT teams should budget real time for this category of legacy remediation rather than assuming every fix will be a quick configuration change.

Where Dashboards and Reporting Fit In

Once disclosure logging exists, someone needs to actually look at it. Compliance and IT leadership will want a rollup view — which surfaces are compliant, which are pending, where gaps remain — rather than digging through raw logs per bot. This is a natural fit for the kind of purpose-built reporting layer covered in Custom Dashboard Development: From Requirements to Rollout, where the requirement (prove disclosure happened, across every AI touchpoint, on demand) drives the dashboard design rather than the other way around.

What to Do About It Now

The organizations that will handle this smoothly are the ones that treat it as an architecture decision, not a legal memo to be filed. That starts with getting an honest inventory of every AI-driven conversational surface in production, including the ones that were never formally reviewed by IT because they were spun up by a business team through a low-code tool. From there, the priority is building or adopting a shared disclosure pattern that any team can plug a new bot into without reinventing the logic, and instrumenting it so disclosure is a logged, provable event rather than an assumption.

It's also worth treating this as a moment to consolidate rather than patch. If your organization has five or six disconnected AI chat tools accumulated over several years, each with its own disclosure gaps, that is a strong argument for moving toward a smaller number of well-governed agent deployments rather than adding a disclosure patch to each legacy tool individually.

Building It So It Doesn't Need Redoing

The teams that will feel this least in twelve months are the ones who use this requirement as the forcing function to build a proper agent governance layer now, rather than the minimum patch needed to pass today's requirement. Concretely, that means designing conversational AI systems so that "is this AI or human," "has disclosure been shown," and "what happened in this session" are first-class, queryable facts about every interaction — not details buried inside a vendor's proprietary chat log format that's hard to export or audit later.

It also means being deliberate about ownership. Assign a single accountable owner for AI disclosure compliance across the organization, even if the underlying bots are built and maintained by different teams. Without a single owner, this kind of cross-cutting requirement tends to fall into the gap between teams, where everyone assumes someone else is handling it. A short, recurring review cadence — quarterly is reasonable for most organizations — keeps the inventory current as new AI tools inevitably get adopted by teams outside IT's direct line of sight.

Finally, don't treat this purely as a defensive compliance exercise. Clear, well-designed AI disclosure, done properly, can actually build user trust rather than eroding it — users who know they're talking to AI and see that the system is transparent about it tend to calibrate their expectations more sensibly than users who suspect something is off but can't tell what. Framed that way, this becomes an argument you can make to business stakeholders beyond just "we have to," which tends to get budget approved faster than a purely legal justification.

None of this is unique to chatbots in the narrow sense — the same governance thinking applies wherever AI-driven automation touches customers, whether that's e-commerce storefronts, internal tooling, or marketing infrastructure. Teams running platforms like Shopify, for instance, are increasingly layering AI assistants into storefronts, and the same disclosure and architecture questions raised here apply directly to work like the kind described in Shopify Custom Development for Growing Brands — any AI-driven storefront assistant is a disclosure surface too. Similarly, organizations investing in SEO for Multi-Location Businesses: Local Pages Done Right should note that AI-driven local chat or booking widgets on those location pages fall under the same rule, market by market.

Pricing Context: What This Kind of Work Typically Falls Under

The scope of the work — inventory, disclosure architecture, logging, and rollout — varies with how many conversational AI surfaces an organization runs and how fragmented they currently are.

Tier	Typical scope for this kind of work
Essential ($1,000)	Audit and disclosure fix for a single chatbot or agent surface, with basic logging
Growth ($2,000)	Shared disclosure component across multiple bots/channels, plus reporting on compliance status
Enterprise ($4,000+)	Full inventory across web, app, and voice surfaces; centralized AI agent governance layer with audit-ready logging and vendor review

Key Takeaways

• Chatbots and interactive AI systems in Europe must now clearly disclose that users are talking to AI, per Digital Strategy EC, Aug 2026 — this is an engineering requirement, not just a legal note.
• Most enterprises don't have a single inventory of every AI conversational surface they run; building that inventory is the necessary first step.
• Disclosure needs to survive handoffs between AI and human agents, and be logged as a provable event, not assumed from a UI label.
• A shared, platform-level disclosure pattern is more defensible and maintainable than per-team, per-bot implementations.
• Vendor contracts should be reviewed now, before renewal, to confirm who owns compliant disclosure on third-party chat platforms.
• Compliance dashboards give leadership a rollup view of which AI surfaces are compliant and which still need work.

Getting disclosure right across every AI touchpoint takes coordinated architecture, not a scramble across five different teams — if you want help mapping your current AI surfaces and building a compliant, auditable structure around them, book a meeting with our team.

Frequently Asked Questions

What exactly counts as an "interactive AI system" under this disclosure requirement?

Based on how Digital Strategy EC described it, this covers any system where a user has a real-time, conversational exchange with AI — chatbots, virtual assistants, voice-based AI agents, and similar tools. It is broader than just customer-support chat widgets and likely extends to sales bots, in-app assistants, and AI-driven voice systems.

Does this apply to internal tools, or only customer-facing chatbots?

The reporting centers on user-facing disclosure, which most directly implicates customer-facing systems. However, enterprise IT teams operating in Europe should still review internal tools used by contractors, partners, or mixed employee/external audiences, since "user" isn't necessarily limited to external customers.

Our chatbot already says "AI Assistant" in the header — are we compliant?

A visible label is a reasonable starting point, but the safer approach is to make disclosure explicit at the start of the interaction itself, not just implied by a UI label a user might not read. Teams should also confirm the disclosure is accessible (readable by screen readers, not just visual styling) and consistent across every channel the bot runs on.

What about voice-based AI systems — how do you disclose there?

Voice is the harder case because there's no header or label to rely on. The practical approach is a spoken disclosure at the start of the call or session, delivered clearly enough that a reasonable listener would register it, and logged as an event in the call record.

Do we need to disclose AI on every single message, or just at the start of a session?

The reporting suggests the obligation is about making it clear the user is interacting with AI, which is generally interpreted as an upfront disclosure at the start of the interaction, though ongoing clarity matters if the conversation is long or if a handoff to a human occurs mid-session.

What happens if a human agent takes over an AI conversation partway through?

This is one of the trickier architecture problems. The system needs to track and clearly communicate the transition, since a user who was told they're speaking with AI shouldn't be left assuming that's still true once a human has taken over — and vice versa.

How do we prove disclosure happened if we're ever audited?

You need session-level logging that captures the disclosure event itself — not just the chat transcript, but a record showing the disclosure message was rendered or spoken to the user at a specific point in the session. This is a logging design decision, not something you can add retroactively without instrumentation.

We use a third-party chatbot platform — is disclosure the vendor's responsibility or ours?

Ultimately, the deploying organization is accountable for how its AI systems behave toward users, regardless of whose platform powers them. It's worth confirming in writing whether your vendor supports compliant disclosure natively or whether you need to implement it yourselves.

How many different AI chat tools does the average enterprise actually run?

We don't have a precise industry figure for this, but in practice, larger organizations frequently accumulate multiple AI chat tools across support, sales, marketing, and product teams, often without a central inventory — which is exactly why an audit is usually the first real finding of this work.

Is this specific to one EU country or does it apply across Europe?

The reporting frames this as a broader EU digital strategy requirement rather than a single-country rule, meaning enterprise IT teams operating across multiple European markets should assume it applies wherever they have EU users, not just in one jurisdiction.

What's the difference between disclosure and consent?

Disclosure means telling the user they're interacting with AI. Consent, in a broader data-protection sense, is a separate concept about agreeing to data processing. This requirement is squarely about disclosure — making the nature of the interaction clear — not a new consent mechanism, though the two can intersect in your privacy documentation.

Does this affect AI-generated content on a website, or only live chat interactions?

Based on what's been reported, this is specifically about interactive systems — real-time exchanges where a user is conversing with AI. Static AI-generated content (like a blog post) is a separate governance question, not covered by this particular disclosure rule.

How long will it take to audit our AI chatbot surfaces?

It depends heavily on how fragmented your current deployments are. A single, centrally managed chatbot might take a short audit; an enterprise with bots spread across support, sales, marketing, and multiple regional sites will take considerably longer, since much of the effort is simply finding every surface that exists.

Can we handle this with a policy update instead of an engineering change?

A policy update alone won't produce the disclosure itself or the logs proving it happened. You need both: a clear internal policy defining the standard, and the engineering work to implement and log it consistently across every AI touchpoint.

What's the risk if we don't comply?

We don't have specific penalty figures to cite, and it would be irresponsible to invent them. What's clear from the reporting is that this is a legal requirement, not a suggestion, so the risk category is regulatory exposure — the scale of which will depend on enforcement details not yet public.

Should disclosure wording be the same across every bot, or can each team write its own?

A shared, centrally maintained disclosure pattern is more defensible than each team writing its own wording, because it reduces the chance of inconsistent, unclear, or non-compliant phrasing slipping through on any one surface.

How does this interact with existing AI transparency guidance we may already follow?

Broader AI transparency principles (like explaining how AI makes decisions) are a different, adjacent concern from this specific disclosure-of-interaction requirement. Treat this as a concrete, narrower obligation that sits alongside — not replaces — any wider AI governance work you're already doing.

What does a "shared disclosure component" actually look like technically?

In practice, it's a middleware or shared UI component that every conversational AI surface is required to route through, so the disclosure message, timing, logging, and accessibility behavior are defined once and applied consistently, rather than reimplemented per bot.

Our AI agents operate autonomously and hand off between systems — does disclosure still apply?

Yes, arguably even more so. Autonomous, multi-agent handoffs are exactly the scenario where a user can lose track of whether they're still talking to AI, a different AI, or a human. This is a strong argument for building agent architectures with explicit, loggable state about who is "speaking" at each step.

How does this affect AI-driven booking or scheduling bots?

Any bot that carries on a real-time exchange with a user — including scheduling or booking flows — falls into the same category as customer support chat. If it's interactive and AI-driven, it needs the same disclosure treatment.

What about AI features embedded inside a larger app, like a smart search or recommendation assistant?

If the feature involves a live, conversational exchange with the user (as opposed to passive AI-driven results like ranked search), it likely falls under this requirement and should be reviewed the same way as a standalone chatbot.

Does multilingual disclosure matter for a pan-European audience?

Yes. A disclosure that's only presented in one language isn't meaningfully clear to users interacting in another language or region. Enterprise IT teams serving multiple European markets should plan for localized disclosure text as part of the same rollout, not as an afterthought.

How do accessibility requirements intersect with this rule?

A disclosure that's visually present but not accessible to screen readers, or that relies solely on color or tiny print, is a weak implementation. Building disclosure to standard accessibility practices from the start avoids a second remediation project later.

What role does our CRM or support platform play in this?

If your support platform routes conversations between AI and human agents, it needs to carry disclosure state through that handoff and ideally log it. This is worth reviewing with whichever platform handles your support or sales conversations, especially before a contract renewal.

Is there a difference between a chatbot that answers FAQs and a fully autonomous AI agent that takes actions?

Both are interactive AI systems from a disclosure standpoint, but autonomous agents that take actions (booking, refunding, updating records) raise additional governance questions beyond disclosure — like auditability of the actions themselves — that are worth addressing in the same project.

How should we prioritize which bots to fix first?

Start with the highest-traffic, most customer-facing surfaces — typically main support chat and any sales-facing bots — since those carry the most exposure, then work through lower-traffic or internal tools.

What's a realistic first step for an IT team that hasn't looked at this yet?

Start with an inventory: list every chatbot, voice assistant, and AI agent currently in production, who owns each one, what platform it runs on, and whether it currently discloses its AI nature. That single document usually reveals most of the actual scope of work.

Do AI-powered email or messaging bots count, or is this only about live chat?

The core concept is real-time, interactive exchange, so live chat and voice are the clearest cases. Asynchronous AI-generated messages (like an automated email) are a somewhat different pattern, but if they simulate an ongoing back-and-forth conversation, it's worth applying the same disclosure thinking rather than assuming they're exempt.

How do we handle disclosure for AI agents used in B2B sales conversations?

The same principle applies regardless of B2B or B2C context: if a business contact is having a real-time exchange with an AI system, they should be told that clearly, especially before any handoff to a human sales rep.

What kind of logging infrastructure do we need to add?

At minimum, you need an event log that records when a disclosure message was shown or spoken, tied to the session ID, so you can reconstruct — on demand — that a specific user in a specific session received disclosure at the appropriate point.

Can existing chatbot analytics tools be extended to capture disclosure events, or do we need new infrastructure?

Many existing chatbot or CRM analytics tools can likely be extended to log a disclosure event as a custom event type, which is usually more efficient than building entirely separate logging infrastructure from scratch.

How does this affect our vendor selection going forward?

Going forward, compliant, loggable disclosure should be a standard evaluation criterion for any new AI chat or agent platform you're considering, alongside the usual functionality and pricing comparisons.

Should legal or compliance teams lead this, or should IT?

This genuinely needs both. Legal/compliance defines what "compliant" means in your specific context; IT is the only team that can actually inventory the systems, build the disclosure architecture, and implement the logging that proves compliance.

What's the cost of doing nothing?

We can't quantify penalty risk without inventing numbers we don't have, but the practical cost of inaction is that any gap surfaces at the worst possible time — during an audit, a user complaint, or a press inquiry — rather than on your own schedule.

How often should we re-audit our AI chatbot inventory after the initial fix?

Given how easily new AI tools get adopted by individual teams, a periodic re-audit (at minimum annually, ideally tied to any major platform change) is a reasonable practice to keep the inventory accurate.

Does this rule apply retroactively to bots we've already deployed, or only new ones?

The reporting describes this as a requirement for chatbots and interactive AI systems generally, which reads as applying to systems already in production, not just new deployments — meaning existing bots need remediation, not just future ones.

What if our chatbot is hosted outside Europe but serves European users?

If the system interacts with users in Europe, the disclosure obligation is generally tied to where the users are, not where the system is hosted — so serving European users from an offshore-hosted bot doesn't exempt you.

How does this intersect with GDPR compliance work we've already done?

GDPR governs data processing and consent; this disclosure requirement is about the nature of the interaction itself. They're related in spirit (transparency toward users) but distinct obligations — GDPR compliance doesn't automatically cover this.

What should a disclosure message actually say to be clear enough?

While we don't have official model wording to cite, the practical bar is that a reasonable user reading or hearing it would understand, without ambiguity, that they are interacting with an AI system rather than a human.

Can we use a passive disclosure, like a small icon, instead of a text message?

An icon alone is risky, since not every user will recognize or notice it as a disclosure signal. A clear, plain-language statement at the start of the interaction is the more defensible approach, with visual cues as a supplement rather than a substitute.

What if the user already knows they're talking to a bot because of context (like a "Chat with our AI" button)?

Even if context suggests it, the safer and more compliant approach is an explicit disclosure at the start of the actual conversation, rather than relying on the user having noticed a button label beforehand.

How does this affect mobile app-based AI assistants specifically?

The same logic applies: if the in-app assistant is a real-time, interactive AI exchange, it needs the same clear disclosure and logging treatment as a web-based chatbot, adapted to the app's UI patterns.

Is there a size threshold — does this only apply to large enterprises?

Nothing in the reporting suggests a size exemption; the obligation is framed around the nature of the interaction (AI-based, real-time) rather than the size of the organization deploying it.

What's the relationship between this rule and the broader AI Act discussions in Europe?

This disclosure requirement fits within the general direction of EU AI governance toward transparency obligations, though the specific scope and enforcement mechanics reported by Digital Strategy EC should be treated as its own distinct requirement rather than assumed to be identical to other AI Act provisions.

How do we handle disclosure when AI is used behind the scenes to draft responses a human then sends?

If a human reviews and sends the message, and the user is genuinely interacting with that human's judgment even if AI helped draft it, that's a different scenario from a fully AI-driven conversation — but if the line blurs, clarity toward the user is still the safer default.

What's the first deliverable we should expect from a project addressing this?

A realistic first deliverable is a documented inventory of every AI conversational surface in production, mapped against current disclosure status, which then drives a prioritized remediation plan.

How does this affect our marketing team's use of AI chat tools for lead generation?

Lead-generation chatbots are squarely interactive AI systems and need the same disclosure treatment as support bots — marketing-owned tools shouldn't be assumed exempt just because IT didn't build them.

Will this requirement likely expand to cover more AI system types over time?

Given the general regulatory direction toward transparency, it's reasonable to expect scope and enforcement detail to sharpen over time, though we can't state specific future changes as fact — building a flexible, centrally governed disclosure layer now is the more resilient approach regardless of how the rule evolves.

How do we get started if we don't have in-house capacity to handle this quickly?

Start with the inventory step internally if you can, since no one knows your systems better than your own team, then bring in outside help for the architecture and implementation work — building the shared disclosure component, the logging layer, and the governance structure around it.

Does this requirement apply to AI used in recruitment or HR chat tools?

If an HR chatbot or recruitment assistant carries on a real-time, interactive exchange with a candidate or employee, it fits the same pattern as a customer-facing bot and should be reviewed for disclosure the same way, even though the audience is internal rather than a paying customer.