En 2025, la Comunidad de Compradores Públicos de la Comisión Europea publicó un conjunto de cláusulas modelo para la compra pública de sistemas de IA — el MCC-AI, con una versión completa para sistemas de alto riesgo y una versión simplificada para el resto, ambas alineadas a las obligaciones del Reglamento de IA de la Unión Europea. La iniciativa no nació de la burocracia: nació porque ningún comprador público quería seguir firmando un contrato de IA apoyado solo en la palabra del proveedor.
El motivo aparece en las investigaciones de gestión de riesgo de terceros. Según Ncontracts, en un relevamiento de 2026 con instituciones financieras de Estados Unidos, el 72% de ellas sabe solo parcialmente qué proveedores usan IA, y el 16% nunca lo evaluó. Ninguna organización dijo sentirse "extremadamente confiada" para gestionar ese riesgo.
Esto importa para quien firma el contrato, no solo para quien opera el sistema después. Una cláusula vaga hoy es una obligación que nadie puede exigir mañana — en una auditoría, en la investigación de un incidente o al momento de renovar.
Lo que le falta a la mayoría de los contratos de IA
Los estudios especializados en contratos de tecnología documentan un patrón parecido entre quienes compran IA: la cláusula de seguridad del proveedor suele repetir el mismo lenguaje genérico — "seguridad de última generación", "cumplimiento total" — sin nombrar un control que se pueda verificar después. Una guía de cláusulas para contratos de proveedores de IA, del estudio Gouchev Law, enumera puntos que suelen faltar: una definición clara del uso del dato para entrenamiento, la propiedad del resultado generado, revisión humana obligatoria según el riesgo, e indemnización que cubra reclamos sobre el dato usado en el entrenamiento — no solo sobre el software en sí.
El punto que más frecuentemente falta es la propia definición de dato del cliente. Un contrato bien redactado, según un análisis del estudio Tish Law sobre cláusulas de proveedores de IA, debe tratar como confidencial no solo el documento enviado, sino también el comando escrito, el resultado generado y cualquier registro de uso — restringiendo el uso del proveedor a la prestación del servicio contratado, salvo que exista un permiso escrito en contrario.
El Instituto Nacional de Estándares y Tecnología de Estados Unidos, el NIST, aborda el mismo problema desde el lado de la estructura de gobernanza. Su marco de gestión de riesgo de IA pide que la empresa mantenga una política formal para el riesgo que viene de proveedores y datos de terceros, evalúe ese riesgo al contratar y en intervalos definidos, y preserve el derecho de auditar las prácticas de IA del proveedor — no solo confiar en su palabra.
La norma internacional de sistemas de gestión de IA, la ISO/IEC 42001, llega a una conclusión parecida por otro camino: exige que la empresa evalúe la capacidad de cada proveedor para cumplir requisitos de IA responsable, pida evidencia — no promesa — y sea avisada cuando el proveedor cambie el modelo, el conjunto de datos o la forma de alojamiento, porque ese cambio puede alterar el riesgo que la empresa ya había aceptado.
Por qué la cláusula de marketing no protege a nadie
La salida más común sigue siendo la equivocada: aceptar la página de seguridad del proveedor como si fuera prueba. Una declaración pública de "seguridad de nivel empresarial" no es una cláusula — es un argumento de venta, y un argumento de venta no se puede exigir después de que algo sale mal.
Lo mismo vale para el certificado aislado. Pedir un sello de cumplimiento en la propuesta es un primer filtro, pero no reemplaza la obligación contractual. La práctica recomendada por quienes evalúan el riesgo de proveedores es otra: convertir cada certificación exhibida en una cláusula que la respalde — el proveedor declara el alcance certificado, se compromete a notificar cualquier cambio de alcance y acepta entregar evidencia cuando se le pida, no solo el sello.
Otro error común es tratar la cláusula de subcontratación como una formalidad. Un proveedor de IA rara vez opera solo: usa el modelo de un tercero, el alojamiento de un tercero, a veces hasta revisión humana tercerizada. Sin una cláusula que obligue a listar esos subcontratistas y notificar cualquier cambio, la empresa contratante descubre la cadena real recién cuando algo ya salió mal.
Y está el punto que más aparece en los análisis jurídicos más recientes: la indemnización suele cubrir el software, pero no el dato de entrenamiento ni el resultado generado por la IA. Si el modelo fue entrenado con un dato que infringe derechos de autor o viola la privacidad de un tercero, la responsabilidad puede recaer sobre quien contrató — no solo sobre quien entrenó. Negociar esa cobertura antes de firmar sale más barato que negociarla después de una notificación de incumplimiento.
Lo que tiene que existir en la práctica
Un contrato de IA auditable se apoya en mecanismos verificables, no en un adjetivo. Son estos los que una cláusula bien escrita debe exigirle al proveedor — y los que una empresa madura ya se exige a sí misma antes de firmar.
Entrada por la identidad corporativa, no por una cuenta suelta. La cláusula debe obligar a que el acceso al sistema de IA venga del mismo directorio de identidad de la empresa: quien se va de la empresa pierde el acceso al mismo tiempo, sin depender de que alguien recuerde cancelar una cuenta paralela.
Acceso según el papel de cada persona, no la herramienta entera. El contrato debe permitir configurar qué ve y qué hace cada función dentro del sistema — y el proveedor tiene que demostrar que esa separación existe, no solo describirla en una página de ventas.
Aprobación humana en acciones sensibles, con una regla clara de cuándo aplica. La cláusula tiene que nombrar en qué situaciones una acción se detiene y pide confirmación de una persona antes de seguir — no dejar esa decisión a criterio del proveedor una vez firmado el contrato.
Registro de auditoría detallado y accesible para quien contrató. El derecho a auditar, que defiende el NIST, solo vale en la práctica si el contrato también garantiza el acceso a los registros — quién hizo qué, cuándo y con qué permiso — y no solo el derecho teórico de solicitar una auditoría algún día.
Regla de retención y borrado de dato, con plazo por escrito. El contrato debe decir por cuánto tiempo se retiene el dato después de terminado el servicio y cómo se comprueba el borrado. Sin eso, "los datos se tratarán con seguridad" no es una obligación verificable — es solo una frase.
Así fue diseñada la plataforma Skyller: identidad que viene del directorio de la empresa, permiso por papel y aprobación humana como estándar del sistema, no como cláusula que la empresa tiene que negociar aparte.
La ganancia de un contrato que se puede auditar
Cuando el contrato nombra los controles en lugar de prometer seguridad, el área legal y el área de seguridad dejan de trabajar en paralelo y empiezan a negociar desde la misma lista. La auditoría interna gana una pregunta objetiva para cada cláusula: ¿existe el control, y existe evidencia de eso?
Esto también acelera la próxima compra. Quien evalúa a un proveedor de IA sin una lista previa de controles a exigir repite el mismo trabajo en cada renovación. Con cláusulas específicas, la próxima negociación usa el mismo guion — y el equipo de compras discute posición, no descubre el vocabulario desde cero.
Hay una ganancia menos obvia: el contrato bien escrito también protege contra la propia evolución del proveedor. Un sistema de IA cambia de modelo, de proveedor de alojamiento y de política de dato con más frecuencia que otros sistemas corporativos. Una cláusula de notificación de cambio material — del tipo que recomienda la ISO 42001 — le da a la empresa la oportunidad de reevaluar el riesgo antes de que el cambio ya esté en producción, no después.
Preguntas para llevar a la próxima negociación de contrato
Antes de firmar — o renovar — un contrato con un proveedor de IA, vale la pena llevar estas preguntas a la mesa:
- ¿El proveedor puede usar nuestros datos para entrenar su modelo, y bajo qué condición eso cambia? Si la respuesta está solo en una política pública y no en una cláusula, puede cambiar sin aviso.
- ¿Quién, de nuestro lado, tiene derecho a auditar las prácticas de IA del proveedor, y con qué plazo de respuesta? Un derecho de auditoría sin plazo definido es un derecho que, en la práctica, nadie ejerce.
- ¿La indemnización cubre reclamos sobre el dato de entrenamiento y sobre el resultado generado, o solo sobre el software? Es la brecha más citada por los abogados especializados en contratos de IA.
- ¿El proveedor está obligado a notificar un cambio de modelo, de subcontratista o de alojamiento? Sin esta cláusula, la empresa se entera del cambio recién después de que ya afectó alguna operación.
- ¿Existe un plazo contractual para borrar el dato después de terminado el contrato, y cómo se comprueba? "Tratamiento seguro del dato", sin plazo por escrito, no es una obligación — es solo una intención.
