Third-party AI risk is becoming an AI governance problem

At a glance

What this is: This is a vendor-risk analysis arguing that AI-specific controls, not legacy third-party questionnaires alone, are needed to assess externally supplied AI systems.

Why it matters: It matters to IAM, NHI, and broader security practitioners because third-party AI increasingly introduces access, data, and accountability decisions that sit outside standard vendor review models.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read OneTrust's analysis of third-party AI risk and vendor assessment

Context

Third-party AI risk sits at the intersection of vendor management, AI governance, and access control. Once an external supplier embeds models, data pipelines, or decision-support tools into business workflows, the risk surface expands beyond contract terms and privacy review into model behaviour, data lineage, and operational accountability.

For identity teams, the key issue is that vendor-delivered AI often behaves like a non-human identity in production: it can touch systems, influence decisions, and consume data under delegated access. That means third-party risk management now has to account for who or what is allowed to act, on what basis, and with what auditability.

OneTrust frames the problem through vendor assessment, but the broader pattern is now common across AI procurement. Organisations that still treat AI as a normal software dependency are likely under-scoping both governance and privilege.

Key questions

Q: How should organisations assess third-party AI risk in vendor contracts?

A: Organisations should assess third-party AI risk by combining standard vendor checks with AI-specific review of model lineage, training data provenance, autonomy, human oversight, and change control. The contract should not be the only control. The real question is whether the supplier can prove how the AI behaves, what it can access, and who is accountable when that behaviour changes.

Q: Why do traditional vendor questionnaires miss AI governance gaps?

A: Traditional questionnaires are usually designed to capture policy existence, not runtime behaviour. That leaves gaps around how a model makes decisions, how data was used to train it, what changes after deployment, and whether the supplier can evidence human oversight. AI governance needs operational proof, not just assurances on paper.

Q: What do security teams get wrong about AI oversight dashboards?

A: Teams often mistake visibility for control. A dashboard can show trust scores and risk exposure, but if no one owns the findings or the controls behind them, the programme has only produced reporting. Effective oversight turns measurements into decisions, and decisions into accountability.

Q: Who is accountable when an AI system makes a harmful decision?

A: Accountability should follow the identity chain that authorized, configured, or triggered the action, including the human owner, the platform team, and any delegated agent or tool account. If the organisation cannot name that chain, the governance model is too weak for regulated AI use.

Technical breakdown

Why standard vendor questionnaires miss AI-specific risk

Traditional third-party risk questionnaires are built to capture security, privacy, resilience, and contractual controls. AI changes the unit of assessment because the material risk often lives in the model, the training data, the update process, and the decisions the system can influence after deployment. A vendor can answer standard questions well and still leave major blind spots around autonomy, explainability, bias, and data traceability. For deployers, the problem is not only whether the vendor is trustworthy, but whether the AI component behaves predictably inside your environment.

Practical implication: add AI-specific control questions to vendor review rather than assuming your existing TPRM template is sufficient.

Dataset lineage, model attributes, and access decisions

The article’s emphasis on dataset attributes and model attributes reflects a real governance shift. Dataset quality, versioning, and ownership affect whether downstream decisions can be explained or challenged. Model attributes such as learning method, bias characteristics, autonomy level, and human oversight requirements determine how much operational trust the organisation is actually extending. This is where AI governance overlaps with identity governance: if an external system can initiate actions or shape decisions, its access and decision scope need to be explicit, reviewable, and limited.

Practical implication: require documented data lineage, model versioning, and explicit oversight boundaries before approving production use.

How AI governance changes third-party risk operations

Holistic assessment means AI governance cannot sit in a separate review lane. It has to be integrated into procurement, privacy, security, legal, and ongoing monitoring workflows so that vendors are assessed for both standard third-party risk and AI-specific behaviour. The governance challenge is lifecycle-wide: onboarding, change management, monitoring, incident response, and offboarding all need AI-aware controls. That is especially relevant when vendor systems act on internal data or are connected to business-critical workflows, because the line between software dependency and delegated actor becomes blurred.

Practical implication: embed AI review gates into procurement and continuous monitoring so new AI functions cannot bypass existing approval paths.

NHI Mgmt Group analysis

Third-party AI risk is now an identity governance issue, not just a procurement issue. When a vendor’s AI system can read data, influence decisions, or trigger actions, it behaves like a delegated digital actor inside the enterprise. That creates a governance problem that sits alongside classic supplier risk, because identity, privilege, and accountability are now part of the vendor assessment. Practitioners should treat AI-enabled suppliers as systems with runtime authority, not static software packages.

