Claira Stories
Canada's Generative AI Crossroads: What the Law Society Guidance Means for Your eDiscovery Workflow

Every law society in Canada has now said something formal about generative AI, and the message is more aligned than the headlines suggest. The Law Society of Ontario, the Law Society of British Columbia, and the Federation of Law Societies of Canada have each published practice guidance over the past two years. None of them ban AI. None of them give it an unqualified blessing either. What they do, almost uniformly, is restate the obligations you already had - competence, confidentiality, candor, supervision - and tell you those obligations now apply to the AI you use as if it were a junior member of your team.
That framing matters more than any specific bullet point in any specific guidance document. It tells you what kind of AI workflow is defensible and what kind is not.
The guidance converges on four obligations
Read the LSO white paper, the LSBC practice guidance, and the Federation's model rules side by side and the same four threads appear. You owe your client a reasonable understanding of the technology. You owe your client confidentiality, which extends to anyone or anything that touches the file. You owe the court accuracy, which means you cannot file output you have not verified. And you owe your team supervision, which means a lawyer is responsible for the work product no matter who or what produced it.
Translate that to litigation support and the picture sharpens fast. The tool you use for first-pass review has to be one you can explain, that processes data in a place you control, that produces output you can verify document by document, and that leaves a record someone can audit later. None of that is new. What is new is that the law societies are now naming the failure mode explicitly: if you cannot answer those four questions about your AI, you should not be using that AI on a live matter.
Competence is mostly about explanation
The competence obligation gets read as "you need to be a prompt engineer," and that is the wrong reading. What the guidance actually asks is that you can explain, in plain terms, what your AI does on a given document and why it returned a given answer. If a reviewer codes a document privileged, you can ask them why and they will tell you. The same standard applies to an AI tool.
Most general-purpose legal copilots fail this test the moment scale enters the room. They retrieve, they rank, they summarize, and when you ask why a specific document was excluded from production they answer with a similarity score. That is a description of a process, not a justification. It will not survive a Sedona Canada Principle 6 conversation with opposing counsel, and it will not satisfy a law society reviewer asking how you supervised the work.
The Claira approach is the inverse. Every document gets read in full, in context, against the case you defined. Every coding decision lands in Nuix Discover with a written justification attached to it. We've written before about why we review the full set rather than a sample, and the competence story is one of the reasons. You cannot exercise reasonable competence over decisions that were never recorded.
Confidentiality is mostly about jurisdiction
The confidentiality obligation has two layers in the guidance. The first is the obvious one - your client's data cannot be exposed to a model that trains on it, stored on infrastructure that another tenant can read, or transmitted in clear across the open internet. The second is quieter but more consequential. PIPEDA, Quebec's Law 25, and the patchwork of provincial rules treat the location of processing as a material fact about the data. A US-based inference endpoint is not the same as a Canadian one, and several Canadian regulators have said so in writing.
This is where the deployment architecture stops being a procurement detail and becomes a competence question. The guidance does not require Canadian infrastructure as a matter of professional ethics, but it does require that you can answer the question. Claira is deployed in Canadian Google Cloud regions, customer content is processed per request and is not used to train Claira-owned models, and operational metadata is captured for audit. The architecture is documented in the Privacy and Security reference and the answer you give a client or a regulator is the same answer you'd give a partner.
If you cannot point your client to a comparable document for the tool you are using, that is a confidentiality problem before it is a data problem.
Candor is mostly about verification
The candor obligation is the one that has produced the headline cases. The Mata v. Avianca pattern - lawyer files brief, brief contains fabricated citations, AI is blamed - keeps repeating because the workflow that produces it is itself defective. The lawyer never read what the AI produced before submitting it. The law society guidance is uniform on this point: AI output is a draft, not a filing, and the lawyer signing the document is the one accountable for what it says.
For document review the candor question is subtler but the answer is the same. You do not need every reviewer to read every document the AI coded - that would defeat the purpose - but you need enough human verification, on enough of the corpus, that the production you swear to is one you can defend. Random verification samples, targeted review of high-risk codes, and a written audit trail on every document are the minimum. The shape of that workflow is now, effectively, table stakes for defensibility.
Supervision is mostly about the audit trail
The supervision obligation closes the loop. Every law society treats AI the same way it treats articling students and contract reviewers: the lawyer of record is responsible for the work, the lawyer is expected to know how it was done, and the lawyer should be able to produce a record after the fact. That last piece is where most workflows break down. A human reviewer leaves coding decisions, notes, and a timestamp. A black-box AI workflow leaves a similarity score.
Claira leaves the record a law society would expect: every scan is logged, every coding decision is accompanied by a written justification, and the Case Context that shaped the review is documented and versioned alongside the matter. This is the part of the product we built explicitly with professional responsibility in mind. Claira does not replace the lawyer's judgment - it produces the artifacts the lawyer needs to exercise that judgment defensibly at scale.
Where to start
If you have not already mapped your current review workflow against the four obligations, that is the first concrete step. Pick a closed matter, look at the AI you used or considered, and write down how you would answer a law society reviewer's questions about competence, confidentiality, candor, and supervision. The gaps tend to surface themselves.
If you want a working session on that exercise against a real corpus, book time with the Claira team and we'll walk it through with you. The guidance is not going to get less strict from here. The workflows that satisfy it today are the ones that will still be there in three years.