AI Guardrails for Contractors: Before It Touches a Contract
AI in a contracting business reads contracts, prices changes and talks to customers. Those are liability surfaces. Here are the guardrails to set before it does any of them.
Most AI governance writing is about model bias and regulatory frameworks. None of that is your exposure.
Your exposure is that a system read a contract, priced a change and sent it to an owner, and now you are arguing about whether you are bound by it. Everything below is about preventing that particular afternoon.
What should AI never do without a person?
Draw the line at commitment. A system can prepare anything. It should not commit you to anything.
- Send a price to an owner or GC. Prepared, yes. Sent without a named human approval, no.
- Accept or acknowledge a change directive. Acknowledgement has contractual weight in most forms.
- Agree a schedule date. A date in writing to a GC is a position in a delay claim.
- Release a lien waiver, or state a payment status. Statutory consequences, and they vary by state.
Everything on that list can be drafted, assembled and queued by a system. The approval is the guardrail, and it has to be a person with a name and a timestamp.
What approval limits make sense?
Thresholds, the same way you already run purchasing authority. A change order under a dollar figure can be prepared and routed to a PM. Above it, routed to an owner. Above a second figure, nothing moves without two approvals.
The figures are yours. The principle is that an automated path and a manual path should carry the same authority limits, because the risk is identical and the speed is not.
What has to be in the audit trail?
On anything touching a contract document, four things.
- What the system produced, in the version it produced it
- What it based that on, which documents and which revision
- Who approved it, and when
- What changed between the draft and what went out
If a vendor cannot show you this in a demo, the system is not ready for contract work. This is not an AI standard, it is the standard any construction document workflow already has to meet.
Where is the data allowed to go?
Three questions worth settling in writing before anything is connected.
- Does your contract data leave your systems? Most AI features send content to a model provider. Ask which, ask whether it is retained, and ask whether it trains anything.
- What does your owner's contract say? Confidentiality clauses on public and institutional work frequently restrict disclosure to third parties, and a model provider is a third party.
- Who can see what internally? A system that surfaces job cost to anyone who asks is a problem the first time a subcontractor's rate shows up in the wrong conversation.
What should it do when it is wrong?
The single most important behaviour, and the easiest to test in a demo.
Ask the vendor what the system does with an ambiguous change directive. The right answer is that it stops, says what is ambiguous and routes it to a person. The wrong answer is a confident interpretation. Systems that bluff get caught once by a field crew and are never trusted again, which means you paid for something nobody uses.
Who owns this?
One named person, usually whoever already owns contract administration rather than whoever owns IT. The decisions above are commercial decisions wearing a technical hat, and a controller or a senior PM will make them better than a systems administrator.
The short version
Let it prepare anything. Let it commit to nothing. Log what it did and what it read. Decide where the data goes before it goes there. Make sure it escalates rather than guesses.
Five rules. They cover nearly everything that actually goes wrong.