Sequence before software: how legal and compliance functions actually become AI-enabled

Something changed in legal and compliance functions over the past eighteen months, and it was not the technology.

The capability question is answered. The operating question is not.

An Association of Corporate Counsel study of 657 in-house counsel across 30 countries put generative AI adoption at 52 percent in the United States for 2025, up from 23 percent the year before, with Europe running ahead at 61 percent. The share of businesses imposing policies against AI use collapsed from 29 percent to 9 percent. Whatever the debate was in 2024, it is over.

And yet, walk into most legal or GRC functions today and you will find the same pattern:

• The tools are in place. A drafting and research assistant is licensed, often enterprise-wide. The capability question has been answered.
• Usage is uneven. A handful of enthusiasts, a majority who tried it once, and very few people whose working day has actually changed shape.
• Nobody captured the "before". Benefits are asserted in board papers, believed by nobody, and quietly dropped from the next update.
• The rule for AI itself is missing. The code of conduct covers confidentiality, data privacy and IT security, and does not mention artificial intelligence once.
• Two clocks disagree. The group policy says 72 hours for breach notification; a sector regulator says 24. Nobody has reconciled them, and the incident runbook runs on whichever one somebody remembered.

The gap between the functions that pull ahead and the rest is not budget. By now it is not tooling either. It is sequence.

There is a second reason this matters more for legal and compliance than for any other function: you cannot credibly govern the enterprise's use of AI if you cannot evidence your own. In most organisations the General Counsel, the DPO and the CISO between them own the AI position, the risk classification, the human review rule and the escalation route. A function that holds that mandate and cannot produce a record of how it uses AI itself is in an awkward position the first time a regulator asks.

So: three stages, in order. Identify the candidates. Design the process. Only then, buy the software.

Stage one: identify the right candidates

The instinct is to start with the work that hurts most. That is usually wrong, because the work that hurts most is normally the work that is hardest to change. Start instead by scoring every candidate task on four axes.

Score each candidate, then plot impact against feasibility. Four groups fall out:

• Priority pilots (high impact, high feasibility). Start here.
• Quick wins (lower impact, high feasibility). Cheap proof, low risk, useful for building confidence.
• Strategic bets (high impact, low feasibility). Remediate the foundations first. Functions that start here stall.
• Deprioritise (low on both). Revisit later, honestly.

Two things about this exercise are more important than the framework itself.

Data readiness is a legal question before it is a technical one. "Can we put this in a cloud tool" depends on residency rules, sector-specific localisation, retention obligations that can run to decades in healthcare and financial services, and whether the contract with the data source permits it. In regulated sectors this is the single most common reason a promising pilot dies in month three. Screen for it at the start, not after the business case is approved.

Score on evidence, not on impressions. A workshop where senior people estimate how long things take produces a list of grievances, not a baseline. What you need before scoring anything is a short, structured baseline: a single work-type taxonomy, time allocation and cycle times measured against it, and an honest audit of what the tools you already own can do but nobody uses. That last item routinely returns a third of the value people expected to buy.

The typical output of this stage is unglamorous and extremely useful: five or six named candidates, each with a measured "before", a stated constraint, and a clear reason it was chosen over the others.

Stage two: design the process, not the prompt

This is the stage that gets skipped, and skipping it is what produces the pattern in the opening section: licensed capability, uneven usage, no measurable change.

Useful AI enablement is not a tool list. It is a change in how work arrives, how it is decided, and how it is recorded. Six domains cover almost everything a legal or GRC function does.

Note where a drafting and research assistant helps: the knowledge row, and part of contracting. The other four rows are about where the record lives, and no drafting layer keeps a record.

Three design rules carry most of the weight.

One front door. Until intake is a single classified channel, nothing downstream can be measured, prioritised or automated. This is the least exciting piece of work in the programme and the one with the highest dependency count.

One data model. A DPIA, a transfer impact assessment, an AI risk classification and a security review overlap heavily in what they ask. Built as separate forms, they are four efforts and four unreconcilable stores. Built on a shared model, you screen once against the strictest applicable requirement and then record which regime each answer serves.

