The slow part of a project is rarely the build. It is the paperwork that runs alongside it: the submittal log that has to stay current, the RFIs that have to be written clearly enough to get a fast answer, the constant cross-referencing of specs and drawings. That text work is exactly where AI helps. The trap is that the same tool that drafts a clean RFI will also answer the RFI itself, interpret a code section, or assert what the design intent was. Those are calls only the architect or engineer can make, and the answer comes back stamped by them, not by you. This is a plain look at where AI genuinely helps with submittals and RFIs, where it does not, and a set of prompts you can paste in and test on your own real project documents.
The honest picture
AI is genuinely useful for the writing and the organizing, working from documents you already have:
- What AI does well today: turn a field issue into a clear, well-formed RFI, summarize a submittal against the spec section you paste and flag where they do not line up, build and clean a submittal log from your register, and keep the language consistent across dozens of items. It compresses the paperwork hours, not the engineering.
- What AI does not do: answer the RFI, interpret the code, decide the design intent, or approve a submittal. The architect or engineer of record owns design intent, code interpretation, and submittal approval, and they are accountable for those calls. AI can draft the question and organize the comparison; it must never supply the answer, declare a submittal compliant, or resolve a conflict between drawings.
The right way to think about it: AI is a fast writer and a clerk for the log, not the design professional. It drafts and organizes. The interpretation and the approval stay where they belong.
The line: it will answer the question only the architect or engineer can answer
The specific failure to watch for is AI stepping over from drafting into deciding, and it shows up four ways:
- Inventing a code interpretation. Ask it whether something meets code and it will write a confident answer. That reads like a ruling, and a code interpretation on a project belongs to the design professional, not to a model.
- Asserting design intent. Give it two ambiguous details and it will tell you what the architect "meant." It does not know. Stating design intent as a conclusion is the exact line not to cross.
- Approving a submittal. Hand it a product data sheet and a spec and it will happily write "this submittal is approved" or "conforms." Approval is the design professional's stamp, and the field relies on the log as if a professional made that call.
- Resolving a conflict between drawings. When the structural and architectural sheets disagree, AI will pick one. That is a design decision dressed up as a summary, and it is not its decision to make.
The fix is the same in every case: AI states the question, organizes the comparison, and flags the discrepancy for the design team to resolve. It never supplies the answer, never interprets the code, and never approves anything.
The setup that keeps the call with the design professional
Two habits make AI much safer here, and the prompts below build them in:
- Tell it to draft and flag, not decide. When it writes an RFI, it states the question and cites the drawing or spec, and it stops there. When it reviews a submittal, it lists where the submittal and the spec line up and where they do not, and it routes every discrepancy to the design team. It proposes no answer as the decision and approves nothing.
- Make it cite the basis for every line. Tell it to tie each item to the specific drawing, detail, or spec section it came from, and to flag anything it cannot ground rather than filling it in. You want a draft that points the design professional straight to the source, not one that quietly resolves the ambiguity for them.
How to test it on your own work
Do not trust a polished demo, including this one. Pull two or three of your own recent items, the raw field issue or the actual submittal and the relevant spec sections and drawings, a timer, and the prompts below. Rate each output 1 to 5 on usefulness and accuracy, and compare the time against how you write the RFI or work the log today. Keep what wins. Use your company's enterprise or no-train settings before you paste any project document, and confirm you are comfortable with that. This is a workflow guide, not design or code-compliance advice.
Paste-ready prompts
Copy these as written. Bracketed text is what you swap per item.
Test 1: Draft a clear RFI from a field issue (text model)
I am giving you a field issue and the relevant drawing and spec references.
Draft a clear, well-formed RFI that the design team can answer quickly.
Rules:
- State the question plainly: what is unclear or conflicting, and what
decision I need from the design professional. Cite the specific drawing,
detail, or spec section the question comes from.
- Draft the RFI question clearly, do not answer it. Do not propose your
answer as the decision, do not interpret the code, and do not state what
the design intent is. If you want to suggest a possible direction, label it
plainly as a contractor suggestion for the design team to accept or reject,
never as the answer.
- Keep it short and specific enough that the architect or engineer can respond
without a phone call.
Field issue: [paste it]
Drawing and spec references: [paste them]
Watch for: did it state the question and stop, or did it slide into answering it? Any sentence that reads like a ruling on code or design intent is the work it cannot do for you.
Test 2: Summarize a submittal against the spec section (text model)
I am pasting a submittal and the spec section it is supposed to meet. Summarize
the submittal against the spec, item by item.
Rules:
- For each spec requirement, say where the submittal appears to match and where
it does not, and quote the relevant line from each so I can verify.
- Flag every discrepancy for the design team to resolve. Approve nothing. Do not
write "conforms," "complies," "approved," or "rejected," and do not interpret
the code or decide design intent.
- If something in the spec has no matching item in the submittal, list it as
missing rather than guessing.
Submittal: [paste it]
Spec section: [paste it]
Watch for: did it flag discrepancies for the design team, or did it quietly declare the submittal compliant? Approval is the design professional's stamp, not the model's.
Test 3: Build or clean a submittal log (text model)
Here is my submittal register: [paste it]. Build a clean, consistent submittal
log from it.
Rules:
- One row per submittal item, with consistent columns: item number, spec
section, description, responsible sub, status, and date. Use only the data in
the register. Do not invent dates, statuses, or items that are not there.
- Where a field is blank or unclear in the register, leave it blank and flag it
in a "Needs my input" list rather than filling it in.
- Do not set or change any approval status. Carry the status exactly as the
register states it.
Submittal register: [paste it]
Watch for: did it carry your data faithfully and flag the gaps, or did it invent statuses and dates to make the log look complete?
Test 4: Audit a draft for design calls AI should not make (text model)
Review this draft RFI or submittal review for one thing only: any place where it
crossed from drafting into deciding. For each instance, quote the exact line and
say what is wrong.
1. Answered a design question: any statement that supplies the answer to the RFI
instead of asking it.
2. Interpreted the code: any sentence that rules on whether something meets code.
3. Asserted design intent: any claim about what the architect or engineer
"meant" or "intended."
4. Approved or rejected: any wording like "conforms," "approved," "compliant,"
or "rejected," or any place it resolved a conflict between drawings.
Do not rewrite the document. Only flag the lines that belong to the design
professional, not to me.
Draft: [paste your RFI or submittal review]
Watch for: does it catch the place where a suggestion got phrased as the answer, or where a summary quietly approved a submittal? Run it on something you already sent.
What success looks like
If your own testing shows real time savings, the next step is a small pilot: run a week of RFIs and submittals through the prompts and measure the hours. If that holds up, the natural next step is a simple agent, running on your company's own cloud, that you use in plain language. The most useful version reads your project documents, drafts each RFI and submittal summary, builds and updates the log, and cites the exact spec section, drawing, or detail behind every item, flagging each discrepancy for the design team and approving nothing. The project data stays in software your company owns and runs, not rented per seat.
The principle holds the whole way through: AI gives you faster paperwork and a second set of eyes on where the documents disagree. It does not answer the RFI, and it does not approve the submittal. Keep that line clear, and the design professional keeps the call, and the rest is upside.
This is a workflow guide, not design or code-compliance advice. Design intent, code interpretation, and submittal approval belong to the architect or engineer of record.
Want a straight answer for your construction business?
I build practical AI and custom software for businesses, on Google Cloud. If you want a second set of eyes on how AI could fit your submittal and RFI workflow, or on a tool you are considering buying, tell me what you are working with. No pitch, just a straight answer.