If you run a regulated practice and you've started wiring Claude into Clio, MyCase, or PracticePanther, you've probably hit the question we get asked most often: do we run this on our own machines, or stand up a server somewhere?
It sounds like an infrastructure decision. It's really a compliance and reliability decision wearing infrastructure clothes. We learned this by building the public Clio and MyCase MCP connectors, then automating the same kinds of workflows on top of them. The gotchas below are ours, found in production, not theory.
This guide is vendor-agnostic on purpose. There's no single right answer. There's a right answer for your data, your audit needs, and your scale. We'll give you the diagnostic to find it.
What "local" and "hosted" actually mean here
People use these words loosely, so let's pin them down.
Local means the automation runs on the user's own device. A packaged agent or MCP server sits on the laptop, authenticates once to Clio or MyCase, talks to the practice-management API, and calls the AI model directly. Nothing sits in the middle. Each user is an island.
Hosted means a server you control runs the automation centrally. Users connect to it. The server holds (or brokers) credentials, runs the jobs, and can keep a single log of everything that happened across the whole firm.
The instinct in regulated work is that local is automatically safer because less data leaves the building. That instinct is mostly right, but for a reason that's more subtle than "the code runs on my machine." We'll come back to it.
The residency question: where does each layer actually live?
Data residency is not one decision. It's three, because a typical AI automation touches three different systems, each with its own residency story.
Your practice-management data. Clio operates a Canadian region at ca.app.clio.com, aligned with PIPEDA. If your account is on the CA server, your matters, contacts, and documents stay in Canada, and your integration must call the CA base URL to keep them there. This part can be fully Canadian whether your code runs locally or on a Canadian server. Worth confirming early: a firm can't assume the API defaults to the right region.
Your meeting recordings and transcripts. If you're feeding consult calls into the pipeline, Zoom has a Canadian data center, but AI-generated content residency is not guaranteed Canada-only. The practical pattern is pull-and-store-fast: get the transcript out of Zoom and into your own Canadian systems quickly rather than relying on it sitting in the right region.
The AI model itself. This is the layer people get wrong. As of mid-2026, Anthropic has no Canadian data region. Claude processes in the US, full stop, regardless of whether your code runs on a laptop in Toronto or a server in Montreal. Running locally does not keep the model in Canada. Anyone who tells you otherwise hasn't checked.
The honest residual: You can keep your Clio data in Canada and pull Zoom content into Canada fast, but the model inference crosses the border to the US. There's no architecture trick that changes that today. The right move is not to pretend otherwise. It's to mitigate with a zero-data-retention arrangement plus US-pinned inference, and to document the cross-border step for your confidentiality obligations under the relevant rules (in Ontario, the Law Society's guidance; in the US, ABA Opinion 512). Stating it plainly is the compliant posture. Hiding it is the risk.
The insight that breaks the false choice: ZDR lives at the org, not the host
Here's the thing we got wrong at first and then corrected. The strongest privacy control you can get from an AI provider is a zero-data-retention (ZDR) arrangement, where prompts and outputs aren't persisted at rest. People assume ZDR is something you earn by self-hosting or by buying the biggest plan. Neither is true.
ZDR is not available on the Claude Team chat product. That's a frequent point of confusion. Team is a chat plan with a fixed retention schedule. If you've been trying to get zero retention on Team, you're chasing it on the wrong product.
ZDR is available at the organization level on the Anthropic API, and a small firm can obtain it without buying Enterprise. Don't over-buy Enterprise to get there: it carries a 20-seat self-serve minimum (50 sales-assisted), which is real money a small practice shouldn't spend on seats it won't use.
The consequence is the part that dissolves the local-vs-hosted dilemma. The ZDR guarantee attaches to a single API organization, a shared credential, independent of where the code runs. Every local install can call the same ZDR-enabled org key. So you can have local execution (privileged data stays on each device) and the strongest retention control (ZDR) at the same time. You don't trade one for the other.
One caveat we learned: ZDR eligibility is per-surface. Keep the pipeline on ZDR-eligible surfaces like the plain Messages API. Some adjacent features (the Files API, batch processing, code execution, certain connector modes) may not carry the same guarantee, so design the data path to avoid them when retention matters.
The audit question: who needs to prove what happened?
This is where hosted earns its keep, or doesn't.
A central hosted server can keep one tamper-evident log of every action across every user. If you're a firm where one party needs to supervise and prove what the whole team did with the AI, that central log is genuinely valuable. It's the cleanest answer to "show me everything the AI touched last quarter."
But many regulated setups don't need that. If you're a network of independent practitioners who each work their own files, with no shared matters by design, a central log isn't an asset, it's an extra copy of privileged data you now have to protect. And your practice-management system already logs per-user activity. In that case, local-first with each device keeping its own append-only audit trail matches the actual structure of the practice better than a central platform does.
We bake an append-only audit log into our connectors at the local level for exactly this reason. It can export on demand (we frame ours against ABA Opinion 512), so even a fully local deployment isn't an audit black hole. The diagnostic question is simple: does someone other than the user need to prove what the AI did? If yes, lean hosted. If no, local audit is enough and lower-risk.
Local vs hosted: the decision grid
| Concern | Local-first | Hosted |
|---|---|---|
| Data surface | Privileged data stays on each device | Data passes through a server you must secure |
| AI retention (ZDR) | Available via shared org key | Available via the same org key (no advantage) |
| Central audit | Per-device logs, export on demand | One firm-wide tamper-evident log |
| Real-time triggers | Polling on an interval | Webhooks, if the platform offers them |
| Scale of many users | Packaged install repeated per user | One deployment, many sessions |
The scale question: do you actually need real-time?
The usual argument for hosting is "it scales and it's real-time." Both deserve a second look in a regulated context.
On triggers: a lot of the auto-trigger work people assume needs a server can run locally through polling. Pulling new Zoom cloud recordings, for instance, hits an endpoint that needs no public address, so a local agent can poll every ten or fifteen minutes and never expose anything to the internet. We initially assumed this required a hosted listener. It doesn't.
And the platforms themselves limit how real-time you can get. Clio has webhooks for activities, bills, calendar entries, communications, contacts, matters, and tasks, but there is no document webhook. So if your workflow keys off new documents, you're polling or listening for a matter update event regardless of whether you host a server. The webhooks that do exist also auto-expire (3 days by default, 31 max) and have to be renewed, which is its own small operational burden.
Then there's latency you can't engineer away. A Zoom cloud transcript isn't ready instantly; it lands roughly two times the meeting length after the call, so about an hour for a 30-minute consult. If the input takes an hour to exist, the "real-time" advantage of a webhook over a 15-minute poll is meaningless. Design for the delay either way.
On scale: a handful of practitioners is a packaging problem, not a throughput problem. Build the install once, deploy it to each person. You don't need a multi-tenant server to serve a number of users you can count on two hands. Reserve hosting for when you genuinely outgrow that, or when the central-audit need (above) is real.
The API gotchas we hit so you don't have to
Whichever way you go, the practice-management API is where good intentions die. These are the specific traps that cost us time building against Clio and Zoom.
Custom fields: the value-id versus field-id trap. Clio supports reading and writing custom-field values. You read them with GET matter?fields=custom_field_values{...} and write them by PATCHing the matter with a nested custom_field_values array. The trap: the id inside that array is the value-instance id, not the field-definition id (custom_field:{id}). Confuse the two and you write to the wrong place, often silently. There's no limit on field count, so a firm with a couple hundred custom fields is fine, but you have to inventory them by type first. Free-text normalizes cleanly. Picklists only accept predefined options (capped at 55 characters). Currency rejects decimals. Dates need valid dates. Promising blanket normalization before you've checked field types is how you ship something that fails on a third of the fields.
Document upload is a three-step presigned-S3 flow. You don't POST a file. You POST a document record, get back a put_url, PUT the raw bytes to that URL, then PATCH the record to mark it fully_uploaded. Miss the final PATCH and you have a phantom document. This is the step that "closes the loop" on a draft-and-file-back workflow, and it's more involved than the docs make it look at a glance.
Rate limits are tighter than you think. Treat the Clio API as roughly 3 requests per second per app (the docs also cite a 50-per-minute legacy figure). A naive batch job that walks hundreds of matters will get 429'd fast. Throttle deliberately, honor the X-RateLimit-* headers, back off on 429, and paginate at 200 per page. For any bulk operation, build it resumable with a dry-run preview, because a batch that writes to hundreds of records is not something you want to run blind the first time.
Zoom's AI summary API is fragile; the transcript is the backbone. If you want Zoom's AI Companion summary through the API, the read scope is blocked in Server-to-Server OAuth, so you need a General or Account-Managed app, and those summaries auto-delete at 30 days. Treat the AI summary as best-effort. The reliable backbone is the cloud-recording VTT transcript (cloud recording and transcription have to be on, which means a paid tier). If the AI summary isn't available, summarize the VTT yourself. Don't build a workflow that breaks when one fragile API surface goes quiet.
The human-review gate is not optional
One rule sits above the architecture entirely. Whether you run local or hosted, an AI-drafted output that touches a client matter needs mandatory human review before it's relied on. In Ontario, the Law Society's April 2024 guidance on generative AI points this way; in the US, ABA Opinion 512 lands in the same place: confidentiality, competence, supervision, verification of AI outputs, and no billing AI time as lawyer hours.
Bake the review step into the workflow as a gate, not a suggestion. Our pattern: the AI drafts, the draft lands in the right matter, and a human reviews and finalizes it there. The automation removes the drudgery (the trigger, the consistent prompt, the file-back) without removing the judgment. That's the line, and it's a feature, not a limitation.
So which one should you pick?
Run the diagnostic in order:
- Does someone other than the user need to prove what the AI did? Yes leans hosted (central audit). No leans local.
- Is real-time genuinely required, or is your input already slow? If transcripts or documents take minutes to an hour to exist, polling is fine and you don't need webhooks.
- How many users, really? Up to a dozen or two is a packaging problem. Hundreds is a hosting problem.
- Where does each data layer live? Pin practice-management data to the right regional server, pull meeting content into your own systems fast, and accept that model inference crosses to the US, then mitigate with ZDR.
For most small regulated firms the answer is local-first on a shared ZDR API organization. It keeps privileged data on each device, gets the strongest retention control anyway, and matches the actual shape of the practice. Hosting is the right call when central audit, true real-time, or genuine scale make it earn its complexity. If a hosted layer is right, host it in a Canadian region, keep it zero-persistence and in-memory, and put the central audit log there.
Tools like n8n can stitch some of this together for simpler cases, and we've seen firms reach for them first. The moment privileged data and a confidentiality duty enter the picture, the residency, retention, and audit questions above are what actually decide the architecture, not the orchestration tool. Generalist build shops like Arkenea or Topflight can build the pipeline; the difference is knowing the value-id trap, the no-document-webhook reality, and the ZDR-org insight before you've burned a week finding them.
Frequently Asked Questions
Should a regulated firm run AI automation locally or on a hosted server?
For a small regulated firm with no need for central audit or real-time webhooks, local-first is usually the better default: it keeps privileged data on the user's device, reduces the third-party data surface, and is simpler to reason about for a confidentiality obligation. Hosted is justified when you need a central, tamper-evident audit log across many users, real-time event triggers that polling cannot match, or shared infrastructure many people hit at once. The key insight: the strongest privacy control, a zero-data-retention arrangement, lives at the API-organization level and is independent of where your code runs. You can have local execution and ZDR at the same time.
Does running AI automation locally satisfy Canadian data residency rules?
Partly. Your practice-management data can stay in Canada: Clio operates a Canadian region (ca.app.clio.com) aligned with PIPEDA, so matters and documents never leave the country if your account is on the CA server. The honest residual is the AI model. As of mid-2026 Anthropic has no Canadian data region, so Claude processes in the US regardless of whether your code runs on a laptop or a Canadian server. The mitigation is a zero-data-retention arrangement plus US-pinned inference, with the cross-border step documented for your confidentiality obligations.
Is zero data retention available on Claude Team or only Enterprise?
Zero data retention is not available on the Claude Team chat product, which retains conversations on a fixed schedule. ZDR is available at the organization level on the Anthropic API, and a small firm can obtain it without buying Enterprise seats. Don't over-buy Enterprise (it carries a 20-seat self-serve minimum) just to chase ZDR. Build your automation on the API with a ZDR-enabled organization key instead, and keep the pipeline on ZDR-eligible surfaces like the plain Messages API.
Can you auto-trigger a Clio or MyCase workflow without a hosted server?
Often yes. Many auto-triggers can run locally through polling. Pulling new Zoom cloud recordings does not require a public webhook endpoint, so a local agent can poll on an interval and never expose a server to the internet. Clio webhooks exist for matters, tasks, contacts, and other entities, but there is no document webhook, so new-document detection has to be done by polling or by listening to a matter update event anyway. If transcript or summary latency is already on the order of an hour, the real-time advantage of a hosted webhook largely disappears.
What are the biggest API gotchas when automating Clio?
Three trip people up. First, custom fields: when you PATCH a matter to write a custom-field value, the id inside the request is the value-instance id, not the field-definition id, and getting this wrong silently writes to the wrong place. Second, document upload is a multi-step presigned-S3 flow (create the document record, PUT the bytes to the returned URL, then PATCH it as fully uploaded), not a single call. Third, rate limits: treat the API as roughly 3 requests per second per app, honor the X-RateLimit headers, and back off on 429s, because a naive batch over hundreds of matters gets throttled fast.
Next step
If you're weighing local versus hosted for an AI automation in a regulated practice, the architecture is downstream of four answers: who needs to audit it, how real-time it truly needs to be, how many people will use it, and where each data layer lives. Get those right and the rest follows.
We built the Clio and MyCase MCP connectors and the automation patterns on top of them, including the residency, ZDR, and audit decisions above. If you want a second opinion on your setup, we offer a free 30-minute architecture review: no pitch deck, just an honest technical conversation about your data path and the trade-offs.
Book a free architecture review →
Or read more from our legal AI integration work: