Home > Security and Compliance Blog > Cybersecurity Risk Management > What AWS Reimagine Reveals About the Enterprise AI Governance Gap

What AWS Reimagine Reveals About the Enterprise AI Governance Gap

by Patrick Spencer updated September 29, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

One enterprise reached 88 percent adoption of its AI tools and still produced genuinely better work in fewer than one in 5,000 sessions. That statistic, buried inside Amazon Web Services’ new Reimagine 2026 report, says more about the state of enterprise AI governance than any adoption survey published this year. Usage was everywhere. Verifiable, governed value was almost nowhere. And the gap between the two is exactly where most organizations’ security and compliance exposure now lives.

AWS built the Reimagine 2026 report on nine months of confidential interviews, from November 2025 to July 2026, with 154 leaders, most of them C-suite executives running AI programs across 23 industries and 27 countries, joined by senior Amazon researchers who coded and cross-checked the findings. It is not a vendor survey padded with adoption percentages. It is a close read of how governance breaks down in practice once AI agents start acting inside real business processes, and it lands on a theme Kiteworks has been tracking closely across its own research. Adoption is outrunning the controls meant to govern it, and the resulting gap is now a data governance problem as much as it is a technology one.

Table of Contents

That framing matters for the reader who owns the consequences when it goes wrong. A CISO or chief compliance officer does not experience shadow AI as a productivity story. They experience it as an unanswerable question from a regulator or an opposing counsel, one that asks who authorized this AI agent to touch this data, and whether it was encrypted, logged, and access-controlled at the time. The AWS findings, read through that lens, describe an accountability vacuum that Kiteworks secure data exchange was built to close, because regulators regulate data, not models, and an audit trail that cannot answer that question is not evidence.

This post works through what AWS found, separates the verified statistics from figures that get misattributed to this report in secondary coverage, and connects the governance gap to the specific controls, per-request access enforcement, credential isolation, and unified audit logging, that turn AI risk oversight from a policy document into something an auditor can inspect.

Key Takeaways

1. Adoption is not evidence of governed value.

AWS found one organization with 88 percent AI tool adoption that produced genuinely better work in fewer than one in 5,000 sessions, showing that usage metrics tell you almost nothing about whether AI output is safe, accurate, or authorized.

2. Documented AI governance remains the exception, not the norm.

A companion Strand Partners survey of European businesses, commissioned by AWS, found more than half of SMEs and large enterprises, along with three-quarters of startups, now use AI, but only 24 percent have a documented responsible AI approach and just 10 percent have a data governance strategy.

3. Slow approval cycles push AI use underground.

AWS interviewees described applying six-month IT review processes to AI experiments that move in days, and reported that when a two-week experiment faces a month-long approval, teams stop asking permission and start asking forgiveness, turning policy into a driver of shadow AI rather than a control on it.

4. Governance must live outside the AI system, not inside it.

The report’s own guidance for agentic AI calls for identity, access, and encryption controls that operate independently of the agent, plus staged autonomy that expands only after demonstrated reliability, language AWS itself compares to probation for a new hire.

5. The fix is enforcement encoded into the data layer, not another policy document.

Closing the gap AWS describes requires controls that apply automatically at the point where an AI agent requests data, which is the specific job of Kiteworks Compliant AI and the Kiteworks Secure MCP Server.

Inside the AWS Reimagine 2026 Research

The Reimagine team, a group of Executives in Residence at AWS drawn from former C-suite leaders at organizations including NASA’s Jet Propulsion Laboratory, spent nine months on this research rather than running a survey and calling it done. Between November 2025 and July 2026, they conducted 154 interviews, 128 of them with executives spanning 23 industries and 27 countries, supplemented by senior AWS leaders and researchers who applied computational grounded theory methods to code the transcripts for consistency. AWS also draws on an internal study of AI adoption dynamics across more than 35,000 practitioners in 27 countries to check the interview findings against a much larger dataset.

That methodology matters because it produced something adoption surveys rarely capture. A consistent account, told from inside dozens of organizations, describes how the gap between AI usage and AI governance forms. The researchers were explicit that this is not a maturity model or a vendor pitch dressed as research. It reads instead as a diagnosis, and the diagnosis is that most organizations built their AI governance for a world where technology projects moved at the pace of an annual budget cycle, and AI does not respect that pace.

