How to evaluate AI for proposal work

Start with the work, not the tool

The owner’s first decision is therefore not which AI product to buy. It is which proposal tasks are suitable for AI, what information those tasks may use, and who must check the result. A tool can save time on a bounded task such as extracting submission requirements from a public solicitation. That does not make it suitable for writing unverified claims about the firm’s qualifications or technical approach.

Treat AI output as working material. Staff should be able to trace important statements to firm records or solicitation language, and a qualified person should review content before it leaves the firm. The evaluation process should make these expectations clear before a pilot begins.

1. Define the tasks

“Use AI for proposals” is too broad to assess. Break the workflow into specific tasks, then identify the person responsible for the final work product. Common candidates include:

Finding deadlines, page limits, required forms and evaluation criteria in a solicitation.
Building a compliance matrix or proposal outline.
Searching approved project sheets and staff resumes for relevant experience.
Drafting a first pass at routine language using verified firm material.
Checking a draft for missing requirements, inconsistent project names or unsupported claims.
Editing for clarity and length. It can also help check grammar.

Describe each task with a clear input and a reviewable output. For example: “Given this public request for proposals, produce a table of submission requirements with page references.” This is easier to evaluate than “make proposal writing faster,” and it gives staff a way to spot omissions.

For each task, specify where AI’s contribution ends. A system might identify a stated deadline, but a proposal manager confirms it against the solicitation. It might suggest projects that fit a criterion, but a technical lead decides which examples belong. It might draft a paragraph, but the proposal lead verifies each claim and approves the final language.

Begin with repetitive, bounded tasks where the source material is clear and mistakes can be found before submission. Keep engineering analysis, interpretations that require professional judgment, pricing commitments, contract positions and final compliance decisions under accountable human control. If a task is difficult to describe, hard to verify, or consequential when wrong, do not begin by handing it to AI.

2. Classify the data

The same task can carry different risks depending on the information entered. Before a pilot, create simple data categories that staff can apply in ordinary work. A practical starting point is:

Public: published solicitations, public agency documents and information the firm has already released.
Internal: approved resumes, project sheets and standard proposal language that are not confidential.
Confidential: client correspondence, nonpublic project details, fee information, draft agreements and information subject to a client restriction.
Restricted: credentials, personal information, sensitive infrastructure details, security-related information, or material whose disclosure could cause serious harm or violate a specific obligation.

The labels should follow the firm’s contracts, client instructions, professional obligations and applicable law. A document’s availability to employees does not automatically mean it is cleared for an external AI service. If staff cannot tell which category applies, they should pause and ask the person responsible for the client relationship or information.

Decide what each approved tool may receive. A low-risk pilot might use public solicitations and approved, nonconfidential firm content only. Do not paste client information into a public chatbot simply because it makes the task easier. Do not assume that removing a client’s name makes a document anonymous. Project location, scope, unusual facts, staff details or combinations of fields may still identify the client or project.

3. Approve tools and access

An owner or named manager should approve tools before staff use them for proposal work. Review the service’s current terms and settings, including how prompts and uploaded files are stored, whether they may be used to improve the service, who can access them, retention and deletion options, account controls, and what happens when an account closes. Confirm whether the firm can manage access centrally and remove it when a staff member leaves.

Write a short approved-use list that staff can find when a proposal is due. It should identify:

Which tools and account types are approved.
Which data categories each tool may receive.
Which proposal tasks are allowed.
Who can authorize an exception.
How to report a suspected disclosure or incorrect output.

An employee’s personal account is not a firm-approved workspace. A tool’s general popularity or a vendor’s assurances are not substitutes for reviewing the arrangement the firm will actually use. If an AI feature is embedded in software the firm already owns, check its settings and data flow too. “Already on our system” does not answer what happens to proposal content.

Limit access to staff who need it, and use individual accounts or managed access where available. Do not share credentials. Remove access when it is no longer needed. Revisit the approval if the service changes its terms, adds a new feature, or starts handling a different category of information.

4. Parse solicitations with a checking process

Solicitation parsing is often a sensible pilot task because the input is usually a published document and the output can be checked against the source. It is also easy to mishandle. A long request may include amendments, appendices, forms, evaluation instructions and conflicting references. A summary that omits a requirement can put the whole submission at risk.

Give the tool a narrow instruction. Ask it to extract requirements into fields such as item, stated requirement, due date or limit, source page, and whether the item needs confirmation. Tell it to report uncertainty and missing information instead of filling gaps with a guess. Keep amendments with the original solicitation and make clear which version is controlling.

A proposal manager should check extracted items against the source, including:

Submission deadline, time zone and delivery method.
Required sections and forms. Confirm any signature or certification requirements.
Page, file, font or format limits.
Questions deadline, preproposal meeting details and addenda.
Any stated evaluation criteria, weights or interview requirements.
Requirements that apply to a specific discipline, team member or project phase.

Keep the original documents with the working compliance matrix. Record where each requirement appears, including page or section, and note which amendments were reviewed. If the solicitation has unclear language or apparent conflicts, refer it to the responsible person for interpretation. AI can help locate the relevant passages; it cannot settle a contractual ambiguity on the firm’s behalf.

Do not let a generated summary replace the solicitation. Use it as an index that helps people review the source. If the tool cannot identify a source page, or if the cited passage does not support the extracted requirement, treat the item as unverified.

5. Keep source traceability

A proposal contains claims the client may rely on: staff experience, project experience and outcomes. It can also include methods, credentials and the firm’s capacity to perform. Every material claim should have a source that a reviewer can inspect. AI can make a sentence sound polished while changing its meaning, blending details from two projects or adding a claim that was never in the record.

