The C-Suite Signal – Perspectives from the people leading the AI transformtion
AI Governance Meets AI Telemetry: Seeing What You’re Running
Nobody Actually Owns This. And That’s the Crisis.
Today’s Post by Manju Mude, CISO
I’ve sat in enough boardrooms and enough incident bridges to know the difference between governance that exists on paper and governance that functions under pressure. Right now, enterprise AI governance is almost universally the former.
The ownership problem isn’t new. We lived this with cloud adoption, with mobile, with Shadow IT. But AI has a property that none of those technology waves had: the system’s behavior is probabilistic, and it drifts without anyone touching it. You can’t own something you can’t characterize. And most organizations cannot characterize what their AI systems are doing at any meaningful level of precision.
What I’m seeing in practice is diffusion of accountability so complete it functions as absence of accountability. The business unit says it’s a technology problem. IT says it’s data governance. Legal says it’s procurement. The CISO gets the call when something breaks, which is the worst possible time to start the ownership conversation.
The organizations getting this right are treating AI ownership the way mature programs treat data ownership: explicit asset registration, named business process owners, and a defined risk handshake between those owners and the security function. The CISO doesn’t own AI. But the CISO absolutely owns ensuring that whoever does is accountable to a defined risk threshold.
If you can’t tell me today what data is flowing through your AI systems, you don’t have an AI strategy. You have an AI experiment running in production.
AI Incident Response Looks Nothing Like What You’ve Practiced
Traditional IR has a comforting property: something broke and you can point to where. A log entry. A payload. A misconfigured control. The incident has a cause, a timeline, a remediation path.
AI incidents don’t work that way.
When a model hallucinates, confidently, fluently, completely wrong, your detection mechanism is what exactly? Most organizations have none. The output looks correct. It’s coherent. It passes human review. By the time the error surfaces, it’s three systems downstream and the blast radius has expanded significantly.
Model drift is worse, because it’s invisible by design. The model you validated six months ago is not operationally the same model today, even if nobody touched it. The world changed. The input distribution shifted. The outputs are subtly different in ways that don’t trigger any traditional monitoring threshold.
This is where telemetry becomes the difference between a program and a prayer. You need behavioral baselines. Not just API call logs. That’s a billing report, not a governance tool. You need output sampling against defined quality criteria. You need semantic drift detection. You need input anomaly monitoring that can surface prompt injection attempts before they become incidents.
The forensic questions for an AI incident are categorically different too. Was this a model failure? A prompt injection? A retrieval failure in your RAG pipeline? A data problem upstream? The kill chain looks nothing like a traditional intrusion, and most IR teams are not equipped for it.
I ask every executive the same question: do you want to design your AI incident response before or after your first significant incident? Because you will have one. The only variable is whether you’re prepared.
Token Economics Is Organizational Intelligence. Start Treating It That Way
Here’s something that almost never comes up in AI governance conversations but should be foundational to every one of them: every token flowing through your AI infrastructure is a signal, and most organizations aren’t listening.
Token consumption tells you who’s actually adopting versus who just attended the training and went back to their previous behavior. It tells you how AI fluency is developing across your organization. Early stage adoption produces short, simple queries; genuine fluency produces complex, context rich, iterative interactions. That trajectory is a real time map of organizational capability building that no skills assessment captures as accurately.
It tells you about risk. If significant consumption is concentrated in a small number of workflows, you have undocumented critical dependencies on probabilistic systems, and your vendor relationships almost certainly don’t reflect that criticality.
It tells you about your business. Consumption spike in customer facing teams? Something real is happening. A deadline, a competitive shift, a workflow that’s emerged organically and is actually working. The telemetry notices before anyone files a report.
And it tells you about cost in the way that actually matters strategically. Cost per token is a finance metric. Cost per outcome is a strategy metric. Connecting consumption data to business outcome data is hard. It requires cross functional alignment that doesn’t come naturally. But it’s the only honest basis for an AI ROI conversation. High consumption with no measured outcome improvement isn’t a success story. It’s expensive activity.
The token economics dimension also has direct security implications that almost nobody is modeling. Every token entering your AI system is a potential data classification event. Every token exiting is a potential liability. Your existing DLP frameworks were not designed for this surface area. Vector databases storing semantic representations of sensitive documents create data residency and retention questions that most governance policies haven’t touched.
SLAs Built for Deterministic Systems Cannot Govern Probabilistic Ones
This is where I get direct, because the legal and procurement frameworks most enterprises are using for AI vendors are inadequate in ways that will matter when something goes wrong.
Traditional SLAs assume determinism. The system is up or it’s down. Latency is within tolerance or it isn’t. None of that maps cleanly onto a system whose outputs vary by design.
What does 99.9% uptime mean for a model that’s available but hallucinating on your specific use case distribution? What does enterprise grade security mean when you can’t fully audit what the model was trained on? What does data privacy mean when excision of specific training data is technically difficult to verify?
The SLA evolution I’m pushing for includes things that almost no current agreement contains: accuracy commitments tied to your data and your task distribution, not vendor benchmarks. Model change notification windows with testing periods before updates go live in your production environment. Data lineage warranties with teeth. Explainability commitments calibrated to your actual regulatory obligations.
Your consumption telemetry is what makes vendor accountability enforceable. Without it, you’re accepting vendor self reporting on performance. With it, you can hold the conversation with empirical grounding. Your observed performance, on your workflows, against standards you defined. That’s a fundamentally different negotiating position.
Predicting What Your Organization Needs Before It Asks
The telemetry foundation does something beyond governance. It gives you genuine predictive capability around departmental AI needs, and this is where the program transitions from reactive management to strategic enablement.
Legal shows heavy, infrequent, high sensitivity consumption. Deep document work that spikes predictably ahead of regulatory deadlines, board meetings, and procurement cycles. If you see that spike forming, you can ensure governance controls are active and capacity is provisioned before the high stakes work happens.
Engineering is where AI consumption gets genuinely revealing, and where the security implications are most direct. Engineers are among the highest frequency, highest volume AI users in most organizations, and their consumption signature is distinctive: rapid iterative cycles, context heavy prompts, and token volumes that dwarf most other functions. What makes engineering telemetry strategically important is what it surfaces beneath the surface. Code generation queries tell you what your engineers are building and in what stack, a real time capability map that no org chart reflects. Debugging patterns tell you where your systems are fragile. Documentation queries, engineers asking AI to explain code that exists in production, are a quiet alarm bell. That pattern almost always indicates systems more complex, more poorly understood, or more poorly documented than your formal records suggest. From a security standpoint, engineering AI consumption also represents your highest IP exposure surface. Proprietary algorithms, unreleased product architecture, competitive differentiation embedded in code, all of it flows through AI inference when engineers work without data classification guardrails. Telemetry here isn’t just optimization. It’s your earliest warning system for IP governance failures before they become material events.
Finance AI telemetry is your highest sensitivity data governance challenge. The workflows are critical, the data is confidential, and the consumption is highly calendar correlated. Quarter end, audit cycles, annual close. All predictable, all governable in advance if you’re looking at the signals.
Customer facing teams produce telemetry that tells you something your CRM doesn’t: how your people actually experience customer interactions. The queries they bring to AI reveal the objections they’re fielding, the competitive pressure they’re navigating, the gaps in their enablement. That’s organizational intelligence hiding in your consumption logs.
Across all of these, the principle is the same. Telemetry converts AI from a system you react to into a system you steer. The organizations building that capability now will be making investment decisions from evidence. Everyone else will be making them from advocacy and competitive anxiety.
Shadow AI Is the Symptom. Telemetry Gap Is the Disease
The Shadow AI problem is structurally identical to Shadow IT. Employees adopting technology that solves a real problem faster than the enterprise can provision an approved solution. But the risk profile is categorically higher.
When someone used personal Dropbox to share files in 2012, the blast radius was bounded. When someone builds a customer facing workflow on an unapproved LLM today, it is not bounded.
By the time most security teams discover a Shadow AI deployment, it’s already in production, it’s already touching sensitive data, and someone’s business results depend on it. That last part is what makes remediation politically difficult. You can’t shut it down without a fight, because someone is going to walk into their executive sponsor’s office and say security is blocking their productivity initiative.
Traditional detection doesn’t catch this well. You can block known AI endpoints, but the surface area expands faster than blocklist management. You can monitor for unusual exfiltration patterns, but LLM queries look like normal HTTPS traffic.
The organizations handling this best have moved away from block and detect toward what I call governed acceleration. Making approved AI tools available fast enough and capable enough that the legitimate productivity need is met, while maintaining the telemetry visibility to know what’s happening. You don’t win the Shadow AI battle by being the party of no. You win it by being faster than the shadow.
The Posture This All Adds Up To
What I’m describing is a shift from reactive AI management to anticipatory AI strategy, and instrumentation is what makes it possible.
The organizations building this capability will forecast infrastructure needs before they become constraints. They’ll identify high value use cases from organic user behavior before they’re formally documented. They’ll detect risk signals before they become incidents. They’ll hold vendors accountable to real standards.
The organizations that don’t will keep discovering how their AI programs are actually being used after it matters.
Telemetry isn’t the overhead of running an AI program. It’s the foundation that makes running one responsibly possible.
Any board that’s accepted AI as a strategic priority should be asking one question right now: what are we actually seeing from the systems we’ve deployed? If the answer is “we’re not sure,” that’s not an AI strategy. That’s exposure.
And that conversation? That’s exactly where your CISO should be sitting at the table.