Contrato de implantación de IA: ocho cláusulas ausentes en el estándar de TI

Guía práctica elaborada desde la perspectiva del proveedor. Describe soluciones estándar y no resuelve casos particulares. En las reuniones previas a la implantación en empresas de 50–250 empleados surge con frecuencia una misma afirmación: para implantar IA basta con un contrato estándar de servicios TI y un anexo de RGPD. Parece razonable. El contrato habitual de TI regula plazos, recepciones, penalizaciones, propiedad del código y tratamiento de datos. Si un chatbot o la automatización documental son «un sistema más», no parece necesario redactar cláusulas nuevas. Además, la propia AI Act no impone un formato contractual específico para sistemas de bajo riesgo.

El argumento principal de la otra parte

Este argumento tiene una base sólida. Un contrato estándar de TI suele incluir un calendario de aceptación, penalizaciones contractuales, cesión de derechos de explotación del código, procedimiento de gestión de incidencias y un acuerdo de encargo del tratamiento según el artículo 28 del RGPD. Para implantar un ERP o una plataforma de comercio electrónico, esto solía ser suficiente. Los proveedores de sistemas de IA también facilitan plantillas con cláusulas genéricas sobre seguridad y prohibición de entrenar modelos con datos del cliente. Las sanciones del RGPD alcanzan el 4% de la facturación anual, por lo que el anexo de encargo del tratamiento suele considerarse protección suficiente. Además, las sanciones de la AI Act (hasta 15 000 000 EUR o el 3% de la facturación global) afectan sobre todo a proveedores de sistemas de alto riesgo, no a una empresa que implanta un chatbot para gestionar pedidos.

AIImagen generada por IA.

Qué no contempla este argumento

El contrato estándar de TI no resuelve cuatro factores críticos para el riesgo en IA. En primer lugar, los prompts y la configuración: que constituyan una obra protegida por la ley de propiedad intelectual depende de su carácter creativo, pero las plantillas no suelen definir a quién corresponden los derechos de explotación. Como resultado, el proveedor puede reutilizar esa misma arquitectura de prompts con la competencia al finalizar el contrato. En segundo lugar, el control de versiones del modelo: OpenAI y Anthropic retiran modelos con pocas semanas o meses de preaviso, como indica su documentación de obsolescencia, y el contrato estándar no permite al cliente bloquear actualizaciones automáticas antes de completar las pruebas de aceptación. En tercer lugar, la exportación de datos: los registros de conversación y los embeddings vectoriales no son tablas SQL convencionales, por lo que la cláusula «el proveedor devolverá los datos» suele quedar vacía de contenido. En cuarto lugar, las alucinaciones: atribuir responsabilidad por un «resultado erróneo» exige fijar un umbral de tolerancia, o cada respuesta inexacta derivará en un conflicto de calidad del servicio. A esto se suma la distinción de roles bajo la AI Act: el proveedor del sistema de IA y el responsable del despliegue tienen obligaciones distintas que un contrato de TI habitual no delimita. A partir del 2.08.2026, los chatbots deberán informar explícitamente de que el usuario interactúa con una IA y etiquetar los contenidos generados.

Nuestra postura

En nuestra práctica, un contrato de implantación de IA en producción incluye ocho cláusulas ausentes en un contrato IT estándar: derechos sobre prompts y configuraciones (cesión de derechos patrimoniales de autor o licencia irrevocable y perpetua con derecho de modificación y sublicencia), notificación previa de 60 días ante la depreciación del modelo y prohibición de actualización automática sin pruebas de aceptación, exportación de datos en 30 días en formato JSON/CSV/JSONL, eliminación de copias de seguridad en 60 días, umbral de alucinación ≤5% en conjunto de prueba, límite de responsabilidad del proveedor fijado en 12 mensualidades, depósito notarial o escrow de prompts y código, y asistencia tras la salida durante 3 meses a tarifa estándar. En nuestro caso, al implantar un asistente de correo sobre una muestra de 500 mensajes, recibimos primero la ficha del modelo con métricas, y las pruebas de aceptación sobre dicha muestra determinaron la versión final. Sin estas cláusulas, el cliente se queda con un sistema operativo, pero sin plan de salida y sin umbral de responsabilidad sobre las respuestas del sistema.

AIImagen generada por IA.

Qué conviene hacer este trimestre

Durante este trimestre, antes de firmar, conviene comprobar si el proveedor acepta negociar la exportación de datos en 30 días y la prueba de alucinación ≤5%. Si rechaza ambas, el proyecto no tiene por qué cancelarse, pero queda claro qué riesgos asume el cliente. Cambiaríamos de criterio bajo una sola condición: si el proveedor facilitase una instancia local del modelo de código abierto con una ficha de modelo auditada y acceso total a los pesos, las cláusulas sobre depreciación de API externas perderían relevancia. Hasta entonces, tratamos el contrato de implantación de IA como un documento independiente, no como un anexo a una plantilla de IT.