For each AI-assisted section, retain enough information to check how it was produced. Depending on the workflow, that might include the source documents, the prompt, the output, the person who edited it and the person who approved it. The record need not become a paperwork project. It should let the firm answer practical questions later: Where did this statement come from? Who checked it? Which version went to the client?

Build drafting instructions around approved source material. Ask the system to use only the supplied resume, project sheet or firm language, and to mark missing information rather than invent it. Then verify names, roles, dates, project descriptions and outcomes against the original records. Check credentials and other factual details against those records as well. Check that the proposed wording does not turn participation into leadership, preliminary work into completed work, or a narrow result into a broad performance claim.

Maintain a clear distinction between source text, AI suggestions and human edits. Staff should not copy generated material into a final proposal without reading it in context. A correct sentence in isolation can still conflict with another section or imply a commitment the firm did not intend.

6. Require human verification

Human review is part of the workflow, not a final courtesy. Set the review level according to the content and potential effect of an error. A proposal coordinator may confirm formatting and completeness. A project manager may check project experience and staffing. A technical lead may review the proposed approach. The person authorized to commit the firm should review promises about scope, schedule and availability. That person should also review price and contract terms.

Reviewers should see both the draft and the supporting source material. A useful check asks:

Is each factual claim supported by a current firm record or the solicitation?
Did the output omit a requirement or misread an amendment?
Are project names, staff roles and credentials accurate?
Does the language imply a result, capability or commitment the firm has not approved?
Does the section agree with the rest of the proposal?
Is technical content reviewed by the appropriate qualified professional?

A grammar check is not a technical review. A fluent response is not evidence that a calculation, design claim, code reference or professional statement is correct. Licensed PE judgment and local codes govern engineering matters. AI-generated technical material should not be treated as a substitute for the responsible professional’s analysis or approval.

Name the reviewer in the workflow, and give that person enough time to do the check. If review routinely happens after the deadline is nearly upon the team, the process is poorly designed. The firm should simplify the use case or stop using AI for it until review can happen properly.

7. Protect privacy throughout the workflow

Privacy decisions do not end when someone selects an approved tool. Proposal files may include personal details about staff, client representatives, subcontractors or members of the public. They may also contain security-sensitive facility information or nonpublic details about planned work.

Use the least information needed for the task. If AI only needs a list of solicitation requirements, do not provide unrelated client correspondence or project files. Where a task can be completed with an approved template, anonymized text or a limited excerpt, use that smaller input. Still classify the material before sending it, since removing names may not remove identifying details.

Keep proposal content in approved workspaces, and follow the firm’s retention practices. Avoid copying drafts or prompts into personal notes, unmanaged storage or public channels. Set a clear process for deleting working copies when the proposal is complete, while keeping records the firm needs under its own retention rules.

Tell staff what to do if they enter information into the wrong service or discover an unexpected disclosure. They should report it promptly to the designated owner, preserve relevant details and follow the firm’s incident process. Waiting to see whether anything happens can make the response harder.

8. Evaluate a small pilot

A pilot should answer a business question, not produce a demonstration. Choose one or two defined tasks, a small group of users and a limited set of approved material. Before starting, record how the work is done now: who performs it, where delays occur, what errors or rework appear, and what a finished, acceptable result looks like.

Compare AI-assisted work with the existing process using consistent examples. Track time spent on setup and prompting, then track correction and review time. Record whether the output was accurate and usable after human review. Check whether it was complete and traceable, too. Note omissions, unsupported statements, privacy concerns and the kind of correction each one required.

Agree on success conditions in advance. For example, the firm might require that every extracted requirement be tied to a source location and that no submission-critical item remain unchecked. The threshold depends on the task and the firm’s tolerance for error. Do not adopt a workflow because a sample looked impressive. Run enough representative work to learn where it helps and where it creates extra review.

At the end of the pilot, decide whether to adopt, revise or stop the use case. Keep the decision with the results: what task was tested, what data was used, which tool and settings were involved, who reviewed the work, and what limits apply. If the pilot saves drafting time but increases verification effort or introduces claims staff cannot reliably check, the net result may not help the firm.

9. Assign ongoing ownership

AI use in proposal work needs an owner after the pilot. Assign one person to maintain the approved tool list, data rules, review expectations and incident path. That person should gather feedback from proposal staff and technical reviewers, and bring material changes to the owner or principal for a decision.

Recheck a workflow when the tool changes, the firm begins using a new data category, a client imposes a new restriction, or a proposal error reveals a gap. Periodically review whether staff still follow the approved process and whether the use case still solves a real problem. Keep training grounded in the firm’s actual proposal examples, with sensitive information removed or appropriately protected.

Ownership also means being willing to narrow or discontinue a use. A task may work for public solicitations and fail on confidential client material. A feature may change its data handling. A reviewer may find that generated language creates more correction work than it saves. Update the rules to match what the firm has learned, and make the current version easy to locate.

For an owner, the goal is straightforward: AI should support a defined part of proposal work while people remain accountable for the information and judgment the firm sends to a client. The firm also remains accountable for its commitments. Clear task boundaries, source records, data rules and named reviewers make that possible.

For more on AI use and implementation, see AI implementation, the resources library and proposal checklists. For help applying AI in your firm, visit CivilEngineers.com AI implementation.

General education only, not engineering, legal, tax or investment advice. Licensed PE judgment and local codes govern.