Gal Ordo is CPO and co-founder of Native, a control plane for cloud security.gettyMost of the AI governance conversation starts with policy: which models employees can use, what data can be shared, who approves a new deployment and how exceptions should be handled. Those decisions matter, but they break down quickly if the environment cannot enforce them. In practice, that enforcement must live at a deterministic layer, where the architecture defines what is possible and what is not. As AI embeds further throughout the enterprise, secure architecture will be foundational to its governance. AI is moving into cloud architectures that were already difficult to govern at a technical level, especially across multiple environments and cloud providers with different built-in security controls. Large organizations run across multiple providers, thousands of cloud units and a long tail of services, vendors, identities and workloads. Each provider has strong built-in controls that have become far more capable over the last few years.The problem is that these controls do not naturally form a single operating model. Customers still have to configure, simulate and operationalize them manually, and one security outcome often requires coordinating multiple controls across environments. I saw this pattern for years while building security products inside AWS. The cloud providers have invested deeply in controls that can enforce real security outcomes, but they have not solved the harder enterprise problem of turning those controls into enforced architecture at scale.Most enterprise AI discussions center on model approval and performance. Those are important questions, but the greatest risk in production AI emerges when AI systems touch real data, infrastructure, identities and business processes.At that point, every AI deployment becomes a cloud architecture decision. Choosing a model provider can create a network path. Giving an agent permission to act creates an identity decision. Connecting a model to enterprise data creates a boundary decision. Putting AI into a production workflow creates an enforcement decision.In most enterprises, security teams already know what good should look like. Sensitive data should stay inside approved regions and zones. Production and non-production environments should be separated. AI services should only be invoked from approved places, by approved actors, with approved data. Agents should not be able to grant themselves admin access, expose data publicly or delete protected resources because a prompt told them to do it.The problem is rarely the sentence. The problem is translating that sentence into controls that work across clouds, knowing what those controls will affect before enforcement and keeping them current as the environment changes.A useful way to think about AI governance starts with the same language cloud architects already use: actors, zones, boundaries and baselines.An actor is anything that can operate in the cloud. That includes employees, workloads, service accounts, CI/CD pipelines, vendors, SaaS tools and AI agents. AI-enabled is an attribute on an actor, not a separate category. An agent your team builds is still an internal actor. A third-party co-pilot is closer to a vendor actor. The architecture should treat them according to what they can reach and what they can do.A zone is a logical grouping of cloud objects and actors that share a security posture. Production is a zone. Non-production is a zone. A regulated data environment is a zone. An AI development sandbox can be a zone. These zones may span multiple clouds, which is why the architecture cannot start and end with provider-specific language.Boundaries define what can cross between zones: which actors can invoke which models, which services can reach which data and which paths are approved between environments.Baselines define what must always hold inside a zone. Encryption, logging, backup immutability, regional restrictions, access assumptions and destructive-action protections should not depend on every team interpreting the policy correctly.This language matters because AI requires tighter boundaries, stronger baselines and a first-class inference perimeter.The inference perimeter defines which models can be invoked, by which actors, from which zones, in which regions and with what data. A regulated workload should not be able to send sensitive data to an unapproved model because the path should not exist. A production AI workflow should not be able to perform a high-impact action unless the required identity scope, approval path, audit trail and blast-radius limits are in place.For AI, the most important controls are invariants: properties that always hold regardless of what runs inside the environment. No datastore in this zone is reachable from the public internet. Regulated data never leaves its region. Protected resources cannot be deleted without the required safeguards. No actor can grant itself broader administrative access.These invariants matter because AI systems are not static. Models and tools change. Teams adopt new services quickly. Agents behave usefully because they can act across steps, but that also means their behavior cannot be governed only through instructions. Prompt injection, hallucination and tool misuse are model behaviors. The architecture should make the dangerous action class impossible regardless of whether the actor is a human, a pipeline or an agent.That does not mean blocking AI adoption. In practice, the organizations that move fastest are the ones that make the safe path the practical path. They define the outcomes that must hold, translate those outcomes into provider-native controls, simulate the impact before rollout, manage exceptions with scope and expiration, and continuously check whether each zone is still protected as the estate changes.An architecture document is not the architecture. The architecture is what actually happens when access is requested, data moves, a model is invoked or a service tries to act.New accounts, workloads, vendors, services and agents enter the environment constantly. Providers release new controls. Business requirements change. Exceptions accumulate. The operating model must measure the gap between the guardrails a zone requires and the guardrails actually enforced there.The next phase of AI adoption will be defined by whether enterprises can operationalize AI across existing cloud environments. The companies that succeed will make governance part of the architecture itself, enforced by the cloud controls they already own and operated continuously as the environment changes.​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?