Why not just ask the model?

Short version: a support chatbot on an LLM that stores transcripts and serves customers in California, Germany and the UK is mainly a privacy and consumer-protection problem. The AI-specific rules are lighter than people expect, though a few apply. This is general information, not legal advice. Have counsel check the details before launch.

Laws that likely apply

Germany (EU)

• GDPR, plus the German BDSG. This is the heaviest obligation for you. Chat transcripts are personal data, and customers often type names, addresses, order details and sometimes health or payment information.
• EU AI Act. A customer-facing chatbot is generally a limited-risk system. The main duty is transparency: users must be told they are talking to an AI unless that is obvious. That duty applies from August 2026 (check current timelines, since the EU has discussed delaying parts of the Act). You are probably a "deployer" of someone else's model. You also need basic AI literacy among the staff who run it.
• ePrivacy / TTDSG (now TDDDG). Cookies, chat-widget scripts and similar tracking need consent in Germany.
• Consumer law. Don't mislead customers, and keep the right to reach a human for contract matters. Withdrawal and warranty information has to be correct.

UK

• UK GDPR and the Data Protection Act 2018. This is essentially the same as the EU rules, with the ICO as regulator.
• PECR covers cookies and similar tech.
• Consumer rights law (Consumer Rights Act and the Digital Markets, Competition and Consumers Act). There are no AI-specific statutes for chatbots yet.
• The Online Safety Act is mostly aimed at user-to-user and search services. A one-to-one support bot is usually out of scope, but check that it can't be used as a platform for user content.

California

• CCPA/CPRA. It applies if you meet the thresholds (roughly $25M+ revenue, or data on 100,000+ consumers/households, or 50%+ of revenue from selling or sharing data). You'd need a privacy notice, notice at collection, access, delete and correct rights, and opt-outs from sale or sharing.
• CalOPPA requires a privacy policy for any commercial site collecting data from Californians, regardless of size.
• California Invasion of Privacy Act (CIPA). This is a real litigation risk. Plaintiffs have sued companies over chat widgets and third-party chat vendors "eavesdropping" on conversations without consent. Disclose recording up front and get consent. Be careful about which vendors can see transcripts.
• California's bot disclosure law (SB 1001) prohibits using a bot to mislead people about its artificial identity in order to influence a purchase or vote. Disclosing it is the safe route anyway.
• Newer AI laws (for example the AI transparency and companion-chatbot rules) mostly target large model developers or companion bots. They probably don't reach you, but check them.

The age issue

Not checking ages is the weak spot.

• GDPR / UK GDPR: children get special protection. In Germany, consent from a child under 16 is not valid on its own. In the UK the age is 13. If you rely on consent, you need a way to handle minors.
• UK Age Appropriate Design Code (Children's Code): it applies to services likely to be accessed by children. An online store may or may not qualify.
• California: you can't sell or share data of consumers you know are under 16 without opt-in. The California Age-Appropriate Design Code is in litigation.
• US federal COPPA: this applies if you have actual knowledge you're collecting data from children under 13.
• Practical approach: you don't have to verify ages if the store isn't aimed at kids. State in your terms that the service is for adults, don't market to minors, and have a process to delete data if you learn a child used the bot. If you sell age-restricted goods (alcohol, knives, vapes), you have other age obligations anyway.

What to do

1. Tell users it's an AI. Put a clear label at the start of the chat, such as "You're chatting with an AI assistant. Chats are saved for quality review." Offer a path to a human.
2. Update your privacy notice to cover chat data: what you collect, why, legal basis (usually legitimate interests or contract, not consent), retention, who receives it (the LLM provider, hosting), international transfers, and user rights. Do this for GDPR, UK GDPR, CCPA/CPRA and CalOPPA.
3. Pick a legal basis and document it. For the EU and UK, write a short legitimate interests assessment for transcript review. Keep a record of processing activities. Do a DPIA if you do large-scale monitoring or profiling.
4. Sign a data processing agreement with your LLM vendor. Confirm they don't train on your data (or that you've disclosed it and have a basis), and check where data is processed. For transfers to the US, use the EU-US Data Privacy Framework if the vendor is certified, or standard contractual clauses, and the UK addendum or UK-US data bridge.
5. Minimize and set retention. Set a fixed period (say 30 to 90 days, or what you can justify), then delete or anonymize. Redact card numbers and credentials before storage. Tell the bot not to ask for sensitive data it doesn't need.
6. Handle rights requests. Be able to find and delete one person's transcripts for access, deletion, correction and opt-out requests. GDPR gives you one month to respond, and CCPA 45 days.
7. Control the vendors and cookies. Get cookie consent in Germany and the UK before loading chat scripts that set trackers. Audit which third parties see transcripts (CIPA exposure).
8. Limit what the bot can do. Don't let it make binding promises about refunds or prices without guardrails. Courts have held companies to what their bots said (the Air Canada case). GDPR Article 22 limits solely automated decisions with legal effect, such as refusing a refund automatically with no human review.
9. Secure it. Use encryption, access controls for staff reviewing transcripts, logging, and a breach response plan (72-hour notification to German and UK regulators).
10. Test for prompt injection and data leakage, so one customer can't pull out another's order data.
11. Name a contact. Because you serve people in the EU and UK, check whether you need an EU and UK representative if you have no establishment there. Appoint a DPO if your core activities require it.

