Privacy & Compliance

The AI never sees your clients’ data.
By design, not by promise.

PROVEAiBLE Intake was built so the hardest privacy problem in legal AI — client data reaching a model — simply doesn’t happen. Identifying details are stripped on our server before any AI call, nothing is kept, and your centre runs on its own AI account. Built to the UK GDPR standard, so it holds across Australia, the UK, Canada and New Zealand — and it meets US professional-conduct rules (ABA Formal Opinion 512).

See how this works in practice →

How it protects data

Six things that are true of every intake

These are verified against our own code — not marketing. Your data-protection officer can hold us to each one.

The AI never receives identifying details

Names, addresses, phone, DOB and government IDs are stripped to typed tokens ([CLIENT], [EMPLOYER], [ADDRESS]…) on our server, before any AI call — enforced server-side, so it can’t be switched off by a tampered browser.

Zero client data in our database

Our database holds only your centre’s settings and a PII-free job record (session id, status, timestamps). Client names, documents and contact details are never written to it.

Processed transiently, deleted on delivery

Intake data lives only for the session, on disk, and is permanently deleted the moment the case file is delivered to your team. Original documents are never stored.

Bring your own key — you’re the controller

In production your centre runs on its own Anthropic (Claude) or OpenAI key, under those providers’ API terms. Your organisation is the data controller; we’re a processor at most. What BYOK means →

Never used to train AI

Anthropic and OpenAI don’t train on API data. We enforce no-logging / no-training per request in code (data_collection: deny), not just in an account setting — and no client PII is written to our logs.

A consent log for your DPO

Every redaction the client confirms is timestamped as a consent record (GDPR Art. 7) and delivered with the case file — a defensible audit trail your data officer can file.

Plain about the demo vs production split: the live demo on our site runs on our own test key with sample data — never enter real client details. Production runs on your centre’s own Anthropic key (we recommend Claude via Anthropic’s API — your key, your control). OpenRouter is used only for demos, never for real client data.
Across five jurisdictions

Built to the UK standard — and to US professional-conduct rules

The UK has the strictest privacy bar (UK GDPR special-category data + DPIA) — build to it and Australia, Canada and New Zealand follow. The US works differently: professional-conduct rules (ABA Formal Opinion 512), which PROVEAiBLE’s architecture is built to meet.

🇦🇺 Australia

Privacy Act 1988 · APPs · NSW PPIPA/HRIPA

  • Pre-LLM redaction means personal information is not input into the AI system — the most direct path to OAIC’s AI guidance.
  • Deletion on delivery satisfies APP 11 (security) and APP 4/6 (purpose limitation).
  • BYOK makes your centre the APP entity / data controller — not us.
Note: from Dec 2026, automated-decision-making must be disclosed — our eligibility/priority scoring is disclosed in your privacy notice.
🇬🇧 United Kingdom

UK GDPR (Art. 9 & 10) · DPA 2018 · SRA

  • Legal-intake data is largely special-category. Because it’s redacted before the AI, that data isn’t processed by the model — dramatically reducing DPIA risk.
  • We provide a DPIA template you can adopt for your clinic (below).
  • Serves SRA principles on client confidentiality and public trust.
Data (Use and Access) Act 2025 in force — legitimate-interests basis available.
🇨🇦 Canada

PIPEDA · Quebec Law 25 baseline

  • Explicit informed consent at intake start meets Law 25’s opt-in requirement.
  • Transient processing + deletion satisfies purpose limitation; no secondary use.
  • No training on client data; BYOK keeps the clinic as controller under PIPEDA.
Monitoring Ontario Bill 194 for funded-clinic AI obligations.
🇺🇸 United States

ABA Formal Opinion 512 · Model Rules 1.6 & 1.18 · State Bar Guidance

The US has no single federal privacy law for legal intake. The governing framework is professional conduct — and the ABA has addressed AI directly.

ABA Formal Opinion 512 (July 2024) is the compliance baseline for AI use in US legal practice, reaffirmed by the ABA Task Force Year 2 Report in December 2025. It requires lawyers to assess three things before using any AI tool with client information: how the tool handles data, whether it could disclose information to third parties, and whether it trains on client inputs. The answer to all three must be satisfactory before a lawyer can use the tool ethically.

PROVEAiBLE is built around those three requirements:

  • The AI never receives identifying details — names, addresses and identifiers are stripped on our server before any model call, directly addressing Opinion 512’s disclosure risk
  • No training on client data — enforced per-request in code, not just in account settings, the specific safeguard Opinion 512 and state bar guidance cite as essential
  • BYOK — your firm is the controller — the firm’s own API key, under Anthropic’s or OpenAI’s terms, means the firm retains control of its data relationship with the model provider

Prospective client duty — Model Rule 1.18: Confidentiality obligations attach at the point of intake — before any lawyer reviews the matter, before representation forms. A law firm website that invites submission of confidential information creates a Rule 1.18 prospective-client duty from the first message. PROVEAiBLE is designed for this: intake data is protected from the moment of capture, not from when a lawyer first opens the file.

