Only 10% of organizations are fully prepared for AI system audits, according to EY's 2025 Europe West Tech Risk AI Survey. That should change the executive question from “Did we review the vendor?” to “Can we detect, explain, and remediate risk after the system reaches production?”
AI due diligence fails when the work ends at procurement. A signed DPA, security questionnaire, and vendor demo can support a purchase decision, but they won't tell your board whether the model drifted, whether an incident can be contained, or whether anyone owns the decision to suspend it. We advise CEOs, CMOs, and CROs to treat diligence as a continuing operating function, with clear evidence, named owners, and a decision path that works under pressure.
Table of Contents
- The Gap in AI Due Diligence
- The Nine Domains a Serious Review Must Cover
- Technical Evaluation That Goes Beyond the Demo
- Data Governance, Provenance, and the Audit Trail
- How AI-Augmented Diligence Changes the Math
- Where Most Programs Quietly Fail
- Prioritized Remediation and Go/No-Go Criteria
The Gap in AI Due Diligence
EY's survey found that only 10% of organizations are fully prepared for AI system audits, only 18% have clearly defined data governance responsibilities, and only 10% have systematic processes for updating AI models (EY survey summary). These figures point to a governance failure that appears after deployment, when revenue workflows, customer data, and operating decisions already depend on the system.
Our position is direct: AI due diligence is a post-deployment governance function, not a pre-purchase gate. The vendor review sets the starting conditions. Production governance determines whether the system remains safe, explainable, and useful when inputs change, suppliers update models, or an incident reaches a customer.
Three phases of diligence
A defensible program separates diligence into three operating phases:
- Pre-deployment review examines the system before approval. The team checks model provenance, data rights, security controls, evaluation evidence, contractual commitments, and the fit between the system and its intended use.
- Steady-state governance monitors the deployed system. Owners review performance, access, model changes, data quality, incidents, costs, and business outcomes against agreed tolerances.
- Triggered review starts after a material change. Triggers include a model update, new training data, a security event, unexplained output changes, a regulatory request, or movement into a higher-risk use case.
Procurement usually owns the first phase. The other two often have no clear owner. The result is a vendor checklist that creates false closure. The contract is signed, the tool enters the stack, and audit evidence becomes scattered across procurement, IT, marketing operations, and the vendor portal.
Board-level definition: AI due diligence is the ability to detect, explain, and remediate AI risk at any point in the system lifecycle.
Executives should use that definition as a practical test. If the team cannot identify the current model version, trace relevant data lineage, reproduce a material output, or execute a rollback, the company has not completed diligence. It has completed paperwork.
A practical starting point is a Stimulead AI readiness assessment, covering strategy, data foundations, infrastructure, culture, governance, and model management. Use the assessment to identify controls likely to fail when real users and changing data reach production, not to create another scorecard.
Treating diligence as a one-time event creates three costs. Remediation becomes more expensive because failures surface after integration. Regulatory exposure increases when the company cannot produce evidence on demand. Commercial value erodes when teams stop trusting a model and cannot determine whether the cause sits in the data, prompt, vendor, or operating process.
The Nine Domains a Serious Review Must Cover
A serious review must connect technical evidence to operating accountability. The Papermark AI due diligence workflow identifies the core areas a buyer should examine, including model provenance, training data rights, architecture, inference economics, compute commitments, evaluation evidence, governance, and key-person risk. For operating companies, we turn those concerns into nine connected domains.
The review domains
Model risk and performance
Request the model card, evaluation report, known limitations, and performance thresholds. The model owner should answer, “Who signs off when performance moves outside tolerance?”Data lineage and quality
Require a lineage diagram, data dictionary, data-quality controls, and change history. The data owner must show where inputs originate and how a reviewer can trace an output back to those inputs.Bias and fairness
Ask for slice-level testing and documented remediation decisions. The accountable business leader should explain what happens if the system produces materially different outcomes for a protected group.Privacy and consent
Review the purpose of processing, consent records where relevant, retention rules, deletion procedures, and the use of legitimate interest. The privacy owner should be able to explain whether customer or employee data enters training, prompts, logs, or evaluation sets.Security and adversarial resilience
Request threat models, access controls, red-team findings, prompt-injection tests, and incident records. The CISO should state how the team isolates sensitive information and limits harmful instructions.Vendor and supply-chain risk
Map the model provider, hosting provider, subprocessors, retrieval layer, monitoring tools, and fallback services. Procurement should identify which supplier changes require customer notice or renewed approval.Regulatory and legal exposure
Link the intended use to applicable privacy, employment, consumer-protection, sector, and AI rules. Legal counsel should identify the evidence the company must retain and the party responsible for each obligation.Integration and operational readiness
Test deployment, permissions, logging, rollback, support escalation, and business continuity. The operations owner should demonstrate what happens when the service is unavailable or produces unreliable output.Business outcome traceability
Connect model activity to a business decision, conversion step, pipeline action, or service outcome. The CRO or CMO should be able to distinguish model contribution from normal variation and explain when the company should stop spending.
| Domain | What Goes Wrong If Skipped | Required Artifact |
|---|---|---|
| Model risk and performance | The team accepts unreliable outputs because no tolerance exists | Model card and evaluation report |
| Data lineage and quality | The company can't explain an output or defend the source data | Lineage diagram and data dictionary |
| Bias and fairness | A workflow creates discriminatory or unequal treatment | Slice-level fairness assessment |
| Privacy and consent | Personal data enters an unapproved training or logging path | Processing map and retention policy |
| Security and adversarial resilience | Prompt injection or access abuse exposes sensitive information | Threat model and red-team report |
| Vendor and supply-chain risk | A supplier changes the system without usable notice | Dependency map and change terms |
| Regulatory and legal exposure | The company can't produce evidence for an inquiry | Control register and obligation matrix |
| Integration and operational readiness | The pilot works in isolation and fails in production | Runbook, access model, and rollback test |
| Business outcome traceability | Leaders can't tell whether the system creates value | Outcome measurement plan |
These domains are one operating checklist. Splitting them into isolated workstreams creates gaps between legal approval, technical validation, and commercial ownership. Our AI governance best practices focus on those handoffs because a control that nobody can execute is only a policy document.
Technical Evaluation That Goes Beyond the Demo
A demo proves that a vendor can produce a polished output under selected conditions. It says very little about production behavior. Run the evaluation in sequence, and require an artifact at every step.
Start with provenance
Ask for the base model identity, weight ownership, training corpus summary, fine-tuning history, and applicable license terms. For a hosted service, ask which parts the vendor controls and which parts depend on another provider. Your legal and technical teams need to know whether derivative outputs, prompts, embeddings, and evaluation data have different ownership rules.
The artifact is a model card with a provenance appendix. If the vendor can't provide one, record the missing evidence as a material finding rather than filling the gap with marketing language.
Demand evidence under stress
Next, review holdout metrics, slice-level performance, adversarial probes, and red-team results. Ask the vendor to demonstrate refusal behavior for cases relevant to your company. A B2B revenue team might test requests for confidential pricing, unsupported product claims, fabricated customer references, and instructions that attempt to bypass approval.
A useful guide to AI evaluation evidence can help your team distinguish a benchmark result from evidence that applies to your intended use. We also recommend documenting the test prompts, expected outcomes, observed outputs, reviewer, and decision for each material failure. Our AI model evaluation service can support this process when internal teams need an independent evaluation structure.
Test production economics
Architecture determines whether the system remains viable after adoption. Measure latency, throughput, context limits, token consumption, queue behavior, and failure handling against realistic workloads. Compare the demo configuration with the production configuration, because a system can look acceptable for one user and become operationally expensive or slow under concurrent demand.
Request an inference cost sheet that explains the unit economics. Also request sample monitoring logs, including latency, errors, usage, and model version. If the vendor won't show how it measures service behavior, your finance team can't forecast operating cost and your operations team can't diagnose degradation.
Verify compute commitments
Ask about capacity reservations, service limits, fallback providers, regional availability, and what happens if the vendor loses access to required compute. A contract should state the service obligations and customer remedies clearly. “We have sufficient capacity” is a claim. A documented compute attestation and continuity plan are evidence.
Anything less than a model card, evaluation report, inference cost sheet, compute attestation, and monitoring-log sample means the demo is still doing the work of diligence.
Data Governance, Provenance, and the Audit Trail
The data layer determines whether the system can survive scrutiny. “We trained on public data” isn't an answer. Public availability doesn't establish ownership, licensing permission, lawful processing, accuracy, or suitability for the intended use.
The OneTrust 2026 AI Ready Governance Report found that 74% of surveyed business leaders said their organizations had AI deployed across departments or at scale, while only 17% said governance was embedded by design. Only 5% said coordination and accountability were clear across the AI lifecycle, and 86% reported at least one AI-related incident in the past year. Those figures make the evidence trail an operating requirement.
Build the inventory before reviewing the controls
Inventory every AI system already in use, including functionality embedded in CRM, sales-engagement, analytics, customer-support, and content tools. The NIST AI Risk Management Framework guidance on inventory processes supports putting AI inventory into vendor onboarding and continuous monitoring so new tool adoption doesn't bypass review.
For each system, record the purpose, owner, data inputs, model provider, deployment location, user groups, outputs, retention period, subprocessors, and change-notification process. Include shadow adoption. A vendor feature can introduce AI into a workflow even when the buyer never approved a standalone model.
Request documents that make reproduction possible
At minimum, request:
- Training data manifest: sources, collection method, licensing basis, exclusions, and known gaps.
- Data sheet: intended use, limitations, quality controls, and retention rules.
- Model card: capabilities, limitations, evaluation context, and version history.
- Lineage diagram: movement from source data through preparation, training, retrieval, inference, and logging.
- Reproducibility artifacts: code or configuration records, evaluation sets, prompts, and environment details appropriate to the service.
The VLA model provenance briefing offers useful context for assessing provenance in systems that combine multiple data and model components. Your reviewers should also test deletion, correction, retention, and access procedures. A consent record that exists in a CRM but never reaches the training pipeline doesn't protect the downstream process.
The NIST AI RMF crosswalk to ISO/IEC 42001 says controls should be scaled to the organization's risk profile and established through transparent policies, procedures, and other controls (NIST crosswalk). That means a low-risk internal summarizer and a customer-facing recommendation engine shouldn't receive identical control treatment. Both still need an owner, evidence, and a response path.
How AI-Augmented Diligence Changes the Math
AI can improve the diligence workflow itself, especially when the review includes a large document population or structured dataset. The benefit comes from coverage and consistency, while human reviewers retain responsibility for judgment, context, and final conclusions.
Independent analysis from MaSynergy on AI versus traditional due diligence reports that AI-augmented diligence can compress end-to-end timelines from 4–8 weeks to 1–2 weeks, reduce total mid-market cost by 55–65%, expand document coverage from 20–40% sampled review to 100% exhaustive review, and increase contract-review consistency from 82–88% to 92–97%. The same analysis describes financial anomaly detection moving from 10–20% samples to full-population analysis.
| Dimension | Sample-Based Manual Review | Full-Population AI-Augmented Review |
|---|---|---|
| Coverage | Reviews a selected portion of the population | Reviews the complete available population |
| Speed | Constrained by reviewer hours and sequencing | Rapid first-pass extraction across the dataset |
| Long-tail risk | Rare clauses and unusual obligations can remain unseen | Unusual patterns can be surfaced for human review |
| Consistency | Interpretation can vary across reviewers and fatigue | The same instruction can run across the population |
| Main failure mode | Missed exposures created by sampling | Hallucinations or false positives without grounding |
| Human role | Reads and interprets a sample | Validates findings, resolves ambiguity, and decides materiality |
Don't hand a general-purpose model an unstructured data room and call that transformation. Ground every finding in the source document, preserve citations, test for false positives, and require a human sign-off for material conclusions. The hybrid model works because the system handles volume while experienced reviewers decide what matters.
For smaller, homogeneous populations, a human-led review may remain faster than configuring an AI workflow. For larger or more varied populations, full-population analysis deserves serious consideration. The decision should rest on document volume, risk concentration, review time, and the cost of missing a rare obligation, not on enthusiasm for a particular tool.
Where Most Programs Quietly Fail
The common failure is a legal and privacy checklist with no operating owner after signature. The buyer asks whether the vendor has security certifications, accepts the DPA, approves the procurement request, and then assumes production governance belongs to IT.
That assumption breaks as soon as the system changes. A model update can alter outputs without changing the product name. A new data source can change the risk profile. A customer complaint can reveal a failure that no procurement questionnaire was designed to detect.
Five gaps that drain value
- No drift monitoring: Nobody compares current output behavior with the approved baseline or investigates material changes.
- No incident response runbook: Staff don't know who can suspend the system, preserve evidence, notify customers, or communicate with the vendor.
- No model owner with budget authority: Technical teams maintain the service, while commercial teams depend on it, and neither can approve remediation.
- No rollback path: The company can't return to a prior model, workflow, or manual process without operational disruption.
- No retraining or review cadence: Model changes happen through vendor releases or informal prompt edits, with no defined reassessment.
The governance gap is visible in the earlier EY findings. Only 18% of organizations reported clearly defined data governance responsibilities, and only 10% reported systematic model-update processes (EY survey summary). Boards approve AI spend, then lose visibility when the system becomes part of daily work.
Put ownership where the risk sits
Pre-purchase diligence asks what the vendor promised. Post-deployment governance asks what the system does. The second question belongs close to the business outcome, because a failure in lead routing, qualification, pricing guidance, or customer communication can affect pipeline and customer trust before IT sees a ticket.
We recommend a named AI risk owner with authority to pause a workflow, obtain remediation budget, and report to the CRO, CAIO, or equivalent executive. That role shouldn't disappear inside a general IT queue. The owner can coordinate with the CISO, legal counsel, data leader, and vendor, but one person must carry the decision.
A program scales when its owner can produce a current inventory, explain the last material change, show the latest evaluation evidence, and run the incident procedure. A program stalls when each answer depends on a different team and nobody owns the gaps between them.
Prioritized Remediation and Go/No-Go Criteria
The nine domains become useful when they change a decision. Don't give every finding equal weight. Separate defects that block deployment from weaknesses that can be managed with a written plan.
Use three remediation tiers
P0 findings block approval or require immediate containment. Examples include undocumented training data, unexplained evaluation gaps, a missing model card, no drift monitoring, absent incident procedures, or no tested rollback path. The executive sponsor owns the decision, with the CISO, legal lead, data owner, and CAIO or technical owner assigned to remediation. Closure requires evidence, such as a provenance record, approved evaluation report, monitoring output, incident exercise, or completed rollback test.
P1 findings allow a conditional decision only when the residual risk is understood. Examples include incomplete lineage, an undocumented model-update process, weak evaluation coverage, an incomplete subprocessor list, or unclear responsibility for retraining. The business owner and control owner should agree on the remedy, date, acceptance criteria, and escalation route. A ticket in Jira isn't closure. A signed policy or a vendor promise isn't closure. The team needs a test result or approved artifact.
P2 findings improve control quality without blocking the use case. These can include dashboard usability, cost optimization, training gaps, and reporting refinements. The functional owner can manage them through the normal operating plan, provided the work doesn't mask a higher-severity issue.
| Severity | Finding Type | Owner | SLA | Go/No-Go Trigger |
|---|---|---|---|---|
| P0 | Data rights defect, missing model card, no monitoring, no incident or rollback path | Executive sponsor with legal, CISO, data, and AI owner | Immediate remediation before approval | No-go until evidence closes the defect |
| P1 | Weak lineage, incomplete supplier evidence, unclear update or retraining process | Business owner and control owner | Written date and acceptance criteria required | Conditional go only with named owners and approved plan |
| P2 | Cost controls, dashboard quality, user training, reporting polish | Functional owner | Normal operating plan | Go if P0 and P1 controls are accepted |
Use three decision outcomes:
- Go: Evidence supports the intended use, owners are named, monitoring is active, and the response path has been tested.
- Conditional go: The use case is bounded, residual risk is documented, and a written remediation plan names owners, dates, evidence, and a pause condition.
- No-go: Training data is undocumented, evaluation evidence doesn't address the intended use, the model card is missing, or the company has no workable rollback or incident procedure.
The NIST AI RMF was released in 2023 after preparatory work and workshops involving 240 U.S. stakeholders and industry members, giving organizations a common structure for trustworthy AI risk management (KPMG AI Pulse coverage). Use that structure as a reference point, then scale controls to the actual risk and operating capacity of your company.
This week, convene the CEO or executive sponsor, the business owner, legal counsel, CISO, data owner, and the person who will operate the system after launch. Pick one live AI workflow, build its inventory, demand the missing evidence, and make a written go, conditional-go, or no-go decision. Don't approve another AI purchase until someone can answer who will monitor it, who can stop it, and what proof they'll bring to the board.
Book a working session with Stimulead to review one production AI workflow, map its nine diligence domains, identify P0 and P1 gaps, and leave with named owners and a documented go, conditional-go, or no-go decision.
