Google acaba de integrar más de 200 modelos, incluido Claude, en una sola plataforma de agentes. Se acabó la dependencia de un único modelo.

Hace dos años, adquirir una "plataforma de IA empresarial" significaba elegir el modelo de un único proveedor y desarrollar todo detrás de su API. La apuesta que hacías el primer día era la apuesta con la que te quedabas. Esa definición acaba de desmoronarse. Google, el tercer proveedor de nube más grande del mundo, ahora ofrece una plataforma de agentes con más de 200 modelos disponibles de forma nativa, y el modelo de frontera de un competidor directo se encuentra ahí mismo en el catálogo, justo al lado del suyo propio. Ser agnóstico respecto al modelo ya no es la postura disidente. Es el producto en sí.

Este cambio se hizo evidente en el Google Cloud Next 2026, celebrado del 22 al 24 de abril en el Mandalay Bay de Las Vegas, donde Google realizó 260 anuncios de productos a lo largo de tres ponencias principales ante aproximadamente 32.000 asistentes. La gran noticia para los compradores empresariales no fue un modelo más potente. Fue un replanteamiento más profundo sobre la arquitectura.

Lo que Google ha consolidado realmente

Google ha integrado Vertex AI en una oferta unificada llamada Gemini Enterprise Agent Platform. Según el propio anuncio de Google, "todos los servicios y evoluciones de la hoja de ruta de Vertex AI se ofrecerán exclusivamente a través de la Agent Platform, en lugar de como un servicio independiente". La API de modelo independiente ha desaparecido. Ahora, todo pasa por una capa de agentes.

La plataforma ofrece a los desarrolladores un acceso de primer nivel a más de 200 modelos a través de Model Garden. Esta lista abarca las propias familias Gemini y Gemma de Google, modelos abiertos como Llama y modelos de frontera de terceros. Google afirma claramente que los clientes disponen de "soporte para modelos de terceros como Claude Opus, Sonnet y Haiku de Anthropic". La familia Claude de Anthropic se ejecuta de forma nativa dentro del mismo catálogo que Gemini, facturándose y gestionándose como una API serverless, sin necesidad de aprovisionar infraestructura independiente.

He aquí el antes y el después, en términos sencillos.

Los elementos que rodean a los modelos importan tanto como el número de estos. Dispone de un servidor MCP remoto gestionado, ahora disponible de forma general, para que los agentes puedan acceder a herramientas y datos externos sin necesidad de conexiones a medida. Hay un agente para navegación web, Project Mariner, que opera en sandboxes en la nube. Y está el protocolo Agent2Agent, que Google y sus socios describen como operativo en producción y no en fase piloto, con 150 organizaciones enrutando tareas reales entre agentes creados en diferentes plataformas. (Hemos analizado A2A y MCP a fondo por separado; el punto aquí es más concreto).

Lo relevante aquí es lo que este catálogo dice acerca de la estrategia.

Por qué incluir a Claude en el catálogo de Google es la verdadera señal

Que un proveedor de nube incluya un modelo de frontera de un tercero dentro de su plataforma de agentes insignia no es un detalle menor. Es una admisión clara de cómo compran realmente las empresas hoy en día.

A Google le gustaría que utilizaras Gemini de extremo a extremo. Su propuesta de valor es la integración vertical, desde las TPUs de octava generación hasta el entorno de ejecución de agentes. Sin embargo, el mismo lanzamiento convierte a Claude en un elemento de primer nivel, porque los clientes corporativos que Google persigue ya han decidido que quieren opciones en la capa del modelo. Cuando la empresa con más incentivos para imponer un único modelo ofrece 200, la tesis del modelo único queda descartada como estándar.

Esto se alinea con lo que las empresas ya venían haciendo. Como explicamos en por qué un único modelo no puede adaptarse a todas las empresas, la respuesta honesta a "¿qué modelo utilizas?" en la mayoría de las grandes organizaciones es "todos". Distintas tareas requieren diferentes modelos. Un paso de suscripción de seguros que requiere un razonamiento complejo y una tarea de clasificación de alto volumen no tienen por qué compartir el mismo motor; de hecho, ni el coste ni la latencia lo justificarían.

