Loading insights
Loading insight article
Insights / Governance
A written AI policy can't stop an associate from pasting client facts into ChatGPT or catch a hallucinated citation before it reaches a brief. Here's the engineering layer including access controls, verification gates, audit trails that turns governance from intention into something actually enforced.
Most law firms now have an AI policy. Very few have AI governance that actually works.
The distinction matters more than it sounds. A policy tells lawyers what they should do, keep privileged material out of consumer tools, verify every citation, route high-risk work through review. AI governance for law firms typically stops there: a document, signed off by the risk committee, filed alongside the rest of the compliance library.
But a document has no way of stopping an associate from pasting client facts into ChatGPT before a filing deadline. It cannot catch a hallucinated citation before it reaches a brief. It cannot see which matter an AI query touched.
That is the gap this piece is about. A durable AI governance framework cannot live in a policy binder alone, it has to be built into the systems lawyers use every day. Governance needs an engineering layer, not just documents. The engineering layer is what transforms governance from intention into enforcement. It is the difference between hoping lawyers follow rules and ensuring they cannot violate them.
Law firms already operate under professional duties that no policy document can discharge on its own. ABA Model Rule 1.1 requires competence, which now extends to understanding the AI tools used on client matters. Rule 1.6 imposes a duty of confidentiality over how client information is handled including by AI systems. Rules 5.1 and 5.3 put supervising partners on the hook for what associates and non-lawyer staff actually do, AI-assisted or not.
The pattern is the same in every row: the policy said not to do something and nothing stopped it from happening anyway. This is also where cross-matter exposure becomes a real risk, not a hypothetical one. If an AI system surfaces information from one client's matter while a lawyer is working on another, that isn't just a confidentiality lapse; it's a conflict of interest serious enough to put both representations at risk.
Firms have already solved this exact problem elsewhere. They just haven't applied the solution to AI yet:
Once the gap is clear, the next question is practical: what does an engineering layer actually consist of? The engineering layer is the technical infrastructure that transforms governance from intention into enforced behavior. It consists of specific, implementable controls that operate automatically making compliance the default, not the exception. Here's what that looks like in practice:
AI queries are checked against the firm's existing DMS or conflicts system, the same way iManage or NetDocuments already controls file access so a lawyer can only bring AI into a matter they're actually authorized to work on. This check happens at the moment of the query, not after the fact.
Before any AI-generated research, draft or citation reaches a filing, it passes through a review checkpoint that flags unverified case law and blocks it from moving forward until a lawyer confirms it. This is the control that stops a hallucinated citation before it becomes a Rule 1.1 problem.
Every AI query is logged automatically: who ran it, which matter it touched, which tool was used, when, and whether a lawyer reviewed the output. This isn't just good record-keeping, it's what a firm needs on hand if a court asks about AI use under a Rule 3.3 disclosure requirement.
Only firm-sanctioned AI tools are reachable from firm systems. Unapproved tools, including free version of ChatGPT, are blocked at the network level while data-loss-prevention rules (DLP) controls can detect and prevent legal data from leaving through unauthorized channels.
Once a matter is underway, the AI tool's version stays fixed, so results stay consistent for the life of that matter instead of shifting every time the underlying model updates.
This is what turns governance from intention into enforced behavior, every query passes through the same set of checks, whether the lawyer remembers the policy that day or not.
Agentic AI systems that can draft documents, file pleadings, schedule hearings, and communicate with courts, often with minimal human intervention, change the governance equation. When AI acts autonomously, "supervise the output" is no longer enough.
Law firms need engineered permissioning and stop-conditions, the same logic already applied to associate authority. Just as a first-year associate cannot file a motion without partner review, an AI agent shouldn't be able to take a high-risk action without a built-in approval gate. This isn't about slowing adoption, it's about recognizing that autonomy without architecture is unacceptable risk. An agent filing documents needs citation verification, conflict screening, and privilege review built into its execution path, not layered on after the fact. An agent scheduling court appearances needs direct integration with calendar and deadline systems to prevent errors that could prejudice a client's matter.
The firms that succeed with agentic AI will be the ones that engineer governance into the agent itself, not the ones hoping a policy is enough to keep it in check.
Law firms face a critical decision when implementing AI governance: what to build internally and what to require from vendors. Getting this split wrong can create gaps that neither side realizes it owns. The firm may assume the vendor is handling data isolation while the vendor assumes the firm is managing access controls. In the end, neither control is actually engineered.
The firm should own the controls that interface directly with its internal infrastructure because vendors cannot build them without access to firm-specific systems. These controls cannot simply be outsourced because they depend on how the individual firm operates and how its systems connect.
Firms must own the governance layer that interfaces with their existing infrastructure. This includes:
Firms must contractually require vendors to provide:
Before signing, a GC or CIO should be able to get a straight answer to each of these:
Scroll horizontally to view all columns.
| Question to ask the vendor | What a safe answer looks like |
| Is our data used to train your models? | No, contractually excluded, not just "opt-out available" |
| Where is our data stored and processed? | Named jurisdiction, confirmed in writing |
| Can you provide a signed data processing agreement? | Yes, as a standard part of the enterprise contract |
| Is our data isolated from other customers? | Yes, with a technical explanation, not just a policy statement |
| What happens to our data if we cancel? | Defined deletion timeline, confirmed in writing |
Success metric: Don't measure whether the policy was approved; measure whether governance is actually enforced. A firm should be able to pull up a complete audit trail at any time showing which AI tool accessed a matter, what it did, who reviewed the output, and when.
An AI governance framework built only on policy documents cannot hold up under real practice pressure. Written rules define intent, but only an engineering layer, matter-level access control, citation verification, audit trails, and enforcement, actually makes that intent operational. For most firms, the most reliable way to close this gap is a custom-built system, engineered specifically around the firm's own DMS, conflicts structure, and disclosure obligations, rather than a generic off-the-shelf AI tool retrofitted to fit. The firms that master AI governance will not be those with the best policies. They will be those with the best engineering.
If your firm is ready to transition from passive AI policies to enforced technical architecture, contact our legal-tech engineering team today to schedule an architecture review.
It exists to keep AI use defensible, not just useful, so a firm can prove, if a client, regulator, or court ever asks, exactly how AI touched a matter and who was accountable for the outcome.
Beyond approved use cases and a written policy, it needs the pieces most frameworks skip: enforcement at the point of use, a way to verify vendor commitments in writing, and a record the firm can produce on demand, not just after an incident.
Because a policy only works if everyone follows it under pressure, and deadlines are exactly when people don't. The moment a rule depends on memory rather than a technical block, it's a matter of when it gets broken, not if.
It's the layer that removes the choice to break the rule in the first place, rather than the layer that reminds someone the rule exists. The difference shows up the first time a firm needs to defend its AI use in front of a judge or regulator, "we had a policy" and "here's the log" are very different answers.
A firm can have its first enforced control live within 90 days, starting with the single highest-risk rule, usually citation verification, rather than waiting to build the entire system before turning any of it on.
Tell me about the system or workflow you are working on.
30-minute intro call on Calendly
