Third-Party AI Risk Assessment and Due Diligence

Introduction

Very few organizations build their AI systems entirely in-house. Most rely on a web of external providers: foundation model vendors, cloud AI platforms, data brokers, labeling services, open-source libraries, and SaaS products with embedded AI features. Every one of these relationships imports risk into the organization. The ISACA Advanced in AI Risk (AAIR) certification, within the AI Risk Program Management domain, tests your ability to identify, assess, and manage the risks that arise when AI capability is sourced from outside the enterprise. This guide explains why third-party AI risk matters, what it consists of, how a sound due diligence and assessment process works, and how to approach exam questions on the topic.

Why Third-Party AI Risk Assessment Is Important

1. Accountability cannot be outsourced. Regulators, courts, and customers hold the deploying organization responsible for outcomes, regardless of who built the model. The EU AI Act, for example, places obligations on deployers as well as providers. If a vendor's model produces discriminatory lending decisions, the bank that deployed it faces the regulatory action and reputational damage.

2. Opacity is amplified. AI systems are already difficult to interpret; when the model is proprietary and hosted by a vendor, the deploying organization may have no visibility into training data, architecture, evaluation results, or update cycles. This creates a double black box: the model is opaque and the vendor relationship adds another layer of opacity.

3. Concentration and dependency risk. Heavy reliance on a small number of foundation model providers creates systemic exposure. A pricing change, service outage, deprecation of a model version, or a change in terms of service can disrupt critical business processes overnight.

4. Data exposure. Sending prompts, documents, or customer records to an external AI service raises confidentiality, privacy, intellectual property, and cross-border data transfer concerns. Some vendors reserve the right to train on customer inputs unless contractually prohibited.

5. Supply chain depth. A vendor may itself rely on sub-processors, open-source components, third-party datasets, or other model providers. Risk can originate several tiers deep in the AI supply chain, far from the organization's direct line of sight.

6. Rapid change. AI vendors update models frequently, sometimes without notice. A model that passed validation six months ago may behave differently today. Traditional annual vendor reviews are insufficient for this pace of change.

What Third-Party AI Risk Assessment and Due Diligence Is

Third-party AI risk assessment is the structured evaluation of the risks introduced when an organization acquires, integrates, or depends on AI capabilities, models, data, or services provided by an external party. Due diligence is the investigative process, conducted before entering into and during a relationship, to verify that the third party's practices, controls, and capabilities meet the organization's risk appetite and requirements.

Together they form a lifecycle discipline that extends traditional Third-Party Risk Management (TPRM) and vendor management with AI-specific considerations. Key categories of AI third parties include:

- Model providers: foundation models, LLM APIs, pre-trained models, model marketplaces.
- Platform and infrastructure providers: cloud ML platforms, MLOps tooling, GPU compute.
- Data providers: training datasets, data brokers, labeling and annotation services, synthetic data vendors.
- Embedded AI in SaaS: HR, CRM, security, and productivity tools that contain AI features the organization may not even realize it is using.
- Open-source components: libraries, model weights, and datasets that carry licensing, security, and provenance risk despite having no formal vendor.
- Consultants and developers: external parties building or tuning models on the organization's behalf.

Categories of Third-Party AI Risk

Exam questions often require you to classify a scenario into the correct risk category. The principal categories are:

Performance and reliability risk: model accuracy, drift, hallucination, robustness, availability, and lack of service-level guarantees.

Data risk: provenance and lawfulness of training data, use of customer data for vendor training, data residency, retention, deletion, and privacy compliance.

Security risk: prompt injection, model extraction, data poisoning, adversarial inputs, insecure APIs, inadequate access controls, and vulnerabilities in the vendor's environment.

Ethical and fairness risk: bias in training data or outputs, lack of explainability, harmful content generation, and misalignment with organizational values.

Legal and regulatory risk: non-compliance with AI regulations, copyright and IP infringement in training data or outputs, unclear liability allocation, and inadequate indemnification.

Operational and continuity risk: vendor lock-in, model deprecation, concentration risk, lack of exit strategy, and dependency on sub-processors.

Reputational risk: association with a vendor involved in controversy, or harm caused by vendor AI attributed to the organization.

