Cada ruta hacia un modelo de IA es ya un proveedor. Mapee su cadena antes de que lo haga un cambio de política

Pregunte a un arquitecto empresarial de dónde vienen los modelos de IA de su empresa y la respuesta suele ser una lista de nombres: OpenAI, Anthropic, Google, un par de modelos de pesos abiertos. Pregunte cómo llega realmente cada petición a un modelo y la respuesta se alarga. El modelo lo construyó una empresa, lo aloja otra, se compra en el marketplace de una tercera, lo enruta el gateway de una cuarta y lo envuelve el runtime de agentes de una quinta antes de que su aplicación lo vea.

Cada una de esas partes tiene ahora sus propias reglas, y esta semana tres de ellas las cambiaron.

• Los modelos de OpenAI llegan a Google Cloud, comprados en su marketplace contra compromisos existentes, con algunos controles de datos todavía “próximamente”.
• OpenAI anunció que, desde el 20 de noviembre, los servicios que ofrecen acceso directo a sus modelos, como routers y gateways de IA, necesitan su aprobación.
• ServiceNow lanzó en disponibilidad general un agente personal y anunció que la revocación de los permisos de un agente se aplicará en el runtime y, más adelante, en la tarjeta de red.

Leídas juntas, las tres noticias describen algo que las empresas aún no gestionan como tal: una cadena de suministro de modelos.

La cadena, capa por capa

Las partes entre su aplicación y un modelo

Su aplicación o agente

• Prompts, habilidades, memoria

Usted

Su capa de control

• Identidad, presupuestos, registros, política de enrutamiento

Usted, si construyó una

Gateway o router

• De terceros o interno

Puede necesitar la aprobación de quien hace el modelo

Marketplace y facturación

• Compromisos de nube, condiciones de reventa

Nube y runtime que lo alojan

• Región, retención de datos, computación confidencial

Quien hace el modelo

• Políticas de uso, versiones, fechas de retirada

Cada capa puede cambiar lo que usted recibe. Quien hace el modelo retira una versión o endurece una política. La nube ofrece un control más tarde que la API directa. El marketplace cambia cómo computan los compromisos. El gateway pierde la aprobación. El runtime añade un punto de control, o carece de él.

Por qué “proveedor” es la palabra adecuada

El sector financiero europeo ya sabe gestionar una cadena así; solo que todavía no la ha aplicado a los modelos. El Reglamento de resiliencia operativa digital, DORA, se aplica desde enero de 2025 a bancos, aseguradoras y gestoras de la UE, incluidas las españolas, y les exige gestionar el riesgo de sus proveedores de servicios tecnológicos durante toda la relación, con estrategias de salida y atención a la concentración. En Latinoamérica, cada supervisor financiero tiene sus propias reglas de externalización, pero la lógica es la misma. Un gateway que puede dejar de servir un modelo el día en que entra en vigor una política es exactamente el tipo de dependencia para el que se escribieron esas normas.

La mayoría de las empresas gestionan a quien hace el modelo como proveedor y tratan todo lo demás como fontanería. Esta semana demostró que la fontanería tiene sus propias reglas. Cuando OpenAI pide a los gateways que obtengan su aprobación, un router que su equipo eligió por comodidad se convierte en un proveedor con una dependencia relevante de la decisión de otro proveedor.

Cinco preguntas por ruta

Para cada carga en producción, registre la ruta, no solo el modelo, y responda a cinco preguntas:

1. ¿Quién puede cortarla? Enumere cada parte cuya decisión podría detener esa carga: quien hace el modelo, la nube, el marketplace, el gateway. Para cada una, ¿con cuánto preaviso?
2. ¿Qué condiciones de datos se aplican? La API directa, la vía de la nube y un router pueden tener condiciones de retención y tratamiento distintas para el mismo modelo. Indique cuál rige esa carga.
3. ¿Dónde se ejecuta la petición? La región y el alojamiento importan para la residencia de datos, sobre todo bajo el RGPD, y pueden variar según la vía, como ocurrió con el mismo modelo Claude en Azure y AWS.
4. ¿Cuál es la alternativa? Otra vía hacia el mismo modelo, u otro modelo que superó la misma evaluación. Una alternativa nunca probada es una esperanza.
5. ¿Dónde está la evidencia? Qué registro muestra qué ruta atendió cada petición, con modelo y versión. Sin él, el análisis de un incidente no puede reconstruir lo ocurrido.

Qué debería poseer en la cadena

El patrón del último año, que describimos en nuestro marco de portafolio de modelos, es que las empresas deben poseer las capas que les permiten cambiar de proveedor: conjuntos de evaluación, política de enrutamiento y el registro de qué se ejecutó dónde. La visión de cadena añade una más: la propia capa de control. Databricks construyó su propio gateway porque no podía gestionar el coste sin ver cada petición. Es en esa misma capa donde se ven las dependencias, se aplican las alternativas y se conserva la evidencia.

Los estándares de interfaz ayudan. La nueva especificación Open Responses de la Agentic AI Foundation, por ejemplo, busca que la llamada a un modelo sea igual entre proveedores. Una interfaz común abarata cambiar de ruta. No le dice de qué rutas depende. Solo un mapa lo hace.

Nuestra expectativa, y es una opinión y no un hecho, es que el año que viene las rutas hacia los modelos aparezcan en los inventarios de riesgo de terceros junto a los proveedores de nube, con las mismas preguntas sobre concentración, salida y preaviso. Las empresas que dibujen el mapa ahora encontrarán esa conversación breve.