Privacy and Compliance
8 min readHow to use frontier AI on data without exposing it
No firm needs to train its own AI model to use AI safely on client data. What it needs is a scrub-and-send pipeline in front of a model that already exists: scrub identifiers locally, send placeholders, log every request, restore the real names on return. Here is how the pipeline works, when the expensive options earn their place, and how it lines up with Canadian and UK privacy rules.
Every few weeks someone tells a firm it needs its own AI model. It doesn't. A firm that wants to use AI on client data needs a clean pipeline in front of a model that already exists, not a model of its own. Using AI on your data is a privacy and plumbing problem, and neither one gets fixed by training anything. Let the big guns with deep pockets and funding keep improving their models. We should just be consumers.
I run HuCortex, where we support firms across many industries. I'll use accounting firms as the example here, but the same approach applies elsewhere. Accounting firms hold other people's SINs, bank accounts and payroll files. The question I hear most is some version of: do we have to train our own model to keep the data safe? No. You need a clean pipeline in front of a model that is already good at accounting.
The model was never the problem
A current frontier model can categorize transactions, summarize a trial balance and draft a client letter with a few good examples in the prompt. Skill is rarely what's missing.
What's missing is a way to send it real client work without sending real client identity. People skip that part, then decide training is the fix. Training teaches a model behavior. It doesn't hand the model your documents, and it doesn't keep names out of your logs.
How does the scrub-and-send pipeline work?
The model never sees a real client. It sees placeholders, and your people see real names again on the way out. Six steps, all but one of them inside your own environment.
- Ingest locally. Documents land on a machine you control. Nothing leaves yet.
- Scrub. Names, SINs, account numbers, addresses, emails and phone numbers get detected and replaced with placeholders like CLIENT_0412 or ACCT_7731.
- Index. The mapping from placeholder to real value goes into a local index file. It never goes to the model and never leaves your environment.
- Send. Only the scrubbed text goes to the API.
- Log. Every request and response is stored as your audit trail. If a client asks what you sent, you can show them.
- Rehydrate. When the answer comes back, placeholders are swapped for the real values before a human reads it.

The model reasons about CLIENT_0412 the same way it would reason about a real name. The accountant reads a normal answer with real names in it.

Two details that matter more than they look
The audit log holds scrubbed payloads, so it proves what left your building without becoming a second copy of your clients' identities. Two choices decide whether the rest of the design holds up.
- Use random or keyed placeholders, not plain hashes. A plain hash of a nine-digit SIN can be brute forced, because the number of possible values is small.
- Treat the index file as the crown jewel. Encrypt it, restrict who can read it, back it up. It's the only thing that can undo your scrubbing.
When does training or self hosting earn its place?
Almost never. Run the cheap, reversible options first, and stop at the first one that works. Each step up the ladder adds cost, upkeep and lock-in, so earn it with a test set of real examples.
- The model is missing information. That's retrieval (RAG): the chart of accounts, firm policies, current CRA guidance. Tax rules change every year, and facts baked into weights go stale.
- It's wrong even with the information in front of it. Better prompts, better examples, or a stronger model.
- It's right but too expensive at volume. Route routine work to a small hosted model and escalate the hard cases to a frontier one.
- It's right but inconsistent in format. Structured outputs first, fine tuning last.