Evidence by default. Every AI-assisted step should leave a record of what was proposed, what a human decided, on what basis, and what the system could not assess. That last item matters more than people expect. A system that silently skips what it cannot handle is worse than one that flags the gap.

Alongside the process work sits a document worth naming separately: one AI rulebook for the function. Approved uses and prohibited ones, the human review requirement and where it is mandatory, how privilege and confidentiality are protected, which data classes may never enter which system, and who signs off. Two practical notes. First, write it as an extension of the policies you already have rather than a parallel AI regime beside them; most groups have a policy review cycle, and riding it makes the work far cheaper to sponsor. Second, name a person. Residual risk needs a named owner and a date, otherwise the decision to escalate is never actually taken, it just defaults to silence.

Finally, decide the measurement before you start. Cycle time, first-pass resolution rate, share of requests self-served by the business, obligations tracked to renewal, assessments completed before the design was frozen rather than after. Measured against the Stage One baseline, reported quarterly, at the same committee where the function already reports.

Stage three: now, and only now, look at tools

By this point you know what the work is, on what data, and where the evidence has to land. That turns tool selection from a beauty parade into a specification.

The first distinction to make is between two layers that are often confused.

The capability layer does research, drafting, bulk document analysis and increasingly multi-step agentic work. Harvey is the best-known example in legal; there are credible alternatives, and general-purpose assistants cover part of the ground. For knowledge work these are strong products, and many functions already own one.

The operating layer holds the record: request intake, matter records, the obligation register, litigation holds, assessments, the risk register, outside counsel and spend. Pritect sits in this layer, as do the established GRC and CLM platforms.

The clearest evidence that these are different layers is the integration lists. Drafting tools connect to document management, contract lifecycle and matter systems precisely because they are not those systems. This is not a criticism of anyone's purchase. If you bought a drafting layer, you bought a drafting layer. What is usually missing is the operating layer beneath it, and very few providers sell both well.

The second distinction is between assurance about the tool and assurance about your compliance. Provider certifications (SOC 2, ISO 27001, ISO 27701, ISO 42001) answer whether the product is securely built. Adoption analytics answer whether people use it. Neither answers the question a regulator or an auditor will actually ask: are you compliant, on what evidence, approved by whom. That record lives in your operating layer, or it does not exist.

Practical questions worth putting to any provider at this stage:

1. Where does the evidence land, and can I export the full audit trail without you?
2. What happens to the output the AI could not produce or could not assess? Is the gap visible?
3. Can a human decision be recorded against every AI proposal, with the reasoning?
4. Which of my regimes does one assessment serve, and how do I show which answer belongs to which regime?
5. Where is the data hosted, which sub-processors touch it, and is my content used for training?
6. What does this replace? If nothing, be honest about that in the business case.

Then make an explicit process, configure or buy call per domain. Some of what surfaces in Stage Two is a process fix with no software attached. Some is configuration of something you already own. Only the remainder is a purchase, and it is usually smaller than the original assumption.

What good looks like after twelve months

Not "we rolled out an AI tool". Something closer to this: intake runs through one channel with measured service levels; a third or more of routine business questions are self-served; contract first-pass review runs against a playbook with obligations tracked to renewal; assessments are screened and completed on one data model with named residual risk owners; and the board pack, the regulator answer and the audit trail come out of the same record rather than being assembled by hand three times.

None of that is primarily a headcount play. It is a play on cycle time, on the business serving itself, and on being able to answer a regulator from a record rather than from recollection.

The functions that get there are rarely the ones that bought first. They are the ones that spent six weeks working out what the work actually was before anyone opened a procurement file.

Sources

Association of Corporate Counsel in-house counsel AI study, 657 respondents across 30 countries, reported January 2026. EU AI Act Article 50 transparency obligations applicable from 2 August 2026; high-risk obligations for Annex III systems deferred to 2 December 2027 under the Digital Omnibus.