AI Due Diligence: What Businesses Should Check

Key Takeaways

• AI due diligence should examine how a system handles business and customer data, not just what the model can do.
• Data flow mapping matters more than marketing claims; businesses need to know where prompts, files, and outputs actually go.
• Model training on customer data is one of the most overlooked risks in AI vendor agreements.
• Security documentation should be specific and verifiable, not a generic list of buzzwords.
• Deployment location and data residency directly affect regulatory exposure.
• A due diligence checklist should be treated as a living document, reviewed whenever a vendor changes its architecture or subprocessors.
• AI due diligence works best as a cross-functional exercise involving IT, security, privacy, legal, and the business owner requesting the tool.

Adopting a new AI tool is rarely as simple as signing up and connecting an API key. Once an AI system touches business data, that data may travel through infrastructure the organization doesn't control, get processed by subprocessors it has never heard of, or end up stored in logs indefinitely. AI due diligence exists to catch these issues before they become incidents, audit findings, or breach notifications.

What Is AI Due Diligence?

AI due diligence means systematically reviewing an AI system or vendor before it is trusted with business information. It covers the technical, contractual, and operational aspects of how the system works: what data it needs, how that data is processed, what the underlying model does with it, and what happens after the interaction ends.

This differs from ordinary software due diligence in a few important ways. Traditional software review focuses mainly on functionality, uptime, and integration. AI due diligence has to go further because AI systems often ingest unstructured content such as documents, chat messages, or customer records, and because many AI vendors rely on third-party foundation models that introduce another layer of data handling entirely. A tool can pass a standard security review and still create risk if nobody asked whether uploaded files are used to fine-tune a model somewhere downstream.

Organizations should perform AI due diligence before signing a contract with a new AI vendor, before rolling out an internal AI feature built on a third-party model, and periodically afterward when a vendor changes its architecture, adds new subprocessors, or expands what the tool is used for. It typically involves IT and security teams evaluating the technical architecture, privacy or legal teams reviewing data handling and contracts, and the business unit confirming the tool actually solves the problem it was bought to solve.

Why AI Due Diligence Matters

The reason AI due diligence has become its own discipline is that AI systems concentrate risk in ways that older software categories usually didn't. A traditional SaaS tool might store customer records in a database with known access controls. An AI system might take that same data, pass it through a third-party model API, log the prompt and response for debugging, and retain that log for an undefined period. Each of those steps is a separate point where sensitive information can be exposed, misused, or retained longer than intended.

Consider a mid-sized law firm that adopts an AI drafting tool to speed up contract review. If nobody checks whether uploaded contracts are used to improve the vendor's underlying model, the firm may unintentionally expose confidential client terms to future training data. A healthcare provider using an AI scribe tool faces a similar problem if transcripts containing patient information are retained by a subprocessor the provider never evaluated. In both cases, the business didn't do anything reckless on purpose; it simply didn't ask the right questions before deployment.

Vendor dependency compounds the problem. Once an organization builds a workflow around a specific AI vendor, switching becomes expensive, which makes it tempting to accept vague answers about data handling just to move a project forward. Regulatory obligations add further weight, since many industries already have specific requirements around data processing, cross-border transfers, and third-party risk that don't disappear just because the vendor markets itself as an AI company rather than a software company. Due diligence performed early gives an organization leverage to negotiate better terms, choose a different vendor, or add compensating controls before the relationship is locked in.

What Should Businesses Check During AI Due Diligence?

The core of AI due diligence is understanding exactly what happens to data at every stage of interaction with the system, along with confirming the tool actually fits the business need it was bought to address.

Business Purpose and Use Case

Before evaluating any technical detail, it's worth confirming the AI system solves a real, well-defined problem. A tool that summarizes customer support tickets is a very different risk profile from one that automates financial decision-making. The intended use case determines how sensitive the data involved will be and how much scrutiny the rest of the review needs.

AI Model and Technology

Businesses should understand which model powers the product, whether it's proprietary or built on a third-party foundation model, and what its known limitations are. A vendor that layers a thin interface over a widely used foundation model inherits that model's data handling practices, so due diligence needs to cover both the vendor's own policies and the underlying provider's terms.

