El verdadero contrato de la IA no está en las cláusulas, está en la política de uso que nadie lee
Compras evalúa un modelo de frontera por capacidad y precio. El límite real lo fija un documento que el proveedor redacta en solitario y puede aplicar después de la firma.
Esta es la parte de un acuerdo de IA que nadie lee en voz alta. La capacidad se demuestra, el precio se negocia, el cuestionario de seguridad se rellena. Y entonces alguien pega una URL en el contrato marco, y esa URL apunta a una política que el proveedor ha escrito en solitario y puede revisar cuando le convenga. Compras no la negoció. La heredó, y puede condicionar un despliegue en producción mucho después de que la firma esté seca.
Así que conviene leer el contrato como lo haría un adversario: cláusula a cláusula, preguntando qué le permite hacer cada una al proveedor en su peor día. La capacidad y el precio ya se escrutan de sobra. Hay cuatro cláusulas que casi nunca se miran, y entre las cuatro deciden cuánto queda expuesta la empresa: qué prohíben las políticas del proveedor, cuándo puede cortar el acceso, dónde corre físicamente el modelo y si el lenguaje de gobernanza significa algo cuando llega una auditoría. Este artículo repasa cada una y termina con las preguntas que hay que poner sobre la mesa, y las respuestas que deberían tumbar el acuerdo.
¿Qué se firma realmente al licenciar un modelo de frontera?
Un contrato empresarial con un laboratorio de frontera hace más que licenciar un modelo: incorpora por referencia las propias políticas del proveedor y se reserva el derecho de suspender el servicio. Las condiciones comerciales de OpenAI incluyen una cláusula expresa de suspensión: OpenAI puede cortar el acceso si cree razonablemente que hay un riesgo de seguridad, una obligación legal o regulatoria, o un incumplimiento de sus políticas. Esas políticas, incluida la de uso aceptable, quedan incorporadas por ese mismo contrato, de modo que un documento que el proveedor puede editar unilateralmente se convierte en cláusula viva del acuerdo. Por lo que se observa en el mercado, ese patrón es la norma, no la excepción. La política de uso aceptable no es letra pequeña: codifica el apetito de riesgo del proveedor, no el de la empresa compradora, y determina qué puede y qué no puede hacer el despliegue.
Cuánto de unilateral resulte esto depende de lo que se negocie. Los compradores con capacidad de presión a veces consiguen plazos de preaviso ante cambios, cláusulas de «abuelo» para los usos ya en marcha o un derecho de salida si la política cambia de forma sustancialmente adversa. La mayoría no pide nada de eso, acepta la política enlazada tal cual y descubre sus límites cuando un chatbot piloto se convierte en un agente que toca sistemas de producción. Ese es el momento en que un caso de uso roza una línea roja, y quien había escrutado capacidad y precio descubre que la cláusula que de verdad mandaba era una página de política que nadie auditó.
¿Qué pasa cuando el proveedor y un gobierno no están de acuerdo sobre tu modelo?
Esto dejó de ser un debate abstracto en cuanto los modelos de frontera entraron en defensa y administración pública. Los laboratorios publican políticas de uso que excluyen unilateralmente ciertas categorías. La política de uso de Anthropic restringe ámbitos como la vigilancia y parte del espacio de las fuerzas de seguridad, y sostener esas líneas frente a un cliente con mucho poder es justo donde las normas de un proveedor y las exigencias de un gobierno pueden tirar en direcciones opuestas. Una empresa compradora que comparte proveedor con ese cliente no tiene ni voz ni voto en esa discusión, pero hereda el resultado. Si la política se endurece, los usos permitidos se estrechan con ella. Si el proveedor cede a la presión, el modelo del que depende la empresa puede cambiar de carácter con poco aviso. Ese, sostenemos, es el verdadero riesgo de contraparte en un acuerdo con un modelo de frontera, y queda completamente fuera del precio.
Para una empresa española la presión llega por más de un frente. El Reglamento de IA de la UE tiene alcance extraterritorial: su artículo 2, apartado 1, letra c), extiende las obligaciones a proveedores y responsables del despliegue situados en un tercer país cuando el resultado producido por el sistema de IA se utiliza en la Unión, según recoge el ámbito de aplicación del Reglamento. Eso significa que un laboratorio estadounidense que presta servicio a clientes en España queda alcanzado por el Reglamento aunque opere fuera de la Unión, un mecanismo que conviene tener presente junto a la supervisión que ejercen la AEPD y la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) sobre el uso final. Fuera de España, el NCSC (la agencia británica de ciberseguridad) trata en su guía sobre seguridad de la cadena de suministro cualquier dependencia crítica de software como algo que se gestiona con responsables designados y planes de salida, no como algo que se da por hecho. Un modelo de frontera sin el que el producto no puede funcionar es exactamente ese tipo de dependencia. Las administraciones públicas afrontan la versión más exigente de esta prueba: las directrices de compra pública de IA del Reino Unido, pensadas para las administraciones británicas, empujan a planificar todo el ciclo de vida del contrato, y la dirección que marcan (documentar cómo sobreviviría la organización a la pérdida del proveedor) es la misma que empieza a exigirse en los pliegos españoles.
¿Debe el modelo correr dentro del propio perímetro de confianza?
La pregunta que un buen proceso de compra hace primero, y que casi siempre se hace la última, es dónde corre realmente el modelo. ¿Puede alojarse dentro del propio perímetro de confianza, con pesos abiertos, en instalaciones propias, aislado de red si la carga de trabajo lo exige, o solo existe como una petición a la nube de otro? Un modelo que se aloja uno mismo queda aislado de que el proveedor cambie de idea, y de que alguien presione al proveedor para que lo haga. Un modelo que se alquila queda expuesto a ambas cosas.
El autoalojamiento es aislamiento, no inmunidad, y conviene decirlo sin rodeos. Los modelos de pesos abiertos siguen llegando bajo licencias que pueden restringir el uso comercial o de alto riesgo, así que descargar los pesos no libera de condiciones. Los modelos abiertos más potentes suelen ir por detrás de los cerrados líderes, así que la resiliencia puede costar capacidad. Y la empresa asume la carga de seguridad, parcheo y evaluación que antes llevaba el proveedor. El intercambio es real, pero para una carga de trabajo regulada, clasificada o soberana suele inclinar la balanza hacia el control, que es la misma disciplina que defendemos al diseñar sistemas agénticos seguros, donde la pregunta nunca es solo qué puede hacer el modelo, sino quién mantiene el control cuando cambian los incentivos.
¿A qué compromete realmente «supervisión humana» al proveedor?
Hay un fallo más silencioso, y se esconde en las garantías con las que compras se queda más tranquila. «Supervisión humana». «Humano en el bucle». Son frases que superan cualquier revisión porque todo el mundo asiente imaginando cosas distintas. Una parte lee «humano en el bucle» como una persona que aprueba cada acción con consecuencias. Otra lo lee como un panel que alguien mira por encima una vez a la semana. Las mismas palabras, márgenes de maniobra opuestos, y la brecha aflora durante un incidente, el peor momento posible para descubrir qué compraba realmente esa frase.
Conviene traducir cada expresión en algo que se pueda suspender en una auditoría. El marco de gestión de riesgo de IA del NIST es tajante sobre el método: definir y diferenciar los roles humanos y los de la IA, documentar el proceso de supervisión, identificar los controles de terceros y usar métodos de prueba y validación objetivos y repetibles. Cada garantía genérica debe convertirse en un control específico y verificable antes de firmar. Si «supervisión» no se puede escribir como una comprobación que se pueda suspender, es decoración. Es el mismo argumento que desarrollamos en nuestra nota sobre IA práctica con control humano, donde el peso lo lleva el mecanismo, no el vocabulario.
¿Qué preguntas frenan realmente un mal acuerdo de IA?
La due diligence solo vale lo que valen las preguntas por las que se está dispuesto a romper el trato. Estas siete, en orden, y la respuesta en cursiva es la que debería acabar la conversación, o al menos trasladarla a los abogados antes de firmar nada. Cada una corresponde a una cláusula que el contrato ya contiene.
- ¿Qué políticas suyas forman parte de este contrato, y pueden cambiarlas sin mi consentimiento? Se está poniendo a prueba la cláusula de incorporación por referencia. Motivo de ruptura: todas ellas, modificables a su sola discreción, con efecto desde el momento en que se publican.
- ¿Bajo qué causas pueden suspender o limitar un despliegue en producción, con qué preaviso y con qué plazo para subsanar? Es la cláusula de suspensión en lenguaje llano. Motivo de ruptura: de forma inmediata, a su discreción, sin preaviso, sin posibilidad de subsanar.
- Si cambian la política de uso de forma que rompe mi caso de uso, ¿tengo preaviso y una salida con mis datos? Se está tasando el derecho de salida ante cambios sustanciales. Motivo de ruptura: no hay salida por cambio materialmente adverso, y la resolución por conveniencia es solo suya, no de la empresa compradora.
- ¿Puede correr esto dentro de mi propio perímetro de confianza, en nube privada, en instalaciones propias o aislado de red, o solo en su nube? Esto decide la exposición a todo lo anterior. Motivo de ruptura: solo API en nuestra región, sin opción de aislamiento, cuando la carga de trabajo es regulada, clasificada o soberana.
- ¿Dónde se procesan mis datos, con qué subencargados y bajo qué compulsión legal podrían revelarse? Se está trazando la jurisdicción y la cadena de subencargados. Motivo de ruptura: no revelamos los subencargados ni nos comprometemos a una región de procesamiento.
- Escriban «supervisión humana» como un control que yo pueda suspender en una auditoría. La aprobación acción por acción se lee de forma muy distinta a un panel semanal. Motivo de ruptura: es lo que decidamos implementar, y no nos comprometemos a nada.
- ¿Con cuánto preaviso retiran o cambian de forma sustancial la versión del modelo que he validado? El cambio de versión puede invalidar la validación de la noche a la mañana. Motivo de ruptura: retiramos versiones según nuestro calendario y usted revalida a su cargo.
Nada de esto es exótico. Es el propio contrato, leído en voz alta pensando en el peor día del proveedor.
El contrato real vive en cuatro sitios que la página de firma apenas menciona: las políticas a las que enlaza, el momento en que se puede cortar el acceso, la nube donde corre el modelo y las palabras de gobernanza que nadie convirtió en una prueba. Auditar esos cuatro puntos, en ese orden, es comprar una relación con el proveedor de la que se puede exigir cuentas. Saltárselos es comprar una dependencia de la que no se puede salir bajo presión. Si se quiere incorporar esa disciplina al proceso de compra en lugar de añadirla después, nuestra práctica de estrategia tecnológica empieza precisamente ahí.
Preguntas frecuentes
¿Qué debe cubrir un checklist de due diligence para proveedores de IA además de capacidad y precio?
Además de capacidad y precio, debe cubrir la política de uso aceptable y el derecho del proveedor a cambiarla o suspender el acceso, la topología de despliegue (si el modelo puede correr dentro del propio perímetro de confianza) y el significado preciso y auditable de términos de gobernanza como «supervisión humana», cerrado antes de firmar y no durante un incidente.
¿Puede un proveedor de IA cortar el acceso a un modelo que ya se está pagando?
Habitualmente sí. Los contratos empresariales que incorporan las políticas del proveedor suelen reservarse el derecho de suspender o limitar el acceso ante un incumplimiento de política, una obligación legal o una emergencia de seguridad, como hacen las condiciones comerciales de OpenAI. A veces se pueden negociar plazos de preaviso o derechos de salida, y el autoalojamiento o los pesos abiertos son la principal vía de aislamiento estructural, aunque con sus propias condiciones de licencia y su propia carga operativa.
¿Por qué genera disputas la expresión «humano en el bucle» en los contratos de IA?
Porque no está definida. Dos partes pueden leer las mismas palabras como aprobación acción por acción o como una simple supervisión ocasional, y esa ambigüedad solo se resuelve durante un fallo. Conviene convertirla en controles documentados y auditables desde el principio, en la línea que marca el marco de gestión de riesgo de IA del NIST, y la ambigüedad desaparece.
Relacionado
- En Ubuntu 26.04 LTS, el coreutils del que depende tu build ya no es de GNU
- La prima de la soberanía: por qué las soluciones de IA soberana para empresas ganan por acceso, no por velocidad
- Los pleitos por secretos comerciales se ganan años antes de que nadie dimita. Que se lo pregunten a Faccenda Chicken.
- Security & Trust
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.