GDPR and the AI Act for Chatbot Operators

What Changed on 2 August 2026, and the Four Documents You Need

Quick answer: On 2 August 2026, three weeks before this was written, the transparency obligations in Article 50 of the EU AI Act became applicable and enforceable. The headline most coverage took from it, you must now tell people they are talking to a bot, is right about the duty and imprecise about who carries it. Article 50(1) is written as an obligation on the provider of the AI system, the party that develops it and puts it on the market under its own name. A small business running a vendor-branded support bot is normally a deployer, and the deployer duties in Article 50 are narrower: disclosing deepfakes under 50(4), informing people about emotion recognition and biometric categorization under 50(3), and labeling AI-generated text published on matters of public interest, also under 50(4). A plain text support bot triggers none of those — but a photoreal AI-generated spokesperson or a cloned voice in your marketing can trigger the first, and white-labeling the bot under your own brand may move you across the provider line altogether. So the work is real; it is just different from what the headline implies: check that your vendor's disclosure exists and that your configuration has not eroded it, take the AI literacy step in Article 4 that has bound deployers since February 2025, and then deal with the part that was always yours, four documents, none of which the AI Act invented. A record of what you process, a contract with your vendor, a privacy notice that states a retention period, and a retention schedule you actually run.

Not the same guide as our PII handling guide

One page of ours sits close to this one and the split is worth stating before you read further.

Chatbot security and PII handling asks how to protect the data while you hold it: the four places a customer's email exists at once, what to mask, who can read it, and what the model provider sees. It is an engineering and operations guide.

This page asks what you owe and to whom: which duties bind, which documents evidence them, and which of them your vendor is supposed to carry rather than you. The overlap is deliberate at one point only, retention, and that is handled by the data retention policy entry published alongside this guide.

Does any of this apply to you?

Worth settling before you read further, because this site's readership is largely outside the EU.

The GDPR. Article 3 sets the territorial scope in two limbs. 3(1) catches you if you are established in the EU, wherever the processing happens. 3(2) catches a controller established outside the EU where the processing relates to offering goods or services to people in the EU — "irrespective of whether a payment of the data subject is required," which matters for free chat support — or to monitoring their behavior within it.

The test under 3(2)(a) is targeting, and the chat widget is not what decides it. What decides it is whether it is apparent that you envisage offering to people in the EU: EU-language or EU-currency options, EU shipping, EU customer references, ad spend aimed at EU markets. Recital 23 says the mere accessibility of a website in the Union does not by itself demonstrate that intention, and the EDPB's Guidelines 3/2018 on territorial scope treat services provided inadvertently or incidentally to someone in the EU as outside it. A US business that markets to Europe and answers those customers in chat is inside; a domestic-only business whose widget occasionally answers a European visitor is, on that fact alone, not.

If 3(2) catches you, two obligations arrive that this guide does not cover. Article 27 requires a written designation of a representative in the EU, with limited exceptions, and Chapter V requires a transfer mechanism for the data that leaves. Both are real, both are outside our competence, and both are reasons the "four documents" below are four documents for a controller already inside scope rather than a complete list for everybody.

The AI Act. It reaches providers established outside the EU whose systems are placed on the EU market, and, per the Commission, providers outside the EU "if the output of their AI system is used in the EU." For a deployer, the practical question is whether your customers are in the EU.

What actually changed on 2 August 2026

Two things happened within a week of each other, and they are routinely reported as one thing.

The AI Omnibus deferred the high-risk regime. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and pushed the obligations for standalone high-risk systems listed in Annex III (employment, education, law enforcement, critical infrastructure) from 2 August 2026 out to 2 December 2027, with AI embedded in products regulated under EU product-safety law moving to 2 August 2028.

The transparency obligations were not deferred. Article 50 applied on schedule from 2 August 2026. The Commission's own FAQ states it plainly: "Article 50 of the AI Act applies as from 2 August 2026. From that date onwards, providers and deployers of AI systems must comply with the transparency obligations laid down in that provision." One narrow grace period exists, and it does not cover chatbot disclosure: for AI systems placed on the market before 2 August 2026, and only for the machine-readable marking of AI-generated content under Article 50(2), compliance is required from 2 December 2026.

