Yes, with conditions, and the conditions are the whole answer. The question is not whether AI tools are safe in the abstract. It is which tool, on which account tier, holding which category of data, under which client agreement. A firm that answers those four questions once can move quickly for years. A firm that never answers them either bans the tools outright or, far more commonly, pretends to ban them while the work happens anyway.

I get this question from principals more than any other, and it usually arrives as a yes-or-no. It is not a yes-or-no. It is a sorting problem, and the sorting is not hard once someone does it deliberately.

The distinction nobody explains clearly

There is a real difference between a consumer account and a business or enterprise account at the same vendor, and most of the anxiety in our industry comes from not knowing it.

On consumer tiers, your inputs may be used to improve the vendor's models by default. On business and enterprise tiers from the major providers, they are not. The data is processed to answer your request and is not fed back into training. That single difference is what separates a genuine confidentiality problem from a manageable one, and it usually costs a few hundred dollars a year per seat.

So when a firm tells me they have banned AI over data security, my first question is which tier they evaluated. Almost always the answer is that someone read an article about the free version and stopped there.

The second question is what their people are doing now. In every firm I have talked to that banned the tools without providing an approved one, engineers were still using AI. They were using it on personal accounts, on personal devices, outside any logging or policy. The ban did not remove the risk. It removed the firm's visibility into the risk, which is worse.

A ban without an approved alternative does not stop the behavior. It just moves it somewhere you cannot see.

Sort your data before you evaluate any tool

Before looking at vendors, sort what you actually handle. Most engineering firms have four categories and treat them all as one.

Public or already published. Building codes, published standards, manufacturer literature, your own marketing material, anything on a public plan review portal. There is no confidentiality question here at all, and this category is larger than people assume.

Internal but not sensitive. Your specification boilerplate, your QA checklists, your proposal templates, your internal procedures. Losing control of these would be annoying and commercially unhelpful. It would not breach anything.

Client confidential. Project documents, drawings, correspondence, reports, anything covered by a confidentiality clause in your agreement. This is the category that needs the enterprise tier and needs a look at the contract.

Restricted. Anything under a specific legal or contractual regime: personally identifiable information, security-sensitive facility details, work under a government clause, anything covered by a nondisclosure agreement with named handling requirements. Some of this should not go into a general purpose tool at any tier, and the agreement will usually say so plainly.

Once a firm sorts its work this way, the argument changes. It stops being "is AI safe" and becomes "which of these four can we run through the approved tool this quarter." The first two are almost always immediately fine, and they cover a surprising amount of daily work.

Read your own client agreements

This is the step firms skip, and it is the one that actually governs the answer.

Your professional services agreements already contain confidentiality language. Some of it is generic and permits disclosure to subconsultants and service providers under equivalent obligations, which is the category a properly contracted AI vendor falls into. Some of it is specific and requires written consent before project information touches any third-party system. Some client agreements, particularly with public agencies, institutional owners, and data center clients, now name AI directly.

You cannot know which of those you signed without reading them. I would pull the ten agreements representing the largest share of current revenue and have someone read the confidentiality and data handling sections specifically. That is a half day of work and it converts the entire conversation from speculation into fact.

What you find shapes the policy, which is the reverse of how most firms do it. They write an AI usage policy first and then discover it conflicts with an agreement they signed two years ago.

What a workable arrangement looks like

The firms that have handled this well landed in roughly the same place, and none of it is exotic.

They chose one approved tool on a business or enterprise tier, with administrative controls and a data processing agreement in place. They wrote down which of the four data categories are permitted in it. They gave every engineer access, because access is what pulls the work back inside the fence. They kept a short list of what never goes in regardless of tier. And they told clients, in the agreement or in the kickoff, rather than waiting to be asked.

That last part makes people nervous, and it should not. Clients are already assuming you use these tools. Saying so on your terms is a stronger position than being asked about it later, which is the argument I make at more length in whether to tell clients you use AI.

Notice what is not on that list: a vendor security questionnaire exercise that takes a quarter, a custom on-premise deployment, or a committee. Those are how firms with no real answer perform the appearance of diligence. The four questions at the top of this article are answerable in about two weeks by two people.

The uncomfortable part

There is a version of this conversation where a firm decides the risk is unacceptable and genuinely restricts the work. That is a legitimate decision if it is made deliberately, if it is enforced, and if the firm accepts what it costs competitively.

What is not legitimate is the middle position most firms occupy right now: no approved tool, no written policy, no contract review, and an unspoken understanding that people are figuring it out on their own. That arrangement carries every risk of adoption and none of the benefit, and it is the one that would be hardest to defend if a client ever asked what your controls were.

If nobody at your firm can currently name your approved tool, your permitted data categories, and the clause in your standard agreement that covers it, you do not have a data security position. You have an absence of one, and the work is happening anyway.

Sorting this out is part of what our readiness and roadmap engagement covers, usually alongside the policy work, because the two answers depend on each other. Start a conversation.

← Back to insights