Generative AI has crossed the line from experiment to infrastructure. Deloitte’s most recent State of AI in the Enterprise survey, drawn from 3,235 business and technology leaders across 24 countries, found that roughly 60% of workers now have access to sanctioned AI tools, up from fewer than 40% a year earlier, and that about 75% of organizations expect to deploy agentic AI within two years. Yet only 21% describe their governance of those agents as mature (Deloitte, 2026). Read plainly, the numbers describe an industry deploying at one speed and governing at another. That is not a technology gap; it is a sequencing gap.
The instinct in most organizations is to treat readiness as a procurement question. Which model, which vendor, which platform, which license tier. Those questions matter, but they are downstream of a more basic one: does the organization understand what it is about to put into production well enough to be accountable for it? Readiness for generative AI is not a property of the model; it is a property of the organization deploying it. The five questions that follow are the ones I have found separate the companies that deploy confidently from the ones that discover their governance program in the incident report. None of them require a new tool. All of them require an honest answer.
1. What is it for?
The first question sounds trivial and is usually the one answered worst. Most generative AI deployments begin as general capability, a chat interface or a coding assistant handed to a population of users with an implicit mandate to find value. That is a reasonable way to run an experiment. It is an unreasonable way to run a production system, because a system without a defined purpose has no defined boundary, and a system without a boundary cannot be governed. Purpose is the first control.
A useful test is whether the organization can state, in one sentence, the business decision or workflow the system participates in and the decision it is not permitted to make. A model that drafts customer correspondence for human review is a different system, with a different risk profile, than one that sends the correspondence. A model that summarizes claims is not the model that adjudicates them. Right-sized controls depend on knowing which of these you are building, and the choice must be made before deployment rather than reconstructed after. Scope is not a limitation on value; it is what makes value measurable.
2. What can it reach?
Generative AI is rarely deployed alone. It is wired to retrieval layers, document stores, ticketing systems, CRMs, code repositories, and increasingly to tools it can invoke on its own. Every one of those connections extends the system’s reach, and reach is what determines blast radius. The model is not the risk. The model’s access is the risk.
Organizations that would never grant a new employee standing access to every data store in the enterprise routinely grant it to a retrieval pipeline, because the pipeline is understood as plumbing rather than as a principal. It should be understood as a principal. The relevant questions are the ones identity and access teams already know how to ask: what data can this system read, what actions can it take, under whose credentials, with what approval, and with what logging. Least privilege did not stop applying because the requester is a language model. If the answer to “what can it reach” is “we are not sure,” the deployment is not ready, whatever the demo looked like.
3. What will it believe?
Traditional software executes instructions; generative AI interprets them. That distinction is the source of an entire class of risk that deterministic security models were never designed to address. A model that reads a document, a web page, an email, or a retrieved record treats the content as context, and context shapes behavior. Prompt injection, retrieval poisoning, and instruction smuggling are not exotic edge cases; they are the predictable consequence of building a system whose control plane and data plane are the same channel.
The question every deployment must therefore answer is which inputs the system is permitted to trust and how that trust is enforced. Content from authenticated internal systems, content from customers, content scraped from the open internet, and content generated by other models all carry different levels of reliability, and a system that flattens them into a single prompt has already conceded the argument. Input provenance, output validation, and constrained tool invocation are the controls that matter here. This is not a flaw to be patched out of the model; it is the nature of probabilistic systems, and governance has to be designed for it rather than around it.
4. Who owns the outcome?
Shared infrastructure does not imply shared accountability. The model may belong to a vendor, the platform to a cloud provider, the retrieval layer to an engineering team, and the prompt to a business unit, but when the system produces a harmful output, the accountability lands on the organization that deployed it. Regulators, customers, and courts do not apportion blame across an architecture diagram.
In practice, most organizations, if they are honest, cannot name the individual accountable for a given AI system’s behavior across its lifecycle. They can name the sponsor who funded it and the engineer who built it, which is not the same thing. Ownership must be tightly coupled to the lifecycle: someone approves the use case, someone owns the data it consumes, someone owns the evaluation that determined it was fit for purpose, and someone owns the decision to retire it when it drifts. Where those roles are undefined, governance becomes aspirational rather than demonstrable. The organizational chart is a control surface, and it should be treated like one.
5. How would you know it failed?
The last question is the one that most reliably exposes the gap between documentation and operation. Nearly every organization deploying generative AI has a policy that says the system will be monitored. Far fewer can say what monitored means: which behaviors are measured, against what baseline, at what cadence, and who is paged when the measurements move. A policy that cannot produce evidence is a statement of intent, not a control.
Failure in generative AI systems rarely announces itself. Outputs degrade as underlying data shifts, a model version changes upstream, a retrieval index absorbs a poisoned document, or users discover a workflow the designers never anticipated. Without telemetry, evaluation baselines, and a defined threshold for intervention, the first signal of failure is a customer complaint or a headline. Aviation and pharmaceuticals settled long ago that the safety question is answered before deployment, not discovered through incidents afterward. Generative AI has not yet made that the default, and the organizations that do will be the ones still trusted when the incidents arrive elsewhere.
The question behind the questions
Each of the five questions resolves to the same underlying one: can the organization demonstrate, with evidence rather than assertion, that it understands what it has deployed? Purpose defines the boundary. Reach defines the blast radius. Trust defines the attack surface. Ownership defines accountability. Observability defines whether any of the preceding answers can be verified after the fact. Answer all five and the deployment decision becomes a decision rather than a bet.
None of this is an argument for slowing down. The 21% of organizations with mature governance are not the cautious ones; they are the ones positioned to deploy faster, because they can say yes with confidence where their competitors say yes with hope. Governance is not the brake on generative AI adoption. It is the reason the accelerator can be pressed.
References
Deloitte. (2026). The state of AI in the enterprise: The untapped edge. Deloitte AI Institute. https://www.deloitte.com/us/en/about/press-room/state-of-ai-report-2026.html