So the widely circulated summary, the AI Act got delayed, is half true, and the half that was not delayed is the half that mentions chatbots by name. Enforcement sits mainly with national market surveillance authorities. The headline penalty ceiling for these provisions, in Article 99(4), is up to €15 million or 3 percent of total worldwide annual turnover for the preceding financial year, whichever is higher if the offender is an undertaking.

Then Article 99(6) reverses it for the readers of this page, and almost nobody quotes it. Its text: "In the case of SMEs, including start-ups, each fine referred to in this Article shall be up to the percentages or amount referred to in paragraphs 3, 4 and 5, whichever thereof is lower." So for an SME the operative ceiling is the lower of the two limbs, which for a business of that size is the 3 percent figure rather than the €15 million one. "SME" here carries the Commission Recommendation 2003/361/EC meaning — broadly, fewer than 250 staff and turnover not above €50 million — so most readers of this page are inside it. The Commission's FAQ renders this softly as proportionality that "can be taken into account"; the Article is a cap, not a discretion. If you have seen the €15 million number quoted at a small business, it was the wrong limb.

The duty is on your vendor. Mostly.

Here is the reading that this guide exists to make, and it is ours rather than a quotation, so treat it as an argument to check rather than a conclusion to rely on.

Article 50(1) obliges providers — the party that develops an AI system and places it on the EU market or puts it into service under its own name or trademark — to design and develop systems that interact directly with people so that those people are informed they are interacting with an AI system, unless that is obvious. The Commission's guidelines set out four cumulative criteria: the thing must be an AI system; it must be designed for genuine two-way exchange "rather than merely collecting data or providing automated responses"; the interaction must be direct rather than mediated by a human; and it must be with natural persons. A generative support bot on a website clears all four comfortably. A rule-based decision tree is a harder case on the first and second criteria, and we are not going to pretend otherwise. The manner of the disclosure is set by Article 50(5), which requires the information to be provided at the latest at the time of the first interaction, clearly and distinguishably, and in line with accessibility requirements.

The duties Article 50 places on deployers are different ones, and there are three rather than the two most summaries give.

Article 50(3) covers deployers of emotion recognition and biometric categorization systems, who must inform the people exposed to them.

Article 50(4), first limb — the one routinely dropped, including from our own first draft of this page — covers deployers of a system that generates or manipulates image, audio or video content constituting a deepfake, who must disclose that the content is artificially generated or manipulated. The Commission is explicit that a deployer "cannot simply rely on the machine-readable marking embedded in the content by the provider under Article 50(2)" to discharge this; the disclosure has to be perceivable by a person, on first exposure at the latest. The definition has three cumulative criteria, not one: the content must be AI-generated or manipulated, it must resemble a person, object, place, entity or event that exists, and it must falsely appear to a person to be authentic or truthful — so an evidently stylized brand mascot may fail the third test where a photoreal synthetic presenter will not. If your marketing uses an AI-generated presenter, a synthetic spokesperson image, or a cloned voice that resembles a real person, this is likely a duty on you, today, and increasingly these are features bundled into the same platforms that run the bot.

Article 50(4), second limb covers AI-generated or manipulated text published to inform the public on matters of public interest, with an exemption where the text has had genuine human review or editorial control.

An SMB running a text-only returns bot triggers none of the three. An SMB running the same bot alongside an AI-generated video ad triggers the deepfake limb of 50(4). Two carve-outs travel with that limb and are worth knowing: content that is evidently artistic, creative, satirical or fictional needs disclosure only in a manner that does not spoil the work, and there is a law-enforcement exception that will not apply to you.

There is also one AI Act duty that binds deployers regardless of any of this, and it predates August. Article 4, applicable since 2 February 2025, requires measures on AI literacy for staff and for others operating the system on your behalf. The original wording was a duty to take measures to ensure, "to their best extent," a sufficient level of AI literacy; the AI Omnibus replaced that with a duty to "take measures to support the development of" it, and added that the article "does not require providers or deployers to guarantee any specific level of AI literacy of any individual." Softened, then, and not removed — and it is the cheapest item on this page to satisfy.

Where you cross back into provider status

The definition quoted above has a second limb that matters more than its placement suggests. A provider is someone who develops an AI system or has one developed, and places it on the market or puts it into service under their own name or trademark.

