AIG-032 Third-Party AI Risk Management
Description
Before a third-party AI system, model, dataset or AI-enabled service is integrated, a documented risk assessment covers the intended use and scope constraints the provider imposes, known limitations and failure modes, data processing and retention practices including whether inputs are used for training, update and model-change notification terms, alignment with the organisation's AI policy and exit and contingency options. For foundation model providers the assessment also covers training data practices, safety alignment methods and incident history. A written agreement with each provider allocates responsibility for compliance with applicable AI regulation and sets the provider's obligations to supply technical documentation and to notify incidents and model changes within defined timeframes. Assessments are refreshed at defined intervals and when the provider makes a material change.
Rationale
Third-party AI systems introduce risks (model change without notice, training data leakage, provider-level failure) that differ from conventional software vendor risk.
Applicability (9 profiles)
The procurement control for every AI system the deployer adopts and the agreement the satisfied-by-provider rows rest on.
Art.25(4) makes the supplier agreement compulsory and fixes its object: a third party supplying an AI system, model, tools, services, components or processes that are used in or integrated into a high-risk system specifies by written agreement the information, capabilities, technical access and other assistance, on the generally acknowledged state of the art, that the high-risk provider needs to meet its own obligations. A tool, service, process or component made publicly available under a free and open-source licence is outside it, general-purpose models excepted. Art.25(1) runs the other way and is what the integrator clause has to anticipate: a distributor, importer, deployer or other third party that puts its name or trade mark on the system, modifies it substantially, or changes a non-high-risk system's intended purpose so that it becomes high-risk, is considered the provider and takes the Art.16 obligations with it.
The procurement assessment is where a public body obtains what both seats need. Art.25(4) fixes the information and assistance the provider owes, Art.25(1) states when the deployer's own changes make it the provider instead and the AIG-037 checks land here as records: the EU declaration of conformity obtained and the CE marking confirmed before the system is put into service. For this profile the vehicle is usually a public tender, so the terms are set once at award and this record is what shows they were. Binds both seats, because neither can complete its own duty without the provider's Art.13 information.
Framework Mappings (24)
| MDS-12 | Open Model Risk Assessment | full |
| EU-AI-Art.25.1 | Value Chain Responsibilities — Assumed Provider Status | partial |
| EU-AI-Art.25.2 | Value Chain Responsibilities — Supply Chain Agreements | full |
| A.10.2 | Allocating responsibilities | full |
| A.10.3 | Suppliers | full |
| SR-3 | Supply Chain Controls and Processes | informative |
| GV-4.2-003 | Organisational AI Risk Communication | GV-4.2-003 | informative |
| GV-6.1-004 | Third-Party AI Risk Policies | GV-6.1-004 | informative |
| GV-6.1-005 | Third-Party AI Risk Policies | GV-6.1-005 | full |
| GV-6.1-009 | Third-Party AI Risk Policies | GV-6.1-009 | full |
| GV-6.2-001 | Third-Party Failure Contingency Processes | GV-6.2-001 | informative |
| GV-6.2-007 | Third-Party Failure Contingency Processes | GV-6.2-007 | informative |
| MG-3.1-001 | Third-Party AI Risk Monitoring and Controls | MG-3.1-001 | full |
| MG-3.1-005 | Third-Party AI Risk Monitoring and Controls | MG-3.1-005 | full |
| MP-5.2-002 | External Impact Feedback Practices | MP-5.2-002 | informative |
| MS-2.3-001 | AI System Performance Measurement | MS-2.3-001 | partial |
| GOVERN 6.1 | Third-Party AI Risk Policies | full |
| GOVERN 6.2 | Third-Party Failure Contingency Processes | full |
| MANAGE 3.1 | Third-Party AI Risk Monitoring and Controls | full |
| MANAGE 3.2 | Pre-Trained Model Monitoring | partial |
| MAP 4.1 | AI Technology and Legal Risk Mapping | partial |
| MAP 4.2 | Internal AI Risk Controls Identification | partial |
| ASI04 | Agentic Supply Chain Vulnerabilities | informative |
| LLM04 | Supply Chain | partial |
Evidence (3)
Third-party AI risk assessment for each integrated third-party AI system or foundation model API, covering intended use scope, known limitations, data practices, model-change notification policy, and exit options.
Example: Third-Party AI Risk Assessment · OpenAI GPT-4o API (Confluence, 2025-09-01): scope constraints (no training on API inputs by default, confirmed via OpenAI enterprise agreement), model change notification: 30-day notice per contract, known limitations: hallucination rate documented, data retention: zero retention confirmed, exit option: 6-month API continuity clause, reassessment trigger: major model version change
Test: Request third-party AI risk assessments for each integrated AI provider. Verify: (1) all required dimensions are covered (scope, limitations, data practices, change notification, exit options), (2) for foundation model providers, training data practices and safety alignment are assessed, (3) assessment is dated within the last 12 months or was triggered by a material provider change, (4) a reassessment schedule or trigger criterion is documented.
Commercial agreement or terms of service with third-party AI providers documenting data processing terms, model change notification obligations, and permitted use constraints.
Example: Enterprise Agreement with Anthropic (executed 2025-06-01): data processing addendum confirming no training on API inputs, 30-day model deprecation notice, permitted use definition excluding prohibited EU AI Act categories, and audit right clause
Test: Request the executed agreements with third-party AI providers. Verify: (1) data processing obligations are explicit (no training on customer inputs, data retention period, deletion obligations), (2) model change notification period is specified, (3) permitted use scope is defined, (4) agreements are executed (signed) and current (not expired), (5) agreements are stored in a retrievable contract repository with the responsible owner identified.
Third-party AI inventory export listing each integrated model, service or dataset with the date of its last risk assessment.
Example: Third-party AI inventory export, 2026-08-31: 11 entries, each with provider, integration point, assessment date, reassessment due date and owner
Test: Export the third-party AI inventory. Verify: (1) every third-party model, service or dataset called from production appears in the export, (2) each entry carries the date of its last assessment and the date the next is due, (3) no entry is past its reassessment due date without a recorded extension, (4) each entry names an owner, (5) the entries reconcile with the outbound calls the network or gateway configuration permits, so an integration made outside the process is visible.
Questions (3)
Does your organisation perform a documented risk assessment before integrating a third-party AI system, model, or AI-enabled service?
Third-party AI systems introduce risks distinct from conventional software vendor risk: model changes without notice, training data leakage, provider-level safety failures. Assessment should cover data practices, change notification policies, and exit options.
Which of the following dimensions does your third-party AI risk assessment cover?
All seven dimensions are expected for foundation model providers such as LLM APIs. Whether inputs are used for model training is often the most commercially sensitive dimension and should be confirmed in contract terms, not assumed from general documentation.
Do your written agreements with third-party AI providers allocate responsibility for compliance with applicable AI regulation?
The same model can shift from non-high-risk to high-risk depending on how it is deployed, so the agreement states who carries which regulatory duty and what documentation, incident and model-change information the provider supplies, with timeframes.