Finance, Insurance, and Legal: AI Without Exposing Client Data

A claims manager at a mid-sized insurer is working through a complex workers' compensation file. The claimant's treating specialist has submitted a detailed medical report, and the file also contains settlement negotiation notes and an internal reserve estimate. To save an afternoon of drafting, the claims manager pastes the medical report and negotiation notes into a public AI assistant and asks for a settlement recommendation memo. The memo is well-written and arrives in under a minute. It goes into the file and informs the offer that goes to the claimant's solicitor the following week.

Eight months later, the claim is disputed. Plaintiff's counsel serves a request for all systems and third parties that processed the claimant's medical information as part of the claims handling process. The insurer's legal team cannot say with certainty where that data went, whether it was retained by the AI vendor, or who else might have had access to fragments of it. What started as a routine claims dispute becomes an allegation of unreasonable claims handling — a category of exposure that is far more expensive, and far harder to defend, than the underlying claim ever was.

I'll address this upfront: I'm not saying public AI tools have no place in a regulated services firm. For drafting a client newsletter, summarising publicly available case law, or preparing generic marketing content, they're fine. The problem is specific, and it applies every week to accountants handling client financials, insurers handling claims and medical files, and lawyers handling privileged case material — usually without anyone in the firm having deliberately decided to take on the risk.

1. Is This Right for Your Operation?

Before I explain how the exposure works, here is the honest filter. Not every accounting practice, insurer, or law firm needs an isolated AI deployment on day one. Some do, urgently. Here's how to tell which side you're on.

2. What Changes Day-to-Day

Here's what I've seen derail otherwise sound projects: the assumption that isolated AI means slower, clunkier tools than what staff already use. It doesn't. The shift is architectural, not experiential. Your accountants, claims handlers, and paralegals use the same interfaces and the same query patterns. What changes is entirely where the data goes once they hit enter.

Before: Efficient Drafting With Hidden Exposure

A Tuesday morning at a mid-tier accounting firm. A tax manager is preparing a restructuring memo for a private client and pastes the client's full trust structure, bank statements, and a draft of a related-party loan agreement into a public AI assistant to get a first-pass summary. The draft comes back polished in under a minute. The manager is pleased with the time saved. Nobody notices that the client's financial position, entity structure, and related-party arrangements have just been processed on servers owned by an overseas technology company, under terms of service that permit the use of submitted content to improve the underlying model. There is no record in the firm's systems of what was submitted or when. If the client's structure ever becomes the subject of an ATO review or a dispute with a related party, the firm cannot demonstrate what left the building.

After: Same Speed, Nothing Leaves the Firm

The same Tuesday morning, five months after an isolated deployment. The tax manager pastes the same categories of information into the same-looking chat interface. The draft comes back in a comparable time. The documents were processed on a server the firm leases exclusively, sitting inside the firm's own network. Nothing left the perimeter. The query is logged against the tax manager's user account and the client file reference. If the client later asks who has seen their structure, or a regulator asks how the firm handles client data in its AI tools, the answer is a complete audit log, not a shrug.

"The shift in mindset is from asking ‘is this AI tool on our approved list’ to asking ‘where does this document go, and who can see it, once I press enter.’"

3. The Business Case

The number that surprises most people is not the cost of building an isolated AI deployment — it's the cost of the incident it replaces. Across the confidentiality incidents I've reviewed at regulated services firms, the average all-in cost — remediation, the firm's PI insurance excess, client compensation, and the partner and risk-team hours spent managing the fallout — lands around $340,000 per incident. That figure sits well below headline mega-breach numbers you may have seen elsewhere, because it reflects the more common scenario at a firm of 50–500 staff: one client file, one bad outcome, one very expensive apology.

The business case for isolated AI doesn't require your firm to have already had an incident. It requires an honest estimate of three things: how often your teams are putting client data into public AI tools, what a confidentiality incident involving that data would cost you, and what an isolated deployment costs to build and run. In the engagements I've worked through, isolated AI pays back within 12–20 months on confidentiality risk reduction alone — before counting the productivity gain from finally being able to use AI on client work that was previously too sensitive to touch.

4. How the System Works

Be sceptical of any vendor quoting an isolated AI deployment as a simple software swap. What you are actually building is a complete data processing environment that sits inside your firm's own network perimeter, connected to the systems your teams already use — practice management, policy administration, or case management. Here's what that looks like in six stages.

Stage 1 — Data Enters the Internal Gateway. Client documents, claim files, case notes, and financial records originate from your existing systems — practice management, policy administration, core banking, or case management. A data classifier checks the content against your firm's governance policy before the AI ever sees it. Queries that don't meet policy are returned to the user with a clear explanation, not silently blocked.

Stage 2 — Policy Enforcement. Your firm sets the rules: which data types can go to which AI functions, who is authorised to submit what, and what must be logged. For a law firm this includes privilege tagging; for an insurer, claimant medical sensitivity; for an accounting practice, related-party and trust structure flags. The policy enforcer applies these rules at the gateway — not buried inside the AI model where your risk team can't see them.