White-labeling is exactly that fact pattern. A widget you rebrand as "Acme Assistant," with your logo and no visible mention of the platform underneath, is closer to that line than a vendor-branded one — and white-label webchat is a paid-tier feature on platforms we review, including Botpress. The Act does have an express rebranding rule, and reading it is reassuring rather than alarming: Article 25(1)(a) provides that a deployer is considered a provider where they put their name or trademark on a high-risk AI system already placed on the market, "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated." It is written only for high-risk systems, and an ordinary support bot is not one. That leaves the position for a white-labeled non-high-risk chatbot unsettled rather than adverse, and we are not aware of a Commission decision or guideline settling it. The practical consequence is narrow and worth acting on: white-labeling is the one configuration choice on this page where you should take advice rather than take our reading.

Three practical consequences follow from the allocation, and the second is the one worth acting on.

Ask the vendor to show you the disclosure. If your platform is the provider, the "you are chatting with an AI assistant" affordance is their design obligation, and a vendor who cannot tell you how their product meets it is telling you something.

Check that your customization did not undo it. This is the live risk. Platforms let you rename the bot, give it a human first name, attach an avatar photo and rewrite the opening message. The Commission's guidance requires that people be informed "from the start of the first interaction in a clear and distinguishable manner," and says the "obvious" exception "should be interpreted in a restrictive manner." A bot renamed Sofia, given a stock headshot and a greeting with no mention of automation is moving in the wrong direction on both tests. We read that as a configuration risk that lands on the deployer even where the drafting duty does not, and we flag it as our reading rather than a rule anyone has stated.

Do not treat the AI Act as a substitute for the rest. Consumer-protection law on misleading commercial practices, and the GDPR's own transparency requirements, bind you directly and did before August. The AI Act analysis above narrows one duty; it does not narrow those.

The four documents

None of these is new, and none is optional in the way people treat them.

1. The record of what you process

Article 30 requires controllers to maintain a record of processing activities. The exemption in Article 30(5) is the one everybody reaches for and almost nobody qualifies under. Its text, in full:

Read the conditions as the "unless" they are. A chatbot that runs on your website every day, collecting names and email addresses from whoever arrives, is processing that is not occasional. That single limb is usually enough to put a small company back inside the obligation, and it does not require the processing to be risky or sensitive — a reading the Article 29 Working Party set out in its position paper on Article 30(5) of 19 April 2018, which treats the three conditions as alternatives rather than cumulative. The same paper limits what you then have to write down: the record covers the qualifying processing, not everything the business does. The practical version is a spreadsheet: what the bot collects, why, on what legal basis, who it goes to, how long you keep it, and whether it leaves the EEA, and if it does, see Does any of this apply to you? above, because a transfer mechanism under Chapter V is a separate obligation this guide does not cover.

2. The contract with your platform

Where your chatbot vendor processes personal data on your behalf, Article 28 requires that the relationship be governed by a contract binding the processor to the controller, and it specifies what that contract must contain — processing only on documented instructions, confidentiality, security, conditions on sub-processors, assistance with data subject rights, deletion or return at the end, and audit cooperation. In practice this is the vendor's Data Processing Agreement, and your job is to obtain it, read the sub-processor list, and know where the data sits.

We went through our own fifteen platform reviews on 24 August 2026 to see how well we have served readers on this, and the answer is: not well. Four of the fifteen record a DPA field at all. Of those four:

Three readings, and we are keeping them apart.

The eleven silent reviews are about us. Our review protocol has never systematically asked the DPA question, so eleven blanks mean we did not look. That is a gap in our own work and it is going into the protocol, alongside the retention questions the companion glossary entry commits us to.

Two of the four rows are weaker evidence than a table makes them look. Intercom's entry rests on an inference about what is standard for paid tiers, and Landbot's partly on third-party profiles. Neither is a read of a published DPA. We have not read any vendor's DPA, for any platform, and the column above exists so that this is visible rather than smoothed over.

One row is genuinely surprising: a DPA that is unavailable on a free tier. If a controller needs an Article 28 contract before a processor may handle personal data on their behalf, and the contract begins at Plus, then our reading is that the free tier is not usable for EU personal data by a controller who needs one — a materially different thing from "the free tier has fewer features." Two qualifications belong with that. Intercom's row conditions on paid tiers too; it is less striking only because Intercom has no free tier to be excluded from. And we put no question to Botpress before publishing this; the statement is a reading of the vendor's pricing matrix as our review recorded it, not a description of vendor policy, and a buyer for whom it matters should put it to the vendor in writing.

