Production AI Starts Beyond the Model

A working AI model is not production-ready until identity, spend, capacity, observability, permissions, and rollback are controlled.

AI production-readiness concept with identity, secrets, spend, capacity, observability, tool permissions, and escalation or rollback.
Original Netics editorial illustration.

Source: Google Cloud: 10 questions every startup should answer before moving to production with their AI prototype

TL;DR

A working demo proves that a model can produce a useful result. Production readiness proves that the team can control who calls it, what it can access, how much it can cost, how it behaves under capacity pressure, and how the deployment can be stopped or reversed. Google’s current prototype-to-production guidance is structured around Onboard, Scale, and Govern.[1] A seven-question readiness test turns each control into evidence a reviewer can check, and a founder or CTO can run a first pass in about 30 minutes. A convincing answer is not operational control. Netics’ position is simpler: if nobody owns the boundary, the prototype is still a demo.

A convincing answer is not operational control

The most dangerous sentence in an AI project is often “the model works.” It compresses several different questions into one positive signal:

  • Who can invoke it?
  • Which identity does it use?
  • What happens when demand exceeds quota?
  • Who sees the logs?
  • Can a tool take an action without approval?
  • What is the spending limit?
  • How do we roll it back?

Google’s source is useful because it refuses to treat the transition as a single deployment command. It groups ten questions into Onboard, Scale, and Govern, and explicitly says the scope is the prototype-to-production transition rather than the complete data, RAG, CI/CD, and network architecture.[1]

That limitation is important. A checklist is valuable when it defines its boundary. It becomes dangerous when teams mistake it for the entire operating model.

The Netics control boundary — technical controls

Netics treats production readiness as seven connected controls.

AI production-readiness gate covering identity, secrets, spend, capacity, observability, tool permissions, and escalation or rollback.
Production readiness requires evidence across seven operating controls.

1. Identity

The prototype may begin with an API key. Google’s guidance distinguishes that local convenience from production authentication based on IAM, service accounts, and short-lived credentials.[1] The production question is not whether the key works. It is whether the running workload has an identity that can be limited, rotated, and attributed.

2. Secrets

A credential that reaches a client bundle, public repository, shared chat, or unmanaged server is already outside its intended boundary. The migration trigger is exposure risk, not a particular team size.

3. Spend

An AI feature that can call a model without a visible budget is not production-ready. Google’s Antigravity enterprise announcement describes project-level budget caps, pooled quotas, overage controls, and centralized usage metrics for eligible subscriptions.[2] Those are useful mechanisms, but the durable rule is vendor-neutral: name the owner, cap the spend, and make the alert actionable.

4. Capacity

HTTP 429 responses are not just an inconvenience. They test whether the system has a capacity strategy. Google discusses quota ceilings, global versus regional routing, and retry with exponential backoff in its production guidance.[1] A readiness review should ask what the service does during a quota failure and whether the answer is retry, degrade, queue, or stop.

The Netics control boundary — operational controls

The remaining controls determine whether the service can be observed, constrained, escalated, and reversed.

5. Observability

Logs must show enough to investigate a failure without becoming an uncontrolled data dump. Google’s enterprise material emphasizes centralized audit logging for prompts, agent responses, and metadata, while the startup guidance separates Cloud Logging and Monitoring from the prototype path.[1][2] The Netics question is: can the owner reconstruct what happened, under the organization’s data rules?

6. Tool permissions and agent behavior

An agent can turn a model-quality success into an operational failure if its tools, browser, MCP server, or external APIs are too broad. Google’s Antigravity announcement names sandboxing and browser/MCP server access as configurable security-policy areas for eligible enterprise use.[2] The general lesson is broader than the product: model access and action authority are different controls.

7. Human escalation and rollback

The team needs a defined response when the model is uncertain, a tool asks for more access, spend crosses a threshold, or an output reaches a sensitive workflow. A stop button is not a rollback plan. A rollback plan names the owner, the trigger, the previous version, and the data or side effects that cannot be undone.

The seven-question readiness test

Before inviting real users, answer each question with evidence:

Flow from a working model to an operated service with identity, spend, observability, and rollback evidence.
A successful model response is only one input to production readiness.
GateEvidence a reviewer should see
IdentityWorkload identity, role scope, rotation path
SecretsNo production key in code, client bundle, or shared file
SpendBudget owner, cap, alert, and escalation path
CapacityQuota view, retry/backoff test, degradation behavior
ObservabilityUseful logs, retention rule, access owner
PermissionsTool inventory, minimum scopes, approval path
RollbackVersion rollback, kill switch, side-effect procedure

A “yes” without evidence is an intention, not a control.

What this position does not claim

Not every prototype needs the same platform. A low-risk internal experiment with no external users and disposable data may not require a large enterprise surface on day one. Google’s own source says AI Studio is the appropriate starting point for many ideas.[1]

The claim is narrower: the control boundary must grow with exposure. Do not use a working model as evidence that identity, spend, capacity, tools, and rollback are solved.

For the permission side of the same argument, see why AI agents need controlled access before another cloud platform.

The smallest 30-minute review

A founder or CTO can assemble a useful evidence pack in half an hour:

  1. Draw the request path from user to model to tools.
  2. Identify every credential and its owner.
  3. Show the current spend limit and alert destination.
  4. Trigger or simulate a quota failure.
  5. List the logs that would explain the last request.
  6. Remove one tool permission and test graceful degradation.
  7. Name the person who can stop the feature.

If the team cannot complete this review, the problem is not necessarily that the model is immature. It is that the operating boundary is undefined.

Netics’ conclusion

Production-ready is not a model-quality adjective. It is a control boundary. The model must be useful, but usefulness does not cap spend, narrow identity, survive quota pressure, constrain tools, or create a rollback path.

If nobody owns those decisions, the prototype is still a demo—no matter how impressive the answer looks.

Sources

[1] Google Cloud: 10 questions every startup should answer before moving to production with their AI prototype

[2] Google Cloud: Expanding Google Antigravity for enterprise customers

Book a free 30-minute audit

Source: Google Cloud: 10 questions every startup should answer before moving to production with their AI prototype — cloud.google.com, 2026-08-21

Explore Netics for practical infrastructure and AI operations guidance.