AI for law firms: a privilege-safe architecture (2026)

Why the default AI answer doesn't hold up

Legal professional privilege belongs to the client, not the firm, and it's backed by professional conduct rules that don't bend for "the AI probably didn't read it." That changes the risk calculation entirely. Generic enterprise AI advice — "Microsoft is enterprise-grade, you're covered" — is true up to a point, and dangerously incomplete past it.

Azure OpenAI and Azure AI Foundry don't train the base models on your prompts. That part holds up. But by default, Microsoft retains prompts and completions for up to 30 days for abuse monitoring, and in flagged cases a human reviewer can read that content. For most customers that's irrelevant. For a firm pasting in draft settlement terms, it's a stranger reading privileged material without the client's knowledge.

The fix is a real, specific thing: Microsoft runs a Limited Access / modified abuse monitoring process for customers handling sensitive or regulated data. Apply, get approved, and that logging switches off for your tenant. Almost no firm knows to ask.

The pattern: three components, six safeguards

Every privilege-safe AI assistant comes down to three components, all inside a tenant the firm controls rather than a third-party SaaS product:

Six safeguards close the specific gaps a generic deployment leaves open:

Locking the network down is a few lines of Bicep:

resource disablePublicAccess 'Microsoft.CognitiveServices/accounts@2024-10-01' = {
  name: foundryAccountName
  properties: {
    publicNetworkAccess: 'Disabled'
    networkAcls: { defaultAction: 'Deny' }
  }
}

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2023-11-01' = {
  name: '${foundryAccountName}-pe'
  location: location
  properties: {
    subnet: { id: subnetId }
    privateLinkServiceConnections: [{
      name: '${foundryAccountName}-plsc'
      properties: { privateLinkServiceId: foundry.id, groupIds: ['account'] }
    }]
  }
}

None of this is exotic — it's the same private-endpoint pattern used to lock down any Azure PaaS resource. What's different is the decision to bother, because most AI deployments never disable public access simply because nobody told them it was on.

What it actually costs

Build cost — tenant setup, network lockdown, document indexing, the abuse-monitoring exemption application — typically runs £3,000-8,000 as a one-off, with a working system in two to three weeks.

Compare that to off-the-shelf legal AI SaaS, which typically charges £100-300 per user, per month. A ten-person firm on a per-seat product is paying £1,000-3,000/month for something with less control over where the data actually sits. Past a handful of users, the self-hosted pattern is usually cheaper within the first year — as well as safer.

The rule generalises past legal

Swap "privilege" for "patient confidentiality" and the same architecture applies to a healthcare provider handling special category data under UK GDPR. Swap it for "client money and market-sensitive information" and it's the pattern for an FCA-regulated advisory firm. The regulator changes; the shape of the problem doesn't:

1. A duty of confidentiality exists that's stricter than general data protection law.
2. The default AI vendor configuration wasn't built with that duty in mind.
3. A safer configuration exists, but it has to be requested, not assumed.

If your organisation has a professional body, a statutory duty, or a client relationship built on confidentiality, this checklist applies with the nouns changed.

Getting help

We build privilege-safe Azure AI deployments for firms that can't treat "probably fine" as an acceptable answer — from the tenant and network design through the abuse-monitoring exemption to the document index itself.

Related: Azure AI Foundry: a practical guide, Azure AI landing zone, Azure AI Foundry consultancy and Azure AI cost management.