Fourth-party (Nth-party) risk: risks originating from the vendor's own suppliers, which the organization has no direct contract with.

How Third-Party AI Risk Assessment Works

An effective program follows a lifecycle approach. Candidates should understand each stage and the controls associated with it.

Stage 1: Inventory and Discovery
You cannot assess what you do not know about. The first step is building and maintaining an inventory of all third-party AI systems and components, including AI embedded in existing SaaS tools and open-source models used by development teams. Many organizations discover shadow AI, where business units adopt AI tools without procurement or risk review. Inventory should capture the vendor, the use case, the data flows, the business criticality, and the ownership.

Stage 2: Risk Tiering and Classification
Not every AI vendor warrants the same depth of scrutiny. Organizations tier third parties based on inherent risk: the criticality of the business process, the sensitivity of data shared, the degree of autonomy the AI has in decision-making, the potential for harm to individuals, and regulatory classification (for example, whether the use case would be deemed high-risk under the EU AI Act). Higher tiers receive deeper due diligence, stronger contractual terms, and more frequent monitoring. This is a risk-based approach and is a core principle tested on the exam.

Stage 3: Pre-Contract Due Diligence
Before engagement, the organization investigates the vendor using tools such as:
- AI-specific questionnaires covering model development practices, training data sources, evaluation methods, bias testing, explainability capabilities, security controls, and incident history.
- Documentation review including model cards, system cards, data sheets, and transparency reports.
- Independent assurance such as SOC 2 reports, ISO/IEC 27001, ISO/IEC 42001 (AI management systems) certification, or third-party AI audits.
- Technical evaluation including pilot testing, red teaming, benchmarking on representative data, and bias testing in the organization's own context.
- Financial and reputational checks to assess vendor viability and track record.
- Regulatory alignment review to verify the vendor can support the organization's compliance obligations, including conformity assessments and documentation requirements.

Stage 4: Contracting and Risk Allocation
Contracts translate due diligence findings into enforceable commitments. AI-specific clauses should address:
- Prohibition or restriction on using the organization's data to train vendor models.
- Data residency, retention, deletion, and sub-processor transparency.
- Notification of material model changes, updates, or deprecations within defined timeframes.
- Performance commitments and service levels for accuracy, availability, and latency where feasible.
- Transparency obligations, including access to documentation and audit rights.
- Incident notification and cooperation requirements.
- IP ownership of outputs and indemnification for infringement claims.
- Liability allocation and limitation of liability appropriate to the risk.
- Compliance representations and warranties tied to applicable AI regulation.
- Exit, transition, and data return provisions.

Stage 5: Onboarding and Integration Controls
Once contracted, the organization applies its own compensating controls: input filtering and output validation, human-in-the-loop review for consequential decisions, logging and monitoring of interactions, access controls, data minimization before sending data to the vendor, and clear user guidance. The principle here is that the organization retains a shared responsibility for safe use even when the vendor controls the model.

Stage 6: Ongoing Monitoring
Because AI changes rapidly, point-in-time assessment is insufficient. Continuous monitoring includes tracking model performance and drift in production, reviewing vendor change notifications, re-running bias and robustness tests after updates, monitoring vendor security posture and incident disclosures, periodic reassessment based on tier, and tracking regulatory developments that alter the risk profile. Key risk indicators (KRIs) should be defined and reported to governance bodies.

Stage 7: Incident Management and Issue Resolution
When a vendor AI system fails, produces harm, or suffers a breach, the organization needs defined escalation paths, communication protocols with the vendor, and the ability to invoke contractual remedies. Lessons learned should feed back into the due diligence process.

Stage 8: Offboarding and Exit
Exit planning must address data retrieval and deletion, model portability or replacement, continuity of dependent business processes, and verification that the vendor has destroyed the organization's data. Concentration risk is mitigated by maintaining credible alternatives and avoiding architectures that make switching prohibitively expensive.

Governance and Roles

