A vendor may promise faster decisions, better customer experiences, or lower operating costs. But if its AI system mishandles sensitive data, produces unexplainable outcomes, or changes materially after launch, the risk does not stay with the vendor. It reaches your organization, your customers, and your leadership team. AI third party due diligence is the process of identifying, assessing, documenting, and managing those risks before an AI vendor becomes embedded in the business.

For many organizations, traditional vendor reviews are not enough. A standard security questionnaire may establish whether a provider uses encryption or has an incident response plan. It may not reveal how a model was trained, whether customer data is used for model improvement, how harmful outputs are monitored, or who is accountable when automated recommendations cause harm.

The goal is not to slow every AI purchase into a months-long review. It is to create a proportionate, repeatable process that gives decision-makers a clear basis for approving, restricting, or declining an AI vendor relationship.

Why AI vendors require a different review

Third-party risk management has long covered cybersecurity, privacy, financial stability, legal obligations, and operational resilience. AI introduces additional questions because the technology can make predictions, generate content, rank people or options, and influence decisions at scale. Its behavior can also change as models, prompts, data sources, and product features evolve.

A vendor can be secure and still create meaningful AI risk. Consider a recruiting platform that uses AI to screen candidates. Even with strong access controls, the organization must understand whether the system can create discriminatory outcomes, what data informs its recommendations, whether a human can override the result, and how performance is tested over time.

The level of review should depend on the use case. An internal writing assistant used for low-sensitivity marketing drafts does not present the same exposure as an AI tool involved in credit, hiring, healthcare, fraud prevention, insurance, or customer eligibility decisions. Risk-based review makes diligence practical: focus the deepest questions and strongest controls where the potential impact is highest.

Start AI third party due diligence before procurement is complete

The best time to assess an AI vendor is before the business has committed to a contract, integrated the platform, or built key workflows around it. At that stage, the organization still has leverage to ask for evidence, negotiate contractual protections, select a safer configuration, or choose another provider.

This requires a simple intake process. Procurement, legal, security, privacy, and the business owner should be able to identify when a proposed service includes AI or relies on AI-enabled decisioning. Do not rely on the vendor's product category alone. AI capabilities are now embedded in customer service software, HR platforms, sales tools, productivity suites, security products, and analytics applications.

The intake should establish what the system will do, who will use it, what decisions it will influence, and what data it will receive. A useful description is specific: "The tool will summarize support tickets using customer communications" is more actionable than "The team is evaluating generative AI."

Build the review around the actual use case

A meaningful review combines vendor evidence with the context of your planned deployment. The same model may be acceptable for one purpose and unacceptable for another. A general-purpose generative AI service may be suitable for internal brainstorming but require tighter restrictions when it processes personal information or produces content that reaches customers.

Ask how data enters, moves, and is retained

Data handling is usually the first practical question. Determine whether the vendor receives personal information, confidential business information, regulated data, source code, customer communications, or decision records. Then clarify where that data is processed, how long it is retained, who can access it, and whether it is used to train or improve models.

Contractual language matters, but it should match the technical reality. If the organization expects customer data not to be used for training, that restriction should be explicit and supported by the vendor's configuration and operating practices. Teams should also understand whether employees can enter data directly into a public AI interface outside approved controls.

Examine model and output risk

Not every vendor will disclose detailed model architecture or proprietary training information. That does not prevent a useful review. Ask the vendor to explain the model's intended purpose, known limitations, testing practices, safeguards, and process for addressing harmful or inaccurate outputs.

For high-impact use cases, request evidence that the system has been evaluated for reliability, bias, safety, and performance in conditions similar to your own. If the vendor cannot provide complete evidence, that is not always an automatic rejection. It may mean the organization needs additional testing, narrower use, human review, or a decision not to automate the activity.

A key distinction is whether AI output is advisory or determinative. An assistant that drafts a recommendation for a trained employee to review creates a different risk profile from a system that automatically denies service, prioritizes investigations, or ranks applicants. The more consequential the outcome, the stronger the validation and oversight should be.

Confirm accountability and human oversight

When a vendor's AI system makes an error, accountability can become unclear quickly. The business owner may assume the vendor is responsible; the vendor may point to customer configuration, prompts, data quality, or user behavior. A sound diligence process identifies who owns each part of the risk.

Internally, assign a business owner for the use case and make clear who approves deployment, monitors results, manages user access, and escalates incidents. Externally, establish the vendor's responsibilities for support, security events, performance issues, model changes, and regulatory inquiries.

Human oversight should be operational, not symbolic. Specify when a person must review output, whether they have the authority and information to override it, and how their decisions will be recorded. For consequential decisions, a nominal click-through approval is rarely enough.

Review security, resilience, and change management

AI vendors can introduce familiar technology risks in unfamiliar ways. Review identity and access management, encryption, vulnerability management, incident response, subcontractor controls, business continuity, and independent assurance materials. These remain core elements of third-party diligence.

Then address AI-specific changes. Will the vendor notify you before replacing a model, adding a new data source, enabling data retention, or materially changing system behavior? Can features be disabled if they no longer meet your requirements? Is there a process to test updates before they affect a production workflow?

Change notification is especially valuable for generative AI services, where an updated model can alter accuracy, tone, output quality, or safety behavior without a visible change to the user interface.

Turn findings into a decision, not a file folder

Due diligence has limited value if evidence disappears into a shared drive and the vendor is approved without conditions. The output should give leaders a concise, documented view of the use case, inherent risk, controls, evidence gaps, and remaining exposure.

A practical decision has three parts: the approved purpose, the conditions of use, and the accountable owner. Conditions might include prohibiting sensitive data entry, requiring human review, limiting access to trained users, completing a pilot before expansion, or obtaining additional vendor commitments before production deployment.

Not every risk can be eliminated. A mature governance process makes residual risk visible and assigns it to the right decision-maker. That supports responsible innovation better than either unrestricted adoption or a blanket ban on AI tools.

Monitor the vendor after approval

AI third party due diligence is not a one-time procurement event. Vendors release new features, underlying models change, data practices evolve, and the organization's use of the tool often expands beyond the original plan. A low-risk internal pilot can become a customer-facing workflow within a few months.

Set a review cadence based on risk. Higher-impact vendors may require periodic reassessment, performance testing, incident reviews, and confirmation that contract commitments still reflect the product in use. Lower-risk tools may need a simpler annual check or a review triggered by material changes.

Monitoring should also include internal evidence. Track material errors, user complaints, override rates, unexpected data use, and any decisions that appear inconsistent or unfair. These signals often reveal operational risk before a formal vendor review does.

Make governance usable across the organization

The greatest challenge is rarely finding a list of questions. It is creating a process that business teams will use before AI becomes embedded in daily work. Clear ownership, short intake questions, risk-based review paths, and professional documentation reduce friction without reducing standards.

A structured AI risk assessment can provide the starting point for that operating model. Alignora's free AI Risk Checkup helps organizations identify governance exposures and generate a professional report that can support internal discussions about vendor oversight, data controls, accountability, and next steps.

The strongest vendor relationship is not the one that offers the most ambitious AI claims. It is the one your organization can understand, govern, and defend when customers, regulators, auditors, or your own board ask how the technology is being used.