An accountancy or law firm needs a clear pre-chat notice saying the visitor is speaking to AI, what data the bot collects, who receives it, how long transcripts are kept and how to reach a person. It also needs a documented lawful basis and a record of any consent actually requested. Consent is not automatically required for every chat.
Before writing a checkbox, map the data flow. A simple FAQ bot that answers from public pages creates different risks from one that invites a visitor to describe a tax dispute, upload a contract or book an appointment. UK and EU GDPR rules, applicable US state privacy laws and professional confidentiality duties may differ. Have qualified privacy counsel confirm the basis and notice for the firm's actual markets and use case.
Separate an AI disclosure from a legal consent choice
The first message should make the interaction plain: a visitor should not have to discover after typing that responses came from AI. That disclosure is an interface promise. A privacy notice explains the processing. A consent request is a separate mechanism used only when the firm's legal assessment says consent is the appropriate basis for a particular purpose. The ICO's consent page says organisations do not always need consent: they can rely on any of six lawful bases, of which consent is one. Nothing there says a chatbot always needs consent. The ICO also flags that this guidance, like its special-category guidance, is under review following the Data (Use and Access) Act, so check the current version before finalising wording.
A useful distinction for an accountancy firm: answering “What documents should I bring to an introductory meeting?” may use little personal information. Asking “Upload your financial records and I will assess the tax treatment” would process much more sensitive material and risks implying professional advice. The latter should be outside a public bot's scope unless the firm has a separately designed, reviewed service. A banner that says “By chatting you consent to everything” does not solve that design problem.
Write down each purpose and data category before choosing wording. For example: answer public service questions; collect a name and contact detail for a callback; keep a transcript for quality review; use chat data to improve the vendor's model; send marketing messages. These are distinct purposes. The firm may permit the first two, limit the third, prohibit the fourth and require a separate choice for the fifth. Ask counsel which legal basis applies to each in the relevant market. Avoid bundling optional marketing or model-training permission into the condition for a basic enquiry.
For a law firm, confidentiality adds a separate concern: a visitor may think a chat creates an adviser-client relationship or gives legal advice. The opening should state that the bot provides general information, cannot assess a case or accept urgent instructions, and offers a person to contact. That is not a substitute for advice on the firm's professional duties. The wording should match the bot's actual behaviour. A disclaimer is misleading if the bot proceeds to ask for detailed case facts or offers a definitive legal conclusion.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowPut a short notice before the text box
Use two layers: a concise notice at the point of interaction and a linked privacy notice with full details. The short layer needs to fit a small screen and be understandable without opening the full policy. Say who operates the bot, that it is AI, the purpose of the chat, a data-minimisation instruction, a link to retention and rights information, and a human alternative. If the bot sends transcript data to a supplier, explain that plainly. Do not claim “your chat is private” without checking who can access or use it.
Illustrative short wording for a firm whose counsel has approved the underlying setup: “You are chatting with an AI assistant for general service information. Please do not enter account numbers, documents, health information or details of a legal matter. We may keep your message and contact details to respond to your enquiry as described in our privacy notice. Ask for a person at any time.” The firm must replace the retention and purpose sentence with its actual policy. If messages are not retained, say that accurately; if a vendor retains copies, do not imply they disappear when the widget closes.
A more explicit opt-in might be needed for a particular optional purpose. Illustrative wording: “I agree to the firm using this chat transcript to send me follow-up marketing messages.” That box should be separate from the basic chat, unticked by default where consent is the chosen basis, and accompanied by a way to withdraw. The exact legal standard varies by jurisdiction and channel, so have counsel approve it. Never make a required service question depend on optional marketing permission if there is no lawful reason to do so.
The longer privacy notice should identify the firm, contact route, purposes, data categories, lawful basis or other required explanation, supplier and other recipients, transfers where relevant, retention or criteria for it, rights, complaints route and any automated decision-making that truly occurs. Do not copy a general website policy and add the word “chatbot” at the end. Trace the widget, analytics script, CRM handoff, email notifications, backups and vendor logs. If one system retains data longer than the public notice says, the notice is wrong.
Keep a record of the choice the visitor actually made
If the firm relies on consent for a purpose, it must be able to demonstrate what the person saw and did. The European Data Protection Board's consent guidelines suggest keeping a record of consent statements so the firm can show how and when consent was obtained and what information the person was given at the time. A database field marked “yes” is weak evidence if nobody can recover the notice version and the action that produced it. A screenshot of today's widget does not show what a visitor saw six months ago.
A practical log schema is: pseudonymous session ID, notice version, purpose ID, choice offered, choice made, time, channel, source page, withdrawal time if any, and the system that received the choice. Keep the log separately from unnecessary transcript detail and protect access. Do not store more identifying data in the consent log merely to prove consent; the same guidelines say the duty to demonstrate consent should not itself lead to excessive additional processing. The firm needs a retention plan for both the choice record and the underlying chat, reviewed by counsel; a one-size-fits-all number of months would be invented here.
An illustrative filled-in entry could read: “session 8F2; notice v3; purpose MARKETING-EMAIL; choice declined; 10:42; service-page chat; CRM flag no marketing; no transcript sent to marketing list.” A second entry could record “choice accepted” and the exact notice version. The point is operational: the marketing system must honour the choice, and a reviewer must be able to retrieve the evidence. Do not fabricate a consent record for visitors who were never asked to consent. For a purpose using another lawful basis, record the firm's assessment and notice version rather than inventing a checkbox event.
Test withdrawal from the visitor's perspective. If a person withdraws marketing consent, can staff identify the right record without exposing the full chat to the marketing team? Does the CRM update before the next campaign? Does withdrawal affect only the consent-based purpose, while any independently justified record retention is assessed separately? A “delete everything” button may conflict with legitimate recordkeeping duties; a “we can never delete anything” statement may also be wrong. Counsel should settle the retention and rights route for the specific processing.
Keep special-category and confidential material out of public chat
A professional-firm visitor may type health details, allegations, identity numbers, financial account data or information about another person even when the bot asks only for a name. Under UK and EU GDPR, special-category data has additional conditions; the ICO guidance describes extra documentation and a relevant condition. A small firm's public bot should be designed to avoid collecting such material, not to rely on a generic “I agree” box as a cure. US state definitions of sensitive information vary, so review the applicable notice and rights rules separately.
Configure the bot to ask only for the minimum needed for a safe handover, perhaps topic category, name, contact method and a convenient callback window. Do not invite uploads, account numbers or detailed case narratives in a public chat. Add a route for an urgent or sensitive matter that goes to the firm's approved secure channel. If a visitor enters restricted material anyway, the bot should stop elaborating, avoid repeating it in its answer, and route the event for controlled handling under the firm's incident and retention procedures.
Illustrative failure: a visitor writes, “My parent has a medical condition and I need advice on their estate.” An unsafe bot asks for diagnosis and asset details. A safer response is, “Please do not share medical or financial details here. I can arrange for a member of the team to contact you through the firm's usual process.” The bot should then collect only the minimal callback details approved by the firm. The test is whether the transcript was already sent to analytics, a model-improvement programme or an unapproved inbox before the guardrail acted.
Another failure is an accountancy bot that asks a potential client to upload a payroll file “for a quick estimate”. Even if the firm never intended to store it, the supplier may hold uploads, previews or logs. Disable file uploads if they are not needed. Check the bot's sample conversation, widget settings and vendor agreement, then run a synthetic upload attempt. If an upload slips through, follow the firm's incident procedure and repair the configuration before launch. The chatbot misuse tutorial covers hostile prompts; ordinary visitors can create equally serious data-handling problems without hostile intent.
Work through a 30-day pilot with a record trail
Consider an illustrative six-person accountancy practice adding a public FAQ bot to its service pages. Its approved purpose is to answer opening-hour and service-scope questions and offer a callback. The firm does not let the bot inspect client accounts, upload files or give tax advice. It sets an illustrative 30-day internal pilot, not a legal retention period. The firm expects 120 chats based on its own planning estimate and assigns one operations lead to sample transcripts and handle escalations. No market conversion rate is assumed.
Before launch, the operations lead maps eight data points: page URL, session ID, message text, optional name, optional contact detail, bot response, handover reason and staff reply. Counsel and the privacy lead decide which are necessary, where they are stored and how long each is kept. The firm saves notice version 1 and a synthetic chat showing it appears before input. It tests a visitor who refuses optional marketing, one who asks for a person, one who types sensitive details, and one who closes the chat without submitting. Each path has a recorded expected result.
After 30 days, suppose the bot handled 96 chats, offered 18 human handovers and collected contact details in 11. These illustrative figures show how to audit the process, not a success benchmark. The lead checks all 11 contact records against the visitor's choice, samples 20 other chats for accidental sensitive content, confirms that the vendor export contains the agreed fields, and verifies that a deletion or access request can be routed. If three chats contain sensitive details despite the warning, the firm changes the prompt and form design, then tests again. It does not declare success because the bot answered 96 questions.
The pilot's release gate has four parts: notice version visible before chat; forbidden collection paths disabled or redirected; transcript and choice records retrievable according to policy; and human handovers reaching the correct team. The firm also checks that the bot's public answers stay within approved FAQ content. The chatbot launch test tutorial covers answer quality; consent management here concerns the evidence and handling around those answers.
Check vendor settings against the words on your site
Ask the supplier to show, in the actual plan and account, whether chat content is used to train models, what logs are retained, who can access transcripts, where data goes when exported, whether uploads can be disabled, and how deletion requests are handled. Inspect analytics and any connected CRM or help desk as well as the chatbot dashboard. A vendor may have a secure main product while an optional integration sends the same message elsewhere. Record the setting names and screenshots at launch, then review after material product changes.
Do not state that a generic “privacy mode” solves every duty. If the vendor says transcripts are deleted after a period, ask whether backups, audit logs and downstream CRM copies follow the same rule. If it says data is not used for training, ask whether that applies to every feature and subcontractor in the selected plan. If a chatbot can read your knowledge base, ensure it cannot retrieve internal client files accidentally. The chatbot vendor questions tutorial helps with procurement; the site's notice must still reflect the final contract and configuration.
US state privacy notices require a separate applicability check. The California Attorney General's CCPA page, for example, describes notice and rights obligations for the businesses that law covers, and lists three coverage tests for a for-profit business: gross annual revenue above a stated threshold, buying, selling or sharing the personal information of 100,000 or more residents or households, or earning half or more of annual revenue from selling such information. Many small firms meet none of them, so that statute does not apply automatically. Other state regimes differ. Use counsel to map where visitors and clients are, which rules apply, and whether the chatbot triggers additional disclosures or opt-outs. Keep the public notice accurate for the actual processing instead of claiming one checkbox satisfies every jurisdiction.
Run a choice-to-record drill before the firm uses real visitor data. In a test browser, decline the optional marketing box, send a harmless question and ask for a callback. Export the session record, the consent log and the CRM entry. The expected result is a callback task with no marketing permission and a recoverable notice version. Repeat with consent accepted, then withdraw it through the published route. Check that the CRM flag changes before a test campaign list is built. If the widget records the acceptance but the CRM ignores the withdrawal, the process is broken even though the front-end notice looks correct.
Also test the visitor who opens the widget, reads the notice and leaves without typing. That person has not supplied a chat transcript or made a marketing choice. The team should check what the widget still logs, such as a page view, device identifier or analytics event, and whether the site's cookie controls apply. A test without JavaScript should leave a visible contact option so the firm does not make the chatbot the only route to a person. Record the results as a short release note: test date, notice version, expected record, actual record, owner and corrective action. A repeatable drill matters more than a polished screenshot.
Audit the live site after the first change
A notice can become stale when a marketing team enables transcripts in the CRM or a supplier adds a model-improvement switch. Put the bot in the firm's change register. For each change, record what data fields or recipients changed, whether the lawful-basis assessment still fits, whether the short notice and privacy policy need new versions, and whether existing choices can be honoured. Retest the visitor path on mobile and without JavaScript where the site still offers a contact route.
An illustrative change ticket might say: “Bot now sends callback enquiries to the CRM. Name, phone and enquiry category added to the CRM; transcript body excluded. Notice updated from v1 to v2 before enabling integration. Synthetic refusal and handover tests passed. Privacy lead approved; counsel reviewed retention.” That record is more useful than “chatbot updated”. It shows the relationship between the words the visitor saw and the technical path the data took.
If the firm cannot answer where a transcript goes, how a visitor's choice is recorded, or how a person can take over, leave the chatbot in test mode. A qualified privacy adviser can settle the legal basis and retention questions; the firm can still do the practical mapping now. A clear notice, minimal collection and a retrievable record trail make the service understandable to visitors and manageable for staff.
Further reads
- AI Chatbot Disclosure: What to Tell Customers at the Start of a Chat — Compare the opening disclosure against the visitor experience.
- What to Check in an AI Tool's Privacy Policy and Terms — Inspect processing and retention clauses.
- Who Is Liable When Your AI Chatbot Gets It Wrong? — Plan responsibility for inaccurate responses.
- When Should an AI Chatbot Hand Over to a Human? — Design a route to a person.
- AI Insurance Lead Generation: Follow-Up Rules Before You Automate — An eight-check pre-send gate for insurance lead follow-up: consent records, calling windows, opt-outs, and what AI may draft versus a licensed person.
- ICAEW AI Guidance for Small Practices: A Client Notice and Staff Checklist — ICAEW's generative AI guide turned into a client notice, terms-of-business wording and a one-page staff checklist for a small accountancy practice.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: ICO Does an organisation need my consent?; ICO What are the rules on special category data?; European Data Protection Board Guidelines 05/2020 on consent (paragraphs 106-108); California Attorney General CCPA page (updated 28 August 2026).