C (3:26)

Absolutely. That's a great question. Because it gets to the heart of why traditional governance approaches don't fully work for AI systems. Historically, governance has often been treated as a static activity. Policies, documentation, approval processes before the deployment. But AI systems are dynamic. They interact with new prompts, new data sets, new users, and sometimes even other AI services. That means risk isn't just introduced during development, it can emerge during operations. So governance has to exist at runtime. It needs to be embedded into the system itself through things like policy enforcement, access control around data retrieval, guardrails around model interaction, and full traceability of what the system is doing. One useful way to think about this is how cloud platform approach reliability. We don't assume reliability just because something passed testing. We build systems that continuously monitor contain failure conditions. AI governance needs a similar shift. What this leads to is what I often describe as a runtime governance model for AI system where policy enforcement, access, control and observability operate continuously as part of the system architecture. Governance should not only approve AI systems before deployment, it should continuously govern how those systems behave while they operate. When governance becomes part of runtime architecture, organizations gain much greater visibility and control over AI behavior.

B (5:06)

So I want to talk about why it is important to have an AI control plane that is separate from the data plane and the applications. So Varun, can you talk to our listeners about not only how, but where they should be enforcing least privilege access?

C (5:29)

Absolutely. And the answer to that question is architecture. And that's why I say this is where the architecture becomes extremely, extremely important. In many early adoption deployments, governance controls are scattered throughout individual applications. Prompts, filters here, safety checks. There's access rules embedded inside different services. The challenge is that governance becomes fragmented and inconsistent. A much more robust approach is to separate the control plane from the data plane, which is a model cloud architects are already very familiar with. The data plane is where the model runs and where interface happens. The control plane is where governance decisions are made. Identity verification, policy valuation, authorization and enforcement of system wide rules. When you centralize governance in a control plane, you can apply least privilege principle continuously and consistently across entire AI system. For example, the control pane can determine which data set a model is allowed to retrieve, which tools an AI agent can invoke, which prompts are permitted and how Outputs are allowed to propagate downstream. This architecture ensures that the model operates within clearly defined boundaries. In other words, the model is no longer treated as an autonomous black box. It becomes a governed component within the controlled system architecture and varun.

A (7:03)

Earlier you talked about shifting a mindset from a model risk thinking to a systemic risk thinking. So can you explain to our listeners what's the difference between the two? And how can organizations mitigate the risk of a good or even a great model being embedded into a not so mature system? What could possibly go wrong?

C (7:22)

There's absolutely I would say this is one of the most important mindset shifts organization need to make as AI becomes embedded into real operational systems. Most governance frameworks today focus on model risk. Things like bias, fairness, the model evaluation, those are important areas, but they only address part of the bigger picture. In production environments, many risks actually emerge from how the model interacts with the surrounding system. A model might perform extremely well in testing, but if that model is connected to sensitive enterprise data, Automated workflows, external APIs or agentic systems, even small error can propagate very quickly. What organizations are really dealing with in those situation is systematic risk. It's no more an operational risk. A helpful analogy is aviation aircraft safety doesn't depend on engine alone. It depends on the entire system. The navigation, the instrumentation, the monitoring and the operational controls. AI system requires the same kind of thinking. If well trained model placed inside an immature system can still produce serious failures. That's why governance has to move beyond evaluating models and towards engineering resilient AI systems where safety, observability and policy enforcement are built directly into the architecture. And that's ultimately what allows organizations to adopt generative AI responsibility at scale.

B (8:56)

What about regulators and CISOs? They want evidence, not only assurances. So when we talk about shifting this mindset for the business, how do we move toward a verifiable and auditable AI model where security, legal and engineering align around what you talk about these architectural controls?

C (9:26)

Absolutely. And the answer to that question is runtime governance model for AI systems. This architecture will allow the organizations to handle the systematic risk which are becoming more and more prominent beyond the model risk. Architecting the systems that enforces governance at runtime will help CISOs to ensure that they don't have the risk that regulators are concerned about allowing organizations to run and operate AI systems in secure and forward looking manner.

B (9:57)

Prune thank you so much for being here today listeners. Thank you for tuning in. Please keep the conversation going on our RSAC membership platform by visiting onersac.com membership and be sure to check onersac.com, for new content posted year round. Until next time.