The AI Risk That Wasn't Found Until After Close
Why acquisition diligence needs an owned AI workstream : and what it should actually look for
The finding
During an ICG AI operating assessment, one finding stood out:
AI had not been included in formal acquisition diligence.
The acquired company’s AI landscape was discovered after the transaction closed.
The client is intentionally anonymous. No industry details are needed. The finding is powerful enough on its own.
The issue was not that the acquiring organization had failed to identify one obscure model buried in a server room. The issue was more basic.
Nobody had formally asked what AI the target was using, where it was being used, what data it touched, which vendors were involved, or who was accountable for it.
The gap surfaced during an ICG AI Operating Sweep. A Sweep establishes an operating baseline by looking at what is actually happening across the business: not only what appears in formal systems documentation.
That is precisely why it found something the transaction process had missed.
The deal had closed.
The AI landscape came afterward.
Why standard diligence misses AI
Traditional technology diligence usually begins with the official stack.
Applications. Infrastructure. Security controls. Contracts. Vendors. Data repositories. Access management.
That work remains necessary. It is also not enough.
The problem is that AI often does not appear on the official map.
It may be:
A team using a generative AI tool through an individual subscription
An AI assistant embedded inside software already approved by the organization
An automation built by one employee to speed up a recurring process
A custom workflow created by a functional team without formal technology involvement
Data being sent to a third-party service that procurement, security, or IT does not know about
A capability being used informally, without a name, owner, business case, or documentation
The company can look orderly in a technology review while AI is operating underneath the visible structure.
This is not necessarily evidence of negligence. It is a predictable result of how AI adoption is happening. People find a tool that helps. They start using it. The workflow changes. Other people copy the behavior. Eventually, the organization depends on something nobody formally decided to acquire.
By the time diligence begins, the tool may be part of how work gets done.
It just may not be listed as an asset.
That is the blind spot.
A technology inventory tells you what the organization says it has. An AI assessment also needs to uncover what people are actually doing.
What a buyer actually inherits
AI diligence should not be treated as a vague request for “AI information.” That produces vague answers, which is a charmingly inefficient way to run a transaction.
A buyer needs to examine the AI landscape across six connected dimensions.
1. Tools and subscriptions
What AI tools are being used? Who uses them? How are they paid for? Are they centrally managed, purchased by teams, or paid for by individuals?
The buyer should care because a low-cost subscription can still support a critical workflow. Cost is not the same as significance.
2. Data flows and handling
What information goes into each tool? Does it include customer information, confidential business material, personal data, intellectual property, or regulated information?
The buyer should care because the risk may sit in the data being processed: not in the tool’s monthly invoice.
3. Contracts and vendor terms
What do vendor agreements permit? Can the contracts be assigned? Are there change-of-control provisions? Does the vendor have rights to retain, use, or improve its services with customer data?
The buyer should care because post-close ownership may change the rights, obligations, pricing, or continuity of a service.
4. Governance and controls
What rules exist for using AI? What has been approved? What requires review? What is prohibited? Are those rules understood and followed?
The buyer should care because an undocumented practice is difficult to evaluate, secure, integrate, or govern after close.
5. Embedded and process AI
Where is AI incorporated into day-to-day work? Is it supporting sales, service, analysis, content, operations, decision-making, or customer interactions?
The buyer should care because a system may not be labeled “AI” even when AI has become part of a material business process.
6. Accountability and ownership
Who owns each capability? Who owns the business outcome? Who can approve changes? Who reviews performance? Who handles an error or escalation?
The buyer should care because an inherited capability without an accountable owner becomes an inherited problem with excellent job security.
These dimensions are connected.
A tool affects data. Data affects contracts and risk. The workflow determines business impact. Governance determines what can happen next. Ownership determines whether anyone is responsible for managing the whole arrangement.
AI diligence is not a hunt for interesting tools. It is an effort to understand the operating conditions the buyer is acquiring.
What it costs to find this after close
Before close, the buyer has leverage.
The buyer can ask for more information. Require remediation. Adjust the purchase agreement. Negotiate protections. Revisit assumptions. In some circumstances, decide not to proceed.
After close, those options narrow.
The buyer has inherited the landscape and must now manage it while integrating the business.
The risks can take several forms.
Security and data exposure. Sensitive information may be moving through tools that were never reviewed against the buyer’s security requirements.
Intellectual property and confidentiality. Employees may have used third-party AI tools with confidential material, customer information, or proprietary work product. The question is not only whether the tool is useful. It is what happened to the information placed into it.
Compliance gaps. AI may be involved in activities that carry privacy, employment, consumer, or industry-specific obligations. Those obligations do not disappear because the tool was adopted informally.
Process dependency. A team may rely on an AI-supported workflow without recognizing how difficult it would be to replace, pause, or reproduce.
Key-person risk. One employee may understand how a custom automation works, which prompts matter, which data sources are connected, and what to do when the output fails. If that knowledge leaves, the capability may leave with it.
Duplicated spend. The buyer may discover that both organizations are paying for overlapping tools or solving the same problem in different ways.
Integration surprises. A tool, data source, or process may not fit the acquiring company’s policies, architecture, contracts, or risk appetite.
This is why diligence is not only about avoiding risk.
It is also about knowing what you bought.
If the buyer does not understand the target’s AI activity, the integration plan is incomplete before it begins.
What owned AI diligence looks like
The recommendation from the assessment was straightforward:
Make AI diligence an owned part of acquisition diligence.
Not an informal question sent to IT. Not a late-stage add-on. Not a post-close cleanup exercise assigned to whoever happens to notice the problem first.
An owned workstream needs a named person or team responsible for making sure the questions are asked, the answers are documented, the gaps are evaluated, and the findings reach the people making deal and integration decisions.
At minimum, the workstream should require four things.
A complete AI inventory
The inventory should include formal and informal use.
It should identify tools, users, business processes, data involved, vendors, dependencies, and current status. It should not stop at tools purchased through approved channels.
The goal is to connect AI activity to how the business operates.
Explicit data-handling requirements
For each meaningful use, document what data enters the system, where it goes, how it is retained, who can access it, and whether the use is permitted.
Do not assume that a standard software review answers these questions. Sometimes it does. Sometimes it very confidently does not.
Clear governance expectations
The buyer should know what rules apply before close and what changes after close.
That includes approval requirements, human review, security expectations, escalation paths, and boundaries around independent AI action.
The aim is not to force every low-risk task through a committee. The aim is to establish the conditions under which routine work can move quickly without making authority ambiguous.
Named accountability
Every material AI capability should have an owner.
That owner may not be the person who built the workflow or selected the vendor. The important question is who is responsible for the capability’s use, performance, risk, and continued fit with the business.
The output of this diligence should feed both the transaction decision and the integration plan.
What must be addressed before close?
What needs to be stabilized on Day 1?
What can be rationalized later?
What should be stopped?
What requires a retained employee, a contract review, a policy change, or a new control?
Five AI Questions to Ask in Every Data Room
Use these questions as a starting point. They are intentionally simple. Simple questions are often the ones organizations avoid until they become expensive.
Where is AI being used today, including outside the formal technology stack?
What data is entering those tools, models, automations, or workflows?
Which vendors, contracts, licenses, or APIs support those uses, and what changes after close?
Which AI-enabled processes are material to the business or difficult to replace?
Who owns each capability, its outcomes, its risks, and the decision to maintain, change, or stop it?
If the answers are incomplete, that is not a reason to abandon the inquiry.
It is the reason to keep going.
The lesson
For buyers, the practical move is to add AI to the diligence plan before the next transaction starts: not after the integration team finds an unexpected dependency.
For sellers, the practical move is to understand the AI activity inside the business before entering a process. Unknown usage can create avoidable questions, delays, and negotiation problems.
For operators, the practical move is smaller: look at one important workflow this week and ask what AI is touching it, what data is moving through it, and who is accountable for the result.
The broader lesson is simple:
If AI is part of how a company operates, it is part of what you're acquiring.
Julie Traxler is the founder of Integration Consulting Group and an operator specializing in M&A execution and AI operationalization. Her work focuses on turning complex, high-risk initiatives into operating systems businesses can actually execute and sustain.