Who is accountable when AI-assisted third-party risk decisions are wrong?

Why This Matters for Security Teams

AI-assisted third-party risk reviews can speed up intake, but they do not transfer accountability. The organisation that owns the vendor decision still owns the consequence when the review is wrong, incomplete, or overconfident. That is especially true when AI summarises evidence from questionnaires, contracts, attestations, and security reports without validating whether the underlying controls are current or even relevant. In practice, the risk is not that the model “made a mistake”; it is that humans accepted a machine-assisted conclusion without enough challenge.

This is why control owners need an auditable decision chain, not just a generated recommendation. Standards such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce the same operational point: automation can assist judgment, but it cannot own it. NHIMG research on the 52 NHI Breaches Analysis shows how quickly weak identity and access assumptions become security failures when tooling is trusted more than evidence. In practice, many security teams discover weak vendor oversight only after a breach, regulatory inquiry, or contract dispute has already exposed the gap.

How It Works in Practice

A defensible AI-assisted TPRM process treats the model as a research aid, not a decision-maker. The workflow should separate evidence gathering, analytical summarisation, and final approval. Security or GRC analysts can use AI to draft vendor summaries, map questionnaire answers to control domains, or flag missing artifacts, but a named reviewer must validate the output against source material before any risk rating is finalised. The final record should show what evidence was reviewed, what the model suggested, what the reviewer accepted or rejected, and why the residual risk was approved.

For stronger governance, teams should apply the same discipline they use for privileged system access: clear ownership, least privilege, and reviewable evidence. That means restricting which inputs the AI can see, logging prompts and outputs where policy permits, and requiring human approval for exceptions, compensating controls, and high-risk vendor decisions. The NIST SP 800-53 Rev. 5 Security and Privacy Controls is useful here because it reinforces auditability, accountability, and control enforcement across decision processes. NHIMG’s LLMjacking research is also relevant because it demonstrates how quickly compromised identities and exposed secrets can turn AI workflows into attack paths.

• Assign a single accountable decision owner for each vendor review.
• Require source-linked evidence for every material risk statement.
• Separate AI-generated summaries from human-approved conclusions.
• Document residual risk, exceptions, and follow-up actions in an auditable record.

This guidance tends to break down in high-volume procurement environments where reviewers rely on template answers and skip source validation because turnaround pressure is too high.

Common Variations and Edge Cases

Tighter AI review controls often increase cycle time, so organisations must balance speed against the cost of a wrong vendor decision. That tradeoff becomes sharper when procurement, legal, and security teams all use different risk thresholds or when the vendor is business-critical and time-sensitive.

Best practice is evolving for where AI can sit in the approval chain. Some organisations allow AI to pre-screen vendors and draft follow-up questions, while others restrict it to summarising evidence only. There is no universal standard for this yet, but current guidance suggests that the more autonomous the tool, the more explicit the human approval and logging requirements should be. This is consistent with the NIST Cybersecurity Framework 2.0 emphasis on governance, and with NHIMG’s Klue OAuth Supply Chain Breach, which shows how trust in external systems can amplify downstream exposure.

Edge cases include jointly owned vendor decisions, delegated reviews across regions, and AI tools that enrich risk data from external sources. In those cases, accountability should still be mapped to the business function that accepted the risk, not to the tool or the analyst who drafted the summary. If the organisation cannot explain who approved what, and based on which evidence, the process is not defensible.

Related resources from NHI Mgmt Group

• Who should be accountable for third-party non-human identity risk when business tools request elevated access?
• Who is accountable for managing software supply chain risk when third-party components are introduced?
• How should security teams use AI in third-party risk management without over-automating decisions?
• Who is accountable when a third party introduces compliance or AI governance risk?