Es conveniente precisar por qué se trata de una concesión estratégica y no de mera generosidad. Google factura el uso de Claude de la misma forma que factura Gemini, por lo que albergar a un rival tiene lógica comercial. Pero la verdadera razón es la retención. Una empresa que tenga que salir de Google Cloud para utilizar Claude es una empresa que podría terminar migrando el resto de su infraestructura. Mantener el modelo rival dentro de la plataforma retiene al cliente. Esto solo tiene sentido si el cliente iba a exigir ese modelo competidor de todos modos, que es precisamente el fondo de la cuestión.

Qué significa esto si ya estás utilizando Vertex AI

Si tu equipo ha desarrollado sobre Vertex AI, lo primero que debes saber es que no se va a cerrar, sino que se va a integrar. La postura de Google es que los servicios de Vertex continúan, ofreciéndose a través de la Agent Platform en lugar de como un producto independiente. Tus llamadas a modelos existentes no dejarán de funcionar de la noche a la mañana.

Lo que cambia es la unidad de aprovisionamiento y arquitectura. Lo que despliegas ahora es un agente con una política de enrutamiento, no un endpoint de modelo básico. Para la mayoría de los equipos de desarrollo, esto representa un cambio de código menor de lo que parece, pero un cambio mental mucho mayor. La llamada de inferencia te resultará familiar. Lo que queda obsoleto son las asunciones tradicionales: que "el modelo" es el proyecto, que se elige una sola vez y que el despliegue consiste en un modelo detrás de un endpoint.

El movimiento práctico es aprovechar esta consolidación como una oportunidad para separar dos decisiones que quizás estabas unificando en una sola: qué modelo ejecuta una acción concreta y qué gobierna al agente que lo invoca. Google acaba de hacer que la primera decisión sea económica y reversible. La segunda decisión, la gobernanza y la orquestación, es donde ahora se concentra el verdadero trabajo.

Los números detrás del movimiento

El contexto del mercado explica por qué Google ha reorganizado toda su suite de IA en torno a agentes en lugar de chats. Gartner predice que el 40% de las aplicaciones empresariales contarán con agentes de IA específicos para tareas a finales de 2026, frente a menos del 5% en 2025. Se trata de un incremento de ocho veces en aproximadamente un año, y las plataformas se construyen mirando hacia dónde se dirige la demanda, no donde se encuentra actualmente.

El valor económico en juego es la otra mitad de la historia. McKinsey estima que la IA generativa podría aportar entre 2,6 y 4,4 billones de dólares en beneficios económicos anuales en 63 casos de uso. Capturar una parte de ese valor no vendrá de que un único modelo sea ligeramente mejor. Vendrá de lograr que múltiples modelos colaboren de forma útil, fiable y segura dentro de procesos de negocio reales. Una plataforma adaptada para agentes en lugar de un único modelo es una apuesta directa por esto, y es una dirección en la que todo el mercado avanza al unísono.

(Si prefieres recibir este tipo de análisis estratégicos en tu bandeja de entrada en lugar de revisar resúmenes de ponencias, enviamos un boletín semanal sobre hacia dónde se dirige realmente la IA empresarial).

Cómo cambia esto tu estrategia de compra

El cálculo del bloqueo de proveedor (lock-in) ha dado un giro radical. Hace un año, estandarizar en un solo modelo parecía una decisión disciplinada. Hoy en día parece un riesgo, porque la frontera de la innovación se desplaza cada pocos meses y el proveedor por el que apostaste puede no liderar la siguiente comparativa de rendimiento. Anthropic, OpenAI y Google se intercambian el primer puesto con tal frecuencia que apostar toda tu infraestructura a uno solo de ellos es jugar en contra de tu propia flexibilidad.

