--- title: "Google Cloud's 20 Questions Before Deploying AI Agents" slug: "google-cloud-20-questions-ai-agents" author: "Mikel Amigot" date: "2026-08-15 13:00:00" category: "Premium" topics: "ai governance, agentic ai, enterprise ai, google cloud, ai risk management, compliance, self-hosted ai" summary: "Google Cloud published a governance checklist for organizations deploying production AI agents rather than another capability announcement. That inversion is the signal worth reading: the constraint on agentic deployment has moved from what models can do to what organizations can defend. Several of the questions cannot be answered at all on infrastructure you do not control." banner: "" thumbnail: "" linkedin: | Google Cloud published 20 questions every organization should answer before deploying production AI agents. Notice the shape of that. The largest cloud providers spend their announcements on capability — bigger context, faster inference, new modalities. A governance checklist is the opposite kind of document. It assumes the capability is adequate and asks whether you are ready to be accountable for it. When the vendor with the most to gain from faster adoption publishes a list of reasons to slow down, the constraint has moved. It is no longer what models can do. It is what organizations can defend. The uncomfortable part is that several questions on any serious version of this list are unanswerable on rented infrastructure: — What did the agent do, exactly, and can you reconstruct it a year from now? — What is the blast radius when it acts wrongly? — Which model version produced this output, and can you still run it? — Where did the data go during inference? These are not model questions. They are infrastructure questions. On a hosted API, the honest answer to most of them is "whatever our vendor retains, for as long as they retain it, on terms we did not write." Governance is often framed as a brake — the thing slowing deployment down. The framing is backwards. An organization that can answer those four questions can deploy agents into consequential workflows. One that cannot is limited to low-stakes pilots regardless of how good the model is. Governance is not the brake. It is the steering wheel — the reason you can go fast at all. #iblai #AIGovernance #AgenticAI #EnterpriseAI #CloudSecurity #Compliance --- ## The Short Answer **Google Cloud publishing a 20-question governance checklist instead of a capability announcement signals that the binding constraint on agentic AI has moved from model capability to organizational accountability. Several such questions — what the agent did, which model version produced it, where data went during inference — are unanswerable on rented infrastructure. On ibl.ai you own all the code and the data, model-agnostic and with no per-seat pricing.** The document is a maturity marker. The interesting part is which questions your architecture makes impossible to answer. ## Why does a governance checklist from a cloud provider matter? Because of who published it and what they usually publish. Hyperscalers compete on capability. Their announcements are about larger context windows, faster inference, and new modalities — all of which encourage adoption. A pre-deployment governance checklist encourages the opposite: it asks organizations to pause and establish controls first. When the party with the strongest commercial interest in faster adoption ships a list of reasons to be careful, that is evidence the failure mode has become common enough to be worth heading off. Vendors do not usually invent friction for their own funnel. ## What has actually changed about agentic deployment? The constraint moved from capability to accountability. Two years ago, the honest blocker was that models were not reliable enough for consequential workflows. That objection has weakened considerably. What replaced it is harder: an agent that takes actions creates obligations — to auditors, regulators, customers, and courts — that a chatbot answering questions never did. An agent that reads and replies is a search interface with better manners. An agent that files, transacts, provisions, or communicates on the organization's behalf is an actor whose actions the organization owns. The governance question is not whether it works, but whether you can explain what it did. ## Which governance questions can't be answered on rented infrastructure? This is the part a vendor checklist tends to leave implicit. Four questions have answers determined by architecture rather than policy:
Question On a hosted API Self-hosted
What did the agent do, exactly? Vendor's log retention Your logs, your retention
Which model version produced it? May be replaced silently Pinned until you change it
Where did data go at inference? Contractual assurance Never left the perimeter
What is the blast radius? Bounded by vendor controls Bounded by your network
Cost shape at 5,000 users Per seat, scales with headcount Usage-based or flat license
Three of the four are answered by where the runtime sits, not by which governance policy you adopt. A policy asserting requirements the architecture cannot satisfy documents an intention, not a control. ## Is governance really a brake on deployment? The framing is backwards, and it is the most useful thing to take from the checklist. An organization that can reconstruct what an agent did, pin the model version, and bound the blast radius can put agents into workflows that matter — payments, filings, customer communication, provisioning. One that cannot is confined to low-stakes pilots no matter how capable the model is. Governance is what makes speed survivable. The organizations moving fastest into consequential agentic work are not the ones that skipped these questions; they are the ones that answered them early enough that the answers stopped being blockers. [AI governance platforms](https://ibl.ai/blog/ai-governance-platforms-enterprise-guide-2026) covers the tooling side — model inventory, risk tiering aligned to the NIST AI RMF and EU AI Act, and the audit record — and [writing an AI governance policy](https://ibl.ai/blog/ai-governance-policy-writing-guide) covers the document itself. ## What should you do before your next agent goes to production? Answer the architecture questions first, because they constrain everything downstream: 1. **Decide where inference executes.** This determines what you can promise about data residency and what you can prove afterwards. 2. **Pin and record model versions.** Validation requires reproducing behavior; a silently upgraded model makes that impossible. 3. **Log tool calls, not just conversations.** The action is what creates obligation, so the tool call is the record that matters. 4. **Bound the blast radius in the network**, not only in the prompt. Guardrails in a system prompt are guidance; egress rules are enforcement. 5. **Know your cost shape before scale.** Per-seat licensing prices the org chart rather than the work — the arithmetic in [enterprise AI agent ROI](https://ibl.ai/blog/enterprise-ai-agents-roi-2026). ## Where ibl.ai fits ibl.ai is the agentic AI platform where **you own all the code and the data**. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with **no per-seat pricing** — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped. That architecture makes the hard questions answerable by construction: logs are yours, model versions are pinned by you, and inference data never crosses a boundary you do not control. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.