Data Processing and Data Flows

This is often the most revealing part of the review. What happens when a prompt is submitted? Does it get sent directly to a third-party API, or processed first through the vendor's own infrastructure? Are uploaded documents stored, cached, or discarded after processing? Are outputs logged for quality monitoring, and if so, where do those logs live? Mapping this flow, even at a high level, tells an organization more than any marketing page will.

Data Privacy and Sensitive Information

If the system will process personal information, financial data, healthcare records, or intellectual property, businesses need specific answers about how that information is protected, minimized, or excluded. Some organizations require sensitive fields to be redacted or anonymized before they ever reach an AI system, which reduces exposure regardless of what the vendor promises to do afterward.

Model Training and Customer Data

One of the most consequential questions in the entire process is whether customer or business data is used to train or fine-tune the vendor's models. Vendors vary widely here: some contractually guarantee that customer data is never used for training, others use it by default unless the customer opts out, and some simply don't address it clearly. This should never be assumed; it should be confirmed in writing.

Security Controls

Rather than accepting general statements about "enterprise-grade security," due diligence should ask about encryption in transit and at rest, access controls, authentication requirements, and whether the vendor has completed independent audits such as SOC 2 or ISO 27001. The goal is a due diligence review, not a general security audit, so the focus should stay on how these controls apply specifically to the AI workflow in question.

Compliance and Regulatory Requirements

Depending on the industry, an organization may need to confirm that an AI vendor supports obligations under frameworks like GDPR, HIPAA, or sector-specific rules, and that contractual terms such as data processing agreements are in place. This section of due diligence should stay grounded in the organization's actual regulatory exposure rather than trying to cover every possible AI regulation in the abstract.

Deployment and Data Location

Where an AI system runs affects both risk and compliance. A cloud-hosted, multi-tenant deployment carries different considerations than a private cloud instance or an on-premises deployment where the organization retains full control over processing. Data residency requirements, particularly for regulated industries or cross-border operations, often narrow the list of acceptable deployment models before any other factor is considered.

Third-Party Vendors and Subprocessors

Most AI products rely on a chain of subprocessors: cloud infrastructure providers, model providers, analytics tools, and sometimes additional AI services layered on top of each other. Businesses should ask for a current subprocessor list and understand what each one can access, since a due diligence review that stops at the primary vendor misses most of the actual data exposure.

Data Retention and Deletion

Retention policies determine how long prompts, uploaded files, outputs, and logs remain accessible after they're no longer needed. Businesses should confirm whether data can be deleted on request, how backups are handled, and whether deletion requests are honored across all subprocessors, not just the primary vendor's own systems.

Vendor Transparency and Documentation

A vendor that can produce clear documentation, a data processing agreement, and specific answers to direct questions is a very different partner than one that offers only general reassurances. Requesting a security whitepaper, a subprocessor list, and a sample data processing agreement early in the evaluation often reveals how mature the vendor's own internal practices actually are.

AI Due Diligence Checklist

The following questions form a practical starting point for evaluating any AI vendor or system.

• What data does the AI system process, and is it necessary for the intended use case?
• Where is that data processed, and does it cross international borders?
• Is customer or business data retained, and for how long?
• Is data used to train or improve the vendor's models?
• Who, internally and externally, can access the data?
• Which third parties or subprocessors are involved in processing?
• How is sensitive information protected during processing?
• Can sensitive fields be anonymized or redacted before reaching the AI system?
• What deployment options exist, and which fits the organization's data residency needs?
• Can data be deleted on request, including from backups and subprocessors?
• What happens to prompts and uploaded documents after a session ends?
• What happens to logs, telemetry, and debugging data?
• What is the process if the vendor changes its model, architecture, or subprocessors?

AI Due Diligence Red Flags

