The EU AI Act is now a third party risk management issue. Many organizations will not build every AI system themselves. They will buy AI-enabled software, use AI agents, embed vendor models into workflows, rely on SaaS copilots, or ask service providers to process data with AI. That means vendor risk teams need a practical way to ask the right questions before approval, renewal, expansion, or monitoring.
This guide is not legal advice. It is a practical TPRM guide for understanding where the EU AI Act changes vendor due diligence. The core question is simple: when a third party provides or supports an AI system, what evidence does the organization need to understand role, risk category, transparency obligations, human oversight, data use, cybersecurity, and ongoing monitoring?
Why The EU AI Act Matters To Vendor Risk
The AI Act uses a risk-based structure. Some AI practices are prohibited. Some systems are high-risk and subject to stricter requirements. Some systems have transparency obligations. Many low-risk systems have fewer formal obligations, but they can still create business, privacy, security, operational, and reputational risk.
For vendor risk teams, the operational problem is that an AI system may sit inside a third party product. The business may see a productivity feature, but TPRM has to understand whether the vendor is a provider, whether the customer is a deployer, whether the use case is high-risk, whether employees or customers must be informed, and whether the vendor can provide enough documentation to support a defensible decision.
Provider, Deployer, And Vendor Role Clarity
Start every AI vendor review with role clarity. Under the AI Act, a provider generally develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority. In a vendor relationship, the vendor may be the provider, the customer may be the deployer, and subcontractors may support the model, data, hosting, or monitoring.
Ask the vendor to identify its role for the specific AI feature being purchased. Do not accept a generic answer that covers the whole company. A vendor may be a provider for one AI module, an integrator for another, and a deployer of a third-party model inside its own service.
High-Risk Classification Questions
The European Commission’s AI Act materials explain that high-risk systems have strict obligations around risk assessment and mitigation, data quality, logging, documentation, information to deployers, human oversight, robustness, cybersecurity, and accuracy. Commission guidance also highlights practical examples and an updated enforcement timeline for certain high-risk areas.
TPRM teams should ask whether the AI system is used in a high-risk area such as employment, education, access to essential services, law enforcement, migration, critical infrastructure, or safety-related product contexts. The answer may depend on how the customer uses the tool, not only how the vendor markets it.
Useful questions include:
- What AI features are included in the product or service?
- Which AI Act role does the vendor believe it has for each feature?
- Could the customer be considered a deployer?
- Is the AI system used in a high-risk area or connected to a high-risk decision?
- Does the vendor have a documented classification analysis?
- Has legal or compliance reviewed the classification?
- Will the system be modified, fine-tuned, embedded, or used for a different purpose by the customer?
Transparency And AI Interaction
Transparency obligations are especially relevant to AI agents, chatbots, generative systems, deepfakes, and AI-generated content. The Commission’s Article 50 guidance states that transparency rules apply from 2 August 2026 and addresses provider and deployer obligations for certain systems. Vendor risk teams should understand whether users, employees, customers, or affected individuals must be told they are interacting with AI or exposed to AI-generated content.
Ask the vendor how AI interactions are disclosed, how AI-generated outputs are marked where required, what configuration options the customer controls, and whether the vendor provides language, logs, or implementation guidance to support deployer obligations.
Evidence To Request From AI Vendors
Evidence should be proportionate to the AI use case and business impact. For low-risk internal productivity tools, a lighter review may be enough. For higher-risk or externally facing uses, request deeper evidence:
- AI system description, intended purpose, and limitations.
- AI Act role and classification analysis.
- Data sources, training data categories, input data requirements, and data retention.
- Human oversight design and customer responsibilities.
- Accuracy, robustness, cybersecurity, and testing summaries.
- Logging, monitoring, incident, and corrective action process.
- Model change, release, and material modification process.
- Subprocessors, model providers, hosting regions, and fourth-party dependencies.
- Transparency notices, user disclosures, and AI-generated content marking where relevant.
- Customer instructions for use and prohibited use documentation.
Data And Input Controls
AI vendor review must include data. Ask what data the customer sends to the system, whether prompts or uploaded files are retained, whether customer data is used for training or improvement, whether opt-outs exist, where data is processed, and who can access it. For high-risk systems, input data quality can matter because deployers may have obligations to use relevant and representative input data for the intended purpose.
Also review whether the vendor supports data minimization, retention limits, deletion, audit logs, access controls, encryption, segregation, and data subject rights. AI risk does not replace privacy and security review. It adds another layer to it.
Human Oversight And Accountability
Human oversight is a recurring theme in AI governance. In TPRM, it should be translated into operational questions. Who reviews AI outputs? Can the customer override decisions? Are users trained on limitations? Are confidence scores or explanations available? Are there escalation paths for unexpected outcomes? Does the vendor monitor for drift, harmful bias, security vulnerabilities, or misuse?
If the AI system supports decisions about people, money, access, safety, employment, education, compliance, or regulated activity, oversight must be more than a statement in a policy. It should be visible in product controls, workflows, logs, testing, and customer instructions.
Contract Terms To Review
AI vendor contracts should address AI-specific responsibilities. Review intended use, prohibited use, customer responsibilities, data use for training, model changes, notification of material changes, transparency obligations, incident notice, audit or information rights, regulatory cooperation, subcontractor changes, output ownership, indemnities, termination, transition, and data deletion.
Pay attention to model changes. A vendor may update prompts, models, data pipelines, safety filters, evaluation methods, or third-party model providers. TPRM should know which changes require notice, reassessment, or approval.
Also make sure the business owner accepts their part of the control model. If the vendor provides instructions for use, human review steps, configuration settings, or prohibited-use boundaries, those responsibilities should be assigned internally and tracked after approval. A strong vendor control can still fail if the customer deploys the tool into a sensitive process without training, oversight, monitoring, or a named accountable owner. Record those internal obligations in the vendor file so reassessment can test whether they still operate effectively today.
Monitoring Triggers
Ongoing monitoring should include regulatory changes, vendor model changes, new AI features, expanded use cases, accuracy issues, bias complaints, security incidents, serious incidents, data retention changes, subprocessors, user complaints, and material changes in role or classification. AI risk is dynamic, so a one-time onboarding review is weak for important AI systems.
Checklist For TPRM Analysts
- Identify every AI feature in scope.
- Clarify provider, deployer, and subcontractor roles.
- Document intended purpose and prohibited uses.
- Assess whether the use case may be high-risk.
- Review transparency obligations and user disclosure needs.
- Request evidence on data, testing, cybersecurity, logging, monitoring, and oversight.
- Check model change and incident notification commitments.
- Review contract terms for AI-specific responsibility and exit.
- Set monitoring triggers for model, regulatory, and use-case changes.
Common Mistakes
Reviewing only the vendor, not the AI feature
A vendor may have strong corporate controls while a specific AI feature creates unresolved risk. Review the actual use case.
Assuming the vendor owns every obligation
The customer may be a deployer with its own responsibilities. TPRM should route those obligations to legal, compliance, product, HR, security, or business owners.
Ignoring changes after approval
AI systems change through model updates, new features, new training data, configuration changes, and expanded business use. Monitoring must reflect that.
Analyst Takeaway
The EU AI Act gives vendor risk teams a practical reason to improve AI due diligence. Start with role, use case, risk category, data, transparency, oversight, cybersecurity, contract rights, and monitoring. The final output should not be a legal memo. It should be a clear vendor risk decision with evidence, conditions, escalation owners, and triggers for reassessment.
LearnTPRM resources can help teams turn AI Act questions into a repeatable AI vendor intake, evidence checklist, and monitoring workflow.
FAQ
Does the EU AI Act apply only to EU vendors?
No. The AI Act can affect non-EU providers or deployers when AI systems or outputs are used in the EU, depending on the facts. Legal review should confirm scope.
Should TPRM decide whether an AI system is high-risk?
TPRM should collect evidence and flag potential high-risk use cases. Legal, compliance, privacy, product, HR, or business owners should confirm the formal classification and obligations.
Is AI Act review enough for AI vendor risk?
No. AI Act review should sit alongside security, privacy, operational resilience, financial stability, contract, and fourth-party risk review.