Priorities

If you're short on time, do these first: the AI disclosure, an updated privacy notice, a DPA with the LLM vendor, a retention limit, and consent and notice for chat recording to cover CIPA. Then handle the age gap with an adults-only statement and a deletion procedure.

If you tell me your revenue, whether you're established in the EU or UK, and which LLM vendor you use, I can narrow this down.

At minimum, you’re dealing with privacy, AI-transparency, consumer-protection, cookie/tracking, and possibly children’s-privacy laws. The exact obligations depend on where your company is established, its size, what the model does, and which vendors receive the chats.

For California:

• The CCPA/CPRA applies if you do business in California and meet a threshold, roughly $25 million in annual revenue, processing personal information of 100,000 California consumers or households, or earning at least half your revenue from selling or sharing personal information. It requires notices, access/deletion/correction rights, opt-outs, and contracts with service providers.
• Even below those thresholds, CalOPPA generally requires a conspicuous privacy policy for commercial online services collecting Californians’ personal information.
• California’s bot-disclosure law can apply when a bot is used deceptively to encourage purchases. Clearly identifying the chatbot as AI is the safe approach.
• If chat data is provided to advertising or analytics companies, that may constitute “sharing,” requiring an opt-out and recognition of Global Privacy Control.
• Recording or allowing a third-party chat vendor to intercept conversations without adequate notice can raise California communications-privacy issues. Give notice before collection begins.
• If you sell or share minors’ data, California requires opt-in authorization for users under 16, with parental authorization under 13.

For Germany:

• The EU GDPR applies because you offer services to people in the EU. Chat messages, account details, IP addresses, identifiers, and model-generated profiles can all be personal data.
• You need a lawful basis for each use. Handling a customer’s support request can often rely on contract necessity or legitimate interests; optional analytics, marketing, or unrelated model training may need a different basis and sometimes consent.
• Germany’s BDSG supplements the GDPR, including rules affecting data-protection officers.
• Cookies or similar storage used by the chatbot are also subject to Germany’s TDDDG. Nonessential analytics and advertising technologies normally require prior consent.
• The EU AI Act requires people interacting with an AI system to be informed that it is AI unless that is already obvious. It also requires appropriate AI literacy for staff operating it. An ordinary support bot is normally not “high-risk,” unless it is used for consequential decisions in a regulated area.

For the UK:

• The UK GDPR and Data Protection Act 2018 impose requirements similar to the EU GDPR, but compliance and international-transfer mechanisms must be handled separately.
• PECR governs cookies, similar tracking, and electronic marketing.
• The UK Children’s Code matters if the service is likely to be accessed by anyone under 18, even if children are not the intended audience.