Third-party AI risk should be integrated into enterprise risk management rather than siloed. Key elements include a clear policy defining when AI due diligence is required, a cross-functional review process involving procurement, legal, privacy, information security, data science, and the business owner, defined accountability (typically the business owner owns the risk and the risk function provides oversight), board or committee reporting on material third-party AI exposures, and alignment with established frameworks such as the NIST AI Risk Management Framework (which explicitly addresses third-party risk in its Govern and Map functions), ISO/IEC 42001, ISO/IEC 23894, and ISACA's own guidance.

Common Pitfalls

- Treating AI vendors like ordinary software vendors and skipping AI-specific questions.
- Relying solely on vendor self-attestation without independent verification or testing.
- Assuming a SOC 2 report covers AI model risk (it generally does not).
- Failing to inventory embedded or shadow AI.
- Ignoring open-source models because there is no vendor to assess.
- Signing standard vendor terms that permit training on customer data.
- Conducting one-time assessments without ongoing monitoring.
- Neglecting fourth-party and sub-processor exposure.
- Having no exit strategy for critical AI dependencies.

Exam Tips: Answering Questions on Third-Party AI Risk Assessment and Due Diligence

Tip 1: Remember that accountability stays with the deploying organization. If an answer option implies that risk, liability, or responsibility transfers fully to the vendor through outsourcing, it is almost certainly wrong. ISACA consistently emphasizes that the enterprise remains accountable for outcomes.

Tip 2: Apply a risk-based approach. When asked how to allocate assessment effort, choose the option that tiers vendors by inherent risk and applies proportionate scrutiny. Options that apply identical treatment to all vendors, or that skip assessment for low-cost tools, are distractors.

Tip 3: Favor verification over trust. Questions often contrast vendor self-attestation with independent evidence. The better answer involves testing in the organization's own context, reviewing independent audits, or obtaining documentation, not simply accepting a completed questionnaire.

Tip 4: Think lifecycle, not point-in-time. If a scenario describes a vendor that was assessed at onboarding and has since updated its model, the correct response typically involves reassessment, ongoing monitoring, or contractual change-notification rights, rather than relying on the original assessment.

Tip 5: Know the AI-specific contract clauses. Expect questions about which clause addresses a specific concern. Data used for vendor training points to data use restrictions; unexpected model behavior changes point to change notification; infringement claims point to IP indemnification; vendor failure points to exit and transition provisions.

Tip 6: Identify the sequence correctly. Questions may ask what should be done first. Inventory and discovery typically precede classification, which precedes due diligence, which precedes contracting. If an organization does not know what AI it uses, inventory is the first step.

Tip 7: Recognize shadow AI and embedded AI. When a scenario mentions business units adopting tools independently or SaaS products adding AI features, the risk is undiscovered third-party AI, and the response involves discovery, policy, and bringing those tools into the governance process.

Tip 8: Distinguish risk categories precisely. Read the scenario carefully to determine whether the primary issue is data privacy, security, fairness, performance, legal, or continuity. Distractors often describe a plausible but secondary risk.

Tip 9: Remember fourth-party risk. If the scenario mentions a vendor that relies on another provider's model or sub-processors, the correct answer will involve sub-processor transparency, flow-down requirements, or assessing the extended supply chain.

Tip 10: Prefer governance and process answers over purely technical fixes when the question is about program management. In the AI Risk Program Management domain, the best answer often involves establishing policy, defining roles, integrating with ERM, or reporting to governance bodies, rather than deploying a specific technical control in isolation.

Tip 11: Watch for absolute language. Options that say a control eliminates risk, that a certification guarantees compliance, or that a vendor should never be used are usually incorrect. Risk management is about reducing risk to acceptable levels, not eliminating it.

Tip 12: Connect to recognized frameworks. Being able to reference the NIST AI RMF, ISO/IEC 42001, and the EU AI Act's provider and deployer obligations helps you recognize correct answers framed in those terms.

Summary

Third-party AI risk assessment and due diligence is the discipline of knowing which external AI capabilities the organization depends on, understanding the risks they introduce, verifying vendor practices before engagement, embedding protections in contracts, applying compensating controls, and monitoring continuously as both the technology and the regulatory environment evolve. For the AAIR exam, anchor your reasoning in three principles: accountability remains with the deployer, effort should be proportionate to risk, and assessment is a continuous lifecycle rather than a one-time gate. Master these and the scenario-based questions in this area become significantly more predictable.