Start with your contracts, because some of them may already answer this. Absent a contractual requirement, you generally do not owe clients a disclosure that you used AI any more than you disclose which drafting software produced a sheet. What you do owe them is the engineering judgment they hired, and the ability to answer confidently when they ask. That second part is where most firms are unprepared, and it is costing them more than any disclosure question would.

The question is arriving in interviews now. I keep hearing versions of the same story from firm leaders: a client asked whether AI touched their deliverable, the principal in the room improvised, and the answer landed somewhere between defensive and evasive. The improvised answer is the actual risk here, not the underlying practice.

Check the contract first

Before any policy discussion, read what you have already signed. AI provisions started appearing in professional services agreements and public procurement documents recently, and they vary widely: disclosure requirements, restrictions on what may be processed, outright prohibitions on generative tools in deliverables, and occasionally consent requirements for specific data.

Where such a clause exists, it governs and the debate is over. Read for it the way you read for insurance requirements and indemnity language. On the pursuit side, read RFPs for it too, since violating a stated procurement restriction is a disqualification risk rather than a matter of style. That belongs in your proposal process as a standing check.

Also check the direction of the obligation. Some agreements require notice, some require consent, and a few require you to certify that deliverables are human-authored. Those are three quite different operational burdens.

The default position, absent a clause

Your client contracted for engineering judgment from a licensed professional, delivered to a standard of care. That is what you owe. The tools you use to produce the work are yours to select, the same as your analysis software, your drafting platform, and your spell checker.

Nobody discloses which structural analysis package produced a result. The engineer chose the model, set the inputs, understood the assumptions, and remains accountable for the output. An AI assistant occupies the same position in that chain, with the important practical difference that its errors are camouflaged as competence, which is a reason to strengthen your review rather than to issue a notice.

Two situations do change the calculus, and both are about data rather than authorship:

  • Their confidential information is going somewhere new. If client material is being processed by a third-party service, that is a data handling question their agreement probably already speaks to, and it deserves an explicit conversation regardless of what the tool is.
  • You are marketing it. If you told a client during a pursuit that AI-enabled workflows are part of your value, you have made it a subject of the engagement and you should be willing to describe it.

How to answer when they ask

Have one answer, rehearsed, that every principal can give. Not a script to recite, a position everyone actually holds. Something close to:

Yes, we use AI in specific parts of our process. It drafts and it checks, it does not decide. Every technical determination is made by a licensed engineer, every citation and number is verified against source, and the verification is recorded in our QA process. It lets our engineers spend more of your fee on judgment and less on formatting.

That answer works because it is true, it is specific, and it puts the licensure boundary where the client actually cares about it. It also does something a defensive answer cannot: it signals that you have thought about this deliberately, which is exactly what a sophisticated client is testing for when they ask.

Three things to avoid. Do not say "we don't use AI" if any part of your firm does, because it will not survive the follow-up question and it costs you credibility you cannot rebuy. Do not oversell it as a differentiator you cannot substantiate. And do not get defensive, since the question is usually curiosity or diligence rather than an accusation.

The question is a business development opportunity

Here is the part firms miss. A client asking about AI is telling you they are thinking about it in their own organization, and they are usually unsure. If you can answer clearly and then say something useful about how you decided where the line sits, you have moved from vendor to advisor inside one exchange.

The firms that will look best in that moment are the ones that can describe a policy, a review workflow, and a reason. Not a marketing claim. The ability to say "here is what we permit, here is what we verify, here is who is accountable" reads as operational maturity in a way that no capability statement does.

That answer is only available if the policy actually exists, which is the practical argument for writing the one-page version before you need it in a room.

When you should proactively raise it

Rarely, but not never. I would bring it up unprompted in three cases.

When the client is a public agency or an institution with a governance function that will eventually ask anyway, raising it first is strictly better than being discovered later.

When you are proposing a schedule or fee that depends on the efficiency, because if the number only works with the tooling, that is a commercial fact they are entitled to understand.

And when their data is going somewhere it has not gone before. That one is not really an AI disclosure, it is a data handling notice, and it would be required if the recipient were a subconsultant instead of a service.

Clients are not asking whether you used software. They are asking whether a person is still accountable. Answer that question.

What to do this month

Three things, none of which take long.

Have someone read your five largest active agreements specifically for AI, data processing, and confidentiality language, and write down what each requires. You may find you already have obligations nobody has operationalized.

Agree the standard answer as a leadership group and make sure every principal and pursuit lead can give it without hesitating. Say it out loud in a meeting once, because the first time should not be in front of a client.

Make sure the answer is true. If you claim every technical determination is made by a licensed engineer and verification is recorded, that has to be a real workflow with a real record, which is a question about how your review process actually works.

If you want the contract review and the standard answer developed against your actual agreements and your practice areas, that is part of our readiness engagement. Start a conversation.

← Back to insights