Governance First, Then Automation: What Law Firms Get Right That In-House Teams Often Miss

The Sequence Matters More Than the Speed

When Johnson Stokes & Master announced its suite of internal AI agents built on Microsoft Copilot, the detail that stood out was not the technology itself. It was the order of operations. Governance first, then automation. That sequence is, in practice, the opposite of how many organisations approach AI adoption, where the tool arrives on a Tuesday and the policy arrives, eventually, sometime later.

The firm's public framing of its programme as "governance-first, human-led" is worth taking seriously. It signals that professional services firms operating in regulated, high-stakes environments are learning that AI implementation is not primarily a technical project. It is a risk management project that happens to involve technology.

For in-house legal teams and commercial functions, this is an instructive model, not because you should replicate a law firm's internal infrastructure, but because the underlying logic applies directly to how you deploy AI across your contract portfolio.

What Governance-First Actually Means in Practice

Governance in the context of legal AI is not a compliance checkbox. It is a set of deliberate decisions about accountability, data handling, review obligations and output standards, made before any tool is switched on at scale.

For a CLM context, this means answering questions such as: which contract types can AI draft without a human review stage, which jurisdictions require local counsel sign-off regardless of what the AI produces, and what happens when AI-generated language conflicts with your standard positions?

Without those answers in place, AI tools accelerate work without anchoring it to the standards your organisation is actually responsible for. The speed is real. The risk is also real.

Adira is designed around this principle. Jurisdictional knowledge is built into the drafting layer, not bolted on afterwards. When Adira drafts a clause, it works from an understanding of the governing law, not from a generic template that a user is then expected to localise. That distinction matters enormously when a contract is later disputed in a Singapore court or reviewed by a Hong Kong regulator.

The Human-Led Frame and Why It Needs Precision

The phrase "human-led AI" is appearing with increasing frequency in legal technology announcements. It is a reassuring phrase, but it can obscure more than it reveals if left undefined.

Human-led can mean a lawyer reviews every AI output before it leaves the building. It can also mean a lawyer is theoretically available to review outputs but volume and time pressure mean that review is cursory. These are very different risk positions.

For in-house teams adopting AI in contract workflows, the honest question is: at what point in the process does human judgement actually engage, and what is that person reviewing for? If reviewers are checking formatting and not legal substance, the governance claim is weaker than it appears.

A well-structured CLM approach specifies the review obligation by contract type and risk tier. Routine NDAs on standard terms sit in a different lane from complex commercial agreements with bespoke indemnities. The AI handles volume in the former; human expertise concentrates on the latter. That is not a reduction in human involvement. It is a more intelligent allocation of it.

The Vendor Relationship and the Knowledge Gap

One tension in the law firm AI model is worth naming. Firms like JSM are building internal agents using a general-purpose platform. That is a legitimate choice, and Microsoft's enterprise infrastructure offers real advantages around data residency and security integration.

However, general-purpose platforms do not arrive with legal domain knowledge pre-loaded. Firms must invest significantly in prompt engineering, training data curation and workflow design to produce outputs that meet professional standards. That investment is not trivial, and it is ongoing.

For in-house legal teams, the build-versus-buy question is particularly pointed. Most commercial legal functions do not have the internal resource to replicate what a well-funded law firm IT programme can do. The more efficient path is a purpose-built legal AI that already understands contract law, knows your jurisdiction and can read a counterparty's paper from your perspective, identifying what is missing, what is aggressive and what is non-standard for your sector.

That is the problem Adira was built to solve. The jurisdictional and doctrinal knowledge is in the product, not in a lengthy configuration project that precedes it.

What In-House Teams Should Take From This

The JSM announcement is a useful data point for any legal function evaluating AI strategy. The takeaways are practical rather than aspirational.

First, decide your governance framework before you select your tools. The tools should serve the framework, not define it. Second, be precise about what human-led means in your workflows, and test whether that precision holds under real volume. Third, assess honestly whether a general-purpose platform with legal customisation layered on top is the right architecture for your team, or whether a purpose-built legal AI gives you the same capability with less internal overhead.

Speed to contract is a commercial advantage. Speed to a poorly governed contract is a liability. The firms and in-house teams that understand the difference will build AI programmes that last.