Not checking ages does not make children’s laws disappear. In the US, COPPA applies if the service is directed to children under 13 or you have actual knowledge that a user is under 13. In Germany, parental authorization can be required below age 16 when consent is the basis for an online service; the UK threshold is 13. You should assess whether children are realistically likely to use the store. If they are, either implement proportionate age assurance and parental-consent processes or design the chatbot to meet child-protective standards for everyone. A terms clause saying “18+” is not necessarily enough.

Before launching, you should:

1. Show a notice before the first message stating that the customer is speaking with AI, that the conversation will be stored and reviewed, why it is retained, and where to find the privacy notice.

2. Publish a privacy notice covering the chat data, purposes, lawful bases, retention periods, recipients, international transfers, user rights, and whether conversations are used to train or improve models.

3. Decide whether transcripts are used only for support and quality review or also for model training, advertising, profiling, or marketing. Treat those as separate purposes; do not assume that agreeing to support also authorizes training.

4. Set a specific retention period and automate deletion. “We may keep chats indefinitely” is difficult to justify. Preserve particular records longer only where needed for an active dispute, legal obligation, fraud investigation, or documented business need.

5. Sign data-processing agreements with the model provider, hosting company, and chat vendor. Require confidentiality, security, deletion, breach reporting, controlled subprocessors, and contractual prohibitions on unauthorized training, advertising, sale, or sharing.

6. Address international transfers. EU data sent outside the EEA may require Standard Contractual Clauses and a transfer assessment. UK data may require the UK IDTA or UK Addendum. A non-EU or non-UK company may also need local representatives.

7. Build processes for access, deletion, correction, objection, restriction, portability, and California opt-out requests. Make sure deletion reaches vendors and backups as appropriate.

8. Minimize sensitive information. Tell users not to enter payment-card numbers, passwords, government IDs, health information, or other unnecessary sensitive data. Add automated redaction where practical.

9. Secure the system with encryption, restricted staff access, audit logs, vendor controls, prompt-injection defenses, testing for leakage between customers, and an incident-response process.

10. Provide human escalation, especially for refunds, account closure, fraud accusations, warranty rights, or other decisions with meaningful consequences. Do not let the bot invent store policies or deny statutory consumer rights.

11. Perform and document a privacy impact assessment if the system involves extensive monitoring, profiling, sensitive information, children, or other high-risk processing. Also document any legitimate-interests assessment.

12. Check the chatbot’s cookies and SDKs through your consent-management system. Do not load nonessential trackers before valid consent in Germany or the UK.

A sensible default is: disclose the AI immediately, use transcripts only for support and tightly controlled quality review, disable vendor training and advertising, retain chats briefly, avoid sensitive data, provide human escalation, and apply strong privacy settings to every user until you have a defensible age-handling process. Have privacy counsel confirm the final design, particularly the CCPA thresholds, children’s access, cross-border transfers, and any use of chats for training or profiling.

Your biggest exposures are privacy law, for the transcripts, and the AI-disclosure rules. The age-check question is mostly a non-issue for a support bot, with one caveat below. My research leaned on law-firm and vendor write-ups rather than the statutes themselves, so confirm the specifics with counsel before you rely on them.

Germany (EU): GDPR and the EU AI Act

• GDPR applies to the transcripts. They contain personal data (names, addresses, order details, anything customers type). You need:
  • a lawful basis, probably legitimate interests or contract performance for support, and a documented reason for reviewing transcripts;
  • a privacy notice that mentions the chatbot, the transcript review, and your LLM provider;
  • a written data processing agreement (Article 28) with the LLM vendor, covering purposes, data types, retention and sub-processors;
  • a transfer mechanism if the vendor processes data outside the EU or EEA;
  • a retention period you can justify, with deletion after it. Don't keep transcripts indefinitely "just in case";
  • a way to handle access and deletion requests that reach into the transcripts.
