What running AI inside a law firm has in common with anything that can't "phone home"

Anyone who has operated a system that can’t leave the network — an air-gapped environment, an appliance at a client site with no outbound firewall rule, a regulated deployment that isn’t allowed to “phone home” — recognizes this pattern from a mile away. It isn’t an AI pattern. It’s old infrastructure routine, and Anne for Legal is just its latest instance.

The problem isn’t new, only the failing component is

Any system that needs to keep working without depending on something external has to answer an uncomfortable question: what happens when the one piece you most wanted to work, doesn’t?

In classic infrastructure, that question shows up as: the auth service went down, what does the rest of the system do? The link to the main datacenter dropped, does the site fall over or keep serving from cache? The license expired with no internet to validate it, does it lock up or keep running?

The wrong answer, almost always, is “quietly try something else.” A badly designed circuit breaker that falls back to a cloud service without telling anyone isn’t resilience — it’s a data leak waiting for the right moment. The right answer is fail-closed: when the piece that’s supposed to answer doesn’t, the system stops and says so. It doesn’t invent a response, doesn’t slip out another door, doesn’t pretend everything’s fine.

In Anne, that rule becomes concrete: the local model runs on the firm’s own appliance, and cloud fallback is deliberately disabled. If the local model goes down, Anne stops working — it doesn’t go looking for help elsewhere. That sounds obvious until you remember how many “resilient” systems you’ve seen do exactly the opposite: when the primary failed, a silent plan B kicked in that nobody had consciously decided on — it just happened.

A health check isn’t SRE fussiness, it’s the same question

A classic health check answers one simple question: is this dependency up right now, yes or no? It sounds trivial until you notice that most serious infrastructure incidents aren’t “the system went down” — they’re “the system kept answering as if it were fine, while a critical part of it already wasn’t.”

Anne treats every verification layer exactly the same way: every state is explicit — passed, flagged, needs review, blocked, or unverified. A layer that didn’t run never silently becomes “passed.” That’s a health check applied to an AI’s claims instead of a network service, but it’s the same discipline: never let the absence of verification default to approval.

An immutable snapshot is a versioned backup by another name

Anyone who has done blue-green deploys, or versioned infrastructure as code, knows the rule: the version currently in production doesn’t change under your feet. If something needs to change, a new version ships; the old one keeps existing, referenceable, auditable.

Anne’s audit trail follows the same rule: when new evidence arrives, it creates a new snapshot. Any decision made against the old snapshot gets flagged for re-review, and anything already released stays pinned to the snapshot it was released against. Nothing gets rewritten in place. A correction is a new record, not an edit to the old one — the same reason you don’t overwrite a release tag, you cut the next one.

Why this matters more than it sounds

The temptation, when the subject is AI, is to treat everything as a new problem requiring new vocabulary. It almost never is. A law firm that can’t send a file outside has exactly the same shape of problem as any environment that can’t leak data to an unaudited third party — just swap “hosted model” for “cloud vendor,” “outsourced service,” “SaaS with no signed confidentiality agreement.”

The architecture that solves it isn’t sophisticated. It’s the same old infrastructure discipline — fail-closed, explicit state, immutable history — applied where most AI products today pick the easier path: send everything to the cloud and call it scalable.