Simply put, AI governance in law firms is becoming more important as legal technology gains greater access, capability, and connectivity.
The question isn’t only whether new legal technology works. It’s whether the firm is ready for what happens when it becomes part of the work.
I recently watched a LawNext demonstration of LawToolBox’s Model Context Protocol capabilities for Microsoft 365 and Claude.
What caught my attention was not simply what the technology could generate. It was how much more connected legal AI is becoming.
The demonstration showed AI working with matter containers that can bring together deadlines, documents, legal information, meeting transcripts, strategic analysis, and other matter-specific information. The technology can also support activities such as extracting and calculating deadlines, drafting documents, analyzing matter information, and interacting with calendars and other systems.
That is an important evolution in capability.
And it raises a question I suspect law firms will encounter more often as legal AI becomes connected to the systems where work actually happens:
What needs to happen before we connect it?
This is not an argument against connected AI. Quite the opposite.
Increasingly capable legal technology may create meaningful opportunities to reduce administrative friction, improve access to information, and support professionals doing complex work.
But selecting a technology and approving its use are only part of responsible adoption.
Governance is the lifecycle surrounding adoption.
As AI gains more capability, more access to organizational information, and a greater ability to influence or perform work, operational oversight needs to mature alongside it.
A useful principle may be:
More capability + more access + more consequence = more governance.
Not more bureaucracy.
More intentional governance.
Start With the Work, Not the Technology
A compelling demonstration can make it tempting to begin with the question, “Where could we use this?”
I think there is a more useful place to start:
What problem in the work are we actually trying to solve?
That distinction matters.
If the problem is unclear, it becomes difficult to determine what access the technology needs, what actions it should be permitted to take, or whether the resulting workflow is actually an improvement.
A firm evaluating an AI-enabled tool might therefore anchor its discussion around three questions:
1. What information can it access?
Matter information? Client documents? Email? Calendars? Internal knowledge? Research platforms?
Access defines part of the operating environment.
2. What can it do with that information?
There is a meaningful difference between a system that retrieves information and one that can modify records, generate work product, create calendar entries, initiate workflows, or perform other actions.
3. Where must human judgment remain in control?
Who reviews the output? Who approves consequential actions? Who is accountable when the technology becomes part of the workflow?
Taken together, those questions create a fairly simple governance lens:
Access → Action → Accountability
The point is not to turn every technology evaluation into an exhaustive risk exercise. A low-impact tool with limited access should not necessarily receive the same scrutiny as a system interacting with sensitive matter information and consequential workflows.
Governance should be proportional.
Read, Recommend, Write, Act
Another way to think about capability is as a progression:
Read → Recommend → Write → Act
Imagine an AI tool that can read matter information and summarize it for an attorney.
Now imagine the same technology can recommend what should happen next.
Then draft the communication or document associated with that recommendation.
Then take an action inside another system.
Each step may be useful. Each also changes the operational relationship between the human and the technology.
That relationship deserves attention because responsibility does not disappear as AI becomes more capable. The workflow may change, but someone still owns the outcome.
This is particularly relevant in legal practice.
The American Bar Association’s Formal Opinion 512 identifies professional obligations lawyers need to consider when using generative AI, including competence, confidentiality, communication, supervision, candor, and reasonable fees. The opinion also emphasizes understanding the capabilities and limitations of the technology being used.
That does not prescribe one governance process for every firm or every tool.
It does reinforce a larger point: adopting AI does not transfer professional responsibility to the technology.
The National Institute of Standards and Technology makes a similar lifecycle observation from a broader risk-management perspective. Its voluntary AI Risk Management Framework describes AI risk management as something that should occur throughout the lifecycle of an AI system, with governance operating across the process rather than appearing only at deployment.
That distinction becomes increasingly important as technology changes after it enters the organization.
Approval Is a Moment. Governance Is a Lifecycle.
Suppose a firm approves an AI product after reviewing its intended use, security posture, permissions, and workflow.
Six months later, the product gains a new integration.
Then another.
Perhaps it can now interact with email, calendars, a document-management system, matter data, research tools, or another AI-enabled application.
The product may have the same name.
But operationally, it may no longer be the same system the firm originally evaluated.
That creates an important architecture question:
When does adding another connection materially change the risk profile of the system?
There probably isn’t one universal answer.
But the question itself deserves a place in the governance process.
Permissions change. Integrations change. Models change. Capabilities change. Workflows change.
Sometimes those changes will be minor.
Sometimes they should trigger another look.
That is why governance cannot simply be a gate technology passes through before deployment. It needs enough visibility to recognize when the environment has materially changed.
Bring the People Closest to the Work Into the Evaluation
This is one place where I borrow from my years as an Agile Coach and Business Agility Manager: the people closest to the work often see things that aren’t visible from the conference room.
An attorney may understand where professional judgment cannot safely be compressed into a workflow rule.
A paralegal may recognize an exception that rarely appears in the documented process but occurs regularly in practice.
IT or security may see implications created by permissions or system connections that other participants would never think to ask about.
That does not mean everyone gets veto power. Decision ownership still needs to be clear.
It means responsible adoption benefits from multiple perspectives before the technology becomes embedded in everyday work.
The people closest to the work shouldn’t just be trained on the technology after the decision is made. They should help pressure-test it before the decision is made.
And pressure-testing should go beyond reproducing the successful vendor demonstration.
What happens when information is incomplete?
What happens when two sources conflict?
What happens when an output sounds convincing but is wrong?
The purpose isn’t to prove that the technology is unsafe.
It is to understand what the firm is introducing before people begin depending on it.
Pilot Before You Expand
For higher-impact AI use cases, a limited pilot can create room to learn without immediately exposing the entire organization to a workflow that is still being understood.
Keep it proportional.
A pilot might involve a small group of users, defined use cases, and bounded permissions. Human review points and success criteria can be established before the pilot begins.
But there is another component that is easy to overlook:
Give people a simple way to tell you what they experience.
The mechanism does not need to be sophisticated.
A firm might use an existing form, shared inbox, Teams channel, or service-management process.
In fact, there is a useful design principle here:
Don’t introduce another technology merely to govern the technology you just introduced.
Make observation easy.
Someone reporting an experience should only need to explain what they were trying to do, what happened, what they expected to happen, and anything else that seems relevant.
They should not have to diagnose the problem.
Was it a software defect? A training issue? A policy question? A security concern? A poorly designed workflow?
That determination belongs with whoever is responsible for triage.
And the observation channel should capture successes too. Knowing what works reliably is just as useful as knowing what fails.
Turn Experience Into Governance
This is where human-centered AI adoption starts to become organizational learning.
People use the technology.
They observe what happens.
Someone triages those observations.
Then, periodically, the organization steps back and asks what the experience is teaching them.
A simple Agile retrospective technique works surprisingly well here:
START
Based on what we have learned, what should we begin doing?
STOP
What isn’t working, creates unnecessary risk, or needs to change?
CONTINUE
What is working and should be preserved, taught, standardized, or expanded?
The observations collected during the pilot give that conversation evidence. The retrospective is no longer dependent on whoever remembers the most noticeable incident from the previous month.
The loop becomes:
Observe → Triage → Retrospect → Adapt
I discuss Start / Stop / Continue in my professional video because the technique is intentionally simple. Its value comes from creating a recurring moment where experience can become adaptation.
AI governance can benefit from the same rhythm.
When Does Experience Become Policy?
There is another question hiding inside this learning loop.
Suppose users repeatedly discover that a particular use case requires additional review.
Or a pilot reveals a boundary that was not obvious during the original evaluation.
Or the technology gains a capability that changes how people should use it.
At what point does something learned through actual use need to become an explicit rule, boundary, or accepted practice?
Policy cannot anticipate every situation before adoption begins.
But neither should organizations rely indefinitely on informal knowledge circulating among a handful of experienced users.
Somewhere between those two extremes is governance maturity: the ability to observe what is happening, recognize recurring patterns, and decide when experience needs to become organizational practice.
That is how policy remains connected to actual work rather than becoming a document that describes how people were expected to use the technology six months ago.
AI Agility Is More Than Learning to Use AI
There is a broader capability underneath all of this.
Organizations increasingly need to become good at adapting around AI, not simply adopting it.
That means learning how to introduce technology thoughtfully, observe its effects, adjust workflows, clarify accountability, and change oversight as capability changes.
I think of that as part of AI Agility.
The goal is not to predict every possible issue before deployment.
That would be unrealistic.
The goal is to build an organization capable of learning without surrendering accountability while it learns.
An emerging lifecycle might look something like this:
Listen → Pressure-Test → Decide → Pilot → Observe → Retrospect → Adapt
I am intentionally hesitant to turn that into another branded framework.
The sequence matters more than the label.
It reflects something organizations already understand in other forms: responsible change is rarely a single decision. It is a series of decisions informed by what we learn along the way.
AI simply increases the importance of making that learning visible.
Before You Connect It
Connected legal AI will continue creating new possibilities.
The question for law firms is not whether every new connection should be treated as dangerous.
It is whether firms understand what changes when technology gains access to more information, becomes capable of more consequential actions, or moves deeper into the workflows professionals depend on.
That requires technical understanding.
It also requires people who understand the work, clear decision ownership, practical feedback mechanisms, and governance that can adapt as the technology changes.
Considering an AI tool for your firm?
Before you connect it, pressure-test it.
Understand the workflow it is entering. Understand what it can access and what it can do. Decide where human judgment must remain in control. Then create a way to learn from what actually happens after deployment.
That is the kind of work The Agile Phoenix supports with legal and compliance-sensitive organizations: bringing people, workflows, responsibilities, and governance into the AI adoption conversation before technology becomes simply another part of the operating environment.
Because the real measure of responsible adoption isn’t whether a firm successfully deploys AI.
It’s whether the firm can remain accountable as AI becomes more capable.
Three Takeaways
- Governance surrounds adoption. Approval is one decision in a longer lifecycle of observation, oversight, learning, and adaptation.
- Capability should shape oversight. As AI gains greater access and moves from reading toward consequential action, governance should become more deliberate.
- The people closest to the work matter. Human-centered adoption means involving the people who understand real workflows in pressure-testing, observation, and adaptation—not simply training them after deployment.
Here’s a Thought Experiment
Imagine your firm approved an AI tool six months ago. Since then, the vendor has added new integrations, broader permissions, and the ability to take actions inside systems that were outside the original review.
The product name hasn’t changed. The contract may not have changed. But what the technology can do has.
At what point would your firm know that it needs to evaluate the technology again?
And, optionally: Who is responsible for noticing that the threshold has been crossed?
