What Article 50(1) requires when a chatbot talks to people
If your team runs a chatbot or AI agent that talks to customers, staff or citizens, Article 50(1) requires the provider to design that system so the people it interacts with are informed they are dealing with an AI system. The only exception is where this is obvious to a reasonably well-informed, observant and circumspect person in the context of use. The risk the provision addresses is simple: people who believe they are speaking to a human may disclose data, rely on advice or make decisions they would otherwise handle differently. The duty sits with the provider, which means the party that develops the system or has it developed and places it on the market under its own name, even if a deployer configures it for a specific customer journey. The timing rule is strict. The information must be clear and distinguishable and given at the latest at the first interaction, and it must meet accessibility requirements under Article 50(5). A notice buried in terms of use, or a label that appears only after the user has typed a question, does not satisfy the wording. Because the requirement is written as a duty to design, the evidence is the system itself: the greeting flow, the interface labels, the voice prompt for telephony channels, the handoff behaviour when a human takes over, and the configuration that stops the bot from presenting itself as a person. A policy stating that the company discloses AI use will not, on its own, show compliance. The hard part is the obviousness test. It is contextual, so the same interface may be obvious in a branded assistant that openly says it is automated and not obvious in a chat window that mimics a human agent. Assessors will expect a documented judgment for each channel and user group, recording why disclosure was or was not treated as unnecessary, who approved that view and when it was last reviewed. Confirm with your legal and product owners which channels, languages and vulnerable user groups are in scope before you rely on the exception, and check the Commission's transparency guidelines for current interpretive guidance.
Which AI interactions fall under the disclosure duty
Article 50(1) applies to a specific set of systems: those intended to interact directly with natural persons, placed on the EU market or used in the EU. The cards below cover the decisions that determine whether a given chatbot or assistant is in scope, and where the two exceptions start and stop.
Provider or deployer for a chatbot
Article 50(1) is a provider duty, so the first question is who designed the system and places it on the market. An organization that builds its own assistant and offers it to customers is the provider. An organization that configures a vendor's chatbot for its own website may be treated as the provider if it puts its name or trademark on the system or substantially changes its purpose. Map each chatbot to a named provider and confirm the role with counsel before assigning the disclosure design to a product team.
Systems built on third-party models
A chatbot that calls a general-purpose model through an API is still an AI system intended to interact with people, so the disclosure duty attaches to the system built on top. The business that wraps the model, adds a persona, and offers the product to users is the party to check. Confirm which entity controls the user interface and the system prompt, because that entity usually holds the design obligation, and write that allocation into the contract with the model vendor.
The obviousness exception
The duty does not apply where the interaction is obvious to a reasonably well-informed, observant and circumspect person in the context. This test is judged from the point of view of the intended audience, not the builder. It tends to fail for voice agents that mimic human speech, assistants embedded in a messaging thread with a human-like name, and any channel where a user may reasonably assume a person is replying. Record the reasoning for each channel rather than relying on a general claim.
The law enforcement exception and its carve-back
Systems authorized by law to detect, prevent, investigate or prosecute criminal offenses are excluded from the disclosure duty. The exclusion does not hold if the system is available for the public to report a crime. A police or fraud-team tool used only by staff may fall outside Article 50(1), while a public-facing reporting assistant does not. Confirm the legal authorization in writing, and list every public entry point that could receive a crime report.
Non-EU providers serving EU users
Article 2 extends the Act to non-EU providers and deployers whose AI output is used in the EU, so a chatbot hosted outside the Union can be in scope when EU users interact with it. Organizations with overseas product teams should identify which channels, languages and markets reach EU residents, including through a global website. Confirm the scope analysis with EU counsel, since the trigger is output use in the Union rather than the location of servers.
How an assessor tests the disclosure duty
This table compares each test an assessor is likely to run against Article 50(1), the evidence it expects to see, and the findings that most often come up. Read each row as a question the assessor will ask of the system as it runs today, not as it was designed.
| Test area | What the assessor checks | Evidence requested and common findings |
|---|---|---|
| Interface as shipped | The live chatbot, voice agent or assistant as end users actually reach it, on each channel and in each language offered | Screenshots or recordings from production builds with dates. Finding: disclosure present in the design files but missing from a mobile app or partner widget. |
| First-interaction timing | Whether the notice appears no later than the first message or spoken turn the user receives from the system | Timestamped transcripts showing where the notice sits in the flow. Finding: the greeting or an automated message runs before the AI notice appears. |
| Disclosure wording and placement | Whether the wording plainly states the user is dealing with an AI system and is distinguishable from other content | Approved copy with version history and placement specifications. Finding: wording such as virtual assistant with no reference to AI, or a notice styled to blend into the page. |
| Accessibility of the notice | Whether the notice can be perceived by users with visual, hearing or cognitive limits, including on assistive technology | Accessibility test results for the notice element and a record of who reviewed them. Finding: notice rendered as low-contrast text or not announced by screen readers. |
| Documented obviousness decisions | Whether the organization relied on the obviousness exception and can show a reasoned, context-specific basis for it | A dated decision record for each interface naming the context and the reasonably well-informed user it was assessed against. Finding: obviousness assumed with no record at all. |
| Law enforcement exception | Whether any system relying on the exception is authorized by law for criminal detection or prosecution, and whether it is available to the public to report a crime | Legal basis, scope statement and access controls. Finding: the exception is claimed for a public-facing reporting tool, which the duty does not exempt. |
| Change control after model or UI changes | Whether disclosure was retested after the model, prompts, interface or hosting changed | Retest records linked to change tickets and release notes. Finding: no evidence of testing after a model swap or UI redesign, so the notice may have been lost without anyone noticing. |
| Disclosure buried in terms | Whether the AI notice relies only on terms of use or a privacy notice the user must find | Comparison of the notice location against the interaction flow. Finding: the only statement is in the terms, which the assessor will not treat as clear and distinguishable at first interaction. |
How to implement the disclosure in a chatbot
This sequence turns the Article 50(1) duty into a documented, tested disclosure in each channel where people interact with an AI system. Each step produces a record that an assessor or market surveillance authority can review.
Inventory every AI interaction point
The product or compliance owner lists every place where an AI system interacts directly with a person: web chat, in-app assistants, voice bots, email replies, messaging integrations and API consumers that show AI output to end users. For each point, record the system name, the operator that provides it, the audience and the first moment a person can interact. The output is an interaction inventory that names each channel and its owner. The step is done when engineering confirms the list matches what is deployed in production.
Classify each point against the obviousness test
For each entry, the compliance lead decides whether the AI nature of the interaction would be obvious to a reasonably well-informed, observant and circumspect person in that context. Document the reasoning, including the typical user, the product framing and the visual or verbal cues already present. Mark any point that relies on the criminal-investigation exception, and have legal counsel confirm that exception applies before relying on it. The output is a classification table with one justified decision per interaction point. Obviousness should not be assumed for a product that sounds or looks human.
Design the disclosure wording and placement
For every point not covered by the obviousness finding, the product and legal teams draft the disclosure text, decide its placement and set the trigger. The text must be clear and distinguishable, must appear at the latest at the first interaction, and must be understandable to the intended audience, including in the languages the product offers. Placement covers the chat header, the first message, the voice greeting or the API response metadata, as the channel allows. The output is a disclosure specification for each channel, approved by the owner of the interaction point.
Build the disclosure into each channel
Engineering implements the approved specification in the interface, the voice flow or the API contract, and ensures the disclosure is not removed by a configuration change, a prompt update or a theme change. Where the system is delivered through a third-party platform or an open-source front end that DeployOpen or the client configures, the build covers the configuration files and templates that control the text. The output is a build record linking each specification to the code, template or configuration version that delivers it. The step is closed when a tester can see the disclosure on each channel in a clean session.
Test the disclosure for accessibility
QA tests each disclosure with assistive technology and standard accessibility checks, covering screen readers for text channels, captions or transcripts for voice channels, contrast, keyboard navigation and mobile layouts. Testers also confirm the disclosure appears before the first meaningful exchange, not after the user has already relied on an answer. Results are recorded as a test report with the channel, the test steps, the observed result and any defect raised. The step is done when every defect is fixed or formally accepted by the owner.
Log the design decision
The compliance lead writes a decision record for each interaction point that combines the inventory entry, the obviousness finding, the wording, the placement, the build reference and the test report. The record names the approver and the date, and is stored in a version-controlled location so later changes can be compared. Organizations often use a wiki or documentation platform for this, which keeps each version and who changed it. The output is a decision record per point that an auditor, a customer or an authority can read without asking the team for context.
Re-test the disclosure on every release
Each release, prompt change, model change or new channel triggers a review of the inventory and a regression test of the disclosure on every affected point. Monitoring tools can help confirm the disclosure is shown in live sessions by reviewing sampled traces, but the test itself must be recorded. The output is an updated test report and, where the interaction point changed, a revised decision record. Confirm with counsel how often reviews should run for your product and whether your sector rules add requirements.
Evidence that shows the disclosure works
An assessor testing Article 50(1) will want proof that the disclosure exists at every entry point, that the team reasoned about when it can be omitted, and that it still works after changes. The cards below cover the artifacts that answer those questions and the routines that keep them current between reviews.
Entry point captures at release
Keep dated screenshots and screen recordings of every place a person meets the AI system: web chat, mobile app, voice channel, email reply and embedded widget. For each capture, show the disclosure as a user sees it on first contact, not only in the source code. Record the release identifier beside each capture so a reviewer can match it to the build that was live. Re-capture whenever the interface, onboarding flow or language variant changes, because a disclosure that sits below the fold or disappears after a redesign is a common gap.
Obviousness analysis per use case
Article 50(1) allows the disclosure to be skipped only where it is obvious to a reasonably well-informed, observant and circumspect person in the context. Write one short analysis per use case that states the context, the likely user, what the interface shows and why an informed person would or would not recognise the AI. Where you rely on the exception, have legal counsel review it and record the reviewer and date. Revisit each analysis when the use case changes, such as a new audience or a new channel.
Design specification and accessibility results
The design specification states where the notice appears, its wording, how it is distinguished from other content and when it is first shown. Attach accessibility test results for the notice, including screen reader output, keyboard navigation, contrast and captions for voice interfaces. Article 50(5) requires the information to be clear, distinguishable and accessible, so an assessor will check these results against the specification. Confirm the accessibility standard your organization uses for testing, since the Act refers to accessibility requirements without fixing a test method here.
Versioned history of notice wording
Store the notice text in a version-controlled wiki or document system so every change records what changed, when and by whom. Approved wording should be traceable to a review, and it should be possible to compare any two versions and roll back if a change weakens the notice. XWiki supports this kind of page history, and BookStack limits who can edit or approve pages through role-based permissions. Confirm the retention period your audit requires, since the history is only useful if it is kept.
Automated probing and test logs
Run scripted probes that ask the system whether it is an AI, whether it is a human, and what happens after a user says they want a person. The garak scanner writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a weakness, which is useful evidence for the probe set. Keep the probe configuration and model version with each run. Langfuse traces can show, for production conversations, whether the disclosure was delivered at the first interaction. Schedule re-runs after every model, prompt or interface change, and keep the logs for the period your assessor will sample.
What meeting Article 50(1) costs in money and effort
This table lists the cost components of designing AI interaction disclosure, who is paid for each, whether it is one-time or recurring, and what pushes it up. No fee or duration figures are supplied for this duty, so use the drivers column to scope a quote and ask each bidder to price every row separately.
| Cost component | Who is paid or who carries it | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Interface engineering | Internal product or front-end team, or an implementation partner | One-time build, then recurring when screens change | Number of entry points such as web widget, mobile app, voice channel and email auto-replies |
| Legal and compliance review of wording | In-house counsel, external counsel or compliance lead | One-time for initial wording, recurring on each material change | Number of languages, jurisdictions where users sit, and how often the bot's scope changes |
| Testing and accessibility checks | Internal QA, accessibility specialists or a testing partner | One-time baseline, recurring at each release | Number of channels, assistive technologies in scope, and how many conversation flows must show the notice |
| Logging and evidence storage | Internal platform team; storage and hosting costs in your own infrastructure | Recurring, scales with usage | Conversation volume, retention period set by your policy, and how many versions of the notice you must prove existed |
| Ongoing re-testing after model or prompt changes | Internal engineering or a retained testing provider | Recurring | Frequency of model swaps, prompt edits, new tools or agents, and new languages |
| External review | Independent auditor, assessor or legal reviewer. DeployOpen prepares evidence but does not issue reports | Usually one-time per review cycle, recurring if reviews are scheduled | Scope of the review, how many systems are covered, and whether the review is part of a wider AI Act or ISO/IEC 42001 assessment |
| Self-hosted open-source components | Licence spend is reduced where tracing, versioning and access control tools are open source; you still pay for hosting, operations and support | Recurring infrastructure and operations cost | Choice of self-hosted versus managed services, storage sizing, and the staff needed to run the stack |
Who owns the disclosure duty, who helps and who checks
Your organization owns the Article 50(1) duty. As the provider of a chatbot or other AI system that interacts directly with people, you decide whether the system needs a disclosure, where it appears, and how it is worded. Those decisions carry legal accountability, so they should be made by named people who understand the product, its users and the context of use, not delegated to a vendor or a contractor.
- Design decision: Decide whether each interaction channel is covered, and record whether you rely on the obviousness exception for any of them.
- Wording and placement: Approve the exact text, its language versions and its position at the first interaction.
- Accessibility review: Confirm that the notice meets the accessibility requirements that apply to your users.
- Exception ownership: Document who judged the law enforcement exception and on what basis, if it is claimed.
- Governance record: Keep the approval, the rationale and the review date in your AI governance records.
Before sign-off, confirm with legal counsel how the notice interacts with other transparency duties in Union or national law that may apply to the same product.
An implementation partner can build the disclosure into the system and prepare the evidence that it works. Under a fixed-scope engagement, DeployOpen would implement and test the notice inside your own infrastructure, but the decisions described in the previous tab stay with your organization, and DeployOpen does not issue reports, attestations or certificates.
- Build: Implement the notice in the interface, API responses or voice flow you operate, with settings you can change without redeploying where your platform supports it.
- Test: Run scripted and adversarial tests to check that the notice appears at the first interaction and cannot be skipped in the normal flow.
- Evidence preparation: Capture screenshots, configuration exports, test records and trace logs that show the disclosure in operation.
- Logging: Set up tracing so that each session records when the notice was shown, using a self-hosted tool such as Langfuse.
- Handover: Document the setup and the test procedure so your team can rerun it after changes.
Ask any partner to state in writing which of these tasks it performs and which remain with your team.
Independent parties check the disclosure, but their role is different from that of your team or a partner. Depending on your situation, the check may come from a national market surveillance authority, from an independent reviewer you engage, or from an internal audit function that is separate from the team that built the system. Only that independent party can give an opinion on conformity.
- Regulator review: A market surveillance authority can request documentation and test the system in practice.
- Independent review: An outside reviewer can read the notice, the design rationale and the test records and report findings to you.
- Internal audit: Your audit function can test the control if it has no role in building it.
- Independence line: A firm that designed or built the disclosure should not be the only party that declares it compliant.
- Scope of opinion: Ask any reviewer exactly what it will examine and what its conclusion will and will not cover.
Confirm with the relevant authority in your Member State who is competent for your system before you plan the review.
Open-source tools that produce disclosure test evidence
Which open-source tool can test whether a chatbot discloses that it is an AI?
garak is the closest fit for probing a language model's behaviour, since it is an open-source scanner that sends adversarial prompts to a model and records how it responds. It is licensed under Apache-2.0. Its probes cover hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks, so you can build custom probes that ask the system whether it is human and check whether the answer or the surrounding notice meets your disclosure wording. garak does not decide whether a disclosure is obvious in context, and it does not test the user interface where the notice appears. Treat its output as one input to your test file, and confirm its current probe library in the project's garak README.
What does a garak JSONL report prove about disclosure testing?
The JSONL report records every attempt and evaluation that garak ran, and the hit log lists only the attempts that found a vulnerability. Together they show which prompts were sent, which responses came back and which failed your check on a given date. That record is useful evidence of a repeatable test run. It does not show that a notice was visible to users, because it captures model output, not the rendered screen. Keep the report with the model version, probe configuration and date, so an assessor can match each run to the system that was in production at that time.
How does Langfuse show when a disclosure notice appeared?
Langfuse is an MIT-licensed observability platform that records traces. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. If your application writes the disclosure as a span or metadata field, such as a notice version identifier attached to the first assistant turn of a session, the trace shows when that notice was served to a user. Confirm with your engineering team that the notice is logged at the point it is displayed, not only in the prompt template, because a trace of the template does not prove the user saw it.
Should trace data include personal information from chat sessions?
Usually it should be minimized. Traces can hold inputs, outputs and metadata, and chat content may include personal data, so the GDPR applies to that logging in addition to the AI Act. Record the notice identifier, session timing, model version and an anonymized session reference, and decide with your data protection officer which message content is stored, for how long and who can read it. Masking or redacting fields before they reach the trace store is an engineering decision you should document. The AI Act does not require you to store full transcripts to evidence disclosure.
How does XWiki keep a record of disclosure wording changes?
XWiki is an LGPL-2.1-or-later wiki that keeps every change to a page under version control. It records what changed, when and by whom, lets users compare any two versions and roll back to an earlier one. Use it to hold the approved wording of each disclosure notice, the language for each channel and language, and the decision record that explains why a particular notice was judged necessary or obvious. When a regulator or assessor asks what the chatbot said on a given date, the page history shows the wording in force. XWiki supports this evidence, but the organization still needs its own approval process and sign-off.
How does BookStack control who can edit disclosure text?
BookStack is an MIT-licensed documentation platform where a user's abilities come from the roles assigned to them. Permissions can be overridden per role at the shelf, book, chapter or page level. You can place disclosure notices in a restricted book, allow product and legal reviewers to edit, and limit everyone else to read access. That gives you a clear record of who holds edit rights at any time, which is the access evidence an assessor will ask for. Confirm the role configuration you rely on against the current BookStack roles and permissions documentation, and review it on a schedule, since access drifts as staff change.
Can these open-source tools alone satisfy Article 50(1)?
No. Article 50(1) is a design duty on the provider: the system must be built so people know they are dealing with an AI, unless that is obvious to a reasonably well-informed, observant and circumspect person in context. Tools help you produce evidence that the design was tested, changed under control and operated as described, but they cannot decide whether a notice is clear, distinguishable and given at the first interaction. Those judgements belong to your product, legal and compliance owners. Read the Commission's transparency guidelines alongside any tool plan.
Who should set up these tools and what does that cost?
The organization owns the controls and the evidence. An implementation partner such as DeployOpen can install and configure self-hosted tools inside your own infrastructure, connect garak runs and Langfuse traces to your release process, and set up the wiki and documentation roles. Cost depends on the number of AI systems in scope, how many environments need testing, how much logging you keep, and how much integration work your stack needs. These are one-time setup costs plus recurring hosting, maintenance and review effort. Most engagements are fixed-scope, so ask for a written scope listing systems, environments, tools and deliverables before work starts. Only an independent assessor or auditor issues any report or certificate.
Where chatbot disclosure usually fails
Most chatbot disclosure failures are not missing notices but notices that are placed, timed or recorded badly. Each gap below shows where a provider's design can drift from what Article 50(1) expects, and the check that closes it.
Disclosure only in terms of service
Some providers state that the assistant is AI in the terms of service or a help article, then assume that satisfies the duty. Article 50(1) asks that the people interacting with the system are informed, which means the information has to reach the person in the interaction itself. Check that a user who never opens the legal pages still sees a clear statement that they are talking to an AI system before the conversation begins.
Notice shown after the first message
A banner that appears after the user has already typed a question, or a disclosure that loads below the fold, may arrive too late. Article 50(5) requires the information to be given at the latest at the first interaction. Test the flow on a fresh session and a mobile screen, and confirm the notice is visible before any input is accepted.
No record of the obviousness judgment
Providers sometimes skip the notice because they believe the AI nature is obvious in context. That belief is a judgment against a reasonably well-informed, observant and circumspect person, and it needs a written rationale. Record the context, the user groups, the test applied and the reviewer, so an assessor can see why the notice was omitted.
Disclosure lost in voice and API channels
A web chat may show a clear label while the same model answers through a telephone voice bot, a mobile SDK or a partner API with no label at all. Each channel that exposes the system to a person needs its own disclosure, spoken or embedded in the response, and the integration team should own that requirement. Test every channel and every customer-facing integration before release.
Unchanged notices after model or prompt updates
A disclosure written for one assistant can stop matching what it does after a new model, a new persona or a new scope of tools. A notice that describes a human-sounding agent, or that omits a new capability, weakens the information the user receives. Tie notice text to the release process so a change to the model, system prompt or persona triggers a review of the disclosure.
No evidence trail
Without stored versions of the notice, test results and channel checks, a provider cannot show an assessor what users saw on a given date. Keep the notice text under version control with approval records, and retain screenshots or test logs from each release. Ask whether your current tooling can answer, for any past session, which notice version was displayed.
How much work is Article 50(1) and can we do it ourselves
Does Article 50(1) apply if we only configure a vendor's chatbot?
It depends on who places the system on the market under their own name, so confirm the provider role with counsel before assuming the duty sits with the vendor. Article 50(1) is addressed to providers, meaning the organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its name or trademark. If you switch on a vendor's assistant inside an internal tool, the vendor may hold the provider duty while you hold deployer duties under other paragraphs. If you build a customer-facing assistant on a third-party model, configure its persona, and release it under your brand, you are likely the provider. Record the role for each chatbot in your AI system inventory and keep the reasoning with it.
What should we document to support the obviousness exception?
Keep a dated written rationale for each interface that relies on the exception, tested against the context in which people meet it. The exception applies when the AI interaction would be obvious to a reasonably well-informed, observant and circumspect person in that context. The Act does not prescribe a record format, so agree the set with counsel. A practical record usually includes:
- A description of each entry point and the user journey, with dated screenshots
- The audiences likely to use the interface, including vulnerable groups you serve
- Usability test results showing whether users recognized the AI nature without a label
- Version history of the wording and design, so you can show what was live on a given date
Read the Commission's transparency guidelines of 20 July 2026 before you finalize the rationale.
How long does it take to meet Article 50(1)?
The Act sets no fixed duration for this work, so the timeline depends on how many interfaces you have and how much design and testing each one needs. Confirm the schedule against your own plan and any partner's written scope. The main drivers are:
- The number of touchpoints where people interact with AI, such as web chat, voice, email agents and in-app assistants
- Whether disclosure already exists and needs only wording and placement changes, or whether flows must be redesigned
- The languages and accessibility checks required under Article 50(5)
- How much testing you run to support the obviousness argument
Disclosure that is a clear label at first interaction usually moves faster than a redesign of a multi-step agent. Ask any partner for a plan that lists each interface, the work per interface, the test approach and the dependencies on internal reviews.
What do product, legal and engineering each need to contribute?
Product owns the user journey and decides where disclosure appears, legal owns the role determination, the exception reasoning and the wording, and engineering builds and tests the disclosure in each channel. Product should map every point where a person can meet the AI, including support handoffs and automated follow-up messages. Legal should review the wording in every language you serve and confirm whether the law enforcement exception could ever apply. Engineering should make the disclosure clear, distinguishable and accessible, show it no later than the first interaction, and log the event so it can be evidenced later. A named owner for each interface prevents gaps when a team ships a new channel.
Can a partner prepare the evidence for Article 50(1)?
Yes, a partner can prepare systems and evidence, but the organization still owns its controls and the legal conclusion. DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it can prepare the technical and documentary evidence that supports a disclosure position. DeployOpen does not issue audit reports, attestations or certifications. Article 50(1) has no certificate, and national market surveillance authorities enforce the Act for AI systems. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
What does the 2 August 2026 date mean for systems already in use?
Systems already in operation are expected to meet the transparency duty from 2 August 2026, because the rest of the Act applies from that date under Article 113. The Commission lists informing people when they interact with an interactive AI system, such as a chatbot, among the transparency requirements that apply from 2 August 2026. The supplied timeline does not give Article 50(1) a separate grace period for existing systems, so confirm that position with counsel. The 2026 amendment moved the high-risk dates, so check your sequencing against the current text in the consolidated Regulation. The separate marking duty in Article 50(2) has its own date, which is covered on its own page.
Which open-source tools can show that users were told?
Observability and version control tools can show what was displayed and when, but confirm that your chosen platform can record the disclosure event you need. Langfuse captures each trace of a request, including inputs, outputs, timing and metadata, so you can log a disclosure event and its version as metadata for each session. XWiki keeps every change to a page with the time and author, and lets you compare versions and roll back, which helps prove what wording was live. BookStack lets you restrict who can edit approved disclosure text through role permissions at the book or page level. Test each tool in your environment before relying on it as evidence.
Does the law enforcement exception cover our chatbot?
Probably not, unless the system is authorized by law to detect, prevent, investigate or prosecute criminal offenses. The exception is narrow. The duty does not apply to such systems, but it still applies if the system is available for the public to report a crime. A customer service assistant, sales bot or HR helper does not fall under this exception because it is not a law enforcement tool. Confirm the legal basis for any system that claims the exception, and document the authorization and the public reporting feature so that the position can be checked later.
How DeployOpen prepares disclosure evidence
DeployOpen starts every Article 50(1) engagement with a written scope that names the chatbots, voice agents and other interactive AI systems in the client's estate, the channels they run on, and the interfaces where a person first meets them. The scope also records who owns the disclosure text, who approves changes to it, and which obviousness and law enforcement positions the client has decided to rely on, with the reasoning written down. Deliverables and timelines are agreed in that document before work begins, and the quote follows from it. DeployOpen implements the disclosure in the client's own cloud accounts or data center, so the notice, its placement and its logging stay under the client's control.
Evidence is built with self-hosted tools inside the same environment. Langfuse can record traces of each session, so the team can show that the AI disclosure appeared at the first interaction, and XWiki keeps the approved disclosure wording under version control with a record of who changed it and when. BookStack can hold the policy, the scope decisions and the owner sign-offs, with role-based permissions limiting who may edit them. Where a chatbot takes a voice or other non-text channel, DeployOpen also tests whether the notice is clear, distinguishable and accessible under Article 50(5). Retesting is part of the work: when a model, prompt, channel or interface changes, DeployOpen reruns the checks and updates the evidence set. DeployOpen prepares these systems and this evidence but does not issue audit reports, attestations or certifications. Where a regulator, auditor or notified body needs an independent view, the client engages that party directly.
