data privacy and AI — where's your red line?
we talk a lot about AI accuracy on this forum but not enough about data privacy. so let me ask directly:
where do you draw the line on what client data goes into an AI model?
my current rules:
- ✅ sanitised/anonymised financial data (amounts, categories, no names)
- ✅ generic tax questions with no client identifiers
- ✅ skills files and statutory references (public info)
- ❌ client names, PPSNs (Irish tax IDs), addresses
- ❌ bank statements with account numbers
- ❌ engagement letters or correspondence
- ❌ anything from a client who hasn't consented
but here's where it gets grey:
- what about a P&L that doesn't name the client but has such specific numbers that the business is identifiable?
- what about prompts like "my client is a Dublin-based fintech with 50 employees" — no name, but pretty narrow
- what about using AI to draft client emails? the OUTPUT might be fine but you've leaked the context
i use local-runtime agents (Claude on my machine) for anything even slightly sensitive. cloud models only for generic research. but i know not everyone has the hardware for local models.
genuinely want to know where others draw the line. especially EU practitioners dealing with GDPR.
5 replies
DSGVO (GDPR) practitioner perspective: technically, ANY processing of personal data — including feeding it to an AI model — requires a legal basis under Art. 6 GDPR. most of us are relying on "legitimate interest" or "contractual necessity" but neither has been tested in court for AI-assisted tax work.
my red line: if the data could identify a natural person, it doesn't go into a cloud model. period. Steuergeheimnis (tax secrecy under §30 AO) adds another layer in Germany — we're legally bound to protect client tax data beyond what GDPR requires.
local-runtime only for client data. no exceptions.
la CNIL (French data protection authority) issued guidance in 2024 specifically on AI and professional services. key point: using a cloud AI model to process client personal data requires either explicit consent or a data processing impact assessment (DPIA).
i did a DPIA for our firm's AI workflow. took 2 days but now we have a documented, defensible process. happy to share the template if anyone wants it (anonymised obviously).
Malta's Data Protection Act basically mirrors GDPR so same rules apply. in practice though — small jurisdiction problem. "a Maltese company in the iGaming sector with revenue of €Xm" narrows things down FAST. even "anonymised" data can be re-identifiable here.
i strip everything. amounts get rounded to the nearest €10k. industry gets genericised. dates get fuzzed. only then does it go into a cloud prompt.
is it overkill? maybe. but the reputational risk of a data incident in a market where everyone knows everyone is existential.
Australia's Privacy Act is being reformed right now — the new version will likely have stricter rules on AI and automated decision-making. CA ANZ has flagged this as a watch area.
practically: i use Cursor (local) for anything with client data. cloud Claude only for generic research where i've removed all identifiers. the OpenAccountants skills are public info so no issue there.
the email drafting point mike raises is underappreciated. if you ask AI to "draft a response to my client about their rental property deduction query" you've just told the model your client has a rental property. that's tax return information.
US perspective is different — no federal equivalent to GDPR for tax data specifically. but IRC §7216 restricts disclosure of tax return information. feeding client return data into a cloud model is arguably a "disclosure" under §7216 that requires consent.
my consent form now covers this explicitly. most clients sign without issue but a few HNW clients have pushed back. those clients get manual-only service. it's a cost of doing business.
Sign in as a verified accountant to reply.
Sign in