Compras, y no un benchmark, puede decidir su arquitectura de IA. OpenAI convierte el contrato en moneda

Pregunte a un arquitecto cómo se eligió la plataforma de agentes de atención al cliente y hablará de funcionalidades, integraciones y una prueba comparativa. Pregunte al responsable de compras y quizá la respuesta sea otra: qué proveedor ya estaba homologado, cuál había superado la revisión de seguridad y qué compra podía pagarse con un presupuesto ya comprometido. Esa segunda respuesta va a pesar cada vez más.

Qué ha lanzado OpenAI

En su DevDay del 29 de septiembre, OpenAI anunció un marketplace en el que los clientes empresariales elegibles pueden aplicar parte de su compromiso de gasto con OpenAI a software de socios aprobados. Los 32 primeros socios incluyen Figma para trabajo creativo; Adobe, Sierra, Decagon, HubSpot, Salesforce y ServiceNow para experiencia de cliente; Harvey y Legora para el área legal; Palo Alto Networks y CrowdStrike para ciberseguridad; y Baseten para modelos de código abierto. Por ahora, los clientes empresariales pueden registrar su interés.

Los socios han empezado a explicarlo desde su lado. Decagon, que desarrolla agentes de IA de atención al cliente, dijo el 2 de octubre que los clientes empresariales elegibles de OpenAI pueden destinar parte de su compromiso a Decagon, reduciendo la fricción de compras que suele frenar los despliegues de IA.

Lo que todavía no es público también importa. Ni el anuncio de OpenAI ni los textos de los socios aclaran quién es elegible, qué parte del compromiso puede redirigirse, cómo queda el precio frente a la compra directa ni si el programa se aplica a contratos firmados en España o en Latinoamérica. Trate la descripción de los socios como su punto de vista, no como las condiciones del programa.

El patrón ya existe, y ya condiciona arquitecturas

Quien compra nube reconocerá el mecanismo. Con un Microsoft Azure Consumption Commitment, las compras de ofertas marcadas como “Azure benefit eligible” en el marketplace computan para el compromiso, y Microsoft indica que cuenta el 100% del importe antes de impuestos. AWS aplica una lógica parecida desde hace años. El efecto es conocido: cuando dos productos están igualados, gana el que consume un compromiso existente.

La arquitectura aparece en la letra pequeña. La propia documentación de Microsoft dice que el beneficio solo se aplica a licencias usadas exclusivamente en Azure; una licencia desplegada en local o en un entorno híbrido no computa. Una regla comercial decide, sin hacer ruido, dónde se ejecuta el software. Es razonable esperar condiciones parecidas en los marketplaces de IA vinculados a compromisos.

Qué cambia en la decisión de construir o comprar

1. ¿Encaja en el proceso?
2. ¿Supera nuestra revisión de seguridad?
3. ¿Puede consumir un compromiso?
4. ¿Cuánto cuesta salir?
5. Decisión

Encaje técnico y de negocioRiesgo que el marketplace no transfiere

La velocidad de compra se convierte en ventaja real. Una compra que se apoya en un contrato marco existente se cierra en semanas, no en trimestres. Para un equipo con un caso de uso urgente, eso puede pesar más que unos puntos de calidad. En Latinoamérica, donde contratar a un proveedor extranjero nuevo implica pagos en dólares y trámites de pago al exterior, evitar un contrato adicional tiene un valor añadido, aunque conviene confirmar cómo se facturan las compras del marketplace.

Los compromisos generan gravedad. Cada dólar redirigido a un socio en el marketplace de un proveedor de modelos aumenta la dependencia de su ecosistema, justo cuando enrutar entre proveedores se ha convertido en buena práctica. En nuestro artículo sobre el harness de IA defendimos que la identidad, las definiciones de negocio, la evaluación y el registro de agentes deben ser de la empresa, una sola vez y por encima de los proveedores. Las compras pagadas con compromisos lo hacen más importante.

La proliferación de agentes estrena una nueva vía de entrada. Si las unidades de negocio pueden comprar agentes de un catálogo aprobado con dinero ya comprometido, aparecerán más agentes y más deprisa. Es el problema que intentan resolver los planos de control de agentes entre plataformas.

Lo que el marketplace no hace

Estar en el catálogo no equivale a superar una revisión de seguridad. Cada socio trata sus datos con sus propias condiciones, en su propia infraestructura y con sus propios subencargados. Su proceso de riesgo de terceros sigue necesitando el informe SOC 2, el contrato de encargo del tratamiento que exige el RGPD, la política de conservación y los compromisos ante incidentes. Para una entidad financiera española sujeta a DORA, cada socio que preste un servicio TIC es un proveedor más que debe constar en el registro de información sobre acuerdos contractuales con terceros, con su evaluación de riesgo. El canal de compra no cambia esa obligación.

Tampoco resuelve la salida. Pregunte qué ocurre con las configuraciones, el historial de conversaciones y los datos de evaluación si deja al socio, y si salir del marketplace cambia el precio.

Qué hacer ahora

1. Pida a su equipo de cuenta de OpenAI las condiciones por escrito: elegibilidad en su país, parte del compromiso que puede redirigirse, precio frente a compra directa y forma de facturación.
2. Mantenga la evaluación técnica en primer lugar. Haga la comparativa antes de que nadie mencione el compromiso y úselo después para acelerar la compra del ganador.
3. Someta a cada socio a la revisión completa de riesgo de terceros. El catálogo es un canal de venta, no una certificación.
4. Anote en el inventario de agentes qué agente se compró con qué compromiso, para que finanzas y arquitectura vean lo mismo.
5. Revise también sus otros compromisos. Los marketplaces de Microsoft, AWS y Google ya aplican esta lógica; el camino más barato puede pasar por un contrato que ya tiene.

En resumen

Los proveedores de modelos ya no compiten solo por la calidad del modelo. Compiten por hacia dónde fluye el presupuesto de las empresas, y el gasto comprometido se ha convertido en un canal de distribución. Puede ser un buen acelerador. Nunca debería ser la razón por la que un producto supera una revisión, ni decidir en silencio dónde se ejecutan sus agentes o de quién depende.