One caveat is worth stating plainly, since a widely circulated statistic about this report gets it wrong. Some secondary coverage attributes an “83 percent adoption, 13 percent visibility” figure to AWS Reimagine 2026. That number does not appear in the AWS report or in AWS’s own announcement of it. It traces back to an unrelated vendor survey. The verified AWS and Strand Partners figures below are the ones worth building a governance argument on.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

When 88 Percent Adoption Produces Almost No Governed Value

The clearest evidence that adoption is the wrong success metric comes from a single case AWS highlights in its research. One enterprise showed 88 percent tool adoption, meaning almost every employee had used the AI system at least once, yet fewer than one in 5,000 sessions produced work that was genuinely better than what existed before. Adoption was universal. Improvement was statistically almost invisible. AWS found the same pattern across the wider dataset, noting that fewer than 5 percent of practitioners who became fluent with AI early in their adoption journey ever reached the level of sophisticated use that produces measurable business value.

That gap should reframe how a security or compliance team reads its own AI adoption dashboard. A high adoption number tells you exposure is high. It tells you nothing about whether that exposure is governed, whether the data an agent touched was appropriate for it to see, or whether anyone could reconstruct after the fact what happened in any one of those sessions. An adoption metric with no corresponding access log is not a governance metric. It is a liability surface with a friendly name.

This is precisely the blind spot AI data governance programs need to close first, before they invest further in expanding AI capability. Visibility into what an AI agent touched, and authority over what it was allowed to touch, must exist at the moment the request happens, not as a retrospective report generated weeks later when someone finally asks.

The Strand Partners Findings on Adoption Without Governance

AWS’s own interviews are reinforced by a companion survey the company commissioned from Strand Partners, “Unlocking Europe’s AI Potential in the Digital Decade 2025,” drawing on data from thousands of businesses across Europe. The pattern it found matches the interview data almost exactly. More than half of small and medium-sized enterprises and large enterprises, along with three-quarters of startups, now report using AI. Only 24 percent, though, have a documented approach to responsible AI use. Just 10 percent have a data governance strategy at all.

Sasha Rubel, Head of AI and Generative AI Policy for AWS in EMEA, pushed back against reading those numbers as simple failure. “It reflects the genuine difficulty of governing a technology that reinvents itself every quarter,” she told the Reimagine researchers. That is a fair point, and it does not change the exposure those numbers describe. An organization using AI without a documented data governance strategy has no consistent basis for answering a regulator’s most basic question, what data did this system access, under what authority, and where did the output go. Difficulty explaining why governance lags adoption is not the same as evidence that the gap is safe to leave open.

The upside case is worth naming too, because it strengthens the business argument for closing the gap rather than just the compliance one. Bain and Company’s research on responsible AI adoption, cited in the same AWS report, found organizations with an effective responsible AI approach see a median profit impact of 6 to 10 percent from their AI use cases, compared with 3 to 5 percent for organizations without one. Governance, done well, is not a tax on AI value. It is a multiplier on it.

Why Six-Month Review Cycles Cannot Govern AI That Moves in Days

The most specific and, for a compliance leader, most useful finding in the AWS report concerns process design rather than technology. Many of the organizations AWS interviewed still apply the same approval rigor to AI experiments that they built for traditional six-month IT programs, complete with committees that review AI proposals, policy documents approved by legal, and a mandatory human sign-off on outputs. Those processes worked when a project took six months to build. They do not work when the same idea can be prototyped in days.

United Rentals Chief Technology Officer Tony Leopold described the shift bluntly in the report. Work that used to cost hundreds of thousands of dollars and six months to execute now happens in days for hundreds of dollars. A review process calibrated to the old timeline becomes, in AWS’s words, “insufficient when it takes six days,” because the governance sits outside the AI system, bolted on rather than built in, and defaults to treating every use case as equally high risk.