State bar guidance: New York (Formal Op. 2024-5 and 2025-6), Texas (Op. 705), Florida (Op. 24-1) and Illinois (Supreme Court AI Policy, Jan. 2025) have all issued AI guidance consistent with Opinion 512. Each requires lawyers to vet vendor data handling, avoid self-learning tools that could expose client data to third parties, and obtain informed consent before entering confidential information into a third-party AI system. PROVEAiBLE’s architecture — redact, process transiently, delete on delivery, no training — is the control pattern each of these opinions points to.

Privilege: Early 2026 case law (US v. Heppner, SDNY; Morgan, E.D. Mich.) distinguishes enterprise AI tools with contractual confidentiality, no training on inputs, and deletion on request from public consumer tools. Courts have consistently indicated the former are designed to support confidentiality obligations; PROVEAiBLE’s architecture aligns with the controls those decisions identify.

HIPAA: Most plaintiff-side PI and immigration firms are not HIPAA business associates and their intake data is not regulated as PHI. Firms acting as business associates — typically defense-side or insurer-retained — may require a BAA. Contact us to discuss if your practice needs one.

California CCPA/ADMT: California’s automated decision-making regulations (effective January 2027) apply to AI used for significant decisions in employment, credit, housing and healthcare. Legal intake and case triage are outside the regulation’s defined scope. Baseline CCPA obligations — notice at collection, data minimisation, deletion rights — may apply to large firms meeting the revenue threshold. PROVEAiBLE’s transient processing and deletion on delivery architecture supports compliance.

No federal AI privacy law has passed as of June 2026. US compliance requirements continue to develop. We monitor state bar opinions and privacy regulations and update this page when material changes occur.
🇳🇿 New Zealand

Privacy Act 2020 · IPP 3A (from 1 May 2026)

  • The widget tells clients at the start exactly what happens to their data — satisfying the new indirect-collection disclosure (IPP 3A).
  • Collection limitation, purpose specification and deletion-after-delivery satisfy the 13 IPPs.
  • The least prescriptive of the four — satisfied automatically once AU and UK are.
NZ integrates AI expectations into existing law — no separate AI Act.
For your data officer

A consent record, delivered with every case file

Every term your client chooses to redact is captured with a timestamp as a consent record under GDPR Article 7 and handed to your caseworker alongside the case file. It shows which entities were redacted (CLIENT, OTHER_PARTY, ADDRESS, ID, PHONE…), when the client confirmed each, and that the AI only ever received the protected version.

The case file your team receives is itself the proof the AI never saw identifying data — defensibility by architecture, not by promise. The token–to–name mapping is never sent to anyone and is deleted on delivery; your team receives the role-tagged file, with original documents arriving through your own configured channel.

Questions

Common compliance questions

Does the AI ever see our clients' personal details?
No. Personal identifiers — names, addresses, document IDs and the like — are stripped on our server before any data is sent to an AI model. The model only ever works on the redacted version, so it never receives the details that identify who your client is. This happens in the architecture, not as an optional setting you have to switch on.
Do you train AI models on our clients' data?
No. We never use your clients' intake data, documents or matter files to train or improve any AI model. The intake runs on your organisation's own AI account (BYOK), so each model call is made under your provider's API terms — and we set the no-training flag on every request in code (data_collection: deny), not just as a setting in an account dashboard.
Where is our clients' data stored, and for how long?
We don't retain client matter data. It's processed transiently to build the case file, then permanently deleted the moment that file is delivered to your team — no client PII and no copy of the matter remains in our database. The only thing we store is your organisation's own configuration (widget settings, branding, delivery address) for the life of the subscription. Operational infrastructure (hosting, transactional email) runs through named sub-processors bound by data-processing agreements; the AI itself runs under your account.
Who is the data controller — you or us?
You are. The intake runs on your organisation's own AI key (BYOK), so your relationship with the AI provider is yours, under your terms. For the brief, transient intake step we act only as a processor; once the case file is delivered it lives with your team, and you are the controller of it. We never become the controller of your clients' matter data.
Can we show that the AI never saw identifying information?
Yes — by design, not just by assurance. Every identifier that's redacted is captured with a timestamp as a consent record (GDPR Article 7) and delivered alongside the case file. Your team receives the redacted file the model worked from, plus that record — together they evidence that the AI only ever processed the protected version. The mapping between the redaction tokens and the original names is never sent to anyone and is deleted on delivery.
Take it to your board

DPIA template & compliance checklists

We’ve done the privacy paperwork so your clinic doesn’t have to start from a blank page. Enter your email and we’ll send it.

UK DPIA template (intake AI)

A Data Protection Impact Assessment pre-filled for AI client intake — adapt it to your clinic and file it.

Compliance checklist (AU · UK · CA · NZ)

A one-page checklist per jurisdiction — map PROVEAiBLE to your obligations and tick them off.

US firms: compliance reference mapped to ABA Formal Opinion 512, Model Rules 1.6 and 1.18, and 2025–2026 state bar guidance — available on request.

We’ll email the document and may follow up once. No list-selling, ever. This page is information about our architecture, not legal advice — your clinic remains bound by its own privacy and professional-conduct obligations.