Proposals are the highest-volume writing an AEC firm produces and the worst place to let AI write unsupervised. Used well, it cuts assembly time substantially on the parts nobody reads closely. Used badly, it produces the fluent, generic response that selection committees have now seen forty times this year and have learned to discount on sight.
The distinction is not about tool quality. It is about which parts of a proposal you let it near, and in my experience that single decision separates the firms this helps from the firms it quietly hurts.
Split the proposal into two kinds of content
Every proposal contains two categories of writing, and they have opposite risk profiles.
Assembly content is material that already exists and needs to be found, reformatted, and fitted to this RFP: project descriptions, resumes, past performance, org charts, standard QA language, safety records, certifications. It is a retrieval and formatting problem. It consumes an enormous share of proposal hours and contributes almost nothing to your win rate, because every competent competitor has equivalent content.
Differentiating content is why you should win this specific job: your understanding of this client's problem, your technical approach, your assessment of the risks, the reason your team composition fits. It is the only part a selection committee actually weighs when choosing between qualified firms.
Let AI do the first category aggressively. Keep it away from the second, except as an editor. Firms that get this backwards, automating the technical approach because it is the hardest writing, produce proposals that are faster to assemble and less likely to win, which is the worst possible trade.
Where it pays immediately
Compliance matrices. Reading a hundred-page RFP and extracting every submittal requirement, page limit, format constraint, and evaluation criterion into a checklist. Tedious, high-stakes, and mechanical. Missing one requirement can disqualify a technically superior proposal, and this is the single most reliable use in the whole process.
Project description tailoring. You have a description of a project written for a different pursuit. It needs to be reframed for this client's emphasis at half the length. This is genuine editing work on existing factual material and it is fast, safe, and immediately useful.
Resume reformatting. Same résumés, new format, new page limit, emphasis shifted toward the relevant experience. Pure formatting labor that consumes coordinator days.
First-draft standard sections. QA plans, safety approaches, project management methodology. The sections that must be present, are read for adequacy rather than brilliance, and are largely consistent between pursuits.
Ruthless length compliance. Cutting an over-length section to fit is a task most engineers find painful and AI does well, because it is willing to delete sentences an author is attached to.
The failure mode that costs you work
Fluent emptiness. AI-drafted proposal prose has a distinctive character: grammatically clean, structurally correct, full of sentences that make a claim without committing to anything. "We will implement a collaborative approach to ensure project success through proactive communication." Nobody could object to it. Nobody could distinguish it from any other firm's paragraph.
Selection committees have become fast at spotting this. Public agency reviewers in particular now read dozens of proposals per cycle and the pattern is unmistakable. The penalty is not that they mark you down for using AI. It is that a proposal reading as generic gets scored as a firm with no specific insight into their project, which is exactly the impression you were paying to avoid.
The tell is almost always the same: sentences that could appear in any proposal for any project. The correction is specificity, this site, this schedule constraint, this client's stated concern, this named individual and what they did on a comparable job. Specificity is the thing AI cannot supply because it does not know your firm or their project, and it is precisely what wins.
How to use it on the technical approach without hollowing it out
The technical approach should be written by the person who will do the work. There is a legitimate use for AI around it, in three roles:
- Interviewer. Have it ask you questions about the pursuit and dictate your answers. Many strong technical leads are far better talking than writing, and the transcript-to-draft path preserves their actual thinking. This is the highest-value use in the whole proposal process.
- Editor. Give it your draft and ask what a selection committee would find unconvincing, or which paragraphs make claims without support. It is a genuinely useful adversarial reader.
- Compliance checker. Ask whether your draft addresses every stated evaluation criterion. It catches omissions reliably, and an omission against a scored criterion is a straightforward lost point.
Notice all three keep the substance yours. The tool is working on your thinking rather than substituting for it.
Two rules worth making firm policy
Check the RFP for AI provisions. Some agencies and owners have begun including disclosure requirements or restrictions on AI-generated content in procurement documents. Read for it the same way you read for insurance requirements. Where it exists, it governs, and violating it is a disqualification risk rather than a style question.
Never paste an RFP or client material into an unapproved tool. Pursuit documents are frequently confidential and sometimes competition-sensitive. This belongs in the second tier of your usage policy's information tiers, approved tools with enterprise data terms only.
And verify every factual claim. Project values, completion dates, staff credentials, certifications, award names. AI-assisted proposal text will occasionally produce a plausible wrong number for a project you actually did, and a factual error in past performance is a credibility problem in the one document where credibility is the product. The mechanism is the same one described in what AI gets wrong in construction documents.
Let it do the assembly. Write the part they are actually scoring yourself.
What this is worth
Proposal effort in most firms is substantially assembly rather than thinking. Compressing the assembly does two things. It lowers the cost of pursuing, and, more valuably, it moves hours from formatting to the technical approach, which is the only section that moves win rate.
Measure it if you do it. Hours per proposal is easy to pull from timesheets, and win rate is already tracked. That gives you a clean before-and-after on a workflow that recurs constantly, which makes proposals one of the better pilot candidates in a firm. The measurement approach is in the four numbers that convince a partner group.
If you want your proposal process restructured around this split, using your own content library and past pursuits as the material, that is what our workflow automation engagement does. Start a conversation.
← Back to insights