La unidad de arquitectura también ha evolucionado. El elemento central ya no es el modelo, sino una capa de orquestación que determina qué modelo gestiona cada paso. La propia reestructuración de Google lo confirma: la API del modelo ha pasado a ser un subcomponente de una plataforma de agentes. Como señalamos en el caso de la orquestación multimodelo, el modelo es ahora una decisión de enrutamiento, no un compromiso fundacional.

Un ejemplo práctico de la capa de enrutamiento

Pensemos en un flujo de tramitación de siniestros de seguros. El paso que analiza las notas complejas de un perito y determina si apuntan a un posible fraude requiere un alto razonamiento y se realiza a bajo volumen; se beneficia de un modelo de frontera avanzado, y vale la pena pagar su coste premium. Por otro lado, la clasificación de cincuenta mil documentos recibidos al día según su tipo es una tarea de alto volumen y crítica en latencia; ejecutarla en un modelo de frontera avanzado sería un desperdicio de presupuesto y de tiempo de procesamiento. Un mismo flujo, dos pasos, dos modelos distintos. Esto solo funciona si existe una entidad superior que dirija cada paso al modelo óptimo. Esa entidad es la capa de orquestación, y es el motivo por el cual el modelo se convierte en una decisión de enrutamiento dinámico en lugar de un compromiso rígido con una plataforma.

Además, la interoperabilidad está pasando a ser un requisito mínimo indispensable. Con la puesta en producción de A2A y los servidores MCP gestionados, se asume que los agentes deben comunicarse entre diferentes plataformas y proveedores. Un agente que solo pueda interactuar con agentes de su mismo proveedor resultará tan obsoleto como un software que no pudiera leer los formatos de archivo de la competencia.

Tres conclusiones clave para quienes toman las decisiones de compra:

• No estandarices sobre un modelo. Estandariza sobre una capa de enrutamiento. Es poco probable que el modelo que elijas hoy sea el que desees utilizar dentro de doce meses. Las arquitecturas que contemplan la flexibilidad de intercambio sobrevivirán. Las que acoplan de forma rígida un solo modelo, no.

• Exige el soporte de modelos de terceros como un requisito básico. Desde el momento en que Google ofrece Claude en su propia plataforma, el soporte a múltiples proveedores deja de ser un factor de diferenciación y pasa a ser el estándar mínimo aceptable.

• Prioriza la interoperabilidad en la evaluación. Los grandes proveedores ya están ofreciendo protocolos de comunicación entre agentes listos para producción. Desarrolla para un ecosistema donde tus agentes colaboren con sistemas fuera de tu control directo.

Esta es la visión de consenso actual, no una postura minoritaria

Durante un tiempo, apostar por una arquitectura agnóstica al modelo y centrada en la orquestación era una postura que había que defender activamente. Es la filosofía bajo la cual diseñamos ModelMesh de Beam: dirigir cada tarea al modelo óptimo, mantener la capa de orquestación por encima de cualquier proveedor e interactuar con los modelos como piezas intercambiables en lugar de como cimientos inamovibles. Nuestra plataforma está diseñada para ser agnóstica por definición, con Claude, Gemini y otros modelos disponibles bajo una única capa de enrutamiento uniforme.

Cuando comenzamos a defender esta visión, se interpretaba como una simple cobertura frente al riesgo de dependencia de un proveedor. Tras el Google Cloud Next 2026, queda claro que es la dirección en la que avanza todo el sector tecnológico. Uno de los mayores proveedores de infraestructura del mercado ha convertido la interoperabilidad multimodelo y entre agentes en la postura predeterminada de su plataforma de agentes de referencia. El debate sobre si las empresas deben vincularse a un solo modelo está cerrado. Los retos cruciales ahora se centran en cómo enrutar, gobernar y orquestar a través de múltiples opciones de manera eficiente.

Y ese es un escenario mucho más estimulante. Significa que el valor competitivo ha pasado de la mera selección del modelo a la madurez con la que eres capaz de estructurar tus sistemas en torno a todos ellos.