Skip to content Skip to footer

What Are You Feeding Your AI Tools?

Data security is the AI conversation most contracting firms haven’t had yet.

Earlier this month, it came out that xAI’s Grok Build CLI had been quietly uploading users’ entire code repositories to a cloud storage bucket. Not summarizing them. Not referencing them. Uploading them, including private codebases and unredacted credentials, without meaningful disclosure to the people whose data it was.

The story made headlines in technology circles and then moved on. But it carries a direct lesson for contracting firms that are actively using AI tools, and it is worth sitting with for a moment.

Every time someone on your team pastes a subcontractor agreement into an AI tool, uploads a project manual for review, runs a bid through an estimating platform, or asks an AI assistant to summarize a contract, data is leaving your organization. Where it goes, how it is stored, whether it is used to train future models, and who else might have access to it are questions most firms have never formally asked.

That is a gap worth closing.

The Data Flowing Through AI Tools Right Now

Think about what a typical specialty contractor feeds into AI tools in the course of a normal week. Contract language with liability terms and indemnification clauses. Bid pricing and margin assumptions. Subcontractor names and rates. Project schedules with milestone dates. RFI logs. Closeout documentation. Change order correspondence.

Any one of those categories contains information that would be competitively sensitive if it ended up in the wrong place. Taken together, they represent a fairly complete picture of how your firm operates, what your work costs, and who you work with.

Most AI platforms have privacy policies that address this in some form. The problem is that those policies vary significantly from one tool to the next, they are written in language that takes effort to parse, and almost nobody on a busy contracting team reads them before using a new tool.

That is not a criticism of the people using the tools. It is a structural problem that firms need to address at the organizational level, not leave to individual users to sort out on their own.

What Reasonable AI Governance Looks Like

This does not require a dedicated IT department or an enterprise compliance program. It requires a few clear decisions made at the leadership level and communicated consistently to the team.

The first is knowing which tools are approved for use with sensitive information and which are not. Not every AI tool your team uses needs to handle contract data or bid pricing. Some are appropriate for drafting emails, summarizing meeting notes, or generating field report language. Others may be appropriate for document review. The distinction matters, and it should be explicit.

The second is understanding the data handling terms of the tools you are relying on for sensitive work. Specifically: does the platform use your inputs to train its models? Is your data stored, and for how long? Does the enterprise or business version of the tool offer stronger protections than the free tier? These are answerable questions for any reputable platform, and the answers should inform which tools get used for which tasks.

The third is making sure the people using these tools know what the boundaries are. Not in a way that creates friction or discourages AI use, but in a way that makes the rules clear. A short internal standard, covering what can and cannot go into which tools, is more useful than a lengthy policy document that nobody reads.

The Cost of Not Having This Conversation

The xAI story is a useful reminder that AI platforms are built by companies with their own interests, their own infrastructure decisions, and their own definitions of what constitutes acceptable data handling. Some of those decisions will not be visible to end users until something goes wrong.

Contracting firms that have thought through their AI governance posture before something goes wrong are in a significantly better position than those that have not. Not because a breach is inevitable, but because the discipline of thinking through these questions also tends to produce smarter, more consistent AI use across the organization.

AI is genuinely useful for contractors. The goal is not to slow down adoption. It is to make sure the efficiency gains do not come with risks the firm never agreed to take on.

If you want help thinking through an AI governance framework that fits how your firm actually operates, that is a conversation Dynaimix AI is well positioned to have.