This is Part 2 of our multi-part deep dive in the 2026 State of GRC in the Age of AI report. In Part 1 we covered how 87% of teams reported not having visibility into the AI used by their organizations. This post follows that blind spot to its consequence. When AI breaks a control's operating effectiveness, the audit fails, and someone has to explain why.
Whether overtly causing noticeable issues or simply operating unmonitored in the shadows, AI issues in GRC ultimately show up as an audit finding, a lapsed certification, or a control that was supposed to be operating effectively but didn't. When these surface, someone is left having to answer for them.
Respondents to this survey reported that this is already happening! 71% of IT and security professionals say AI tools have already led to a failed audit or a lapsed regulatory standard. 53% have seen it happen once or twice, 18% have seen it multiple times, and only 5% haven't been audited yet.
The Challenge Rolls Uphill
Ultimately, in practice, someone is left having to explain why. Audit findings—especially at organizations where any finding is a hit against zero-finding goals—quickly bubble up through the organization chart to our leadership teams to review and understand why.
Asked who would ultimately be held accountable for an AI-related compliance or security failure, 35% of respondents named the CIO or CISO. No surprise there. For most CISOs, this is one more thing on a long list they'll be asked to explain from the hot seat. GRC and compliance leadership (25%) and IT and security leadership (22%) absorb much of the rest, with the executive leadership team (13%) and the board (3%) at the bottom.
The distinction that matters here is ownership. An agent (and the team member who built, deployed, maintains, and monitors this agent) owns an outcome and can be held to repeatedly yield that outcome. Many of us are still working in a platform, where the work happens but doesn’t answer for the result. Most AI in GRC was sold as the second and is now being asked to behave like the first.
That distinction matters because of how these actually get adopted within our organizations today. Something quickly deployed—often to just to save an analyst a few hours a week—can end up carrying consequences that surface to the most senior executives at the organization. Our leadership teams rarely own the problem itself, but they own the questions when something goes materially wrong. These and other AI-related risks now live rent-free in the minds of our highest leadership team members. Accountability shifted upward before most governance programs accelerated to meet us in this new reality.
The Buyer Owns the Outcome
There's a second party that rarely shows up in the accountability data: the vendor. A lot of AI in GRC is sold on the promise of transformation and has so far delivered something closer to only marginal gains against the hopes we initially held. When that gap is realized—either by the internal GRC team who deployed it or the auditor who assessed it, the buyer ultimately carries the consequence. The question of who was accountable for the outcome is one many vendors rarely have to answer to, potentially citing the customers’ fault in the shared responsibility model.
That's the standard worth holding every provider to, and more importantly, the one we hold ourselves to: a vendor should be able to tell you exactly what its tool owns, and stand behind it when it matters. The ones worth keeping are the ones we trust who can do these consistently over time.
Similarly surfacing are the financial impacts. Ninety percent of organizations admit at least some of their AI investments in GRC fell short of expectations, and 74% describe their AI returns as modest or lower. Our finance teams who approved our AI investments are now asking the harder questions about what they bought and who owns the results. "The platform did it" is still not an acceptable answer when things go wrong.
Accountability Requires Evidence For Assurance
If 71% have already seen AI contribute to a failed audit or lapsed standard, and the buck stops with the CIO or CISO, then those executives are on the hook for systems they often can't fully trace. Accountability without evidence is just exposure.
I've been in the room when our auditors have asked how and why a control failed. The programs that come out of those conversations with a positive outcome are the ones that can evidence the control operated effectively and how.
Closing that gap means treating every control AI is taking part in operating the way we’d treat any other audited control: with continuous evidence, a clear owner, and a record both we and our external assessors can trust. When a control depends on AI to operate, the program has to show that the control was in place and operating. When done in a way that produces consistently and defensibly reliable outcomes, that's the difference between having to defend a potential finding after the fact and preventing that conversation needing to happen in the first place. The teams that get this right stop thinking about AI accountability as a simple policy statement and start treating it as an embedded, trusted capability with a supporting evidence trail.
Three Changes To Make Now
Our organizations resetting this accountability are making three specific moves:
Include Outcomes into AI Vendor Contracts
Specify the outcome the agent owns, how it's measured, and the consequence when it makes a mistake. Diffuse SLAs (such as uptime) covering "platform availability" no longer fit the risk.
Track Outcome Accountability for Vendors
Rate vendors on what their tool owns alongside cost and integration. A vendor that can clearly articulate what its tool can do and what it’s responsible for is one we can hold to account as it operates our key processes and helps us confidently stand strong through the next assessment cycle.
Name Specific Tools in Executive Reporting
Reporting AI risk in aggregate is ending. The teams that name the tools producing the most exposure internally are the ones that control the narrative externally.
All three come down to one discipline. Decide, in writing, who owns each AI-touched outcome before it fails. Do that and accountability stops being a scramble after a finding and becomes something you can show on demand. That is what lets a program keep moving fast without hoping the next audit goes quietly.
Get AI Audit-Ready With Drata
Drata keeps evidence collection running against your controls in real time, so the systems your executives are accountable for stay audit-ready instead of audit-exposed. Every control gets an owner, a status, and a record, which is exactly what a board wants to see before an auditor asks. See how we change the accountability equation: request a demo.
Next in the series: if AI is failing audits and accountability rolls up to the CISO, the natural next question is why so many of these tools weren't enterprise-ready or built to survive scrutiny in the first place. Missed the start? Go back to Part 1: The Visibility Problem.