AI Governance Checklist for IT Leaders During M&A Due Diligence

Two years ago AI barely appeared in a technology diligence request list. It now shows up in three places at once: as a value-creation thesis in the investment memo, as a risk item in the legal review, and as an operational unknown in the IT workstream. Whether you sit on the buy side, the sell side, or the integration team afterwards, the questions are converging — and the organisations that cannot answer them quickly get the finding priced against them.

This is the checklist I work through. It is deliberately practical: every item is something a diligence team can evidence in days, not a maturity model.

1. Inventory — what AI is actually in use?

You cannot govern what has not been enumerated, and in most mid-market companies the real inventory is larger than the official one. Build the list from three independent sources: procurement and expense records, SSO and identity logs, and network or CASB telemetry. Then reconcile.

• Standalone assistants and copilots, including personal or team-level subscriptions bought on a card.
• AI features embedded in existing SaaS — the ones enabled by a vendor release rather than a purchase decision.
• Internally built models, scripts, or agents, including anything a business team built without IT involvement.
• Vendors and outsourced providers processing your data with AI on their side.
• Anything customer-facing, which carries the highest disclosure and liability exposure.

For each entry capture: owner, business purpose, data classes touched, whether output is customer-facing, and annual cost. That table is the single most valuable artefact in an AI diligence exercise, and it is the one most targets cannot produce.

2. Data lineage and rights

The critical question is not which model is used but what it was fed and whether the company had the right to feed it. Establish, per use case: what data goes in, under which classification, whether it includes personal or regulated data, whether customer contracts or privacy notices permit that processing, and whether any of it has been used for vendor model training.

Two findings recur often enough to look for specifically. First, customer data processed under an old master services agreement that predates AI processing entirely and says nothing about it. Second, training or fine-tuning on scraped or licensed content whose terms do not clearly permit commercial derivative use. Both are contract problems dressed as technology problems, and both are expensive to unwind after close.

In AI diligence, most of the real findings are contractual. The technology is usually the easy part.

3. Control narrative and evidence

A control narrative is a short written description of how AI use is bounded, plus the evidence that the boundary is real. Ask for five things:

1. The acceptable-use standard, with its date and the record of how it was communicated.
2. The data-classification mapping showing permitted and prohibited AI use per class.
3. The human-review threshold: which outputs require sign-off before they leave the building or reach a customer.
4. Admin configuration evidence — tenant settings for training opt-out, retention, and entitlements, exported rather than described.
5. Log samples proving usage is attributable to identities and retained long enough to investigate.

A policy with no configuration evidence behind it is a document, not a control. Diligence teams have learned to ask for the export.

4. Agentic access and blast radius

Assistants that read are a data question. Assistants that act are an access question, and by 2026 most targets have at least one. For every agent or automation with system access, establish which systems it can reach, under which credential, with what privilege, and what the maximum damage is if the instruction stream is manipulated.

The controls worth verifying are unglamorous: dedicated service identities rather than shared human credentials, least-privilege scoping, a human approval gate before irreversible actions, rate limiting, and full logging of agent-initiated changes. Where those are absent, the finding is not theoretical — it is an unmonitored privileged account with a natural-language interface.

5. Model risk where decisions affect people

If AI touches hiring, credit, pricing, clinical, or benefits decisions, the bar rises sharply. Look for documented purpose and scope, evaluation of accuracy on representative data, bias testing where protected classes could be affected, a documented human override, disclosure to affected individuals where required, and a monitoring plan with an owner. The regulatory picture varies by jurisdiction, but the diligence expectation has already standardised: someone must own it and be able to explain it.

6. Vendor and contract review

• Training rights — is customer content excluded from model training, contractually and at tenant configuration level?
• Retention and deletion — stated periods, verifiable deletion, and behaviour on termination.
• Sub-processors — the current list and the notification mechanism for changes.
• Indemnities — IP and output-related indemnification, and its exclusions.
• Residency and cross-border transfer terms.
• Exit — export of prompts, configurations, and generated assets, plus assistance obligations.

Contract review of AI terms is now a standard technology diligence workstream. Running it alongside the inventory rather than after it saves a week on a compressed timetable.

7. Day-one and first-hundred-days integration

Integration is where governance gaps become the acquirer's problem. Before close, decide which of the target's AI tools continue, which are consolidated, and which stop on day one. On day one itself, ensure entitlements follow the identity migration, that the acquirer's acceptable-use standard is communicated to the acquired population, and that no personal-account usage carries across.

In the first hundred days, consolidate to a single sanctioned toolset where practical, migrate the inventory into the acquirer's register, close the highest-severity findings with named owners and dates, and re-run the log review to confirm the old paths are actually closed. Fold the remediation into the technology plan rather than tracking it separately — the sequencing discipline in Building an IT Roadmap Your Board Will Actually Approve applies directly here.

Sell-side: what to prepare before the room opens

If you are preparing for a sale, assemble four documents in advance: the reconciled AI inventory, the classification-to-permitted-use mapping, the acceptable-use standard with communication evidence, and exported admin configuration for each material tool. Targets that produce those in the first week of diligence answer most of the AI questions without a follow-up cycle. Targets that cannot spend three weeks assembling them under time pressure — and the delay itself becomes a signal about operating maturity.

The evaluation criteria behind these controls are covered in How CIOs Should Evaluate Claude and Enterprise AI Tools in 2026, and the governance patterns, classification templates, and agentic guardrails are set out in full in The Claude Playbook Series and The Hidden Playbook.