The short answer is the one nobody wants: you are. If your seal is on it, you are responsible for it, and no tool in the chain changes that. AI does not create a new category of liability. It creates a much faster way to generate plausible-looking work that a licensed engineer has not actually verified, which is a different and more practical problem.
I am a licensed PE, and this is the question I get most often from firm leadership, usually phrased as whether the firm is allowed to use these tools at all. That framing is backwards. Your obligation was never about which software produced a draft. It is about whether a qualified engineer exercised judgment over the result before it left the building.
One caveat before the substance: this is an engineer's operational read, not legal advice. Licensure rules are set state by state and your professional liability policy has its own language. Confirm specifics with your state board and your carrier or counsel before you set firm policy.
Responsible charge is the concept that governs this
Every state's practice act is built around some version of responsible charge: the licensee must exercise direct professional control over the work they seal, based on their own knowledge and judgment. The concept predates computers entirely, and it has already absorbed several waves of automation without amendment.
Nobody argues that a structural analysis package dilutes responsible charge. The engineer chooses the model, sets the inputs, understands the assumptions, and evaluates whether the output is physically sensible. The software does arithmetic no human would do by hand, and the engineer remains accountable for the result. That arrangement has held for forty years.
An AI assistant sits in the same position, with one important difference in behavior. A finite element solver that receives bad input generally produces obviously bad output, displacements in the wrong order of magnitude, results that fail a sanity check. A language model that receives an incomplete prompt produces confident, well-formatted, professionally-worded output that is wrong in ways that read as correct. The failure is quiet rather than loud.
That single property is the entire liability story. Your exposure does not come from using AI. It comes from the fact that AI's errors are camouflaged as competence, so the review step that has always been required becomes both more necessary and easier to skip.
Where the exposure actually sits
In practice I see three patterns, in descending order of how often they occur and ascending order of how much damage they do.
Unreviewed narrative text in a sealed deliverable
The most common, and the least dramatic. A geotechnical report's background section, a basis-of-design narrative, an existing-conditions summary. Someone drafts it with AI, it reads well, and it goes out with light review because narrative sections are not where reviewers concentrate. The model invents a plausible detail, a code edition, a standard designation, a site condition, and it is now in a sealed document.
These rarely cause harm on their own. They damage you in the discovery phase of an unrelated dispute, when opposing counsel finds a factual error in your report and uses it to characterize the whole document as unreliable. Credibility is the asset you lose.
Fabricated citations to codes and standards
Worse, because it looks specific. Language models produce authoritative-sounding references to code sections and standards that do not exist, or that exist with different numbering, or that were superseded two cycles ago. The format is always convincing. In a jurisdiction with a specific adopted code edition, this can put you on the wrong side of a compliance question you did not know you were answering.
Any code or standard citation that came from an AI tool gets verified against the actual document. Not spot-checked, verified, every one. This is a hard rule with no exceptions, and it is cheap to follow.
Confidential client information sent to a consumer tool
The scenario that becomes a contract problem rather than an engineering one. Most professional services agreements contain confidentiality provisions that predate generative AI and were not written with it in mind. An engineer pastes a client's geotechnical data, a site plan, or a draft agreement into a personal account to summarize it, and depending on that tool's terms, the firm may have breached its obligations before anyone touched an engineering question.
This is a governance failure rather than a technical one, and it is fixed with a policy and an approved tool rather than a prohibition. Firms that ban AI outright do not eliminate this risk; they move it onto personal accounts where they have no visibility. That is the argument for writing a usage policy your engineers will actually follow.
What your carrier is likely to ask
Professional liability underwriting moves slower than technology, but it does move, and AI use is becoming a renewal-questionnaire topic. I would expect the questions to track what underwriters have always cared about: not whether you use a technology, but whether you control it.
Practically, that means being able to answer four things without assembling them from scratch:
- Which tools are approved for use in the firm, and on what kinds of information
- Who reviews AI-assisted work before it enters a sealed deliverable, and what that review covers
- Whether your engineers have been trained on the specific failure modes, rather than just handed a login
- Whether you can produce evidence that the review actually happened
Ask your broker what your carrier's current position is before your next renewal rather than after. A firm that has documented answers is in a materially better negotiating position than one improvising during the call.
The review record is the thing that protects you
Here is the part most firms miss. In a dispute, the question will not be whether AI was involved. It will be whether a licensed engineer exercised judgment. That is a question about evidence, and evidence has to exist before you need it.
Three practices, none of which require new software:
Mark AI-assisted drafts as drafts, inside the file. A working-document header that says the text is AI-assisted and pending engineering review costs nothing and creates an unambiguous record of what stage the document was in. It also stops the most common accident in any firm: a draft escaping as a final.
Record the verification, not the generation. Nobody needs a log of every prompt. What matters is a note in the QA record that the engineer verified the code citations, checked the numerical values against source data, and confirmed the recommendations reflect their own judgment. One line in your existing review checklist, signed by a person.
Keep the human in the sequence, not at the end. A reviewer handed a polished 40-page document reads it as finished work, because that is what it looks like. A reviewer who sees the source data first and the AI-assisted draft second reads critically. Order changes attention, and attention is what you are actually buying.
The standard of care did not change. What changed is how convincing unverified work now looks.
What I would tell a firm principal
Do not ban these tools. A ban is unenforceable, it drives usage onto personal accounts where your confidentiality exposure is highest, and it costs you the engineers who will otherwise leave for a firm that is not fighting the last decade.
Do not treat this as an IT decision either. Sealed deliverables are a licensure matter, so the policy needs a licensed engineer's name on it, and the review workflow belongs inside your existing QA process rather than beside it.
Start with the narrowest useful step: approve one tool, define what information may go into it, require verification of every citation and number, and put one line in your review checklist. That is a week of work and it addresses the overwhelming majority of realistic exposure. Then train people on how these tools fail specifically on engineering documents, because a reviewer who knows the failure modes catches them and one who does not, does not.
The firms that will get hurt here are not the ones that adopted AI. They are the ones that adopted it without deciding who was responsible for checking it.
If you are working through what this means for your firm's QA process and your policy language, that is a conversation worth having with someone who holds a license and does this work. Our readiness and enablement engagements address the review workflow directly. Start a conversation, thirty minutes, no pitch deck.
← Back to insights