An AI usage policy for an engineering firm should fit on one page and answer four questions: which tools are approved, what information may go into them, what must be verified before the work goes anywhere, and who to ask when the policy does not cover the situation. Everything beyond that is legal padding that guarantees nobody reads it.
The policy you are most likely to be handed is six pages of definitions and prohibitions. It will be circulated, acknowledged, filed, and ignored, and your firm will be in exactly the position it was before: engineers using these tools on personal accounts with no guidance, because the document that was supposed to guide them was unreadable.
Write it knowing shadow usage already exists
Start from the truth. In nearly every firm I work with, staff are already using AI tools without approval. Not maliciously, they found something that helped with a task they hate, and no one told them not to.
This matters because it determines what your policy is for. If you write it as a prohibition, you are not stopping the behavior; you are pushing it further out of sight, onto consumer accounts where your confidentiality exposure is highest and your visibility is zero. That is strictly worse than the situation you started with.
Write it instead as a permission with boundaries. Here is what you may use, here is what you may put into it, here is what you must check. Engineers follow rules that make sense and route around rules that do not, the same as with any other procedure in the firm.
The four clauses that matter
1. Approved tools, named specifically
Name the tools. Not "enterprise-grade AI solutions", the actual products, with the actual account your firm pays for. Staff need to know whether the thing on their screen is the approved one, and a category description does not tell them.
Say explicitly that personal accounts are not approved for firm work, and say why in one sentence: consumer terms typically permit the provider to use your inputs, which conflicts with client confidentiality obligations. Engineers respond well to a stated reason and poorly to a bare prohibition.
Include how to request an addition. A policy with no path to "can we use this?" generates either shadow usage or a stalled team, and both are worse than a two-line request process.
2. What information may go in, in three tiers
This is the clause that prevents the expensive mistake. Three tiers, concrete enough to apply without a judgment call:
- Fine. Public information, published codes and standards, general technical questions, your own already-public marketing material, internal notes containing no client identifiers.
- Approved tools only. Client project data, drawings, specifications, reports, correspondence, and anything under an NDA, permitted in the tool your firm has enterprise terms with, and nowhere else.
- Never. Personally identifiable information, anything under a security agreement or covered by export restrictions, credentials, and anything a client has specifically restricted in writing.
Note that the third tier is short and absolute. Long prohibition lists get skimmed; three items get remembered. And check your actual professional services agreements before finalizing tier two. Some clients, particularly in data center and government work, have language that restricts this further than your default.
3. Verification requirements before work leaves the firm
The clause with the most practical value. Four requirements, all of them narrow:
- Every code or standard citation is verified against the source document.
- Every number is traced to source data, not accepted from the tool.
- A licensed engineer reviews anything entering a sealed deliverable, and that review is recorded in the existing QA record.
- Client-facing text is read for firm voice, not just correctness.
These map directly onto how these tools actually fail, which is why they are worth the space. The reasoning behind each is in what AI gets wrong in construction documents, and it is worth circulating alongside the policy so the requirements read as engineering rather than bureaucracy.
4. Who decides, by name
One named person, and it should be a licensed engineer rather than your IT lead. Sealed deliverables are a licensure matter, and the questions that arrive will be about professional judgment more than technology.
Give them the authority to approve a new tool and the obligation to answer questions within a few days. A policy with no responsive owner becomes a policy people stop consulting.
What to leave out
Resist these, all of which appear in most templates and all of which cost you:
Definitions of artificial intelligence. Nobody needs them, and it signals that the document was written for lawyers rather than engineers.
A prompt log requirement. Logging every prompt is unenforceable, and it creates an obligation you will fail to meet. Record the verification, which is what actually demonstrates engineering judgment. That distinction matters for how liability actually works when AI touches sealed work.
Blanket disclosure to clients. Tempting, and usually wrong as a default. You do not disclose which word processor drafted a report. Do check your contracts, some agreements now include AI provisions, and those govern. Handle it contractually rather than by unilateral policy.
Aspirational language about innovation. A policy is an operating document. Put the ambition in your strategy, not in the file people consult at 6pm on a deadline.
How to roll it out so it sticks
Do not email it. A policy delivered by email attachment has a compliance rate close to zero.
Run one forty-five minute session per office. Show three real examples: a good use, a use that violates tier two, and an output containing a fabricated citation. Then ask people what they are already using. You will learn more about your firm's actual exposure in that half hour than from any audit, and you will surface the workflows worth piloting. The shadow users have already found where the payoff is highest.
Review it in six months, and expect to loosen rather than tighten. First policies are almost always more restrictive than they need to be, because they are written in the absence of experience. After two quarters you will know which tiers were overcautious.
A one-page policy people follow protects you more than a six-page policy they acknowledged and never opened.
One page. Four clauses. A named owner. Written by someone who holds a license, reviewed by your counsel, and explained in person.
If you want the policy drafted against your actual client agreements and your existing QA process rather than from a template, our readiness engagement includes exactly that. Start a conversation.
← Back to insights