Somewhere in your firm right now, two conversations are happening in parallel. In one room, an innovation team is demonstrating what AI can do on a transaction. In another, a risk committee is drafting a policy that would prohibit most of it. Both groups are doing their jobs. The problem is that nothing connects them: the AI use is real, the governance is a document and neither can see the other.
Clients are now asking partners directly: “How are you using AI on our work?” The firms that can answer well aren’t the ones with the best models. They’re the ones whose AI use is governed in a way they can actually show.
What ungoverned AI on transactions looks like
Strip away the policy language and the risk picture is concrete. When lawyers use AI tools disconnected from the deal workflow:
- There’s no record of what the AI read or did. If output makes it into work product, nobody can reconstruct how.
- There are no permission controls. The tool sees whatever the user pastes into it, on any matter, for any client.
- There’s no deal-level context to catch errors. An answer that’s plausible at the document level can be wrong at the transaction level, and nothing flags it.
- Supervision is impossible at scale. A policy that relies on every associate remembering the rules on every matter isn’t a control; it’s a hope.
Most firms respond with one of two bad options: prohibit AI on client matters (and watch usage go underground) or permit it broadly (and carry risk nobody has measured). There’s a third option: change where the AI works.
Governance as architecture, not policy
One principle reframes the whole problem: an AI agent’s access should be defined the same way a person’s is.
Law firms already know how to govern participants on a transaction. Role-based permissions decide what each person can see and do, at matter, list and document level. An audit trail records every action. That’s how firms safely include clients and counterparties on live deals today.
When AI operates through the same layer, it inherits the same governance. On Legatics, an agent connected to a matter works within defined scope: the permissions decide what it can see, and every action it takes is logged and attributable. The audit trail doesn’t distinguish between “controls we wrote down” and “controls that exist”; they’re the same thing.
That’s the difference between AI use a firm can supervise and AI use it has to prohibit.
What this gives each stakeholder
The risk committee gets a framework it can enforce. “What’s our AI framework?” has a concrete answer when there’s a governed layer AI operates through: defined permissions, complete logging, reviewable actions. Without it, the framework is a policy document nobody can enforce.
The partner gets visibility. What the AI did, what the humans did and where the deal stands, in one place. And an answer for clients that holds up: “Our AI works inside a governed transaction platform your team can see into.” That beats “our associates have ChatGPT.”
The lawyer gets clarity. The rules aren’t a memo to remember; they’re built into where the work happens. Use the AI inside the matter and you’re inside the guardrails, automatically.
The AI program gets more capability, which surprises people. Firms extend more to AI they can supervise, so the governance ends up funding the ambition rather than limiting it.
Conclusion
The question “is AI use on my matters a risk I’m carrying without knowing it?” deserves a better answer than a policy PDF. The answer that works is architectural: AI that operates through the transaction layer, permissioned and logged like every other participant, visible to the people accountable for the deal.
Next in this series: the CIO’s view. What “AI architecture” means when your stack is being reshaped around AI, and why an open standard changes the vendor calculation.
Want to show your risk committee what governed AI on a live matter looks like? Book a demo.