The consequence is predictable and AWS names it directly. If a two-week experiment faces a month-long review, teams stop asking for permission and start asking forgiveness after pressing forward anyway. Policy in that situation is not mitigating risk. It is pushing risk underground, into unmonitored tools and unlogged workflows that a security team only discovers after something has already gone wrong. Boston University’s Chris Sedore, Vice President of Information Services and Technology and Chief Information Officer, put a number on how far this has already gone at his own institution, estimating that 40 to 50 percent of staff use AI on at least a weekly basis, “some of it in models and systems we provide, some of it going rogue.” One interviewee described the resulting dynamic as familiar in shape but not in scale, noting that CIOs who spent years managing shadow IT are now facing shadow AI at ten times the scale.

Shadow AI Is a Symptom of Governance Design, Not a User Problem

It would be easy to read the shadow AI findings as a discipline problem, employees ignoring the rules, and design a response around more training and stricter enforcement of the existing approval process. AWS’s own analysis argues against that reading, and it is worth taking seriously. The existence of shadow AI is not evidence that governance has failed as a concept. It is evidence that governance has been designed in a way that people experience as an onerous barrier to doing their jobs, which means the fix is redesign, not enforcement of the same design with more consequences attached.

That diagnosis lines up with what other researchers are finding independently of AWS. OneTrust’s 2026 AI-Ready Governance Survey Report, fielded with Sapio Research across 1,200 senior decision-makers in eight markets, found that 87 percent of organizations actively encourage employees to use AI agents, while only 47 percent have clear governance in place for how those agents are allowed to operate. Two independent research efforts, run by different organizations with different methodologies, converge on the same structural gap. Leadership wants the productivity, and the control layer has not caught up.

Closing that gap does not mean building a stricter version of the same governance, risk, and compliance process and applying it to AI more slowly. It means moving governance out of a document that a committee approves once and into a system that enforces the rule every time an AI agent requests access to data, which is a fundamentally different kind of control. A policy that says an AI agent should only access data relevant to its task is unenforceable if nothing verifies that claim at request time. Attribute-based access control that evaluates each request against the agent’s role, the sensitivity of the content, and the context of the task is what makes that policy real instead of aspirational.

Four Principles the Report Gets Right About Governing Agentic AI

AWS distills its research into four practical principles for governing agentic AI, and each one maps directly onto a specific control gap that most organizations currently leave open. The first is to get the basics right before anything else. Identity, access, and encryption still do the protective work that prevents security failures from moving at machine speed, and skipping them because an agent seems too fast-moving to slow down for is precisely backward. The second is to set security boundaries outside the agent itself, since agents can misinterpret or work around rules embedded in their own instructions, which means real limits on behavior must live in infrastructure the agent cannot negotiate with.

The third principle treats autonomy as something an agent earns rather than something it is granted by default. AWS’s own phrasing is direct. Start with human approval, expand autonomy only after demonstrated reliability, and retain the ability to narrow it again. “Treat it like probation for a new hire,” the report advises, a comparison that should resonate with any compliance officer who already manages onboarding, access provisioning, and periodic access review for human employees and has never extended that same discipline to a non-human identity acting with similar reach. The fourth principle calls for continuous testing rather than a one-time approval, since models update, prompts evolve, and each change can introduce a failure mode the original governance review never anticipated.

Read together, these four principles describe an approach AWS calls governance-as-code, policy translated into enforcement mechanisms that operate at machine speed, so that human judgment gets reserved for genuine exceptions rather than spent re-approving the same low-risk decision every time it recurs. That is a meaningfully different architecture than a review board that meets monthly, and it is the architecture Kiteworks Compliant AI and the Secure MCP Server were built to provide.

Closing the Evidence Gap for CISOs and Compliance Officers

Every finding in the AWS report eventually arrives at the same question a CISO or chief compliance officer must answer under pressure, one that asks whether the organization can produce evidence, not an assurance, not a policy document, but a specific, timestamped, attributable record, of what happened when an AI agent touched sensitive data. Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report found a parallel gap on the enforcement side, with 79 percent of organizations having deployed no automated kill switch capability for their AI systems, meaning most organizations could not reliably stop an AI agent mid-task if it began accessing data it should not have. Adoption outpacing governance and enforcement outpacing incident response are the same underlying problem described from two different angles.

