Most CISOs dealing with AI risk are not failing because they lack frameworks or policies. They are failing because they are being asked to govern something they cannot see, and the industry has responded by selling them better ways to document their assumptions rather than tools to replace those assumptions with facts.
The result is paralysis. A CISO who knows AI adoption is accelerating, knows the exposure is real, but has no reliable picture of what is actually running, who is using it, or what it is touching. Not because they have not tried to find out, but because the tools available to them were built for a world where things get formally procured and formally logged. AI does not work that way, and neither do the people using it.
Nobody Will Admit It, But Everyone Is Doing It
Most engineers have outsourced a significant proportion of their daily work to LLMs by now, and a meaningful share of that involves LLMs with access to production databases, codebases, payroll systems, and customer data. Nobody will say this out loud. But everyone is doing it.
That gap between what people will declare and what is actually happening is why policy-first governance always fails. Stricter intake forms, mandatory approvals, acceptable use frameworks: none of these address the structural reality that the most significant AI activity in your organisation was never going to be voluntarily surfaced in the first place.
You cannot design governance in the abstract. You have to see what exists before you decide what to do about it.
The Picture Comes First
What changes when you start from discovery is that governance design becomes empirical rather than theoretical. Instead of spending months trying to reach consensus on what engineering is doing with AI tooling, you run a few queries against the data you have already collected, and within an hour you have an accurate picture of what exists, what it is doing, and what you can and cannot realistically control today.
That picture tells you where your real exposure is rather than where you assumed it was. It shows you which AI dependencies are so deeply embedded in how people work that cutting them would break operational continuity, so you know in advance which interventions are viable and which would cause more damage than the risk they address. And it gives you a basis for governance design that is grounded in the actual structure of your AI estate rather than a theoretical model of it.
No two companies are the same. Governance designed from your own telemetry will always be more accurate, more proportionate, and more enforceable than governance designed from a vendor template.
What Instrumentation Actually Means
Building this kind of visibility requires collection at three layers, each catching activity the others miss.
At the device level, MDM gives you visibility into AI activity across every managed endpoint. This is the layer that application-level observability tools cannot reach. Datadog lives inside instrumented applications and has no visibility into what an employee is doing on their workstation outside those boundaries, which means the engineer running a local LLM against a production database and the automation someone built that runs silently in the background are completely invisible to it. MDM sees all of it.
At the browser and identity level, SSO-integrated browser telemetry captures web-based AI usage tied to real identities, catching everything that never went through any procurement or onboarding process.
At the application level, SDK integration captures the deepest signal: tool calls, model decisions, agent actions, and the full chain of what an AI system actually did during a given interaction.
Together these layers produce continuous, ambient visibility across your entire AI estate that does not depend on anyone choosing to surface what they are doing.
Watching Is Not the Same as Controlling
Most observability tools are post factum by design. They record what happened and give you an audit trail to reconstruct events after something goes wrong. That is useful but it is not control.
Just-in-time enforcement changes the model entirely. Rather than recording that an agent accessed a production system, a JIT layer intercepts the access before it happens, evaluates it against your policy, and acts in real time. In the context of autonomous agents making sequences of decisions faster than any human can review them, the ability to intervene at the moment of action is the difference between governance that is real and governance that is retrospective.
It also dissolves the false choice that paralyses most CISOs: kill AI tool access entirely, or leave it ungoverned. JIT means you can allow access in a controlled, enforceable way, preserving operational continuity without surrendering accountability.
The Equation
Discovery plus Observability plus Proof equals Accountability.
Registry without observability is a list that goes stale. Observability without a registry means watching activity you cannot contextualise. Both without proof are operationally useful but meaningless in any audit or regulatory context. Accountability is only the output when all three are present, which is exactly why no existing tool delivers it on its own.
The organisations that get this right will not be the ones with the most comprehensive policy documentation. They will be the ones that stopped trying to design governance in the abstract, started from what their telemetry actually showed them, and built accountability infrastructure that reflects the AI estate they actually have.
How much of what you believe you know about your AI estate was told to you by the people operating it, and how much was independently observed?