• Consider a DPIA (data protection impact assessment). Routine support chat probably isn't high risk on its own. Do one if you start profiling customers or using transcripts to train models.
• EU AI Act, Article 50. Sources I found say the chatbot disclosure duty has applied since 2 August 2026. Customers must be told at or before first interaction that they are talking to an AI, unless that is obvious. A short line such as "You're chatting with an AI assistant" at the start of the chat does it. The sources disagree on some Article 50 timing, but only for the machine-readable marking of AI-generated content (Article 50(2)). That is the provider's job, not yours as a deployer of a support bot. A support bot is not a high-risk system under the Act. Penalties for transparency breaches are reported as up to €15 million or 3% of turnover.
• German-specific: Germany has its own ePrivacy and telemedia rules on storing or reading information on a user's device (the TTDSG/TDDDG). If your chat widget sets cookies or similar storage that isn't strictly necessary, you may need consent. I did not research this in detail.

UK: UK GDPR and the Data Protection Act 2018

The rules are essentially the same as the EU GDPR points above: lawful basis, transparency, a processor contract, a lawful route for any international transfer, and storage limitation. The ICO's guidance on purpose limitation, data minimisation and storage limitation is the baseline for how long you keep transcripts. I could not find ICO guidance specific to chatbot transcripts, and I did not confirm what the Data (Use and Access) Act 2025 changes here. The UK has no AI-specific statute with a chatbot disclosure rule. Consumer-protection law still applies, so don't present the bot as a human or mislead customers. You may need a UK representative or a separate registration step, depending on how you're set up. Check this.

California

• CCPA/CPRA. This applies only if you meet the thresholds (roughly $25M+ in revenue, or data on 100,000+ consumers, or most of your revenue from selling or sharing data). Verify the current figures. If it applies:
  • give a notice at collection that covers the chat data;
  • disclose the categories of data in your privacy policy;
  • honor access, deletion and opt-out requests;
  • have a contract with your LLM vendor that restricts it to a service-provider role, with no selling or sharing of the data. The California Privacy Protection Agency has also written rules on automated decision-making technology. I could not confirm their current status or dates, and they look aimed at significant decisions rather than support chat.
• Wiretap claims (CIPA). This is the practical California risk for chat transcripts. Plaintiffs have sued websites under California Penal Code sections 631 and 632.7, and also under a "pen register" theory (section 638.51), arguing that a third-party chatbot vendor intercepts conversations. Statutory damages are $5,000 per violation. The case law is mixed and the material I found was mostly from 2023 to 2024, so I can't tell you where it stands now. Reduce the risk by:
  • disclosing at the start of the chat that it is an AI and that conversations are recorded and shared with your service provider;
  • using a vendor that is contractually barred from using the chat data for its own purposes;
  • getting a clear acknowledgement from the customer where practical.
• Bot disclosure. California's older bot law (SB 1001, 2018) requires disclosure when a bot is used to influence a purchase or a vote and the person could be misled into thinking it's human. I'm going from memory on that one. The same "tell them it's AI" line covers you.
• SB 243 (companion chatbots). This is the new California chatbot law, in effect since 1 January 2026. It does not apply to you. It exempts bots used solely for customer service, business operations or technical support. That also covers the age and minors provisions, which is why not checking ages is generally fine here. It would matter if the bot started acting like a companion or friend. It has a private right of action.

What to do

1. Put an AI disclosure at the start of every chat. Add a line saying conversations are recorded and processed by a service provider, linked to your privacy policy.
2. Update the privacy policy for the chatbot, the transcript review and the LLM vendor, with notices that fit the EU, UK and California.
3. Sign a data processing agreement or service-provider contract with the LLM vendor. Check training opt-outs, sub-processors, data location and the retention it applies. Use business or API terms, not consumer terms.
4. Set and enforce a transcript retention period. Restrict who can read transcripts, and consider redacting payment card numbers and other sensitive details automatically. Tell customers not to share card numbers in chat.
5. Give people a human option and a route to make data requests.
6. Keep a short record of your assessment: lawful basis, transfers, retention, vendor review, and whether a DPIA was needed.
7. Stop the bot from handling anything outside support. If it gets into health, vulnerable users or personalized decisions, revisit all of this. On age, nothing requires checks for a store support bot, but if minors might use the store, take extra care with what the bot collects and says.