Static questionnaires are a poor fit for dynamic AI behaviour. The article is right to call out model attributes, data lineage, and human oversight, because those are the controls that determine whether the system can be trusted in operation. Traditional TPRM can confirm that a supplier has policies, but it rarely proves how an AI model behaves after deployment. The result is an assurance gap that only closes when review becomes lifecycle-based and evidence-driven.

Third-party AI governance debt: organisations are accumulating risk when they procure AI before they can supervise it. That debt shows up later as unclear accountability, missing approval trails, and weak change control when a model update alters behaviour. This is especially acute in enterprises that already struggle to govern non-human identities, because the same ownership and lifecycle issues reappear in AI form.

AI vendor oversight should converge with access governance. Where a vendor system can act on internal resources, procurement teams should not be the only gatekeepers. IAM, security architecture, legal, and risk functions need a shared view of what the AI can access, what it can decide, and what evidence proves it remains within bounds. The practical conclusion is simple: if the system has agency, governance must include privilege.

What this signals

Third-party AI reviews now need to operate like access reviews as much as supplier assessments. If a vendor’s model can make decisions or trigger actions, procurement evidence alone is not enough. Security teams should expect pressure to prove not just who supplied the system, but what authority it received and how that authority is monitored across its lifecycle. Delegated AI authority: the control problem created when an external model behaves like an internal actor with its own effective privileges.

The governance model is shifting toward evidence-based AI assurance. That means workflow owners, IAM teams, and third-party risk functions will need shared artefacts for data lineage, model change tracking, and approval scope, ideally aligned to the NIST AI Risk Management Framework. Organisations that cannot connect procurement decisions to runtime control will struggle to defend their AI adoption choices in audit or incident review.

For identity programmes, the practical signal is clear: AI vendor governance is converging with non-human identity governance. As vendors embed more agent-like functionality, the question becomes whether the enterprise can constrain the system’s access the way it would constrain any other high-risk non-human actor. That makes least privilege, reviewability, and offboarding evidence more important than questionnaire completeness.

For practitioners

• Expand vendor assessments for AI behaviour Add questions on model ownership, training data provenance, versioning, autonomy level, and human oversight to third-party questionnaires so AI is assessed as a runtime capability, not a feature checkbox.
• Tie AI vendor approval to access scope Require explicit review of what systems, datasets, and workflows a third-party AI can touch, and document that scope in the same approval record used for privileged access decisions.
• Make AI monitoring continuous Recheck AI vendor behaviour after deployment, especially after model updates, data changes, or workflow expansion, because the original assessment quickly goes stale.
• Bring IAM into AI procurement Involve identity, security, and risk teams in vendor selection when an external AI will read or act on enterprise data, so delegated authority is governed from the start.

Key takeaways

• Third-party AI risk is no longer limited to privacy and security questionnaires, because vendor models can act with delegated authority inside enterprise workflows.
• The evidence gap is real: organisations are granting AI systems more access than humans in the same job, while many still lack formal AI policies.
• Practitioners should connect vendor assessment to access governance, model lineage, and continuous oversight before AI systems are allowed into production.

Key terms

• Third-Party AI Risk: Third-party AI risk is the exposure created when an external supplier provides models, data pipelines, or decision-support tools that affect your environment. The risk is not limited to traditional security or privacy concerns. It also includes explainability, autonomy, data lineage, and the organisation’s ability to supervise changes over time.
• Model Lineage: Model lineage is the traceable record of what data, code, training runs, evaluations, and approvals produced a deployed AI model. It is the trust chain for machine learning operations, because it lets security and risk teams verify provenance, investigate changes, and support rollback or audit requirements.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• AI Governance Debt: AI governance debt is the accumulation of unresolved control gaps that appear when AI is adopted faster than oversight can mature. It builds when teams deploy models before they can monitor behaviour, document lineage, or assign accountability. Over time, the debt shows up as audit gaps, unclear ownership, and weak incident response.

What's in the full article

OneTrust's full article covers the operational detail this post intentionally leaves for the source:

• A practical checklist of questions to add to existing vendor assessments for AI-specific risk review
• The article’s breakdown of dataset and model attributes that should be documented before deployment
• How OneTrust suggests integrating AI governance into existing third-party risk management workflows
• The vendor’s framing of how AI governance supports compliance, transparency, and trust across supplier relationships

👉 OneTrust's full article expands the checklist, governance framing, and operational questions for AI vendor review.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a stronger governance lens for delegated access, lifecycle control, and policy enforcement across identity programmes.