Five AI Outputs That Should Never Leave the Office Without a Human Check

The problem is not the output. It is the confidence.

AI tools are genuinely useful in design and construction workflows. They can accelerate research, generate options, organize information, and produce first-pass documentation faster than most teams can do manually.

The risk is not that AI is unreliable. The risk is that AI outputs look finished when they are not. The formatting is clean. The language is confident. The numbers are specific. And a busy team, under deadline pressure, sends the output to a contractor or client without stopping to check it.

That is where expensive mistakes happen. Not a vague future risk. A drawing with an inferred dimension goes to a contractor for pricing. The number is wrong. The bid comes back, the project moves forward, and the conflict surfaces during construction when it costs the most to fix.

Not every AI output carries the same risk. Some are low-stakes and easy to verify. Others carry real consequences if they are wrong. The five categories below are the ones that should never leave the office without a qualified human check.

---

A simple stoplight framework

Before the list, a useful mental model:

The five categories below are all yellow or red. The distinction matters because yellow outputs can become red the moment they touch a code-rated assembly, a contractor's pricing exercise, or a document that creates contractual obligations.

---

1. Code and compliance references

AI tools can produce plausible-sounding references to building codes, accessibility requirements, fire ratings, and egress rules. The problem is that codes vary by jurisdiction, are updated on different cycles, and are interpreted differently by local plan checkers and inspectors.

An AI tool does not reflect which version of the code your jurisdiction has adopted. It does not account for local amendments. It does not know what a specific plan checker in your city has flagged on similar projects.

Code references from AI should be treated as a starting point for research, not as a reliable answer. Before any code-related language goes into a drawing set, specification, or client document, it needs to be verified against the current adopted code for that jurisdiction by someone qualified to read it.

This is a red-category output.

---

2. Dimension-critical drafting

AI-assisted drafting tools can generate floor plans, elevations, and details quickly. But dimensions generated or inferred by AI should be treated as approximate until verified against actual site measurements, structural drawings, and manufacturer specifications.

The issue shows up most often in tight clearances: accessible route widths, appliance rough-in dimensions, cabinet depth assumptions, and door swing conflicts. AI tools may fill in plausible numbers based on training data, not on the actual conditions of the project.

A common version of this problem: a studio uses an AI-assisted tool to produce a preliminary kitchen layout for a pricing conversation. The layout looks clean and dimensioned. The contractor prices it. Later, field measurements reveal the actual rough opening is narrower than the drawing assumed. The cabinet package has to be respecified. The contractor submits a change order. The client is unhappy.

A drawing that looks clean and dimensioned is not the same as a drawing that has been checked against field conditions. Before a dimension-critical drawing goes to a contractor for pricing or construction, a qualified person needs to have verified the numbers against real sources.

This is a red-category output.

---

3. Material and product substitutions

AI tools can suggest substitutions quickly when a specified product is unavailable or over budget. The suggestions often look reasonable. The problem is that substitution decisions involve more than surface similarity.

A substitution may affect:

• Fire rating or code compliance of the assembly
• Warranty conditions on adjacent products
• Installation method and contractor familiarity
• Lead time and regional availability
• Client approval requirements under the contract

AI does not know your project's contract conditions, the contractor's preferred suppliers, or the current availability of the suggested product in your market. A substitution suggestion from AI is a useful starting point for research. It is not a substitution approval.

This is a yellow-category output that becomes red if it touches code-rated assemblies or fire-rated construction.

---

4. Structural, MEP, and systems assumptions

Design teams sometimes use AI to generate preliminary layouts that include structural walls, mechanical chases, plumbing locations, or electrical panel assumptions. These outputs can be useful for early massing and planning conversations.

The risk is when those assumptions carry forward into documents that go to contractors or clients before the relevant engineers have reviewed them. A layout that assumes a wall is non-structural, or that a chase can be relocated, can create real coordination problems once the engineer of record weighs in.

Layouts that include structural or systems assumptions should be clearly marked as preliminary and unverified until the appropriate consultants have reviewed them. The label matters because contractors price what they see. If the drawing looks resolved, it will be treated as resolved.

This is a red-category output.

---

5. Specification language with liability implications

AI can draft specification sections quickly. The language often reads well and follows familiar structure. The problem is that specification language creates contractual obligations. Errors in specifications can result in scope disputes, change orders, and claims.

Common failure points in AI-generated specifications include:

• Referencing superseded standards or discontinued product lines
• Using generic language that does not match the actual products specified elsewhere in the set
• Omitting submittal, testing, or warranty requirements the project actually needs
• Including language carried over from a different project type or jurisdiction

Specification sections generated by AI should be treated as a first draft that requires review by someone who knows the project, the products, and the contract conditions. They should not go to a contractor as issued specifications without that review.

This is a yellow-to-red-category output depending on the section and what it governs.

---

Before it leaves the office: a three-step check

For any AI-assisted output that is about to go to a client, contractor, or drawing set, a short internal check helps:

1. Does this output reflect actual project conditions? Dimensions, product selections, and code references should be traceable to a real source, not inferred by the tool.
2. Has a qualified person reviewed it for the specific risk category? Code language needs someone who can read the adopted code. Structural assumptions need an engineer. Specification sections need someone who knows the contract.
3. If this is wrong, what does it cost? If the answer involves a change order, a permit correction, a client dispute, or rework in the field, the output is not ready to leave the office.

AI is most useful when it accelerates the work that a qualified person then reviews. It is most dangerous when it replaces that review step entirely.

For studios and contractors who want a cleaner way to structure production work, documentation, and drawing review, Creo's production support model is built around exactly this kind of quality layer: useful output, properly checked before it moves forward.