If you tell me the LLM vendor, where it processes data, how long you keep transcripts and your rough revenue, I can narrow this down.

Short version: disclose that it is AI, give notice before collecting the first message, minimize and secure transcripts, put proper terms around the model provider, and either assess age or make the service safe for children by default. Not checking ages is not automatically unlawful in California, but it is a much bigger problem in the UK.

The principal laws are:

• Germany: EU GDPR, the German BDSG, the EU AI Act, and, if the widget uses cookies or local storage, the German TDDDG. Consumer-protection rules also prohibit misleading customers.
• UK: UK GDPR and the Data Protection Act 2018 as amended, PECR for cookies/device storage, the Children’s Code, and consumer-protection law. The EU AI Act does not govern UK interactions merely because the customer is in the UK.
• California/US: the FTC Act, COPPA, CalOPPA, California’s bot-disclosure law, breach-notification and security laws, and potentially the CCPA/CPRA. California wiretap litigation also creates risk when an undisclosed third-party chat or analytics provider intercepts conversations.

Here is what I would implement.

1. Put a notice at the entrance to the chat. Before the customer types anything, say something like:

You’re chatting with an AI assistant. Messages are stored and may be reviewed by our staff to resolve requests and improve support. Please don’t enter passwords, full payment-card details, government ID numbers, or sensitive medical information. [Privacy notice] [Talk to a person]

In the EU, the AI Act’s chatbot transparency rule has applied since August 2026: people must be told they are interacting with AI unless that is already obvious. An ordinary support chatbot is normally a transparency-risk system, not a high-risk system. The information must be clear, distinguishable, accessible, and given by the first interaction. Staff responsible for it also need appropriate AI literacy. European Commission AI Act overview https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

California’s bot law is narrower: it concerns intentionally misleading someone about a bot’s artificial identity to deceive them in a commercial transaction. Nevertheless, a clear up-front disclosure is the sensible compliance position.

2. Publish a chatbot-specific privacy notice. Identify the company controlling the data and explain:

   • What the chat records: messages, account/order identifiers, timestamps, IP/device data, and any inferred classifications.
   • Why each item is used: answering the request, fraud/security, quality review, and, only if applicable, model training.
   • Your legal basis in Europe and the UK.
   • Who receives it, including the model, hosting, logging, and support vendors.
   • Where it is processed, how long it is retained, and how people exercise access, deletion, correction, objection, and complaint rights.
   • Whether the bot makes decisions and how customers reach a human.

For order support, performance of a contract may cover processing genuinely necessary to handle the order. Quality review, security, and service improvement may fit legitimate interests, but document a legitimate-interests assessment. Do not use “consent” as a blanket justification merely because someone opened the widget. The GDPR and UK GDPR require purpose limitation, minimization, storage limitation, security, and accountability. EU GDPR https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng, ICO data-protection principles https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/

3. Treat training as a separate purpose. Do not quietly reuse support conversations to train your model or permit the LLM vendor to train its general models on them. If you want training data, assess and document a separate lawful basis, update the notice, remove direct identifiers, filter sensitive information, and provide any required objection or consent mechanism. In practice, configure the vendor for no secondary use and no general-model training.

4. Set a real retention period. “We keep chats in case they are useful” is not sufficient. Choose a period tied to a documented need, for example, a relatively short period for raw transcripts, then delete or irreversibly anonymize them. If a dispute, warranty, or accounting obligation requires particular facts for longer, extract those facts into the relevant customer record instead of keeping every raw conversation indefinitely. The FTC’s amended COPPA rule likewise prohibits indefinite retention of covered children’s data. FTC COPPA amendments https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-finalizes-changes-childrens-privacy-rule-limiting-companies-ability-monetize-kids-data

