Applied AI6 min read

AI in tendering needs context, not a chat window

A language model bolted onto a project tool does not make delivery intelligent. What determines usefulness is how much of your operating context the system can actually see.

SCOPERATESHISTORYRISKSAPPROVAL

Ask a general-purpose assistant to price a tender and it will produce something fluent, plausible and unusable. It has no access to your rate card, no knowledge of what the last similar job actually cost, and no way to distinguish a requirement the client stated from one it inferred.

The gap between novelty and value in engineering AI is almost entirely a question of grounding.

Generation versus grounding

Generation is the easy half. Any current model can write a technical proposal section that reads well. The hard half is constraint: ensuring every statement traces to something you supplied, and that what cannot be resolved is declared rather than invented.

In a tender this distinction is contractual. A confidently invented scope item is not a productivity gain: it is an unpriced obligation you may be held to.

Context determines usefulness

The useful context is specific and mostly already in your business: the tender document as issued, your proposal templates, your rate cards and margin rules, the outturn cost of completed projects, and your review authorities.

A system with all five can tell you that a scope item resembles work you delivered twice before and over-ran both times. A system with none can only tell you what such work generally involves.

Where it earns its place

Reading long clause-referenced documents and extracting structured scope. Matching new scope against historical delivery. Applying rates consistently across hundreds of line items. Flagging where a tender is silent on depth, frequency or method. Summarising status across a portfolio. All are high-volume, low-judgement tasks where machines are reliable and people are expensive.

What it should not do is decide commercial position, accept technical risk, or approve a submission.

Accountability has to be designed in

Three properties make automated output defensible. Attribution: every extracted item retains its source location. Declared uncertainty: anything unresolved is marked as unresolved rather than completed by inference. And a review gate: submission is blocked until a competent person closes the open items.

Without these, an organisation has not adopted AI. It has adopted an unattributed opinion with a confident tone.

A worked example

A tender specifies a vibration survey across a compressor train but does not state survey depth or measurement frequency. Both materially change the effort.

A general-purpose assistant produces a scope line with a plausible assumed frequency. Nothing marks it as assumed, and it is priced accordingly.

A grounded system records the item as unresolved, cites the clause where the specification stops, and blocks submission until an engineer decides. The decision takes four minutes. The alternative is discovering the gap during delivery, when it costs a conversation with the client.

What changes in practice

Attribution

Every line traceable to its source clause

Reviewers verify against the client's original wording before approval.

Declared gaps

Ambiguity referred rather than inferred

Unpriced obligations are caught at bid stage, not at delivery.

Retained judgement

Commercial decisions stay with your engineers

Automation covers extraction and application, not risk acceptance.

In Athervia

Athervia's AI works only from documents you supply: the tender, your templates, your rate structures. Anything it cannot resolve is referred for engineering decision, and unresolved items block submission.

See how QuoteFlow applies it