A CISO Dashboard that shows every AI agent’s activity in one place is a starting point, but visibility alone does not answer the accountability question AWS raises, who is the named owner when an AI agent causes harm, and that question cannot be answered with an org chart alone. It must be answered with a system that generates the record automatically. Kiteworks’ Control Plane captures every AI-to-content interaction in a unified audit trail, which means the evidence a regulator or an opposing counsel eventually asks for already exists rather than needing to be reconstructed under a deadline. AWS’s own next-step recommendation, commission an agent register with a named owner for every agent in production, only works if the register is backed by logs precise enough to prove what that agent did, and that is a data-layer requirement, not a spreadsheet exercise.

How Kiteworks Compliant AI and the Secure MCP Server Close the Gap

The specific controls AWS’s research points toward, boundaries that live outside the agent, access that scales with demonstrated reliability, and continuous enforcement rather than a one-time review, describe almost exactly what Kiteworks Compliant AI is built to do. Every request an AI agent or large language model makes for content is evaluated against role-based and attribute-based policy at the moment of the request, not after the fact, which is the “governance outside the agent” principle AWS recommends made concrete.

The Secure MCP Server extends that same enforcement to the fastest-growing category of AI risk, agents connecting to enterprise systems through the Model Context Protocol. It stores OAuth authentication tokens in the operating system’s secure credential store rather than exposing them through prompts, so a compromised or poorly scoped agent cannot use stolen credentials to reach data beyond what its own permissions already allow, and it logs every interaction to the same unified audit trail that covers Kiteworks secure email, managed file transfer, and file sharing. That combination, enforcement at the point of request plus a complete, exportable record of every access, is what turns AWS’s “governance-as-code” recommendation from an aspiration into something an assessor can verify during an audit.

Organizations do not need to choose between the speed AI promises and the governance regulators require. The AWS Reimagine 2026 report makes the case, backed by 154 executive interviews and a companion survey of thousands of European businesses, that trying to have speed without governance produces adoption with almost no verifiable value and a shadow AI problem that outgrows the one it replaced. Building governance into the data layer itself, rather than bolting it onto the AI system after the fact, is what lets an organization keep both.

To learn more about closing the gap between AI agent adoption and governed, auditable data access, schedule a custom demo today.

Frequently Asked Questions

Not necessarily, and AWS makes this point directly. Widespread shadow AI use is evidence that employees find the approved path too slow or too restrictive relative to the value AI offers, not evidence that governance itself is a wrong idea. The useful response is to treat the volume of shadow AI as an honest metric of where your review process creates friction, then move the controls that matter, access control and data visibility in particular, into the system itself so the approved path becomes the fast path rather than the slow one.

At minimum, a timestamped record of which agent or model made the request, what content it accessed, what policy authorized that access, and where any output went afterward. A general statement that “the AI system is monitored” will not satisfy a regulator or an assessor. An audit trail generated automatically at the point of each request, rather than reconstructed from logs after an incident, is the difference between a defensible answer and a scramble.

Most identity and access management systems govern whether a user or service account can authenticate to a system at all. Kiteworks Compliant AI governs a narrower and more consequential question, namely which specific content that AI agent or large language model can see for this particular request once authenticated, evaluated in real time against role and attribute-based policy. That per-request enforcement is what the AWS report describes as setting security boundaries outside the agent rather than trusting the agent’s own instructions to behave.

The AWS research found this genuinely unsettled across the organizations it studied, and treats the ambiguity itself as part of the problem worth solving rather than assuming a settled answer exists. Its recommended fix is structural rather than organizational, maintaining an agent register with a named human owner for every agent in production, so accountability does not depend on reconstructing intent after something goes wrong. A unified audit trail across every system an agent touches makes that named ownership enforceable rather than symbolic.

Yes, and this is the core argument of the AWS report’s governance-as-code recommendation. The slowdown comes from routing every AI decision through a human committee regardless of risk level, not from having governance at all. Encoding policy into the data layer, so low-risk requests are evaluated and approved automatically while genuinely high-risk or unusual requests still reach a human, preserves control while removing the human-speed bottleneck from the majority of routine decisions. The Secure MCP Server applies exactly this model to agents connecting through the Model Context Protocol.

Additional Resources