What you need to know before automating your contracts with AI

The request that arrives on every desk

The organisation is a public-sector body. It manages a large portfolio of commercial contracts.

The request that reached me will sound familiar to most executives right now. Contract drafting takes too long. The legal team is drowning in repetitive work. There must be something AI can do about it.

The obvious answer is a drafting agent. It reads the client data, picks the right template, fills in the variable clauses, checks the result, and hands a near-final contract to a human for approval. Five steps. A clean before-and-after slide. A productivity figure at the end.

Most suppliers will propose exactly that. They will also be able to demonstrate it working, because it does work.

I did not propose it. Not because the technology is bad. My team has built that architecture before, for an insurance client, and it does what it promises. I did not propose it because there was no way yet to know whether it was the right thing to build. That distinction is worth money to you, and the rest of this article explains why.

The questions you should expect to be asked

Our first session was deliberately structured. Twenty to thirty minutes of questions. Then a short presentation. Then a demonstration of work we had delivered elsewhere.

The questions came first on purpose.

Once a supplier shows you a solution, the conversation reorganises itself around that solution. You start describing your process in terms of how it fits the thing on the screen. You mention the details that match the demo. You skip the ones that do not. The raw version of your process disappears, and the raw version is the one that contains the surprises.

Here is what we asked. These are also the questions you should expect from anyone proposing to touch your contract process.

• From the decision to contract through to signature, how much time actually passes?
• Who intervenes, and at exactly which step? Commercial, legal, management?
• How many contract types do you manage? Are they genuinely different, or do they share a common skeleton? Is there a clause library?
• Which tools are already in the loop? Where do the contracts live, and can anyone search them?
• Have there already been incidents? Errors, costly delays, disputes, contracts nobody can find?
• What is the monthly volume? Is it stable, growing, or seasonal?
• What do signature delays cost you in revenue?
• Which KPIs do you track on the contract process today?
• Is the priority cutting cost, accelerating cycles, or securing compliance?
• Who else, beyond you, decides whether this project launches?

If a supplier opens with a demonstration instead of questions like these, the product was designed before anyone looked at your process. That is worth noticing.

What the answers surfaced

Some of it was expected. Around 500 contracts under active management. A process running across roughly 17 steps. Around 75 % of legal time spent on repeatable work, which is close to one and a half full-time posts consumed by tasks a machine could do.

Those numbers justify an automation conversation on their own. The rest did not fit the automation frame at all.

• 500 contracts under management, across roughly 17 process steps.
• 75 % of legal time spent on repeatable tasks. Roughly one and a half posts.
• One missed indexation clause, compounding at 2 % a year across a seven-year contract.
• Personal criminal liability attaching to the executive who signs.
• AI already in use, informally, with no logging and no data classification.

The indexation clause changed the shape of the project.

It had been missed. Over a seven-year term, that omission compounds, and the money involved was real. It had nothing to do with drafting speed. Nobody was checking that a specific clause existed in a specific contract type. That is all it took.

If your own contracts carry indexation, escalation or renewal terms, sit with that for a moment. The loss was not caused by slowness. It was caused by an absence of checking. A faster process would not have caught it. A faster process would have produced more contracts with the same gap in them.

Then there is the liability. These contracts concern public assets. That carries personal criminal responsibility for the executive who signs. An error does not get absorbed by the balance sheet. It attaches to a person. You cannot insure against it and you cannot delegate it away.

And AI was already in the building. Staff were pasting contract text into public chat assistants. No logging. No record of which model had seen which clause.

This is worth stating plainly, because it is almost certainly happening in your organisation too, whether or not anyone has told you. AI governance is not a future problem to be handled in a compliance annex. It is happening right now, and until somebody looks, nobody is managing it.

Two problems that look identical

The client described a productivity problem. What they had was a liability problem.

From the inside, the two are almost impossible to tell apart. Legal is slow. Drafting is repetitive. Cycles are long. Everybody can see it and everybody complains about it, and all of it is true.

But the system you should build is completely different depending on which one you are actually solving.

If the problem is throughput, you optimise for speed. Generate fast, check lightly, get the document in front of a human quickly. The metric is time saved, and the return is easy to show.

If the problem is exposure, speed does not help you. It hurts you. You optimise for traceability, for clause-level verification, for a documented chain of who decided what on the basis of which data. That system is slower than the demo. It is also the only one that protects you.

Now consider what a drafting agent would have done in this organisation. It would have worked exactly as advertised. Contracts out faster. Legal team relieved. A productivity figure to report upward.

The indexation problem would have been untouched. Except now it runs at volume.

Four things nobody could have known yet

Once the problem was reframed, the case against proposing an architecture became concrete. Four facts were missing. Each one silently decided something in the design.

If you are evaluating an AI proposal, these are the four holes to check for.

Which of your data is allowed to go where

Commercial contracts mix public information, internal information and trade secrets. Until every step of your process is sorted into those three categories, nobody can choose a hosting model for you.

Sovereign hosting, European cloud and on-premise are not three options with different price tags. They are three answers to a question nobody has asked yet. If a proposal names the infrastructure before anyone has classified your data, it has guessed. You will find out it guessed wrong when your legal counsel reads the terms.

