If you practice in Ontario and you want to point Claude at a client matter, you are governed by two things at once: the Law Society of Ontario's practice guidance, and the broader professional-responsibility logic that the American Bar Association spelled out in Formal Opinion 512. They were written by different bodies on different sides of the border. They arrive at almost the same place.
We learned this the practical way. We build and maintain the open-source Clio MCP connector and the MyCase connector that let Claude read and write inside a law firm's practice-management system. Building those, and scoping automation on top of them, forces you to answer the compliance questions in code, not in a memo. This post is what we wish someone had handed us first.
What does ABA Formal Opinion 512 actually say?
ABA Formal Opinion 512, issued in July 2024, is the first formal ethics opinion in the US to address generative AI head-on. It does not ban it. It does something more useful: it maps generative AI onto the duties lawyers already have, so there is no special "AI exception" to professional responsibility.
The opinion works through five existing duties and asks what each one means once a model is in the loop:
- Competence. A lawyer must understand the benefits and risks of the AI tool they use, at least well enough to use it responsibly. You do not have to be able to train a model. You do have to know it can be confidently wrong.
- Confidentiality. Before you put client information into a tool, you have to understand where that data goes, whether it is used to train the model, and who can see it. Self-learning tools that train on inputs are flagged specifically.
- Communication. In some circumstances you may need to tell the client you are using AI, especially if it touches their confidential information or affects the fee.
- Supervision. Using AI is treated like delegating to a non-lawyer assistant. The output is your responsibility to check.
- Reasonable fees. You cannot bill for hours the AI saved you. If a memo that took three hours now takes twenty minutes, the client pays for twenty minutes.
The single most important line for anyone building a workflow: the lawyer must independently verify the AI's output before relying on it. Opinion 512 does not let you treat the model's answer as the answer. That is not a soft suggestion. It is the load-bearing rule, and it shapes how an automated pipeline has to end.
Quotable summary: ABA Formal Opinion 512 (July 2024) does not prohibit generative AI for lawyers. It subjects AI use to the existing duties of competence, confidentiality, client communication, supervision, and reasonable fees, and it requires the lawyer to independently verify any AI output before relying on it.
What does the Law Society of Ontario say about generative AI?
The LSO published a generative AI white paper in April 2024. A useful distinction up front: this is practice guidance, not a black-letter rule you can be disbarred for breaking by name. It is evolving, and it reads as the regulator thinking out loud about a fast-moving technology. But the substance is conceptually aligned with Opinion 512, which makes the cross-border picture simpler than you would expect.
The LSO guidance lands on the same pillars: protect client confidentiality, maintain technological competence, supervise the tool the way you supervise staff, verify what the model produces, and do not bill AI-saved time as human time. If you build to satisfy Opinion 512's verification and confidentiality requirements, you are most of the way to satisfying the LSO. The frameworks rhyme.
Where Ontario diverges in practice is not the ethics. It is the data. Family law and other privileged Canadian practice areas come with a hard data-residency instinct: keep privileged information on Canadian or US servers, and minimize what sits on any third party's infrastructure at all. That instinct is correct, and it collides with a technical fact most vendors gloss over.
Where LSO guidance and ABA Opinion 512 line up, side by side
LSO Guidance vs ABA Opinion 512
| Duty | ABA Opinion 512 (US) | LSO Guidance (Ontario) |
|---|---|---|
| Form | Formal ethics opinion (July 2024) | Practice guidance / white paper (April 2024), evolving |
| Confidentiality | Understand data handling and training use before input | Protect privilege; minimize third-party exposure |
| Competence | Know the tool's benefits and risks | Maintain technological competence |
| Supervision | Treat AI like a delegated assistant | Supervise the technology you rely on |
| Human review | Mandatory independent verification of output | Mandatory verification of output |
| Billing | No billing AI-saved time as lawyer hours | No billing AI-saved time as lawyer hours |
The takeaway from the table: there is no real conflict to resolve. The two frameworks agree on the duties. Compliance work for a cross-border or Ontario-based practice is less about reconciling rules and more about building a workflow that satisfies both at once, then handling the data-residency problem they both leave to you.
The gap nobody warns you about: your model has no Canadian region
Here is where the ethics opinions hand the problem to your architecture and walk away. Both require you to understand where confidential data goes. Neither tells you that the most capable models on the market today process in the US and offer no Canadian data region.
Anthropic's Claude is the case we know best, because we route legal workflows through it. There is no Canadian region for Claude at the time of writing. Data is processed in the US. You can keep your practice-management system in Canada, but the moment a matter's text is sent to the model, it has crossed the border. Pretending otherwise is how firms end up out of step with their own confidentiality obligations.
The good news is that the cross-border step can be made defensible. It just takes three deliberate choices, and the order matters.
1. Keep the practice-management data in Canada
Clio operates a Canadian region at ca.app.clio.com, governed under PIPEDA. If your firm's account is on the Canadian server, your matters, contacts, documents, and notes live in Canada. The catch we hit building the connector: your integration has to actually call the Canadian base URL. Pointing the same code at the default US endpoint silently routes you to the wrong region. Confirm which server the account is on before anything else, because it changes every API call you make. We dug into this in Clio's Canadian region and Claude residency.
2. Use zero data retention on the model API, not the chat plan
This is the most common place we see firms get confused, and it is an honest confusion because the vendor product names do not help. Zero data retention (ZDR) is not available on Anthropic's Claude Team plan, which retains conversation data on a rolling window. A lot of small firms sit on Team waiting to be granted ZDR and never are, because they are asking the wrong product.
ZDR is available on the Anthropic API, granted at the organization level, and it is obtainable by a small firm. We wrote up the Team-vs-API zero-data-retention distinction in detail, because it is the single most misunderstood point we hit. The API does not train on your inputs by default. Under a ZDR arrangement on plain Messages API calls, privileged content is not stored at rest after the response comes back. One caveat we learned to respect: ZDR covers the plain Messages API. Keep the pipeline off the surfaces it does not cover, including the Files API, Batch, code execution, and the hosted MCP connector. If you want the model's confidentiality posture to hold, the whole workflow has to stay on ZDR-eligible calls.
One more thing this avoids: you do not need Anthropic Enterprise to get ZDR. Enterprise carries a seat minimum (roughly 20 self-serve, 50 sales-assisted) that a four-to-fifteen-lawyer practice will overpay for. The API path gets you the compliance posture without the seat commitment.
3. Pin inference to the US and document the cross-border step
Set inference geography to the US so you know exactly where processing happens, and write down the cross-border step as part of your confidentiality assessment. The LSO and Opinion 512 both ask you to understand and disclose where confidential data goes. A short, honest record that says "model inference occurs in the US under a zero-retention arrangement, with no data persisted at rest" is the kind of thing that satisfies both frameworks. The mistake is silence, not the border crossing itself.
The honest residual: there is no architecture that keeps a frontier model's inference inside Canada today, because the region does not exist. The defensible answer for an Ontario practice is Canadian practice-management data, a zero-retention US-pinned model call, and a documented cross-border note. Anyone promising fully Canadian-resident frontier AI is either using a weaker model or not telling you the whole story.
How the human-review duty changes the workflow design
Both frameworks require a human to verify AI output. That sounds like a checkbox. It is actually an architecture decision, and it is the one most "AI does it for you" pitches quietly skip.
The rule means an AI-assisted legal workflow cannot end at an automatically filed or sent document. It has to end at a draft that lands in front of a lawyer to review and finalize. Take a common pattern we build: a client consult on Zoom, plus the lawyer's notes in Clio, turned into a standardized draft note that gets written back into the right matter. The model can pull the Zoom transcript, read the notes, and draft the document. What it cannot do is close the file. The last step is always the lawyer opening the draft in Clio, checking it, and approving it.
We build that gate into the workflow itself rather than leaving it to discipline. The automation stops at "draft ready for review," and a person has to act. That is not a limitation we apologize for. It is the thing that keeps the workflow inside Opinion 512 and the LSO guidance instead of outside them. It also happens to be where the actual legal judgment lives, which is the part no model in 2026 should be assembling unsupervised anyway.
A few real engineering details that fall out of getting this right, in case you are scoping your own build:
- Write-back is the closing step. Reading from Clio is easy; uploading a finished document back into the correct matter is what closes the loop. Clio's document upload is a two-step presigned-S3 flow (create the document, PUT the bytes to the signed URL, then PATCH it as fully uploaded). It works, but it is not a single call, and a lot of integrations stall here.
- There is no Clio document webhook. You cannot subscribe to "a document was created." You detect new work by polling or by listening to the
matterupdated webhook, and Clio webhooks auto-expire (three days by default, thirty-one max), so you have to renew them. More on that missing document webhook. - Rate limits are real. Plan around roughly 3 requests per second per app, honor the
X-RateLimitheaders, and back off on 429s. A bulk job over hundreds of matters is a throttled, resumable batch, not a tight loop. - Zoom AI summaries are fragile over the API. The AI Companion summary read scope is blocked in Server-to-Server OAuth and the summaries auto-delete after thirty days, so the reliable backbone is the cloud-recording VTT transcript, not the summary. Design for the transcript and treat the summary as best-effort.
A diagnostic, not a verdict
There is no single correct architecture here, and we are wary of anyone, including us, who tells you there is. The right shape depends on your facts. Run these questions:
- Is your data residency a hard requirement or a strong preference? A hard Canadian-only mandate may rule out frontier models entirely and push you toward a smaller model you can self-host. Most practices land on "Canadian practice data plus a documented US model call," which is a different answer.
- Local or hosted? A local-first setup that calls a shared firm ZDR key keeps privileged data off any middle-tier server and right-sizes for a small practice. A hosted layer earns its keep only if you need central audit or real-time triggers. Neither is automatically "the compliant one."
- Where does the human gate sit? If your workflow ever sends or files without a lawyer's review, the tooling is the problem, not the model.
- What is your practice-management platform, exactly? Clio, MyCase, and PracticePanther all expose different APIs with different limits and different webhook behavior. The compliance principles are the same; the plumbing is not.
If you want a view of how to give Claude write access to a case-management system without losing your nerve, our guide to safe write access is the companion piece. And the open-source connectors themselves are worth a look before you build: there is no reason to reimplement Clio's presigned upload flow or its webhook renewal from scratch.
Frequently Asked Questions
Does ABA Formal Opinion 512 say lawyers can use generative AI?
Yes. ABA Formal Opinion 512 (July 2024) does not prohibit generative AI. It treats AI as a tool a lawyer may use, subject to existing duties: competence, confidentiality, communication with clients, supervision, and reasonable fees. The opinion is explicit that a lawyer must independently review and verify any AI output before relying on it. Generative AI does not relieve the lawyer of professional judgment.
What does the Law Society of Ontario say about generative AI?
The LSO issued a generative AI white paper in April 2024. It is practice guidance rather than a binding rule, but it lands in the same place as ABA Opinion 512: lawyers stay responsible for confidentiality, competence, supervision of the technology, and verification of outputs, and must not bill AI-saved time as if a human did the work. Both frameworks make the lawyer, not the model, accountable for the result.
Can a Canadian family law firm use a US-hosted AI model under LSO rules?
It is possible but requires deliberate design. Most frontier models, including Anthropic's Claude, have no Canadian data region and process in the US. You can keep practice-management data in Canada (Clio offers a Canadian region at ca.app.clio.com under PIPEDA), but the model call crosses the border. The defensible pattern is a zero-data-retention arrangement on the model's API, US-pinned inference, and a documented record of the cross-border step for your confidentiality obligations.
Do lawyers have to review AI output before using it?
Yes. Both ABA Opinion 512 and the LSO guidance require a human lawyer to verify generative AI output before it is relied on or sent to a client or court. In practice this means any AI-assisted legal workflow should end at a draft that a lawyer reviews and finalizes, not at an automatically filed or sent document. We build that review gate into the workflow itself rather than leaving it to discipline.
Can you bill clients for time saved by AI?
No. ABA Opinion 512 is direct on this: a lawyer may not bill for time the AI saved as though a person spent it. If a task that took three hours now takes twenty minutes, you bill the twenty minutes. The LSO guidance is consistent. Charging for AI as a cost or disbursement is a separate question that depends on your fee agreement and disclosure to the client.
Next Step
If you are a lawyer or a small legal network trying to put Claude to work on real matters without tripping over confidentiality, residency, or the human-review duty, the architecture is the hard part, not the model. We have built the Clio and MyCase connectors, hit the webhook, upload, and rate-limit gotchas ourselves, and wired the ZDR plus human-review pattern into workflows that hold up under LSO and ABA Opinion 512.
We offer a free 30-minute architecture review. Bring your stack (Clio or MyCase, your model plan, your residency requirements) and we will give you an honest map of what is and is not defensible, with no pitch deck.
Book a free architecture review →
Or read more from our legal AI integration practice: