An acquirer inherits the target's AI estate in full: its agents, its model contracts, its service accounts, its vendor data flows and whatever its employees adopted without telling anyone. Most of that inventory is invisible in a conventional technology diligence, because conventional diligence asks about systems and this risk lives in permissions.
This page sets out what to request, what the answers usually reveal, and the integration problems that arrive on day one after close.
Why standard technology diligence misses it
Technology diligence is organized around assets. It asks what the target owns, what it licenses, what it built and who wrote it. AI risk in a target is not organized that way. It sits in three places a standard request list does not reach.
Authority rather than code. An agent's risk is a function of what it is permitted to do, not what it is made of. A two-hundred-line script with a production database credential and an outbound model call is a larger exposure than a substantial internal application with read-only scope. The diligence question is about agent authority scope, and it is rarely documented anywhere.
Adoption rather than procurement. The tools that matter most were often never procured. They were signed up for with a corporate email address, and they hold whatever was pasted into them. This is shadow AI, and in a diligence context it is not a hygiene issue but an undisclosed data flow.
Data that has already left. Training and fine-tuning are not reversible. If customer or regulated data entered a third-party model under terms that permitted retention or training, the remediation available after close is contractual, not technical. This is the finding with the longest tail and it is worth asking about first.
The request list
Inventory and ownership
Ask for a complete list of AI systems in production, each with a named business owner, the data it touches, the models it calls and the tools it can invoke. Ask separately how the list was assembled. A list built from a survey of engineering leads has a different reliability than one built from observed traffic, and the difference should be priced.
Where the target maintains an AI bill of materials, request it in its native form rather than as a summary. Where it does not, the absence is the finding, and the first post-close workstream is building one.
The contracts behind the models
For every model provider, request the executed agreement and read three things: the data retention terms, whether the target's data may be used for training, and whether the contract is assignable on change of control. The third is routinely overlooked and routinely becomes an urgent problem in week one.
Also request the billing detail rather than the summary. Provider invoices show which teams are calling which models at what volume, which is a more accurate map of actual AI adoption than any document the target will prepare for a data room.
Credentials and service accounts
Ask for every API key and service account with model or tool access, with its owner, its scope and its last rotation date. Expect the list to be incomplete. Keys embedded in agent configurations by departed employees are the common case, and they are indistinguishable from a legitimate integration until someone audits scope.
The tool and MCP surface
Where the target's agents call tools, request the tool definitions and the integration surface. MCP security is the current vocabulary, and the relevant exposure is that an agent trusts the description of a tool it is offered. Tool poisoning is the attack that follows, and it is upstream of anything the target's own code does, which means code review will not find it.
The governance record
Request the policy set, then request the evidence that the policies were enforced. These are different documents and the gap between them is the single most informative artifact in AI diligence. A target with a thin policy set and a real enforcement record is in better condition than a target with a mature policy set and nothing behind it.
Where records exist, ask whether they are tamper-evident. A log an administrator can alter will not support a representation after close.
Testing and incidents
Ask for the results of any adversarial testing, not the fact that testing occurred. AI red teaming findings that were accepted rather than remediated are disclosed risk and should be treated as such. Ask for the incident log, including near misses, and ask specifically about prompt injection and jailbreak events, which targets often classify as product bugs rather than security incidents and therefore omit.
Regulatory classification
Where the target operates in Europe or serves European customers, ask for its own EU AI Act classification of each system and the analysis behind it. An unperformed classification is a workstream the acquirer inherits with a clock on it. Sector rules travel the same way: a regulated acquirer taking on an unregulated target does not get to apply the target's standard, and obligations under SR 26-2, NYDFS Part 500, GLBA or the HIPAA Security Rule attach to the combined entity.
Five findings that should change terms
Regulated data in a third-party model under training-permissive terms. Not remediable after the fact. Handle in representations and indemnities rather than in the integration plan.
Agents with production write access and no approval gate. The exposure is what the agent can do on a bad day, not what it has done. Where a human-in-the-loop control is absent on a consequential action, the gap is concrete and quantifiable.
No attribution of model spend. A cost forecast the acquirer cannot build, and usually a sign that no control point exists.
Policies without enforcement evidence. Relevant to any representation the target has made about its AI controls, and to what the acquirer can say to its own regulator afterward.
Keys without owners. Every unowned credential with model access is an access path that survives the transaction and the employees who created it.
The day-one problem nobody plans for
Two integration problems arrive immediately and neither is usually in the plan.
The first is the information barrier. During a transaction, and often for a period after it, deal information and competitively sensitive data must stay separated between entities. AI assistants do not respect organizational boundaries that were never expressed to them: a model with access to both sides' documents is a leak path that exists by default rather than by breach. The control required is an information barrier enforced at the point of the model call, and it needs to be in place before the two estates touch. DLP for AI covers the adjacent content-inspection problem.
The second is policy reconciliation. Two firms will have different model allowlists, different approval thresholds and different logging standards. Reconciling them by taking the stricter of each pair sounds prudent and tends to break the target's working systems on the first day. Reconciling by taking the looser is the finding your own examiner will raise. The workable path is to route both estates through one control point and reconcile the policy afterward, as policy as code with a review history, rather than reconciling the policy first and the traffic later.
How APERION fits
Smartflow is an on-premises control plane in the call path between an agent and the model it uses. Every prompt, response and tool call passes through it, and policy is enforced inline before anything leaves the enterprise perimeter.
In a transaction context that has two consequences. Before close, routing a target's traffic through a control point produces the observed inventory that a survey cannot, which converts diligence from interviews into measurement. After close, one control point spanning both estates makes the information barrier enforceable and the policy reconciliation a configuration exercise rather than a migration. For acquirers that cannot route traffic outside their own infrastructure, the control plane runs in an air-gapped deployment.
Related reading
Shadow AI · Agent governance · Board reporting · Financial services · Glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs