Technology disputes often turn on what the parties agreed to do and what the delivery record shows they did. The requirements, the acceptance criteria, the allocation of operational responsibilities and the evidence of delivery are technical matters that lawyers cannot write alone. This work sits alongside your legal advisers to get them right.
Who this helps
Procurement and legal teams in corporations and government agencies buying IT or AI systems; suppliers who want a contract they can actually deliver; and law firms drafting or disputing technology agreements who need the technical substance behind the clauses. This is technical and commercial expertise; it is not legal practice and does not offer jurisdiction-specific legal advice.
The questions teams bring
Are our requirements specific enough that a supplier could fail them, and we could show it?
What should acceptance mean for an AI system whose behaviour changes with its data?
Who is operationally responsible for the model, the data, the monitoring and the failures, and does the contract say so?
What evidence of delivery should we require, and in what form, so that a later dispute is decided on records rather than recollection?
How do we govern a supplier through delivery rather than discovering the problem at go-live?
What the work involves
Requirements and procurement. Technical requirements that can be evaluated, evaluation criteria that test what matters, and procurement processes that surface supplier capability rather than presentation skill.
Acceptance and evidence. Acceptance criteria and test regimes for conventional systems and for AI systems, and the delivery evidence, from plans to test results to operational metrics, that the contract should require and the customer should keep.
Allocation of operational responsibilities. Making explicit who owns data quality, model performance, monitoring, incident response, retraining and decommissioning, so that the governance in AI governance and project delivery has a contractual footing.
Supplier governance. Contract governance that works during delivery: reporting that reveals, gates that bite, and escalation that reaches people who can decide.
Dispute support. Where a contract is already in dispute, the technical reading of obligations and performance that a legal team needs; see expert witness work.
Why AI contracts are different
An AI system's performance depends on its data, its model and its operating conditions, and it can vary after acceptance as any of those change, whether or not the model itself is updated. A contract that treats the delivered thing as fixed may not address acceptance, monitoring, change control and responsibility for that variation, and the customer can find that evidence and control are thinner than expected when the system misbehaves. These are relevant risks to address, not certainties. Dr Carlton's practitioner workbook Garbage In, Gospel Out treats procurement and governance in contracts as part of AI governance itself, and his Whose Intent Is Being Verified? series examines the evidentiary design of AI agent transactions.
A workbook that turns AI governance from a compliance burden into a delivery discipline: mapping an organisation against an AI technical standard, an implementation methodology, procurement and contract governance, and oversight across the AI lifecycle.
Argues that a merchant's terms for AI-agent purchases and Europe's payment rules converge on one requirement, a per-transaction record of what the buyer actually authorised, and that the card networks' new agent protocols verify intent at the payment end rather than where the buyer's evidence has to live.
Examines what Mastercard's Verifiable Intent and Visa's Trusted Agent Protocol actually do, layer by layer, and where each stops short of proving what an agent was instructed to do.
Where the evidence has to live when an AI agent buys the wrong thing: the instruction, the agent's reasoning under it, and the decision, all of which sit upstream of the payment. A practical account of evidentiary design for agent transactions.
Questions people ask before engaging
Do you draft the contract?
No. Your lawyers draft it. The work here supplies the technical schedules, requirements, acceptance criteria and responsibility allocations, and reviews the draft for whether its technical content will hold up in delivery and in a dispute.
Can you help on the supplier side?
Yes. A supplier benefits as much as a customer from requirements that are achievable, acceptance that is defined and evidence that is agreed in advance.
Is this only for large contracts?
The discipline scales down. Even a modest AI procurement benefits from clear acceptance criteria and an explicit allocation of operational responsibility; the cost of omitting them does not scale down.
Which jurisdictions?
The technical content of a contract is largely jurisdiction-independent. The legal form, and any jurisdiction-specific requirement, is for your legal advisers.