Certain warning signs should prompt closer scrutiny or a pause before moving forward. A vendor that cannot clearly explain how customer data is processed is one of the clearest indicators of trouble, since a company selling an AI product should be able to describe its own data flow without hesitation. Vague retention policies matter for the same reason: if a vendor doesn't know how long it keeps data, it likely hasn't built the controls to delete it properly either.

Vague answers about model training deserve particular attention. A vendor that says data "may be used to improve our services" without specifics is often using data for training by default. Similarly, if third-party access is difficult to trace, or the vendor cannot explain where processing physically occurs, that opacity usually reflects a lack of internal governance rather than a simple communication gap.

Requiring sensitive information to be sent directly to an external model without any option for redaction or anonymization is a structural red flag, since it removes the organization's ability to limit exposure regardless of the vendor's other practices. Generic security claims unsupported by documentation, the absence of a clear deletion process, and an inability to explain what happens to prompts, files, or logs all point to the same underlying issue: the vendor hasn't thought through its own data handling carefully enough to explain it to a customer.

How to Conduct AI Due Diligence

A practical AI due diligence process usually follows a consistent sequence. It starts with defining the intended use case clearly, since the sensitivity of the data involved should shape how deep the rest of the review needs to go. From there, the organization identifies exactly what data the tool will touch and maps how that data flows through the vendor's architecture and any subprocessors involved.

Evaluating the vendor comes next, covering its documentation, contractual terms, and track record. Privacy and security controls get reviewed against the organization's own policies and any applicable regulatory requirements, and where possible, the system is tested in a limited environment before full deployment. Findings should be documented formally, even when the outcome is a straightforward approval, because that record becomes useful if the vendor's practices change later. The process ends with a decision: approve the tool as-is, require additional controls such as data redaction or a revised contract, or reject the vendor and look elsewhere.

Who Should Be Involved in AI Due Diligence?

AI due diligence works best as a shared responsibility rather than something handled entirely by procurement or IT. IT and security teams evaluate technical architecture and controls. Privacy teams or a data protection officer assess how personal information is handled and whether it aligns with applicable law. Legal reviews contracts, data processing agreements, and liability terms. Procurement manages the vendor relationship and contract negotiation, while compliance confirms alignment with industry-specific obligations.

Business owners requesting the tool play an equally important role, since they understand the actual use case and can flag when a vendor's capabilities don't match what was promised during a sales demo. Data teams, where they exist, can help validate technical claims about data flow and storage. Treating AI due diligence as a single department's job almost always leaves gaps, because no one function has visibility into every dimension of risk an AI system introduces.

Reducing Exposure Before Data Reaches an AI System

One theme comes up repeatedly across every section of AI due diligence: the less sensitive information that reaches an external AI system in the first place, the smaller the risk footprint an organization has to manage. This is why many businesses handling sensitive data are looking at privacy-focused technologies that can identify and redact or anonymize personal and confidential information before it's ever sent to a model, rather than relying solely on vendor promises after the fact.

Questa AI is one example of this approach. Its Blackbox and Developer API products are designed to sit between an organization's data and the AI systems it uses, applying anonymization to sensitive fields before that data reaches an external model, while Questa AI Cloud extends this to broader deployment scenarios. For organizations conducting AI due diligence on a vendor that cannot guarantee data won't be used for training or retained indefinitely, adding a layer that limits what sensitive information ever leaves the organization in the first place can meaningfully reduce risk regardless of what the downstream vendor ultimately does with the data.

Frequently Asked Questions

Conclusion

AI due diligence is not an optional formality; it is the mechanism that determines whether an organization understands what happens to its data before an AI system starts processing it. Businesses should complete AI due diligence before allowing any AI vendor to touch sensitive company or customer information, because the cost of asking these questions upfront is far lower than the cost of discovering the answers after an incident.

The organizations that get this right treat due diligence as an ongoing practice rather than a one-time checkbox, revisiting vendor relationships whenever architecture or subprocessors change. Reducing how much sensitive data ever reaches an external AI system in the first place, whether through internal policy or privacy-focused tools that anonymize data before it's processed, remains one of the most effective ways to limit exposure regardless of how thorough any single vendor's due diligence answers turn out to be.