Most content about GDPR and chatbots opens with EU hosting. That is a marketing frame, not a legal one, and starting there sends procurement chasing the wrong requirement.
A few terms first, because the rest of this depends on them. GDPR is the General Data Protection Regulation, the EU law governing personal data. A controller decides why and how personal data is processed, which is your organization; a processor acts on the controller's instructions, which is the chatbot vendor. A DPA, or Data Processing Agreement, is the contract Article 28 requires between the two.
Two more. A DSAR, or data subject access request, is a person exercising their rights over their own data, such as asking for a copy or asking for deletion. SCCs are Standard Contractual Clauses, the template contract terms the European Commission publishes to make transfers of personal data outside the EU lawful.
Nothing in GDPR says personal data must stay in the EU. What it says is that transfers out need a valid mechanism, which is a very different requirement with a very different answer.
iShort answer
Three things gate an EU chatbot deployment: the lawful basis you rely on, a signed DPA with the vendor, and a valid mechanism for transfers to processors outside the EU. Residency is not on that list. Consent is usually the wrong lawful basis for a service chatbot; legitimate interests or contract performance normally fits better. On SiteGPT, processing is US-based, transfers rely on the European Commission's Standard Contractual Clauses plus the EU-U.S. Data Privacy Framework where a provider is certified, Article 27 representatives are appointed in both the EU and UK, and the DPA is executed for Enterprise customers.
Three gates, in the order a DPO works through them. Clear all three and the widget can go live.
Gate 1: a lawful basis
Article 6. For a service chatbot this is usually legitimate interests or performance of a contract, not consent. You provide this; nobody can supply it for you.
Gate 2: a signed DPA
Article 28 requires a contract governing the processor. The vendor provides it, you sign it, and it has to exist before the widget collects anything.
Gate 3: a transfer mechanism
Chapter V. Needed the moment a processor sits outside the EU. Standard Contractual Clauses are the usual route, with a transfer impact assessment alongside them.
Not a gate: EU hosting
Residency avoids gate 3 rather than satisfying a requirement of its own. A US-hosted processor operating under SCCs is lawful. Judge vendors on the mechanism, not the map.
Key takeaways
| The question | The short answer |
|---|---|
| Does GDPR require EU hosting? | No. Chapter V allows transfers with appropriate safeguards. SCCs are the standard safeguard. |
| What lawful basis for a support chatbot? | Usually legitimate interests, or contract performance. Consent is the common wrong answer. |
| Is a DPA optional? | No. Article 28 requires a contract with any processor, and a chatbot vendor is a processor. |
| Are SCCs a formality? | No. Schrems II requires a transfer impact assessment and supplementary measures where needed. |
| Where does SiteGPT process data? | The United States. See the subprocessor list; no EU-based subprocessor is named. |
| How is a SiteGPT DPA executed? | For Enterprise customers, signed by both parties. Other plans contact support. |
The three questions an EU buyer actually asks
A DPO reviewing a chatbot proposal is working through a short list, and it is shorter than most vendor comparison tables suggest.
What is the lawful basis? Every act of processing needs one, and the answer determines what you must tell visitors and what rights they can exercise. This one is yours to decide.
Will the vendor sign a DPA? Article 28 makes the contract mandatory, not advisable. A vendor who cannot produce one is not deployable, regardless of the product.
How are transfers covered? The moment any processor sits outside the EU, Chapter V applies. This is where residency gets confused with compliance.
Lawful basis, and why consent is usually the wrong answer
Article 6 lists six lawful bases. For a website chatbot, three are plausible and one is chosen far too often.
Consent feels like the safe default and usually is not. Consent must be freely given, specific, informed, and as easy to withdraw as to give. A support channel that stops functioning when someone withdraws consent is not a viable service design, and bundling consent into a cookie banner to unlock a support widget tends not to meet the freely given standard.
Legitimate interests under Article 6(1)(f) is the usual fit for a service chatbot. Answering a question someone came to your site to ask is a legitimate interest, the processing is necessary to do it, and a visitor who opened a chat window reasonably expects their message to be read. That last part matters, because the balancing test turns on reasonable expectations.
Performance of a contract under Article 6(1)(b) fits where the chatbot is part of delivering a service the person already has, such as an assistant inside a logged-in area.
| Basis | When it fits a chatbot | The trap |
|---|---|---|
| Consent, Art 6(1)(a) | Separate purposes layered on top, such as marketing follow-up | Must be withdrawable without breaking the service, so it rarely works as the primary basis |
| Contract, Art 6(1)(b) | Assistants inside a logged-in product or account area | Does not stretch to cover anonymous marketing-site visitors |
| Legitimate interests, Art 6(1)(f) | General customer service and website assistance | Requires a documented balancing test, and it is not available to public authorities in their official tasks |
Two things follow. If you rely on legitimate interests, write the balancing test down before launch, because the accountability principle means being right is not enough if you cannot show it. And if the chatbot ever handles special category data, such as health information, Article 9 adds a separate condition on top of the Article 6 basis, and the analysis restarts.
What your privacy notice has to say before launch
Articles 13 and 14 set out what people must be told, and the widget going live before the notice is updated is the most common avoidable finding.
Cover the purposes and the lawful basis for each, the recipients or categories of recipients including the chatbot vendor, any transfers outside the EU together with the safeguard relied on, the retention period or the criteria for setting it, and the full list of data subject rights along with the right to complain to a supervisory authority.
Where legitimate interests is the basis, name the interest rather than asserting the label. And if the chatbot's answers are AI-generated, say so plainly in the interface, which is both an honesty point and increasingly a separate regulatory expectation.
The DPA, and what it commits a processor to
Article 28 requires that processing by a processor be governed by a contract binding the processor to the controller, and it specifies what that contract must contain. This is the document that turns a vendor's security claims into obligations.
| Article 28 requirement | The question to ask a chatbot vendor |
|---|---|
| Subject matter, duration, nature, and purpose | Is the scope written to cover conversations, or only account data? |
| Process only on documented instructions | Is anything processed for the vendor's own purposes, such as product improvement? |
| Confidentiality commitments for personnel | Who internally can read conversations, and under what conditions? |
| Security measures under Article 32 | Are the controls in the contract, or only on a marketing page? |
| Subprocessor authorisation and flow-down | How are you notified of a new subprocessor, and can you object? |
| Assistance with data subject rights | What is the mechanism and the turnaround when a DSAR names a conversation? |
| Deletion or return at the end | Which one is the default, and on what timeline? |
| Information for audits | Will they provide evidence, and in what form? |
How SiteGPT handles it, including the gap. The security page states that a Data Processing Agreement is available for Enterprise customers for GDPR compliance, and the DPA page states the agreement binds only when signed by both parties. Customers on other plans contact support rather than relying on a self-generated document.
That gating parallels the Enterprise-only BAA on the HIPAA side, with one honest difference worth naming. SiteGPT publishes its standard BAA in full so counsel can read it before a sales conversation. The DPA text is not published the same way, so an EU buyer cannot do the equivalent pre-read. If that matters to your review process, ask for the text early rather than late.
Where your data actually goes
A subprocessor list is the most useful compliance document a vendor publishes, and the least read. It answers the transfer question factually, before anyone characterises it.
Read it for three things: which companies appear, what each one does, and which country each operates in. Then check that the list is public rather than available on request, because a public list is one the vendor has to keep accurate.
SiteGPT's list, in plain terms. The published list names no EU-based subprocessor. Convex and Pinecone run in the United States on AWS, OpenAI and Cohere are United States, Cloudflare is listed as Global, and Paddle is United Kingdom. The privacy policy states that service providers are primarily located in the United States.
So there is no EU data residency and no regional hosting option. If your requirement is EU-only storage and processing, SiteGPT does not meet it, and competitors that lead with EU hosting genuinely do have that advantage. What SiteGPT offers instead is a documented transfer mechanism and a list you can verify without asking anyone.
International transfers, SCCs, and US processing
Chapter V governs transfers to countries outside the EEA. Where there is no adequacy decision covering the recipient, the controller needs appropriate safeguards, and the most common safeguard is the European Commission's Standard Contractual Clauses.
SiteGPT's mechanism. The privacy policy states that transfers relating to EU, EEA, and UK residents rely on "the European Commission's Standard Contractual Clauses and, where the provider is certified, the EU-U.S. Data Privacy Framework." The DPF part is per provider rather than blanket coverage, so treat it as applying to specific recipients that hold a certification, not to the arrangement as a whole.
SCCs are not a filing exercise. After the Schrems II judgment invalidated the Privacy Shield, a controller relying on SCCs also has to assess whether the destination country's law undermines the protection they promise, and add supplementary measures where it does. In practice this is a transfer impact assessment, and it is your document to produce rather than the vendor's. Ask the vendor for the inputs: encryption in transit and at rest, access controls, and its policy on government access requests.
Article 27
SiteGPT has appointed representatives in both regions: Prighter EU Rep GmbH in Vienna under Article 27 GDPR, and Prighter Ltd in London under Article 27 UK GDPR. Article 27 is mandatory for non-EU organizations offering services into the EU, and it is one of the most frequently skipped obligations, so it is worth checking for every vendor on a shortlist.
Source: SiteGPT privacy policyOn the compliance wording. SiteGPT presents its position as GDPR compliant, and the security page attributes the assessment behind that to DPLMC International. Compliant is the right word: treat any third-party attestation as supporting evidence rather than as an official certification, here and with every vendor, because a formal GDPR certification under Articles 42 and 43 requires a body accredited by a supervisory authority or a national accreditation body, and almost no vendor on a typical shortlist holds one. For a DPO's file the load-bearing items are the signed DPA, the transfer mechanism, the subprocessor list, the Article 27 representatives, and the SOC 2 Type II report, which was completed with zero exceptions noted across all tested controls.
Retention, access, and deletion
Article 5(1)(e) requires that personal data be kept no longer than necessary, and conversation transcripts accumulate quietly. Decide the period before launch and write it into the DPA rather than leaving it to a product default.
Rights requests are the operational half. Under Articles 15 through 21 a person can ask for access, rectification, erasure, restriction, portability, or object to processing based on legitimate interests, and the one month response deadline runs whether or not you can search your chatbot transcripts.
Two practical points. Ask how conversations are searched when a DSAR arrives naming a person rather than a conversation ID, because that is the request that arrives. And check whether lead records are governed separately from transcripts, since captured contact details commonly outlive every retention rule written for conversations.
On SiteGPT, the privacy policy names privacy@sitegpt.ai as the contact for rights requests and enumerates access, rectification, objection, restriction, portability, and withdrawal of consent. A fuller treatment of handling DSARs against chatbot conversations is a separate piece.
A pre-launch checklist for an EU deployment
| Scenario | Best pick | Why |
|---|---|---|
| Lawful basis chosen and documented | Before launch | Article 6. If it is legitimate interests, the balancing test has to be written down, because accountability means being able to show the reasoning and not only reach the right answer. |
| Privacy notice updated and linked from the widget | Before launch | Articles 13 and 14. Name the vendor as a recipient, state the transfer safeguard, give the retention period, and list the rights along with the right to complain to a supervisory authority. |
| DPA signed by both parties | Before launch | Article 28. A generated but unsigned document is not an executed contract, and the processing is non-compliant until it is. |
| Transfer mechanism identified, transfer impact assessment done | Before launch | Chapter V plus Schrems II. Identify the SCC module, then assess the destination country and record any supplementary measures. |
| Subprocessor list reviewed and objection process understood | Before launch | Article 28(2). Know who is on the list today and how you will be told when it changes, since a new AI subprocessor is a new transfer. |
| Retention period set, DSAR process tested | Before launch | Article 5(1)(e) and Articles 15 to 21. Test a search by person rather than by conversation ID, and confirm lead records are covered too. |
| Training content reviewed for personal data | Before launch | Whatever the bot retrieves from, any visitor can reach indirectly. Nothing scans it for you, so this is a manual review step. |
Pros
- Transfer mechanism is stated publicly: SCCs, plus the EU-U.S. Data Privacy Framework where the specific provider is certified
- Article 27 representatives appointed in both the EU (Prighter EU Rep GmbH, Vienna) and the UK (Prighter Ltd, London)
- Subprocessor list is public and specific, naming each company, its function, and its country
- Privacy policy enumerates four lawful bases, the full set of data subject rights, and a dedicated privacy contact
- SOC 2 Type II completed with zero exceptions noted across all tested controls
- Data export and deletion available directly from the dashboard rather than by request
Cons
- No EU data residency and no regional hosting option; the subprocessor list names zero EU-based subprocessors
- The DPA is executed for Enterprise customers; other plans contact support
- The DPA text is not published for pre-review, unlike the standard BAA on the HIPAA side
- GDPR compliance rests on a third-party attestation by DPLMC International rather than a certification under Articles 42 and 43, which is normal across the category but still means there is no accredited seal to point at
- No canonical GDPR program page yet, so the answers are spread across the privacy policy, the DPA page, and the subprocessor list
- Nothing scans training content for personal data; that review is yours
Best forEU controllers who need a chatbot deployment to survive a DPO review, and who are willing to evaluate the transfer mechanism rather than screening on hosting location.
If your organization also handles US health data, the HIPAA side has its own gate and a different contract: start with what makes a chatbot HIPAA compliant and do you need a BAA for your website chatbot.
Frequently asked questions
Does GDPR require EU data residency for a chatbot? No. GDPR does not mandate that personal data stay inside the EU. Chapter V permits transfers to countries without an adequacy decision when appropriate safeguards are in place, and the standard safeguard is the European Commission's Standard Contractual Clauses. EU hosting is one way to avoid the transfer question entirely, which is why vendors market it, but a US-hosted processor operating under SCCs is a lawful arrangement. The test is whether a valid transfer mechanism exists, not where the disk is.
What is the lawful basis for a customer service chatbot? Usually legitimate interests under Article 6(1)(f), or performance of a contract under Article 6(1)(b) where the chatbot is part of delivering a service the person has already signed up for. Consent is generally the wrong choice for a service chatbot, because consent must be freely given and revocable, and a support channel that stops working when consent is withdrawn is not a workable design. Consent remains the right basis for separate purposes layered on top, such as marketing follow-up.
Do you need a DPA with a chatbot vendor? Yes. Article 28 requires that processing by a processor be governed by a contract, and a chatbot vendor handling visitor conversations on your behalf is a processor. The contract has to cover the subject matter and duration, the nature and purpose, the types of personal data, security measures, subprocessor authorisation, assistance with data subject rights, and deletion or return at the end of the relationship. Without it, the arrangement is non-compliant regardless of how good the vendor's security is.
Are Standard Contractual Clauses enough for transfers to the US? They are the mechanism, but they are not a formality. Following the Schrems II judgment, a controller relying on SCCs must also assess whether the law of the destination country undermines them, and apply supplementary measures where it does. In practice that means documenting a transfer impact assessment rather than filing the SCCs and moving on. Where a US recipient is certified under the EU-U.S. Data Privacy Framework, that provides a separate adequacy route for that specific recipient.
Does SiteGPT offer EU hosting or data residency? No. The published subprocessor list names no EU-based subprocessor: Convex and Pinecone run in the United States on AWS, OpenAI and Cohere are United States, Cloudflare is listed as Global, and Paddle is United Kingdom. The privacy policy states that service providers are primarily located in the United States. Transfers for EU, EEA, and UK residents rely on the European Commission's Standard Contractual Clauses, plus the EU-U.S. Data Privacy Framework where the specific provider is certified.
Does SiteGPT have an EU representative under Article 27? Yes, and in both regions. The privacy policy names Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria as the representative in the European Union under Article 27 GDPR, and Prighter Ltd, 20 Mortlake High Street, London SW14 8JN as the representative in the United Kingdom under Article 27 UK GDPR. Article 27 is a hard requirement for non-EU controllers and processors offering goods or services into the EU, and it is frequently skipped, so it is worth confirming for any vendor.
How do you get a DPA signed with SiteGPT? DPAs are executed for Enterprise customers, and the security page states that a Data Processing Agreement is available for Enterprise customers for GDPR compliance. The DPA page provides a generator and states the agreement is binding only when signed by both parties. Customers on other plans should contact support rather than assume a self-generated document is executed. Note the honest gap against SiteGPT's HIPAA posture: the standard BAA is published in full for counsel to read in advance, and the DPA text is not.
Is SiteGPT GDPR compliant? Yes, and the accurate word is compliant rather than certified. The security page presents GDPR compliance and attributes the assessment behind it to DPLMC International. Treat any third-party attestation as supporting evidence rather than as an official certification, here and with every vendor, because a formal GDPR certification under Articles 42 and 43 requires a body accredited by a supervisory authority or a national accreditation body, and almost no vendor on a typical shortlist holds one. For a DPO's file, the load-bearing items are the signed DPA, the transfer mechanism, the subprocessor list, the Article 27 representatives, and the SOC 2 Type II report.
Sources
- GDPR Article 6 for the six lawful bases, read 9 August 2026
- GDPR Article 28 for the required contents of a processor contract
- GDPR Articles 13 and 14 for information that must be provided to data subjects
- GDPR Chapter V for transfers of personal data to third countries
- GDPR Article 27 for the representative requirement for organizations not established in the EU
- EDPB for guidance on supplementary measures following Schrems II
- SiteGPT privacy policy for the SCC and Data Privacy Framework wording, the Article 27 representatives, lawful bases, rights, and the statement that service providers are primarily located in the United States, verified 9 August 2026
- SiteGPT subprocessor list for every subprocessor and its stated country, verified 9 August 2026
- SiteGPT DPA page for Enterprise execution and the both-parties signature requirement, verified 9 August 2026
- SiteGPT security page for the SOC 2 Type II result and the GDPR compliance wording described above, verified 9 August 2026
Last updated: August 2026. All SiteGPT legal and security pages were read directly on 9 August 2026.