5. Control what enters the model. Do not ask for card security codes, passwords, government identifiers, or special-category data. Redact payment data and secrets before sending prompts to the provider. Restrict employee access, log access, encrypt transcripts, test account separation, and have deletion and breach-response procedures. If customers volunteer health, religion, ethnicity, or similar data, EU/UK special-category rules may apply; prevention and prompt deletion are safer than assuming permission.

6. Fix the vendor contract and transfers. The LLM and hosting companies will usually be processors for this use. Put Article 28/UK-equivalent processing terms in place covering instructions, confidentiality, security, subprocessors, deletion, audits, breach notification, and a ban on independent reuse. For California, use CCPA service-provider/contractor restrictions; otherwise vendor reuse can undermine that status.

If EU or UK conversations leave their jurisdiction, document an approved transfer mechanism. For the EU that might be an adequacy decision, including an appropriately certified US participant, or SCCs plus a transfer-impact assessment. The UK has its own adequacy and contractual mechanisms. EDPB international-transfer guidance https://www.edpb.europa.eu/sme/be-compliant/international-data-transfers_en

7. Handle rights operationally. Be able to find, export, correct, and delete a person’s transcript across your database, logs, backups, and vendors. Authenticate requests without collecting excessive new identity data. Maintain a processing inventory and perform a DPIA if the system is likely to create high risk, for example, systematic profiling, children at scale, sensitive data, or consequential automated decisions. The ICO specifically expects an identified lawful basis, minimization, and documented assessment for AI processing. ICO AI governance guidance https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/governance-and-accountability-in-ai/

8. Provide human escalation and limit decisions. A basic FAQ or order-status bot is ordinarily low risk. Do not let it make final decisions about fraud accusations, account termination, credit, legal claims, or similarly significant customer rights without a suitable human process. Test for fabricated policies, unauthorized refunds, discriminatory treatment, and prompt-injection leakage.

The age issue needs its own decision:

• US/COPPA: A genuinely general-audience store is not required to investigate every visitor’s age. COPPA applies if the service is directed to children under 13 or you have actual knowledge that you are collecting from an under-13 child. A message such as “I am 12” can create actual knowledge. You then need a process to stop collection/delete the chat or obtain verifiable parental consent and provide the other COPPA protections. A terms clause saying “no children” does not cure a child-directed service. FTC COPPA guidance https://www.ftc.gov/business-guidance/resources/childrens-online-privacy-protection-rule-not-just-kids-sites

• California: If you are covered by the CCPA, selling or sharing data of a person you actually know is under 16 requires opt-in authorization, with parental authorization below 13. The easiest position is not to sell or share chat data at all. CCPA coverage generally requires a for-profit business doing business in California that meets at least one threshold: $26.625 million annual revenue, buying/selling/sharing data of 100,000 California consumers or households, or deriving at least half its revenue from selling or sharing their data. Covered businesses must give notice at collection and honor access, deletion, correction, opt-out, limitation, and non-discrimination rights. CPPA coverage and rights https://cppa.ca.gov/faq, current revenue threshold https://www.cppa.ca.gov/regulations/cpi_adjustment.html

• UK: If children under 18 are likely to access the store, the Children’s Code is probably relevant even if they are not your target audience. You should conduct and document an age-access assessment. Either use proportionate age assurance or apply the Code’s child-protective settings to everyone: high privacy by default, minimal collection, child-readable explanations, no manipulative nudges, and no unnecessary profiling. ICO Children’s Code https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/

• Germany/EU: Germany’s GDPR age for a child’s own consent to an information-society service is 16. That rule matters only when consent is your legal basis; it does not mean every customer-support interaction needs parental consent. Children still receive heightened fairness and transparency protections.

So the practical choice is: use a neutral age screen before accepting free text and route minors appropriately, or build the chatbot to the UK child-safe standard for everyone. Simply declining to ask age, while retaining whatever children submit, is the weakest option. If your company is outside the EU and UK but deliberately sells into Germany and the UK, also check whether you need separate EU and UK representatives; a DPO is required only if the statutory tests are met.