Which use case is actually worth doing

Contract drafting was the one the client named, because it is the one people complain about. That does not make it the one with the best return.

Payment follow-ups. Compliance checking against a clause library. Document classification. Milestone tracking. All of these were candidates. Several were cheaper to build and worth more. The use case you name in a first meeting is a hypothesis. Somebody has to score it against the alternatives before you commit a budget.

Where the humans have to stay

Every supplier will tell you a human stays in the loop. That is a slogan until they can tell you at which step, on which criterion, and what happens when the model is uncertain.

The answer depends on where your liability actually attaches. Nobody had collected that detail yet. Ask the question directly, and listen to how specific the answer is.

Whether you should build at all

An off-the-shelf platform might cover most of your need for a fraction of the cost. Your data classification might rule it out entirely and force a bespoke architecture. Both are legitimate outcomes.

A supplier who tells you which one applies to you in a first meeting, before seeing your process, is not being decisive. They are guessing. And the guess reliably favours whatever they happen to sell.

What a diagnosis actually buys you

The proposal I built answers one question. Which AI architecture, in this specific context, genuinely reduces the risk, frees up the time, and stays governed and traceable?

Four phases. Four weeks. Eight person-days on site, with two consultants present at once so that several functions can be watched in parallel.

Being on site is not a billing detail. Your process documentation describes the process people are supposed to follow. Observation captures the one they actually follow: the workarounds, the informal handoffs, the undocumented shortcuts. That is where the risk lives. You cannot see it in a written procedure. You cannot see it in a workshop either, because in a workshop people describe the official version.

The engagement produces six deliverables. All of them are named in the contract, so they can be held to.

• A macro map of the 17 steps, read through an AI lens. What could be automated, and what must not be.
• A data classification: public, internal, trade secret. This is what makes your hosting decision answerable at all.
• A scored use-case portfolio across all four business functions, ranked on feasibility, return, legal risk and business impact.
• A target functional schema. What is handled by code, what by AI, what stays human, and where the audit trail sits.
• A strategic report on building internally, buying externally, or partnering.
• A roadmap over 6 to 12 months, with work packages, milestones and required resources.

Naming these in the contract matters, because it means you can act on them without me. A diagnosis that produces a deck of observations is not worth what it costs. A diagnosis that produces a decision you could take to your board, and execute with any supplier you choose, is.

The losses hide between departments

The audit covers the whole contractual chain, not just the legal function. Legal, for review, compliance and signature. Commercial, for negotiation and closing. Account management, for payment tracking and follow-ups. Technical operations.

That was a deliberate choice, and a more expensive one. Auditing legal alone would have been cheaper and easier to sell. Legal is where the complaint came from. Legal is where the 75 % figure comes from. Legal is where the client expected the project to live.

But the failure that cost money did not sit inside legal. It sat between two functions.

A clause that one team should have tracked was assumed to be tracked by another team. Nobody was negligent. The process was wrong at the join. And a join has no owner, no budget line, and nobody complaining about it in a management meeting.

One question to ask any AI supplier

An audit is worth something only if the person conducting it has nothing to gain from the conclusion.

ZECEO resells no software. No vendor relationships. No referral fees. No platform we are quietly steering you towards. Off-the-shelf tools get evaluated against bespoke architectures on the same criteria, and the comparison is written down so you can check the reasoning.

This is not a moral posture. It is what makes the deliverable usable.

Suppose the recommendation is to build in-house. You need to know that it did not come out that way because building is what the supplier bills for. Suppose it is to buy a platform. You need to know there is no commission attached. If you cannot trust where a recommendation came from, your team will argue about it for six months. You will have paid for a decision and still not have one.

So here is a test you can apply to anyone pitching you an AI project.

Ask what they would earn if the honest answer turned out to be that you should do nothing.

If the answer is nothing, and they still ran the analysis properly, you have an adviser. If every possible conclusion routes back to something they sell, you have a supplier. Read their diagnosis accordingly.

Why the cheaper proposal costs more

You will often be looking at two kinds of proposal for the same problem.

The first starts building immediately. A diagram, a timeline, a productivity figure, working software in eight weeks. The second proposes to spend four weeks understanding your process before committing to any of it.

The first is a better sale. It shows progress quickly. It gives you something concrete to defend upward when colleagues ask whether the AI project has started. It is often cheaper on the quotation.

I want to be straight about what the second one costs you. It is slower. It delays the moment anyone sees working software, and that moment is what generates internal enthusiasm and unlocks the next budget. It asks you to pay for a decision rather than a deliverable, at exactly the point where your organisation wants to see a screen.

Here is what it saves you.

A system built on a wrong assumption about your data gets rebuilt in year two, at full cost, once your legal counsel reads the hosting terms. A system built on the wrong use case delivers a productivity gain on the task that was never expensive. And a system that accelerates a process nobody is checking does not save you money. It scales the error, and hands you a green dashboard while it does.

The most expensive way an AI project fails is not that the technology breaks. It is that the technology works perfectly, on the wrong problem, for two years, and every metric says you are winning.

Questions to ask about your own contracts

Almost none of this is specific to one organisation. If your business runs on contracts, and most mid-market businesses do, these are the questions worth putting to your team this quarter.