3. The privacy notice that names a period

Articles 13 and 14 set out what you must tell people when you collect their data. The line most often left blank is 13(2)(a): the period for which the data will be stored, "or if that is not possible, the criteria used to determine that period." You may publish criteria instead of a number. You may not publish nothing.

Two chatbot-specific traps. First, the notice has to be reachable at the point of collection, which for a chat widget means a visible link in the widget rather than only in the site footer. Second, if your bot is generative, the model provider is part of the processing chain and belongs in the disclosure; our PII handling guide covers why that layer is the one operators most often forget.

4. The retention schedule you actually run

The document that turns the promise in item 3 into something you can evidence. The data retention policy entry published alongside this guide covers what it contains, why the GDPR names no period, and the counterintuitive argument we make there: that low-traffic bots need longer windows before their raw logs can teach them anything. The short version for this page: one row per data category, a justification per row, and a name against the deletion actually happening.

The legal basis question people skip

Before any of the four documents, one decision: what makes the processing lawful in the first place. Article 6 offers six bases and three are plausible for a chatbot.

Contract (Art. 6(1)(b)) covers processing necessary to perform a contract with the person — checking an order status for a customer who has one.

Legitimate interests (Art. 6(1)(f)) is the usual basis for handling an inbound support question from someone who is not yet a customer, and it requires a balancing exercise you should write down, because the same article makes it lose to the individual's rights where those override.

Consent (Art. 6(1)(a)) is the right basis for the marketing uses, such as adding a chat contact to a mailing list or retargeting, and it has to be specific, informed and as easy to withdraw as to give. Consent obtained for support and reused for marketing is the commonest failure in this category and it is not a small one.

Separately from Article 6, there is a second rule for anything stored on or read from the user's device — and getting its source right matters on a page about who a duty binds. The ePrivacy Directive is a directive, so it does not bind you directly; what binds you is your country's transposition of it, and those differ. Article 5(3) of the Directive requires consent for storing or gaining access to information stored in a user's terminal equipment, with exceptions for storage whose sole purpose is carrying out the transmission of a communication and for what is strictly necessary to provide a service the user explicitly requested. A chat widget that sets a session cookie so the conversation survives a page reload has a decent claim to the second exception. The same widget's analytics and attribution cookies do not, and they are usually installed by the same script. Check the national rule that applies to you: Germany's TDDDG, France's Article 82 and the UK's PECR are not identical to one another.

Deletion requests, and where transcripts hide

Article 12(3) gives you one month from receipt to respond to a data subject request, extendable by two further months where the request is complex, provided you inform the person of the extension and the reasons for it within the first month.

The chatbot-specific difficulty is not the deadline; it is the inventory. A single conversation can exist in five places at once: the chat platform's transcript store, the CRM record the bot wrote to, the analytics warehouse, the model provider's request logs if your bot is generative, and the export somebody made to a spreadsheet. A deletion carried out in one of them and reported as complete is a partial erasure described as a complete one. To be clear about the trade-off, because it is easy to draw the wrong lesson: both a partial erasure and a missed deadline are breaches, and neither is the safe option. Article 12(3) keeps running while you look. The way out is to build the inventory before you receive the request rather than after, and it is the same inventory Article 30 already asks for, which is the practical argument for doing document one first.

What could still change

Do not rebuild anything in anticipation of the Digital Omnibus.

The Commission proposed a package in November 2025 that would amend the GDPR, the ePrivacy Directive and others. The AI half of it was adopted and is in force, which is what deferred the high-risk timeline. The data half, the GDPR and ePrivacy amendments, was still moving through the legislative process at the time of writing, with Parliament and Council positions pending. The EDPB and EDPS issued a Joint Opinion on 11 February 2026 that welcomes simplification and opposes several specific proposals, most strongly the revision of the definition of personal data, which they say goes beyond a targeted adjustment and would significantly narrow the concept.

The proposals with the most direct bearing on a chatbot operation are the cookie-consent reforms, including machine-readable consent signals, and a proposed EU-wide list of processing operations that do or do not require a data protection impact assessment, replacing the current national lists. Both would be welcome. Neither is law, and the sensible posture is to comply with the rules that exist and keep the change list somewhere you will see it.

