Identifiers are stripped before the analysis model, nothing is stored, and your intake runs on your own AI account. Built to the UK GDPR standard — the strictest bar, so it holds across Australia, the UK, Canada and New Zealand — and aligned with US professional-conduct rules. The same architecture protects a law firm and a community legal centre alike.
Verified against our own code — your data-protection officer can hold us to each claim.Not a policy you have to trust — an architecture your DPO can audit.
Names, addresses, phone, DOB and government IDs are replaced with typed role tags — [CLIENT], [ADDRESS], [EMPLOYER] — server-side, so a tampered browser can't switch it off. The reasoning model only ever works from the tagged version.
Our database holds only your organisation's config and a PII-free job record (session id, status, timestamps). Client names, documents and contact details are never written to it.
Intake data lives only for the session. It is permanently deleted the moment the case file is delivered to your team. Incomplete sessions are purged within 90 days. Original documents are never retained.
In production your firm or centre runs on its own Anthropic (Claude) or OpenAI key. You're the data controller when you configure your key; we're a processor at most. No training on client data: on the demo path we set no-logging / no-training per request in code (data_collection: deny); production runs Anthropic-direct, and Anthropic does not train on API data.
Meet it and Australia, Canada and New Zealand follow. The US works through professional-conduct rules. This section is for information, not legal advice — verify for your jurisdiction; current as of July 2026.
For information only — not legal advice. Verify the position for your jurisdiction. Current as of July 2026.
Five providers touch an intake. Here's each one — what it sees, and whether it keeps anything. Only the OCR step ever reads a raw upload, the model that analyses the case sees only the redacted version, and the one place full client details appear is the finished notification we email to your firm — because you're the one receiving the matter. All bound by data-processing agreements.
The detailed, dated legal mapping — current as of July 2026. Enter your email and we'll send it straight to your inbox. Verify for your jurisdiction; not legal advice.
A Data Protection Impact Assessment pre-filled for AI client intake — adapt it to your firm or centre and file it.
A one-page checklist per jurisdiction — map PROVEAiBLE to your obligations and tick them off. US firms: a 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 you the document; we may follow up once. No list-selling, ever. This page is information about our architecture, not legal advice — your firm or centre remains bound by its own privacy and professional-conduct obligations.
No. Names, addresses, document IDs and the like are stripped to typed role tags on our server before the case-analysis model — the reasoning model that could retain or expose an identity. It only ever works on the redacted version, and this is enforced in the architecture, not an optional setting. Uploaded document images are first read for text by an OCR sub-processor (Google Cloud Vision); redaction happens before the analysis model.
No. On the demo path we set no-logging / no-training per request in code (data_collection: deny), not just as an account setting. In production the intake runs on your organisation's own AI account (BYOK) via Anthropic direct, and Anthropic does not train on API data. No client PII is written to our logs.
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; incomplete sessions are purged within 90 days. The only things we store are your organisation's own configuration, a PII-free job record (session id, status, timestamps), and your own account contact (the lawyer's name and email at signup) — never the client's. Operational infrastructure runs through named sub-processors bound by data-processing agreements.
In production the intake runs on your organisation's own AI key (BYOK), so you are the data controller when you configure your key. For the brief, transient intake step we act only as a processor; once the case file is delivered it lives with your team. We never become the controller of your clients' matter data.
Yes — by design, not just by assurance. Every identifier the client confirms redacted is captured with a timestamp as a consent record (GDPR Article 7 demonstrability) and delivered alongside the case file. The token-to-name mapping is never sent to the AI and is deleted on delivery — so the delivered file is itself evidence the analysis model only ever processed the protected version. Using a consumer AI chatbot can waive privilege, which is exactly why PROVEAiBLE strips identifiers before the analysis model.
A private demo tuned to your practice — with the redaction, consent record and case-file output your DPO can review.
Request a demo