AI in Engineering: Build the Review Before the Automation

An AI tool that produces a polished engineering summary can still create more work than it removes. Someone must establish which revision it read, verify its claims, and determine whether an omission matters. The useful unit of automation is therefore a complete task: input, proposed output, evidence, review, and acceptance.

A reasonable starting point is comparing two approved document revisions and proposing a change list. Keep the task narrow: identify changed text and references, point to their locations, and flag anything that cannot be compared reliably. Let the engineer decide the technical significance. A change in a number is observable; whether that change is acceptable requires context.

NIST’s Generative AI Profile identifies confabulation as a risk: generated content can be confidently wrong. For document work, a useful response is to require an evidence reference beside each proposed finding. A citation is a place to begin verification, not proof that the claim is correct.

For example, a comparison record might contain the equipment tag, previous value, new value, units, document identifiers, revision numbers, and page locations. If the source is a scanned table with an unreadable cell, the record should say that the value could not be established. Filling the gap with a plausible number defeats the purpose of the review.

Keep extracted facts separate from interpretation. “The delivery date changed” and “the schedule is now at risk” are different claims. The first can be checked against the documents. The second needs the project schedule and an assessment of the affected work.

Use explicit dispositions such as accepted, rejected, and needs clarification. Record the reviewer and the reason where a finding changes the downstream task. Avoid a single “looks good” button for a long summary: it makes disagreement difficult to locate and hides which findings received attention.

Run a pilot with representative documents that include awkward cases: missing pages, different unit conventions, revised tags, and unchanged text that has moved. Compare the proposed findings with an independently prepared reference set. Measure missed changes, unsupported findings, and total review time, including corrections. Fast generation alone is an incomplete measure of value.

Save the input revisions and the accepted output together. If the input changes after review, mark the result as needing another check. The next person should be able to answer what the tool saw and what the reviewer accepted without recreating a chat session.

This workflow is a proposed operating pattern, not a substitute for a project’s approval process. Its value is practical: a small, traceable task is easier to evaluate and improve than an assistant asked to understand an entire engineering package at once. Start there, and expand only when the review evidence supports it.