Where it breaks

Treating the platform's "GDPR compliant" badge as your compliance. It describes their processing, not yours. The record, the notice, the legal basis and the retention schedule are the controller's, which is you.

A consent checkbox doing four jobs. One tick covering support, marketing, analytics and profiling is not specific, and the first regulator to look will say so.

Free-tier deployments with no contract. Covered above, and easy to miss because nothing in the product stops you.

Documents written once. A record of processing from the launch of the bot describes a bot that no longer exists. Put a review date on it.

FAQ

Related guides

• Data retention policy (glossary) — this guide's companion, and the fourth document
• Business Associate Agreement (glossary) — the American analogue of the DPA, and not interchangeable with it
• Healthcare chatbot guide — the US healthcare version of this paperwork
• Chatbot security and PII handling — protecting the data while you hold it
• Chatbot QA testing protocol — the pre-launch pass this paperwork belongs in
• Chatbot training data — where transcripts become a second processing purpose
• Chatbot guardrails guide — the behavioral controls that sit next to these duties
• When not to use a chatbot — including cases where the data you would collect is the reason not to
• LLM security (glossary) — the risk surface once a model provider is in the chain
• Session context (glossary) — the shortest-lived category in your retention table
• Entity extraction (glossary) — how structured personal data gets captured in the first place
• Our privacy policy — what we do with yours

Sources