Self-hosting GPUs only pays off with steady, high utilization or a client contract that demands on-prem processing. For most firms, the API bill is lower than hardware, power and the engineer time to keep it running. Count that last one honestly.
If a client needs more control than a public API gives, try the middle option first: run a frontier model inside your own cloud tenant, in a region that meets your residency needs, before you buy a single GPU.
A custom model is also a weak advantage. Your data hygiene and your client relationships are worth more than a model nobody else needs.
This works beyond accounting
Accounting is the example here, but nothing in the pipeline is specific to it. Any job where a capable model has to read sensitive material can work the same way: scrub locally, send placeholders, restore on return.
We run it on our own log reviews at HuCortex. Security and IT logs are full of usernames, hostnames, IP addresses and email addresses. Those get swapped for placeholders before a model looks for patterns, and swapped back when an analyst reads the findings. Same index file, same audit trail, same rules.
Contracts, HR cases, support tickets and claims files fit too. The test is the same each time: can the model do the job without knowing who is who? Regulated records such as health information carry extra rules, so check those before you copy the approach.
Where can this still go wrong?
This cuts exposure a lot. It doesn't erase it. Missed identifiers, context clues and the key file are still risks you manage.
- Scrubbing is probabilistic. A name buried in a free-text memo or an odd account format can slip through. Measure the miss rate on real documents instead of assuming it's zero.
- Scrubbed text can lose context. Sometimes a vendor name is exactly what tells the model how to categorize a transaction. Test on scrubbed inputs, not clean ones.
- Placeholders don't make data anonymous. If you can still look up who CLIENT_0412 is, regulators in Canada and the UK treat it as personal information. Keep your contracts and zero-retention terms in place.
- Some clients care where processing happens, even on scrubbed data. Tell clients when their data is processed outside Canada, and put it in the contract early.
How does this line up with Canadian and UK privacy requirements?
I checked the design against the main Canadian and UK requirements in October 2026. This is a practitioner's read, not legal advice, so run anything you tell a client past a privacy lawyer. For each requirement: what it says, then how the pipeline lines up.
- PIPEDA identifiability test. Information is personal if there is a serious possibility someone could be identified from it. The vendor sees less, but you hold the key, so treat the data as personal information on your side.
- Quebec Law 25. De-identified means no direct identification; anonymized means identification is irreversible. A reversible mapping is de-identified at best, never anonymized.
- UK GDPR, per the ICO. Pseudonymised data is personal data for whoever holds the key. Same answer for UK clients. A recipient without the key may see it differently.
- PIPEDA cross-border processing. A transfer for processing is a use, not a disclosure. You stay accountable and should tell people foreign authorities may access their information. Vendor contract terms, plus plain notice to clients.
- Alberta guidance. Give notice when a service provider outside Canada is used. Add it to your client notice.
- Quebec impact assessment. A privacy impact assessment before personal information leaves Quebec. Do one for Quebec clients. Whether placeholder text counts is unsettled.
- Generative AI principles. Commissioners say to use de-identified data where personal information isn't needed, and to limit retention. Scrubbing matches the first. Your audit log needs a retention schedule.
- Breach reporting (OPC) and Alberta. Report breaches with a real risk of significant harm, and keep breach records. The index file and logs are in scope. Encrypt them and restrict access.
- CPA Ontario guidance. Cites Rule 208: no confidential client information in AI tools unless the environment is verified. Document how you verified yours for each client.
Two things are still open. I found no regulator guidance on this exact setup, so whether placeholder-only text counts as personal information for the vendor isn't settled. And reform is moving: Bill C-36 was introduced in June 2026, and Alberta is reviewing its private sector privacy law.
In summary
The firms getting this right aren't training anything. They built a boring pipeline, they log everything, and they can explain it to a client in two minutes. That's the setup I'd want if it were my books.
If you want a quick read on where your own setup sits on that ladder, we built a free five-minute check: DiscoverAI. Ten fixed-choice questions, and the read arrives by email. Your name and email never reach the model, only the labels behind your answers do, which is this pipeline applied to the form itself.
Check your setup with DiscoverAICommon questions
- Do we need to train our own AI model to use AI on client data?
- No. A current frontier model already categorizes transactions, summarizes a trial balance and drafts client letters with a few examples in the prompt. What a firm needs is a pipeline that scrubs identifiers before anything is sent and restores them on return, plus an audit log of every request.
- What is a scrub-and-send pipeline?
- Six steps: ingest documents locally, scrub names, SINs, account numbers and contact details into placeholders like CLIENT_0412, keep the placeholder-to-real mapping in a local encrypted index file, send only scrubbed text to the API, log every request and response, and rehydrate the answer with real values before a person reads it.
- Are placeholders the same as anonymized data under PIPEDA or Quebec Law 25?
- No. If you can still look up who CLIENT_0412 is, the data is personal information on your side under PIPEDA, de-identified at best under Quebec Law 25, and pseudonymised personal data under UK GDPR. Keep vendor contracts, zero-retention terms and client notices in place; scrubbing reduces exposure, it does not remove obligations.
- When does fine tuning or self hosting make sense?
- Rarely, and only after the cheaper steps fail a test on real examples. Missing information is a retrieval problem. Wrong answers call for better prompts or a stronger model. Cost at volume calls for a small hosted model with escalation. Format drift calls for structured outputs first. Self hosting pays only with steady high utilization or a contract that demands on-prem processing.
- What is the biggest risk in the pipeline?
- The index file, because it is the only thing that can undo the scrubbing. Encrypt it, restrict who can read it and back it up. After that: scrubbing is probabilistic, so measure the miss rate on real documents, and test the model on scrubbed inputs because removing a vendor name can remove the context it needed.
Sources
- Principles for responsible, trustworthy and privacy-protective generative AI technologies, Office of the Privacy Commissioner of Canada
- Guidelines for processing personal data across borders, Office of the Privacy Commissioner of Canada
- What to do if you experience a privacy breach, Office of the Privacy Commissioner of Canada
- Anonymisation and pseudonymisation guidance, Information Commissioner's Office (UK)
- Commission d'accès à l'information du Québec (Law 25)
Ready to take the next step?
HuCortex works with Canadian businesses on CPCSC readiness, PIPEDA compliance, and managed security. Start with a free assessment.
