OpenAI quiere aprobar los gateways de IA que ofrecen sus modelos. Compruebe si el suyo cuenta antes del 20/11

En el último año, el gateway de IA se ha convertido en la caja más útil del diagrama de arquitectura. Envía cada petición al modelo capaz más barato, aplica presupuestos, registra cada llamada y permite al equipo de plataforma cambiar de proveedor sin tocar las aplicaciones. A partir del 20 de noviembre, para los modelos de OpenAI, puede necesitar además el permiso de OpenAI.

En un texto del 21 de octubre, OpenAI anunció que actualiza sus Usage Policies, con efecto el 20 de noviembre de 2026, y que la actualización amplía su trabajo de seguridad “al exigir que los servicios que ofrecen acceso directo a nuestros modelos, como model routers o gateways de IA, obtengan nuestra revisión y aprobación antes de ofrecer ese acceso”.

El mismo día, OpenAI y Google Cloud anunciaron que los modelos de OpenAI llegan al Model Garden de Google Cloud. Los dos anuncios van juntos. OpenAI multiplica los lugares donde se pueden comprar sus modelos y, a la vez, endurece quién puede revenderlos.

Qué dijo realmente OpenAI

El texto es breve, y sus compromisos principales son estos:

• Las políticas se aplican tanto si se accede a los modelos directamente como a través de socios que los alojan o de revendedores.
• Los socios que ofrecen acceso deben mantener salvaguardas coherentes con las de OpenAI, investigar posibles infracciones y actuar, y coordinar la aplicación de las normas para que una restricción en un sitio se mantenga en los demás.
• Los servicios que ofrecen acceso directo, “como model routers o gateways de IA”, necesitan la revisión y aprobación de OpenAI antes de ofrecerlo.
• OpenAI trabaja con clientes para introducir los SafetyIDs, identificadores que el cliente puede enviar para que OpenAI distinga a usuarios finales en una investigación sin conocer su identidad.

Es una política contractual de un proveedor, no una regulación. No procede del Reglamento de IA de la UE ni de ninguna autoridad: obliga a quien acepta las condiciones de OpenAI, directamente o a través de un socio. Y, por ahora, es una declaración de intenciones: el texto no publica el proceso de aprobación, los criterios ni posibles excepciones.

Dónde cae probablemente la línea, y dónde no está claro

Tres configuraciones habituales se leen de forma muy distinta frente a esa frase.

Un router o agregador comercial que vende acceso a muchos modelos, entre ellos los de OpenAI, a cualquiera con una tarjeta de crédito. Es la lectura más directa de “servicios que ofrecen acceso directo”. Si sus equipos usan uno, su estado de aprobación pasa a ser una dependencia de su arquitectura.

Un software que expone acceso en bruto al modelo a sus propios clientes, por ejemplo una plataforma que deja elegir “GPT” en un menú y enviar cualquier prompt. Si eso es “acceso directo” o un producto construido sobre un modelo es justo el tipo de duda que el texto no resuelve.

Un gateway empresarial interno que enruta las peticiones de sus propios empleados y aplicaciones. La mayoría de las empresas montó uno por coste y control, y ya defendimos que el gateway se está convirtiendo en un punto de aplicación de políticas, no en un proxy. El texto no dice si OpenAI considera un gateway interno como un servicio que “ofrece ese acceso”. No dé por hecha ninguna respuesta. Pregunte a su equipo de cuenta y obtenga la respuesta por escrito antes del 20 de noviembre.

Por qué importa aunque usted quede claramente fuera

Su estrategia de enrutamiento depende ahora de las condiciones de distribución de cada proveedor. El enrutamiento entre varios proveedores supone que puede enviar cualquier petición a cualquier modelo que tenga licenciado. Si un proveedor restringe qué intermediarios pueden servir sus modelos, un router que pierde la aprobación deja de servir ese modelo, y su plan de contingencia debe cubrirlo.

Los canales aprobados se multiplicarán, y no son idénticos. A los modelos de OpenAI ya se llega directamente, a través de Microsoft, con compromisos de Oracle, con Bedrock Managed Agents de AWS en vista previa y, pronto, a través de Google Cloud. Cada uno es una vía aprobada con sus propios controles y plazos. Un router sin aprobación es una vía que puede cerrarse. Su inventario de modelos debe indicar qué vía usa cada carga, como sugerimos en nuestro análisis de la llegada de OpenAI a Google Cloud.

La identidad por usuario en el gateway deja de ser opcional. Los SafetyIDs existen porque un proveedor que investiga un abuso a través de una clave de API compartida ve a un cliente, no a la persona que causó el problema. La alternativa de OpenAI a esa ambigüedad es restringir la clave entera. Un gateway que transmite un identificador de usuario estable y seudonimizado permite que la investigación apunte a un usuario y no a toda la aplicación. Es una buena práctica para su propio registro de auditoría en cualquier caso; Databricks, por ejemplo, permite que las políticas del gateway lean el contexto de la petición que aporta quien llama.

Antes del 20 de noviembre

1. Enumere todas las vías por las que su empresa llega a los modelos de OpenAI: API directa, marketplaces de nube, routers y herramientas SaaS que llaman a OpenAI por debajo. El último grupo suele ser el más largo.
2. Pregunte a cada proveedor de router y de plataforma de IA si ha solicitado o recibido la aprobación de OpenAI, y qué ocurre con su tráfico si no la tiene el 20 de noviembre.
3. Pregunte a OpenAI o a su revendedor si su gateway interno entra en el alcance, y deje constancia de la respuesta.
4. Añada una cláusula de continuidad a los contratos de router: aviso si el proveedor pierde el acceso a un modelo, y una alternativa definida.
5. Transmita un identificador seudonimizado del usuario final a través del gateway a todo proveedor que lo acepte, para que una investigación de abuso se detenga en un usuario y no en su aplicación.

Nada de esto es motivo para abandonar los gateways. Es motivo para tratar el gateway como lo que ya es: una parte contractual de su cadena de suministro de modelos, no solo fontanería.