ForgeNEX

Open Responses llega a la AAIF: menos ataduras entre proveedores de IA

OpenAI dona su especificación Open Responses a la Agentic AI Foundation para estandarizar las llamadas a modelos. Analizamos qué supone para una pyme.

4 min de lectura

En este artículo

La fragmentación de las API de modelos de lenguaje es uno de esos problemas que no aparece en las presentaciones comerciales, pero que consume horas de trabajo en cualquier equipo técnico. OpenAI ha decidido mover ficha: dona su especificación Open Responses a la Agentic AI Foundation (AAIF), el paraguas impulsado dentro de la Linux Foundation que ya alberga proyectos como MCP, A2A, AGENTS.md, goose, agentgateway o Agent Router. La noticia la adelantó The New Stack y, más allá del titular, tiene lecturas muy concretas para quien desarrolla o mantiene software en una pyme.

Qué es Open Responses y por qué importa

La idea de fondo es sencilla de explicar y complicada de ejecutar: casi todos los proveedores de LLM ofrecen ya los mismos bloques básicos (mensajes, llamadas a herramientas, function calling, etc.), pero cada uno los representa a su manera en su API. El resultado es que cambiar de modelo implica reescribir integraciones, mantener adaptadores por proveedor y asumir que una parte del código quedará atada a un vendor concreto.

Open Responses propone un conjunto de llamadas API comunes que funcionen entre proveedores. No es un modelo ni un producto: es una especificación. Y ese matiz es clave, porque su valor depende de que la adopten cuantos más actores mejor.

Detalle ilustrativo: OpenAI donates Open Responses, its spec for a common LLM API, to the Agentic AI Foundation

Quién la apoya y quién se queda fuera

El respaldo inicial es amplio. Según la información publicada, ya hay implementaciones o apoyo declarado de AWS (en Bedrock), Databricks, LM Studio, Ollama, Hugging Face, Nvidia, OpenRouter, Red Hat, Vercel, además de proyectos open source como vLLM y OGC (antes Llama Stack). Vercel AI Gateway y Databricks Model Serving ya la implementan, lo que da una señal práctica: no es solo una declaración de intenciones.

Las ausencias también dicen mucho. Anthropic, rival directo de OpenAI, mantiene su propia Messages API, y Google tiene su Interactions API. Anthropic es miembro de la AAIF, así que la puerta queda abierta a una adopción futura, pero hoy no está en la lista. La propia guía de contribución del proyecto reconoce que los esquemas centrales se copiaron de la API de OpenAI, algo que conviene tener presente: la especificación nace con ADN de un proveedor concreto, aunque su gobernanza pase a una fundación neutral.

El detalle que muchas pymes pasan por alto

Hay un matiz que merece la pena subrayar: el ecosistema se ha bifurcado. La Chat Completions API de OpenAI se convirtió en referencia temprana, pero la Messages API de Anthropic ha ganado peso, en buena parte por el tirón de Claude Code, y ya hay proveedores como DeepSeek, Moonshot, Z.ai o MiniMax que exponen endpoints compatibles con Anthropic. Es decir, hay dos linajes conviviendo. Precisamente esa fractura es la que una especificación neutral como Open Responses aspira a corregir.

Para una pyme, la consecuencia práctica no es inmediata, pero sí estratégica. Si tu producto o tus automatizaciones dependen de un único proveedor, cualquier cambio de precio, de cuota o de modelo te obliga a tocar código. Si la capa de integración se apoya en un estándar, el cambio se reduce a configuración. La diferencia entre una cosa y otra se mide en días de desarrollo y en riesgo operativo.

Qué recomendamos desde ForgeNEX

  • Separa la lógica de negocio de la llamada al modelo. Aunque hoy uses un solo proveedor, encapsula las llamadas detrás de una capa propia. Si Open Responses se consolida, esa capa será más fina; si no, te habrá salvado igualmente.
  • No reescribas nada por la noticia. La especificación es joven y su gobernanza acaba de arrancar. Adoptarla tiene sentido en proyectos nuevos o en refactorizaciones planificadas, no como migración urgente.
  • Vigila a Anthropic y Google. La utilidad real del estándar depende de que los grandes se sumen. Si siguen fuera, seguiremos con adaptadores por proveedor.
  • Aprovecha para revisar costes y dependencias. Es un buen momento para inventariar qué modelos usas, dónde y con qué criticidad. Muchas pymes descubren en este ejercicio que tienen más integraciones de las que creían.

Este movimiento encaja con una tendencia que ya venimos observando: la IA deja de ser un experimento aislado y entra en la arquitectura. Lo contamos al hablar de automatización de procesos con n8n e IA y también al comparar Claude, GPT y Gemini. En ambos casos, la conclusión era la misma: la portabilidad vale dinero.

La letra pequeña de la neutralidad

Que la AAIF sea parte de la Linux Foundation aporta algo que un proveedor solo no puede dar: un hogar neutral donde desarrollar la especificación en común. El comité técnico de la fundación estará formado inicialmente por los mantenedores de los proyectos, lo que en la práctica significa que quienes más han contribuido tendrán más peso en las decisiones. Es razonable, pero conviene no confundir neutralidad de gobernanza con neutralidad técnica: el punto de partida son los esquemas de OpenAI y eso marcará el diseño durante un tiempo.

Para un equipo de IT de pyme, la lectura sensata es esta: bienvenida sea cualquier iniciativa que reduzca el trabajo de integración, pero no apostemos la arquitectura a que el estándar triunfe. Diseñemos como si fuéramos a cambiar de proveedor mañana, porque probablemente lo hagamos. Y si Open Responses acaba siendo el denominador común, mejor para todos: menos código pegado al vendor y más tiempo dedicado a lo que de verdad diferencia a un negocio.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.

Sigue leyendo