Does the EU AI Act require a RAG assistant to say it is AI?
Yes, if the assistant interacts directly with people, unless it is obvious from the context that they are talking to an AI system. Article 50(1) requires providers to design the system so that people are informed they are interacting with an AI system. 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. A team putting a document-grounded assistant in front of customers or citizens should treat that date as the working deadline for the disclosure, and should confirm the current wording in the Commission's transparency guidelines with its legal counsel before go-live.
The duty is split between roles. The provider designs the system so the disclosure can happen, which in a self-hosted stack usually means the team that builds and configures the assistant, for example the interface settings, the system prompt and the first screen a user sees. The deployer is the organization that puts the assistant in front of people under its own name and controls how it is presented. Many organizations hold both roles at once, so the practical question is who owns the greeting text, the banner, and the wording shown before the first question is answered. Article 50(5) also requires the information to be clear, distinguishable, given at the latest at the first interaction, and accessible. Confirm these points against the Article 50 text on EUR-Lex.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, changed the dates for the high-risk rules but did not change this transparency duty. A RAG assistant that answers from internal documents is not automatically high risk, so the disclosure question should be answered on its own terms. Document the disclosure wording, where it appears in each channel, and who approved it, and keep that record with the configuration of the assistant. Whether a particular deployment falls under Article 50 or under any other category is a conclusion for the organization and its advisers to reach with the facts of their own case.
Which Article 50 duties map to which build decisions
This table maps each Article 50 duty that can reach a RAG assistant to the build decision it drives and the settings to check in Open WebUI, Dify, RAGFlow or AnythingLLM. Read it as a checklist: the first two rows apply to any assistant facing customers or the public, while the last rows show where the duty narrows or falls away.
| Article 50 duty | What the assistant must do | How to configure it |
|---|---|---|
| Article 50(1): disclose AI interaction | Tell people they are interacting with an AI system, unless this is obvious to a reasonably well-informed, observant and circumspect person in context. The provider designs the system to do this. | Set an opening notice in the welcome message or first system prompt output, and confirm the notice is shown before the first question. Check the platform's welcome and branding options in Open WebUI, Dify or AnythingLLM. Confirm whether the chosen platform version supports this without custom front-end work. |
| Article 50(5): clear, distinguishable and at first interaction | Make the AI notice clear and distinguishable, given at the latest at the first interaction, and meet accessibility requirements. | Place the notice in the visible interface label near the input box, not only in a terms page. Test the label with a screen reader and at small widths. Confirm the chosen interface supports accessible labels. |
| Article 50(5): persistent labeling | Keep the AI status visible across the session so users who return or switch windows still know they are talking to an AI. | Use interface labels, assistant names that include the AI status, and a persistent header or footer where the platform allows it. In Open WebUI, check whether custom branding is permitted under the license clause on branding removal. |
| Article 50(4): labeling AI-generated text on public-interest matters | Deployers that publish AI-generated text to inform the public on matters of public interest must disclose it, unless it has undergone human review or editorial control with a named person holding editorial responsibility. | Add a disclosure line to every published answer or export, or route answers through a review queue before publication. Record who holds editorial responsibility. Confirm with counsel whether a chat answer shown only to a single user counts as published. |
| Article 50(4): deepfake disclosure | Applies to image, audio or video deepfakes. A text RAG assistant usually does not generate these. | If a platform feature or plugin adds image, audio or video generation, disclose that content is artificial and review the interface labels. Keep such features out of the public assistant unless the duty is designed for. |
| Article 50(3): emotion recognition or biometric categorisation | Deployers of these systems must inform exposed people and process personal data under the applicable data protection rules. A text RAG assistant does not perform these functions. | Out of scope for a text RAG assistant. Confirm in the design review that no connected tool, plugin or voice feature performs emotion recognition or biometric categorisation before closing this row. |
| Crime detection exception | The duty does not apply to systems authorized by law to detect, prevent, investigate or prosecute criminal offenses, unless they are open to the public to report a crime. | Confirm with legal counsel before relying on this exception. If a public-facing assistant accepts crime reports, the exception does not apply. |
How the duty falls on the provider and the deployer
Under Article 50(1), a provider must design an AI system intended to interact directly with natural persons so that those persons are informed they are interacting with an AI system. The duty is about design: the interface, the first message and the disclosure text have to be built in, not left to whoever publishes the assistant later. The exception applies only where the AI nature is obvious to a reasonably well-informed, observant and circumspect person in the context, and that test is hard to meet for a general chat box on a public website.
- Interface design: Build the disclosure into the first screen or first reply, so it is shown at the latest at the first interaction, as Article 50(5) requires.
- Accessibility: Make the notice clear, distinguishable and accessible to users with disabilities.
- Branding controls: If you use Open WebUI, the Open WebUI License clause 4 restricts altering or removing its branding beyond the listed exceptions, so a disclosure cannot be added by hiding the product's own identity, and white-label changes may need an enterprise license or written permission.
- Dify modifications: The Dify license forbids removing or modifying the logo or copyright information in the console and restricts operating a multi-tenant service without authorization, which limits what a builder can change in a shipped product.
- Logging: Plan records of how the notice was shown, since Article 12 and Article 19 logging duties may apply to high-risk systems.
Confirm with counsel whether the assistant is high risk under the Act, whether the Digital Omnibus dates change your timeline, and which license terms limit the interface changes you need.
A deployer is the organization that uses the AI system under its own authority. For a RAG assistant that answers customers or the public, the deployer is usually the party that publishes the assistant on its website, portal or app. Article 50 places duties on deployers beyond the chatbot notice, especially for generated content. Article 50(4) requires deployers of AI that generates or manipulates image, audio or video deepfakes to disclose that the content is artificial. It also requires disclosure of AI-generated or manipulated text published to inform the public on matters of public interest, unless the text has undergone human review or editorial control and someone holds editorial responsibility.
- Public-interest text: Answers on public matters, such as published guidance or official procedures, may need a disclosure unless an accountable editor reviews them.
- Editorial responsibility: Name the person or team that holds it, and record the review.
- Deepfakes: A text-only assistant is unlikely to create deepfakes, but voice or avatar features built on it would fall under Article 50(4).
- Penalties: Article 99 sets fines of up to EUR 15 million or 3% of worldwide annual turnover for most operator obligations, whichever is higher.
- Enforcement: National market surveillance authorities enforce the Act for AI systems.
Confirm with counsel which of your answers count as public-interest text and who signs off on editorial control.
When an organization builds its own RAG assistant on open-source components and publishes it, it often holds both roles at once. It designs the system, which makes it a provider, and it puts the system into service under its own name, which makes it a deployer. The duties stack. The organization cannot argue that the vendor of Open WebUI, Dify or AnythingLLM carries the disclosure duty, because the component licenses govern the software while the Act governs the system the organization puts on the market or into service.
- Two sets of duties: Design the notice as a provider and apply the deployer duties for generated public-interest text in the same project.
- Component choice: The chosen platform, model and vector store all feed into the system you are responsible for documenting.
- Documentation: Keep a single file that shows the notice text, its placement, the review owner and the change history.
- Model provider: If you use a general-purpose model from another provider, the Act's rules for that model still apply to the provider, so confirm the contract terms that cover transparency.
- Scope of the Omnibus: Regulation (EU) 2026/1744 changed some timelines, so check which dates apply to your system.
Confirm with counsel how the provider and deployer roles divide when an outside integrator builds the assistant for you.
A SaaS vendor that embeds a RAG assistant for its own customers usually acts as the provider of the feature inside its product, while each customer acts as a deployer when it offers the feature to its own users. This setup has two layers of license and disclosure risk. The vendor must build the notice into the product, and it must make sure customers can keep it in place. Dify's license is especially relevant here, because it restricts operating a multi-tenant service from the source code without authorization, and one tenant means one workspace under that license.
- Multi-tenant licensing: Confirm whether the Dify Enterprise terms or another route fit a shared product before you ship.
- Branding in the product: Open WebUI branding limits may prevent a vendor from rebranding the interface and adding its own disclosure without permission.
- Customer configuration: Give customers a supported way to set the notice text and placement, and record their choices.
- Contract terms: State who writes the notice, who reviews answers and who handles incidents in the customer agreement.
- Evidence: Keep logs that show the notice appeared at the first interaction for each tenant.
Confirm with counsel and with each license holder how the multi-tenant and branding clauses apply to your product before any customer-facing release.
Which open-source platforms fit a disclosed customer-facing assistant
When a RAG assistant talks to customers or the public, the platform choice affects how easily the AI disclosure can be built into the interface and what the license allows you to change. The four options below differ in license terms, tenancy model and identity features, so each needs a check before the disclosure text is customized.
RAGFlow for document-grounded answers
RAGFlow is an open source retrieval-augmented generation engine under Apache-2.0, and its document parsing and citation features suit assistants that must show where each answer came from. For Article 50 purposes, the disclosure can sit in the chat header and first message, while the citations give users a way to check content. Confirm that the parsing pipeline handles your file types, and confirm how the interface lets you insert the disclosure text and label AI-generated answers before you rely on it.
AnythingLLM for workspace-based assistants
AnythingLLM is licensed under MIT and organizes documents and chats into workspaces, which can map to one public-facing assistant per product or service line. The MIT license places few restrictions on changing the interface, so the disclosure can be adjusted to match the customer journey. Confirm how workspaces separate document collections and conversation history, and whether the access controls meet your identity requirements for any authenticated part of the assistant.
Dify and its multi-tenant restriction
Dify is an LLM application platform for RAG pipelines and agents, but it is licensed under a modified Apache License 2.0. The license forbids using the source code to run a multi-tenant environment without written authorization, and a tenant here means a workspace. Set SECRET_KEY before first use, because changing it later logs out all users, and route outbound requests through the SSRF proxy so requests to internal and private IP ranges are blocked. Confirm the license scope with Dify before you offer the assistant to multiple customer organizations.
Open WebUI and its branding clause
Open WebUI is distributed under the Open WebUI License, which restricts altering or removing its branding in deployments above 50 users in any rolling 30-day period unless an exception applies. A public assistant can exceed that count quickly, so the disclosure must sit alongside the branding rules rather than replace them. The platform documents SSO through OIDC and LDAP, SCIM 2.0 provisioning and role-based access, which helps with staff-facing controls. Confirm with counsel whether the license permits your disclosure wording and whether an enterprise license is needed.
How the disclosure, logs and citations work together in the build
The build should treat disclosure, logging and citations as three separate controls that work on the same request. The first is the notice: under Article 50(1), the provider must design the system so that people interacting with it are informed they are talking to an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person in context. In a RAG assistant that faces customers, the practical answer is a first-turn notice shown before or at the first message, plus a persistent AI label in the chat header. Under Article 50(5), that information must be clear, distinguishable and accessible. Confirm with your counsel whether the notice text and placement meet that test in each channel, including embedded widgets and mobile views, and check whether your chosen front end (Open WebUI, AnythingLLM or Dify) lets you set these elements without changing protected branding.
Citations do a different job. They do not satisfy Article 50 by themselves, but they let users check each answer against the source document, which supports the accuracy and information-integrity goals a regulator and your own risk owners will ask about. Configure the retrieval layer so every answer returns the document title, section and version it drew from, and so the citation resolves to the current source. Logging is the third control. Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your assistant is high-risk is a classification question, not a design choice. A transparency-only assistant may fall outside the high-risk categories, but you must confirm this with counsel against the Annex III categories and the 2026 amendment, which moved Annex III high-risk obligations to 2 December 2027. Record prompts, retrieved chunk identifiers, cited sources and the notice shown, and set retention in line with your legal review, not only with the six-month figure.
Evidence auditors and regulators ask for
This table lists the artifacts a provider or deployer should be able to produce when asked how a RAG assistant tells people they are talking to AI, which component generates each one, and what it does not prove. Read each row as a request to the implementation team, and treat every artifact as internal evidence that independent reviewers may still question.
| Evidence item | Where it comes from | What to confirm before relying on it |
|---|---|---|
| Disclosure text and placement | Written notice kept in the document register, plus the configured welcome message or banner in Open WebUI or Dify | Wording is clear, appears at the latest at the first interaction, and is reviewed for accessibility |
| First-interaction screenshots by channel | Captured from the web app, embedded widget, mobile view and any messaging channel the assistant uses | Each channel shows the notice before any answer, including after a session reset |
| System prompt and branding export | Configuration export from Open WebUI admin settings or Dify app configuration, stored under version control | Prompt states the assistant is an AI system and branding changes match the Open WebUI License terms |
| Interaction logs and retention settings | Request and response logs from Langfuse or LiteLLM, plus the retention policy applied to the store | Logs record whether the notice was shown and retention meets any longer period set by other law |
| Citation samples | Sample answers exported from the assistant with source links and chunk identifiers from the document register | Citations resolve to the current approved version of each source document |
| Article 50 role analysis | Written memo from the legal or compliance owner mapping whether the organization is provider, deployer or both | Analysis covers the model provider, the platform vendor and any customization made in-house |
| Code of Practice signature position | Written statement of whether the organization signs Section 2 of the Code of Practice on Transparency of AI-generated Content | Signature status is confirmed with the Commission, since each section must be signed as a whole |
What tooling alone does not satisfy
A RAG assistant can ship with citations, a disclosure banner and a branded interface, and still fall short of Article 50. The obligations turn on legal roles, scope, signed commitments and accessibility testing, which a platform setting cannot settle for you.
Banners do not settle scope
A disclosure banner tells users they are talking to AI, but it does not decide whether the system is in scope of the AI Act, whether it is high-risk, or which article applies. Those questions depend on the intended purpose, the sector and the way the assistant is used. Record the scope decision and the reasoning in writing before the banner is designed, and revisit it when the use case changes.
Branding changes need a role analysis
Whether you are the provider or the deployer of a RAG assistant decides who must design the disclosure and who must deliver it. Changing a logo or product name in an open-source interface does not answer that question. If you build on Open WebUI, Dify or AnythingLLM and offer the assistant to others, confirm your position in the chain with counsel, and check the license terms that govern branding and multi-tenant use before you publish.
Citations do not prove accuracy
Source links show where an answer came from, not that the answer is correct or that the cited passage supports it. A retrieved chunk can be outdated, out of context or misread by the model. Article 50 concerns disclosure that the user is interacting with AI, so citations help users check content but do not replace that disclosure. Test answer quality against a reviewed question set and keep retrieval logs so you can show how an answer was produced.
The Code of Practice needs a signature
The Commission's Code of Practice on Transparency of AI-generated Content asks signatories to commit to labeling deepfakes and certain AI-generated text, and each section must be signed as a whole. A platform cannot sign on your behalf. Decide which sections apply to your assistant, confirm the commitments with your legal team, and file the signature through the Commission process before you rely on the Code as evidence.
Accessibility must be tested
Article 50(5) requires the disclosure to be clear, distinguishable, given at the latest at the first interaction, and to meet accessibility requirements. A notice that is visible on a desktop can fail with a screen reader, on a small phone or in a high-contrast mode. Test the disclosure with assistive technologies and real user journeys, including embedded widgets and mobile apps, and record the results. Do not assume that a default theme meets the requirement.
What do buyers ask before adding AI disclosure to a RAG assistant?
How much of the total cost is the AI disclosure itself?
The disclosure is usually a small share of the total spend, because most of the cost sits in the assistant build it is attached to. The notice is a visible statement shown at the first interaction, so the work covers wording, placement, and checks that it appears on every entry point. The larger costs are the RAG pipeline, permission-aware retrieval, evaluation, and ongoing operations. Ask any quote to split out these lines: legal reading of the Article 50 duties, the interface change in the chat front end, accessibility testing of the notice, and regression testing after each platform upgrade. The first design and test are one-time work. Upgrades and periodic review of the wording recur. DeployOpen quotes follow from a written scope, so the disclosure should appear as its own line item.
Can an open-source chat interface be changed to show an AI notice?
Often yes, but check the license before changing the interface. Open WebUI's license restricts altering or removing Open WebUI branding in deployments above 50 end users in any rolling 30-day period, unless an exception applies, such as an enterprise license or written permission. Whether an added notice counts as altering branding is a licensing question to confirm with counsel and the license text. Dify's license forbids removing or modifying the logo or copyright information in the console, and it also restricts operating multi-tenant services from the source code. Ask the implementation partner to document each change, keep it in version control, and retest it after every upgrade. If the assistant is a custom front end on your own code, the license question may not arise for the notice itself.
What does our internal team need to provide for the disclosure work?
Your team needs four roles in place before the build starts. Legal or compliance counsel decides whether the Article 50 duty applies to each use, whether the obviousness exception is relied on, and which fine tier applies. A content owner approves the exact wording, the audience, and the point at which the notice appears. An accessibility tester checks that the notice meets the accessibility requirements in Article 50(5), using your own assistive technology and test procedures. An engineering owner signs off the interface change and its rollback path. Each role also needs time for review rounds, because wording and placement often change after the first test. Name these people in the written scope so the implementation timeline depends on their availability, not on assumptions.
How long does adding an AI disclosure take?
No duration is given here. Implementation work is fixed-scope, so the timeline is set in a written agreement that states scope, deliverables, and milestones before work starts. The main drivers are the number of entry points (web page, intranet, mobile app, embedded widget), whether the interface is custom or a packaged chat product, how many legal review cycles your counsel requires, and how many accessibility test rounds are needed. A disclosure on one entry point with approved wording moves much faster than a change across several products with translations. Ask the partner for a milestone plan that lists your review steps as dependencies, and ask what happens to the schedule if wording changes after testing.
What is the maximum fine for breaching the AI Act transparency rules?
Under Article 99 of the EU AI Act, the ceilings are EUR 35 million or 7% of worldwide annual turnover for prohibited practices, EUR 15 million or 3% for most operator obligations, and EUR 7.5 million or 1% for supplying misleading information to authorities, whichever is higher. The Article 50 duties to inform people they are interacting with an AI system fall within the operator obligation tiers, so the 15 million or 3% ceiling is the one to plan around, but confirm the tier with counsel for your specific use. National market surveillance authorities enforce the Act for most AI systems. The chatbot disclosure duty is among the transparency requirements the Commission lists as applying from 2 August 2026, so check the dates against the current consolidated text before scoping.
Can our implementation partner sign the Code of Practice on Transparency for us?
No. Signing is a decision your organization makes, and a partner cannot sign on your behalf. The Commission's Code of Practice on Transparency of AI-generated Content includes a section on deployers' labeling of deepfakes and AI-generated text, and the Commission's FAQ says each section must be signed as a whole. Your leadership, or the person authorized to bind the organization, decides whether to sign after reviewing the commitments with counsel. DeployOpen can help you prepare the disclosure, the labeling and the evidence that supports the commitments you make. It does not issue audit reports, attestations or certifications, and independent auditors and certification bodies perform those assessments.
Does the disclosure duty apply if only our employees use the assistant?
It depends on the facts, so confirm it with counsel. Article 50(1) applies to AI systems intended to interact directly with natural persons, and employees are natural persons. The duty does not apply where it is obvious to a reasonably well-informed, observant and circumspect person in the context. An internal tool that staff open from a labeled corporate workspace may fall under that exception, but a tool that staff reach through a generic web address, or one used by contractors and visitors, may not. Illustrative example: an HR policy assistant on the staff intranet, with a visible AI label on its home screen, is a different case from the same assistant opened to external candidates. Document the reasoning in the scope, because the answer changes the wording, placement and testing.
What to confirm with counsel and the vendor before launch
Before a RAG assistant answers customers or the public, the first item to settle with counsel is the role analysis under Article 50. Article 50(1) places the duty to inform people on the provider of an AI system intended to interact directly with natural persons, and the deployer carries its own obligations for generated content under Article 50(4). If your organization builds the assistant and offers it to others, or substantially modifies a product it did not build, counsel should map who is the provider and who is the deployer for each component, from the model choice to the chat front end. Confirm whether the assistant is an interactive system counted under Article 50(1), and whether the exception for cases where the AI nature is obvious to a reasonably well-informed, observant and circumspect person could apply. Do not rely on that exception for a public chat window without a documented reason. Read the Commission's guidelines on the transparency obligations, published on 20 July 2026, directly rather than relying on summaries, since they address these role questions in detail.
Next, confirm the software licenses, because they can limit how the disclosure is presented. Open WebUI's license, in clause 4, prohibits altering or removing its branding for most deployments, with exceptions tied to user counts, written permission or other listed cases. Ask the vendor or your counsel whether a customer-facing disclosure banner, a custom product name or a white-labeled interface changes your position, and whether an enterprise license or written permission is needed. Dify's license restricts operating a multi-tenant service from its source code without written authorization and forbids removing or modifying logo and copyright information in the console. Both points matter if the assistant is embedded in a product for external users, so the disclosure design should be checked against the license before build starts.
Finally, identify the national market surveillance authority for each jurisdiction where the assistant will be offered or its output used, because Article 2 reaches non-EU providers and deployers whose output is used in the EU. Ask counsel to confirm the authority's contact route and whether any national rules add to the Article 50 duty. Also confirm the fine exposure under Article 99 for transparency failures in your sector, and document the decision on disclosure wording, placement and timing, including the requirement that information be given at the latest at the first interaction and meet accessibility requirements. Keep that record with the test evidence for the chosen disclosure.
How DeployOpen scopes and delivers the disclosure and evidence
DeployOpen plans, builds and documents the disclosure and logging controls for a self-hosted RAG assistant inside the client's own infrastructure. We prepare the evidence a deployer or provider needs, but we do not issue audit reports or legal determinations, which remain with counsel and the relevant authorities.
How we scope
- Written scope lists every channel where the assistant faces customers or the public, such as a website widget or portal.
- We map each channel to its provider or deployer role and record who must give the disclosure.
- We agree the wording, placement and first-interaction timing of the AI notice before build starts.
How we build
- We configure the chat interface, such as Open WebUI or Dify, to show a clear AI disclosure at first interaction.
- We build accessible notice text and test it with screen readers and keyboard-only navigation.
- We enable event logging for prompts, retrieved sources and answers, and test retention settings against the client's policy.
How we hand over
- Deliverables include a disclosure specification, configuration records, test results and a log retention description.
- We document which obligations the client's counsel must confirm, including the status of any Digital Omnibus changes.
- Operating runbooks explain how to update notices, rotate keys and review logs after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-testing of disclosure wording when the assistant, model or interface changes.
- Fixed-scope engagements are agreed in writing, so changes to channels or obligations are priced as scope changes.
Sources and further reading
- Regulation (EU) 2024/1689 (AI Act), Article 50 Transparency obligations for providers and deployers of certain AI systems, EUR-Lex ↗
- Guidelines on the transparency obligations for providers and deployers of AI systems (20 July 2026) ↗
- Commission publishes Code of Practice on marking and labelling of AI-generated content (10 June 2026) ↗
- Signing the Code of Practice on Transparency of AI-generated Content (European Commission FAQ) ↗
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex ↗