Stage 3 — Isolated Model Processing. The approved query reaches the local language model server. This server has no outbound internet connectivity. It cannot call external APIs, phone home to a vendor's telemetry endpoint, or send query content anywhere outside your infrastructure. The model runs on hardware your firm owns or leases exclusively.

Stage 4 — Encrypted Case Store. Any data retained for context, matter history, or audit purposes sits in an encrypted store inside your perimeter. Your firm holds the encryption keys, not a third-party AI vendor.

Stage 5 — Output Generation. The underwriting note, claims recommendation, contract review summary, or advisory draft is generated and returned through the same internal channel. It never travels over the public internet.

Stage 6 — Audit Trail. Every query is logged against the user, the client or matter reference, the timestamp, and the data classification. If a regulator, an auditor, or opposing counsel asks what happened to a document, you can answer with a complete record instead of an educated guess.

5. How the AI Data Risk Actually Works

Most partners and risk officers I speak with assume data submitted to a public AI tool is handled roughly the way a search query is handled — processed briefly, then discarded. The reality is more complicated, and the distinction matters enormously for firms holding client money, medical records, or privileged case material.

An isolated AI deployment restores the segregation your clients already expect from you in every other part of the relationship. Their data doesn't leave your servers. It isn't used to train someone else's model. It's processed on hardware you control, and the query log belongs to your firm. Output quality is comparable to the public alternative — open-weight models in the 7B–70B parameter range (the number refers to how many internal settings the model has learned, a rough proxy for capability) now perform well enough for drafting, summarising, and first-pass analysis across most client-facing use cases without needing a public internet connection.

6. What It Costs

I'll be direct about costs, because this is where proposals I've reviewed for regulated firms have most often been either too optimistic or deliberately vague. There are two categories: the one-time project cost to build the deployment, and the ongoing annual cost to run it.

7. What Your Team Needs

Here's what I've seen derail otherwise sound projects: launching an isolated AI deployment without the internal capability to run it. This is not a vendor-managed subscription you can forget about after go-live. It requires real ownership inside the firm.

The minimum viable internal team is:

• One infrastructure owner — responsible for server health, the patching schedule, and access control. Does not need to be a data scientist. A senior IT administrator with Linux server experience can fill this role.
• One data governance owner — responsible for the classification policy, privilege tagging rules, and the quarterly audit of query logs. This is typically your risk officer, general counsel, or compliance manager, with 2–4 hours per month of dedicated time.
• One technical integration lead (for the build phase only) — connects the AI layer to your practice, claims, or case management system. This can be an external contractor for the first 3–6 months, with handover to your internal infrastructure owner once the system is stable.

On build vs. buy: the honest answer is that most firms in the 50–500 staff range are better served by a specialist implementation partner than by building everything in-house. The reason is integration work — connecting an isolated model cleanly to a practice management or claims system, and getting the privilege and classification rules right, requires specialised knowledge that's hard to develop internally for a one-time build. Once the system is live, ongoing operations and maintenance can almost always sit with your existing IT team.

8. How You Know It's Working

The metrics for an isolated AI deployment at a regulated firm are different from the metrics you'd track for a standard IT rollout. You're not just measuring uptime — you're measuring whether the deployment is actually reducing client data exposure and delivering the productivity outcomes that justified the spend.

9. Where to Start

In practice, the right starting point for most firms is not a full deployment. It's an honest audit of what's already happening. Here are five specific actions, in order.

1. Conduct a shadow AI audit in the next 30 days. Ask each practice group or business unit to list every AI tool currently in use, including free consumer tools staff have signed up for individually. Don't assume the answer is "just the approved ones." In my experience, most regulated services firms discover 4–8 unsanctioned AI tools in active use once someone asks the question directly. Map what client data is being submitted to each.
2. Classify your data by sensitivity tier. Not all client data carries the same risk. A three-tier classification — public, internal, regulated — is usually sufficient for a first deployment. Regulated data (medical records, financial statements, privileged case material, KYC and AML documentation) goes into the isolated system. Internal data can often stay on managed public AI with appropriate access controls. Public data needs no restriction.
3. Identify your three highest-value blocked use cases. Where are your teams currently avoiding AI because the data is too sensitive? KYC file summarisation, claims triage notes, contract redlining, case research memos — these are the use cases that justify the investment. Quantify the time cost of doing them manually at current staff rates. That's your productivity ROI figure.
4. Brief two or three specialist implementation partners. Not general IT vendors — firms with specific experience deploying private language models for regulated services. Ask for a fixed-price proposal for a 4-week proof of concept on your top use case. The proof of concept will tell you more than any vendor presentation.
5. Put the governance framework in place before the first query goes through the system. The classification policy, privilege tagging rules, and audit log format should be designed and signed off before the isolated model touches production data. Retrofitting governance onto a live deployment is significantly harder and more expensive than building it in from the start.

Key Takeaways