Si tu prototipo con Gemini ya está cerca de producción, no saltes a Vertex AI solo porque la palabra "producción" apareció en la conversación. Empieza suponiendo que Google AI Studio y Gemini Developer API siguen siendo la ruta correcta hasta que aparezca un requisito concreto que no puedan cubrir. Si el problema es cuota, facturación, propiedad del proyecto, acceso a modelos de pago, condiciones de uso de datos de pago o una integración backend normal, primero evalúa Developer API de pago.
La ruta de Gemini Enterprise Agent Platform y los servicios empresariales de Google Cloud tiene sentido cuando el bloqueo ya se llama IAM, política de organización, control regional o de datos, provisioned throughput, Model Garden, MLOps, red privada, revisión de seguridad, soporte empresarial, compras o compliance. La frase "AI Studio para prototipos y Vertex AI para producción" ayuda a orientarse, pero se queda corta porque borra la ruta intermedia.
Decide con tres rutas
| Qué te bloquea ahora | Ruta inicial | Por qué |
|---|---|---|
| Probar prompts, comportamiento del modelo, function calling, structured output o un prototipo backend. | Google AI Studio + Gemini Developer API. | Google coloca Developer API como la ruta de la mayoría de desarrolladores salvo que hagan falta controles empresariales específicos. |
| El prototipo funciona, pero faltan cuota, billing, propietario del proyecto, modelos de pago o términos de datos de pago. | Un proyecto de Gemini Developer API de pago. | Cambia el estado del proyecto sin convertir cada decisión en una migración empresarial. |
| No se puede lanzar sin IAM, org policy, controles regionales o de datos, throughput reservado, MLOps, Model Garden, VPC/security, soporte o compliance. | Gemini Enterprise Agent Platform / ruta empresarial de Google Cloud. | Esos requisitos pertenecen a gobierno de plataforma, no a una API key más seria. |
El error más común es tratar AI Studio como juguete y Vertex AI como la única respuesta para cualquier app real. Developer API de pago puede ser una ruta de producción válida cuando el equipo necesita billing, límites más altos, ownership del proyecto, collaborators, acceso a modelos de pago y términos de datos adecuados, pero no necesita todavía todo el stack empresarial.
El segundo error es creer que una clave creada en AI Studio prueba que la app ya está lista para producción. Una key demuestra autenticación. No demuestra billing correcto, límites reales, política de datos, endpoint, logging, retries, rollback ni gestión de secretos.
Separa los nombres por responsabilidad
No elijas por cómo suena el nombre. Elige por la superficie que asume cada responsabilidad.
| Nombre | Dueño práctico | Úsalo para | No lo confundas con |
|---|---|---|---|
| Google AI Studio | Interfaz web para probar Gemini, ajustar prompts, crear keys y revisar proyectos. | Pruebas rápidas, primeras llamadas, keys, visibilidad del proyecto. | Garantía de todos los modelos, regiones, cuotas o políticas de producción. |
| Gemini Developer API | Ruta directa de desarrollador en ai.google.dev. | La mayoría de integraciones, SDKs, backends y proyectos de pago sin controles empresariales. | IAM empresarial, residencia de datos, MLOps o red privada por sí sola. |
| Developer API de pago | La misma ruta Developer API con billing y comportamiento paid tier. | Presión normal de producción: cuota, billing, project ownership y paid data terms. | Sustituto de una arquitectura de compliance. |
| Vertex AI / plataforma empresarial | Ruta de Google Cloud, hoy cercana a Gemini Enterprise Agent Platform y servicios Cloud AI relacionados. | Gobierno, regiones/datos, throughput reservado, Model Garden, MLOps, soporte, compliance. | Respuesta automática para toda producción. |
| Gemini Enterprise app | Experiencia de aplicación empresarial para usuarios. | Conocimiento corporativo, acceso de usuarios empresariales y flujos internos. | Sinónimo de Developer API o de cada llamada Vertex AI. |
La documentación de migración de Gemini API describe dos API products: Gemini Developer API y Gemini Enterprise Agent Platform API. También dice que la mayoría de los desarrolladores debería usar Developer API salvo que necesite controles empresariales específicos. Esa idea debe estar en el centro de la decisión.
"Vertex AI" todavía aparece en materiales, conversaciones y tutoriales antiguos como shorthand de la parte empresarial. Es útil como palabra de reconocimiento. Pero no debe reemplazar la decisión real: Developer API primero, Developer API de pago para presión de producción común, plataforma empresarial cuando un control concreto sea obligatorio.
Quédate en Developer API cuando el trabajo siga siendo una app
Quédate en Google AI Studio y Gemini Developer API cuando el trabajo consista en construir, probar y operar una app Gemini normal sin obligaciones de plataforma empresarial.
Buenos casos para Developer API:
- probar prompts, response shape, structured output y function calling;
- integraciones backend pequeñas o medianas;
- uso del Google Gen AI SDK unificado;
- pruebas multimodales y validación de comportamiento de modelo;
- prototipos de equipo con propietario de proyecto conocido;
- servicios de bajo riesgo que caben en billing, quota, logging y data-use terms de Developer API;
- backends donde las keys viven en servidor o en un gestor de secretos.
La pregunta no es solo "prototipo o producción". La pregunta es qué riesgo falta resolver. Si el riesgo es cuota, billing, model row, retries, project owner o key restriction, todavía parece un problema de Developer API. Si el riesgo es org policy, data residency evidence, private connectivity o auditoría central, empieza a parecer una decisión de plataforma empresarial.
Separa los trabajos estrechos. Crear una key, guardarla, hacer la primera request o resolver preparación ante 403/429 pertenece a Google AI Studio API key setup. Ver si una fila de modelo sigue siendo gratis, cómo funcionan los límites de proyecto o cuándo activar billing pertenece a Gemini API free tier limits. La elección de plataforma debe concentrarse en owners, contratos operativos y umbrales de migración.
Evalúa Developer API de pago antes de migrar por presión vaga
Developer API de pago es la parte que muchas comparaciones de dos columnas pierden.
| Presión de producción | Developer API de pago puede bastar cuando... | La ruta empresarial importa cuando... |
|---|---|---|
| Billing | El equipo necesita paid project, budget owner y un uso mayor. | Billing debe alinearse con compras, contrato de soporte, descuentos o capacidad comprometida. |
| Cuota | La app necesita RPM, TPM, RPD o paid-tier behavior más altos. | Se requiere provisioned throughput, Cloud quota governance o soporte dedicado. |
| Uso de datos | Los paid Developer API terms bastan para revisión de datos. | Hacen falta residencia, retención, auditoría o compromisos contractuales. |
| Project ownership | Google Cloud project, collaborators, billing account y key restrictions bastan. | IAM, org policy, service accounts, network controls y security review central son obligatorios. |
| Acceso a modelos | El modelo necesario existe en Developer API. | Se necesita Model Garden, partner models, managed model platform o MLOps. |
La página de precios de Google separa Free, Paid y Enterprise. El punto estable no es copiar una tabla de precios que puede cambiar. El punto es entender qué significa cada tier. Free ayuda a desarrollar y probar, pero tiene una frontera de uso de datos para mejorar productos. Paid apunta a production applications con más volumen o features avanzadas y afirma que el contenido no se usa para mejorar productos. Enterprise apunta a soporte, seguridad/compliance, provisioned throughput, descuentos, MLOps y Model Garden.
La documentación de billing añade que rate limits, tiers, billing state y caps son realidades del proyecto o de la cuenta de facturación. Un proyecto puede pasar a paid setup sin convertir cada decisión técnica en una migración a Cloud enterprise.
Por eso "producción equivale a Vertex" es una mala regla. Nombra primero el blocker. Si es usage volume, billing, project ownership, paid model row o paid data-use boundary, Developer API de pago debería estar primero. Si es policy, residency, IAM, provisioned capacity o compliance evidence, la plataforma empresarial se vuelve relevante.
Migra cuando el control empresarial sea obligatorio
La migración empresarial es una decisión de controles. Las razones deben ser concretas.
| Disparador | Pregunta antes de migrar |
|---|---|
| IAM y org policy | ¿El acceso debe pasar por Cloud IAM, service accounts, org policy o revisión central? |
| Endpoint y región | ¿El workload requiere regional endpoint, global endpoint behavior o arquitectura por ubicación? |
| Residencia y retención de datos | ¿Existe un requisito escrito de residency, retention, logging o audit que Developer API no cubre? |
| Provisioned throughput | ¿El tráfico necesita capacidad reservada en lugar de tier movement y retries? |
| Model Garden y MLOps | ¿El equipo necesita managed model platform, evaluation pipelines, deployment governance o partner models? |
| Network y security controls | ¿La revisión exige VPC, private connectivity, logs centralizados o controles Cloud? |
| Soporte y compliance | ¿El comprador necesita enterprise support, contract review, workflow de compliance o procurement alignment? |
Ten cuidado con la palabra endpoint. La documentación de Google Cloud sobre locations describe regional y global endpoints, pero un endpoint no garantiza por sí mismo data residency ni procesamiento ML dentro de una región. Si la residencia importa, revisa la documentación específica de data residency. Si zero data retention importa, revisa la documentación de zero data retention y las acciones concretas del cliente.
Un decision brief de migración debe decir qué control se requiere, qué documento de Google lo posee, qué servicio, endpoint o configuración lo satisface y qué prueba aceptará seguridad o compliance. "Más enterprise" no basta.
Las API keys y el proyecto cambian la comparación antigua
Muchas explicaciones antiguas presentan AI Studio como una key personal simple y la ruta Cloud como la identidad seria. El comportamiento actual de las keys es más matizado.
La documentación de Gemini API key explica que las requests de Gemini API pueden autenticarse con standard API keys o authorization API keys. Las nuevas keys creadas en Google AI Studio son auth keys por defecto. La misma documentación dice que las unrestricted standard keys se rechazan después del 19 de junio de 2026 y que las standard keys deben migrarse antes de septiembre de 2026.
Eso no convierte AI Studio en plataforma empresarial. Significa que Developer API route es más project-aware que los resúmenes antiguos de "simple key". Cada key se asocia a un Google Cloud project, y el project maneja collaborators, permissions y billing context. Para muchos equipos eso basta, pero no reemplaza organization-wide IAM, Cloud network controls, residency architecture, retention policy ni MLOps governance.
| Pregunta | Respuesta de Developer API | Respuesta de plataforma empresarial |
|---|---|---|
| ¿Una project-owned key puede soportar una app backend? | Sí, si project, billing, limits, model y key restrictions encajan. | Sí, pero la razón de migrar debe ser un control más amplio. |
| ¿La key puede vivir en frontend code? | No. Debe estar server-side o en managed secrets. | Tampoco. Enterprise controls no hacen seguras las credenciales públicas. |
| ¿Una key demuestra production readiness? | No. Revisa billing, live limits, data policy, region y model access. | No. Revisa IAM, endpoints, residency, retention, support y rollout controls. |
| ¿Importan las fechas de junio y septiembre de 2026? | Sí, si aún quedan standard keys antiguas. | Sí, pero enterprise migration no debe ser atajo para mala higiene de keys. |
Checklist de migración práctica
Antes de mover un workload Gemini desde Developer API a la ruta empresarial, escribe un decision record corto.
- Nombra la ruta actual: AI Studio prototype, free Developer API project, paid Developer API project o existing Cloud enterprise route.
- Nombra el blocker: quota, billing, data-use policy, region, IAM, support, provisioned capacity, MLOps, Model Garden, compliance o procurement.
- Abre el owner doc: API keys, pricing, billing, rate limits, enterprise locations, data residency o zero retention.
- Decide si paid Developer API resuelve el blocker o si hace falta enterprise platform control.
- Construye un pilot pequeño con la misma model family, request shape, latency expectations, retry policy y logging boundary.
- Confirma cost owner, quota owner, data owner y support owner antes de mover tráfico.
- Mantén rollback simple: la ruta antigua de Developer API debe seguir callable hasta que la ruta empresarial pruebe comportamiento igual o mejor.
Ese record vale más que una feature matrix amplia. Un equipo que solo necesita quota y billing no debería absorber complejidad empresarial demasiado pronto. Un equipo que necesita data residency o provisioned throughput no debería seguir tratando una API key rápida como si fuera control suficiente.
Dónde resolver setup y quota
| Trabajo estrecho | Siguiente ruta |
|---|---|
| Crear una key, guardarla, hacer la primera request o revisar preparación ante 403/429. | Google AI Studio API key setup |
| Revisar free tier, project-level limits, 429, billing state o paid tier. | Gemini API free tier limits |
| Decidir si el workload necesita Cloud controls en lugar de producción normal con Developer API. | Usa la decisión de plataforma y el checklist de migración. |
La separación evita duplicación. Setup necesita comandos y recuperación de errores. Quota necesita revisar límites y precios vivos. Platform choice necesita owners, nombres correctos y umbrales de migración.
Preguntas frecuentes
¿Una app Gemini de producción debe usar Vertex AI?
No siempre. Muchas apps pueden empezar con Gemini Developer API. Un proyecto Developer API de pago puede cubrir billing, quota, project ownership, paid terms y backend integration. La ruta empresarial entra cuando IAM, data controls, provisioned throughput, MLOps, Model Garden, support, compliance o procurement son obligatorios.
¿Google AI Studio es solo para prototipos?
No. AI Studio es la superficie web para probar Gemini y crear o gestionar keys; Gemini Developer API puede seguir siendo la ruta de muchas aplicaciones después del prototipo. Lo importante es si el requisito pendiente es producción normal de app o control empresarial.
¿Gemini y Vertex AI son lo mismo?
No. Gemini models se usan desde varias superficies de Google. La ruta directa de desarrollador es Gemini Developer API. La ruta empresarial de Google Cloud se describe ahora alrededor de Gemini Enterprise Agent Platform y servicios Cloud AI relacionados; Vertex AI sigue como shorthand de esa parte.
¿Cuándo conviene pagar Developer API?
Cuando el bloqueo sea usage volume, billing, project ownership, paid model rows o paid data-use boundary. Esas señales suelen indicar que el prototipo debe convertirse en paid Developer API project, no en enterprise migration.
¿Cuándo vale la pena la plataforma empresarial?
Cuando el requisito nombra un control de plataforma: IAM, org policy, regional endpoint architecture, data residency, zero retention work, provisioned throughput, Model Garden, MLOps, private networking, enterprise support, compliance review o procurement structure.
¿Qué pasa con las AI Studio keys después de junio de 2026?
Las standard keys antiguas necesitan revisión. La documentación de Google dice que las unrestricted standard keys se rechazan después del 19 de junio de 2026 y que las standard keys deben migrarse antes de septiembre de 2026. Las nuevas AI Studio keys son auth keys por defecto.
¿Un regional endpoint garantiza data residency?
No. Endpoint location y data residency son controles distintos. Si residency importa, revisa data residency docs, supported location, request path, logging behavior y retention setup.
¿Se pueden mantener Developer API y la ruta empresarial a la vez?
Sí. Una migración por etapas suele ser más limpia. Developer API puede seguir para prototipos, workloads de bajo riesgo o rollback mientras un pilot empresarial prueba IAM, endpoint, data, throughput, logging, support y cost behavior.