• Regulation (EU) 2016/679 (General Data Protection Regulation), consolidated text, read 24 August 2026. Specifically: Article 5(1)(e) storage limitation; Article 6(1)(a), (b) and (f) as the three legal bases discussed; Articles 13 and 14 information duties, and in particular 13(2)(a) requiring "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period"; Article 12(3), one month to respond to a data subject request "extended by two further months where necessary, taking into account the complexity and number of the requests", with the controller to inform the data subject of the extension and the reasons within one month; Article 3(1) and 3(2) on territorial scope, and Article 27 on the representative, both summarized in the scope section; Article 28 and its required processor-contract terms; and Article 30, whose 30(5) exemption is quoted verbatim and complete in the body. Quoted as the regulation's text, not as advice about its application to any particular deployment. eur-lex.europa.eu
• Directive 2002/58/EC (ePrivacy Directive) as amended by Directive 2009/136/EC, Article 5(3), read 24 August 2026 — the consent requirement for storing information on, or gaining access to information stored in, a user's terminal equipment, together with both of its exceptions: storage whose sole purpose is carrying out the transmission of a communication, and what is strictly necessary to provide a service explicitly requested by the subscriber or user. This is the basis for the widget-cookie distinction in the legal-basis section. A directive does not bind private parties directly; the operative rule in any member state is its national transposition, which is why the body says so and names three of them without asserting their contents. eur-lex.europa.eu
• Regulation (EU) 2024/1689 (EU AI Act), Articles 4, 25(1)(a), 50 and 99, read 24 August 2026 — the source of the Article 50(4) two-limb structure and the Article 3(60) deepfake definition summarized in the body; of the Article 25(1)(a) rebranding rule and its confinement to high-risk systems; and of the penalty provisions, including Article 99(4) and the Article 99(6) SME cap quoted verbatim as "In the case of SMEs, including start-ups, each fine referred to in this Article shall be up to the percentages or amount referred to in paragraphs 3, 4 and 5, whichever thereof is lower." Article 99 was read directly rather than through the Commission FAQ or a client alert, because the FAQ's rendering of 99(6) as proportionality that "can be taken into account" understates a binding cap and would have left this page overstating its own readers' exposure.
• European Data Protection Board, Guidelines 3/2018 on the territorial scope of the GDPR (Article 3), together with GDPR Recital 23 — the basis for the targeting test in the scope section and for the statement that mere accessibility of a website from the Union is not by itself evidence of an intention to offer goods or services there.
• Article 29 Data Protection Working Party, Position paper on the derogations from the obligation to maintain records of processing activities pursuant to Article 30(5) GDPR, 19 April 2018 — cited for the reading that the three conditions in Article 30(5) are alternatives rather than cumulative, which is the basis for the "not occasional" argument in document one. Cited by name and date; we did not re-verify its endorsement history by the EDPB.
• European Commission. Transparency obligations under Article 50 of the AI Act, FAQ page on Shaping Europe's digital future, page footer stating "Last update 24 July 2026", read 24 August 2026 — the source of every Article 50 statement on this page. Specifically: the definition of provider carried from Article 3(3); the four cumulative criteria for the Article 50(1) direct-interaction duty; that people "must be notified when they are interacting with an AI system from the start of the first interaction in a clear and distinguishable manner and in accordance with accessibility requirements"; that the "obvious" exception "should be interpreted in a restrictive manner, given that it deprives people of transparency"; that deployers "must ensure that they inform people when they use emotion recognition or biometric categorisation systems (Articles 50(3) of the AI Act) and clearly label deepfakes and AI-generated or manipulated text published on matters of public interest without human review or editorial control (Article 50(4))"; that "deployers cannot simply rely on the machine-readable marking embedded in the content by the provider under Article 50(2) of the AI Act to fulfil their disclosure obligation" and must disclose "upon first exposure at the latest"; the Article 3(3) definition of provider, including "or have them developed" and "under their own name or trademark", and that providers outside the EU are in scope "if the output of their AI system is used in the EU"; that "Article 50 of the AI Act applies as from 2 August 2026" with a grace period "only for AI systems placed on the market before 2 August 2026 and only as regards the marking and detection obligation for AI-generated content (Article 50(2))", compliance required "only as from 2 December 2026"; that enforcement is "mainly ... by national competent market surveillance authorities"; and that "fines can reach up to 15 million euros or 3% of total worldwide turnover for the preceding financial year, while proportionality can be taken into account in the case of small and medium sized enterprises (SMEs) and small mid-cap companies (SMCs)." The internal numbering inconsistency described in the callout is on this page. digital-strategy.ec.europa.eu
• Goodwin Procter LLP. Not Delayed, Not Deferred: EU AI Act Transparency Obligations Are Now in Force, client alert dated 3 August 2026, read 24 August 2026 — the source for the AI Omnibus identification and the deferred dates: Regulation (EU) 2026/1744, in force 27 July 2026; Annex III standalone high-risk obligations moved to 2 December 2027; AI embedded in Annex I product-safety-regulated products moved to 2 August 2028; and the Article 99(4) penalty ceiling of €15 million or 3 percent of worldwide annual turnover, whichever is higher. Also the source for the note that the Commission adopted its Guidelines on transparency obligations on 20 July 2026; for the statement that deployers "must also disclose deepfakes depicting real persons, places, or events"; and for the AI Omnibus amendment to Article 4, under which providers and deployers must now "take measures to support the development of AI literacy of their staff" rather than ensure a sufficient level of it. Cited as a secondary source for the regulation's content, which we did not read in the Official Journal. goodwinlaw.com
• European Data Protection Board and European Data Protection Supervisor, Joint Opinion 2/2026 on the proposed Digital Omnibus Regulation, issued 11 February 2026, following their Joint Opinion of 20 January 2026 on the Digital Omnibus on AI. The Opinion is published free by the issuing authorities; we read a secondary summary of it rather than the Opinion itself, which is a gap on a page whose methodology otherwise insists on primary text, and it is recorded here rather than smoothed over. edpb.europa.eu
• Covington & Burling, Inside Privacy / Global Policy Watch, "EU Regulators Issue Opinion on Revisions of GDPR and Other Data Laws", read 24 August 2026 — the secondary summary used for the status and content of that Joint Opinion, including that the Authorities "strongly oppose the proposed changes to the definition of personal data", their partial agreement on the cookie-consent reforms and on EU-wide DPIA lists, and the procedural note that Parliament and Council positions were still to be set out. Used for the "what could still change" section only; no proposal described there is law, and this guide states the rules that apply today. globalpolicywatch.com
• Chatbotscape review corpus, counted and read 24 August 2026, published so the count reproduces. Two commands, both run from the repository root. Denominator: ls sample-reviews/*-review.md | wc -l returns 15. Numerator: grep -rlE "\bDPA\b|[Dd]ata [Pp]rocessing [Aa]greement" sample-reviews/*-review.md returns four paths — aisensy-review.md, botpress-review.md, intercom-review.md and landbot-review.md. The glob is scoped to *-review.md so that POC-note siblings and one versioned backup are excluded by the pattern rather than by hand. The four rows in the DPA table are read from those reviews' own compliance tables. The third column is our characterization of how each review knew what it recorded, not a verbatim reproduction of the review's source cell, and where the review's own cell is short enough we quote it: Intercom's reads "Standard for paid tiers", Landbot's "Not surfaced on public site; request via sales", AiSensy's "No DPA download link found". Botpress's compliance matrix has no source column at all — four tier columns only — so that row is read from the pricing matrix and the review's surrounding prose. This is spelled out because the point of the column is to expose sourcing rather than smooth it, and a column that misdescribed its own construction would defeat that. Every figure is a fact about our reviews rather than about the platforms; the eleven blanks mean the question was not asked, and we are not presenting them as findings.
• Ahrefs Keywords Explorer, US overview, queried 24 August 2026 — the demand, difficulty, CPC and parent-topic figures in this page's keyword note, including the checks behind declining 'gdpr compliance', 'eu ai act', 'ai governance' and 'ai compliance', and behind sending 'data retention policy' to the same-day companion entry.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. It covers the legal paperwork of running a chatbot for customers in the EU: what the AI Act's transparency rules require and which party they bind, the four documents a controller needs, the legal basis decision that precedes all of them, and how deletion requests work when a conversation lives in five systems. The engineering side — masking, access control, what the model provider sees — is in our PII handling guide. We are a review site, not a law firm, and this page is written to make you a better-informed buyer rather than to replace advice.

Methodology

Every legal instrument on this page was read from its own text or from the European Commission's own published material on 24 August 2026, and each claim is attributed in Sources to the article and page it came from. Four claims are secondary rather than primary and are labeled as such: the AI Omnibus regulation number and its deferred dates; the 20 July 2026 adoption date of the Commission's transparency Guidelines; the amended wording of AI Act Article 4; and the status of the Digital Omnibus negotiations. The first three come from a law firm's client alert rather than from the Official Journal, and the fourth from a law firm's summary of the EDPB and EDPS Joint Opinion rather than from the Opinion itself. One further disclosure: the AI Act articles were read in the 2024/1689 text, and Article 4's operative wording is the replacement made by Regulation (EU) 2026/1744, which we did not read in the Official Journal either.

The editorial judgment on this page is listed here rather than flagged line by line, in the order the page raises it:

1. The central reading that Article 50(1) allocates the disclosure duty to the provider and that an SMB running a bot on a commercial platform is normally a deployer, and therefore that the widely repeated summary of the August change misdescribes who it binds. This is an argument from the text and the Commission's guidance, not a statement any authority has made in these terms.
2. The corollary that aggressive humanization of a bot, meaning a human name, a stock photograph and a greeting with no mention of automation, is a configuration risk landing on the deployer even where the drafting duty does not. Labeled as our reading in the body.
3. The "four documents" framing itself, which is a way of organizing obligations that the regulation does not organize this way.
4. The reading that a Data Processing Agreement gated above a free tier makes that free tier unusable for EU personal data by a controller who needs an Article 28 contract. Stated as our reading of an arrangement our own review records, not as a claim about vendor policy.
5. The decision to publish the eleven blank DPA fields in our own reviews as a gap in our protocol rather than to omit them or to present them as findings about the platforms. The companion glossary entry does the same for retention and publishes its own counting commands; this page states no retention count of its own.
6. The ordering that puts the record of processing first, on the argument that it is the same inventory a deletion request needs.
7. The judgment that the ePrivacy widget-cookie distinction is worth raising here at all, given that most guides to this subject leave it to the cookie-banner literature.
8. The advice not to rebuild consent infrastructure in anticipation of the Digital Omnibus, which is a risk judgment about a live legislative file and could be wrong if the file moves quickly.
9. The decision to bound the scope section at Articles 3 and 27 and to name Chapter V transfers without covering them, on the grounds that a transfer-mechanism guide written by a review site would be worse than no guide. It means "the four documents" is four documents for a controller already in scope, and the page says so in the scope section rather than in the title, which is a compromise a reader who never scrolls will lose on.
10. The framing of Article 50(4) as two limbs. The deepfake limb was missing from this page's first draft and was restored after our own adversarial review caught it; we mention this because the omission is the same failure the page criticizes elsewhere, and a reader is entitled to know it was made here first.

We have run no compliance audit, we have not read any vendor's DPA, and no statement here is legal advice. See our methodology for how platform facts are verified.

Last updated

25 August 2026.