Aspectos legales para tener en cuenta al contratar servicios de IA.
Lo primero que es necesario comprender en temas de Inteligencia Artificial y relaciones contractuales es que la IA no funciona como un software tradicional, dado que es un sistema probabilístico y no uno lógico soportado en código estático. Mientras que un software tradicional genera una salida según una serie de reglas lógicas programadas en uno o varios lenguajes de programación, los LLM tipo GPT, Large Language Models, calcula el valor de salida según la probabilidad que una red neuronal calcula basándose en un entrenamiento previo. Esto impide que se apliquen normas de contratos de servicios de software a servicios de IA. Por tanto, métricas como el Uptime, tradicionales del SAAS, pierden utilidad en el AI as a Service- AIaaS, puesto que un servicio puede estar disponible pero sus resultados pueden ser erróneos. Por tal motivo, es indispensable establecer métricas de fiabilidad como el F1 score, recall o el Precision, las cuales determinan el valor del resultado generado.
La ausencia de este tipo de métricas en el contrato o en el Service Level Agreement – SLA limitan la obligación del proveedor a simplemente mantener el sistema activo, pero sin comprometerse a niveles de fiabilidad minimos. Esto significa que el comprador del servicio queda vulnerable a daños ocasionados por alucinaciones o drifting del sistema, es decir, se asume el 100% del riesgo operativo. Para evitar esto es necesario estructurar contratos o SLA que tengan en cuenta los principios generales del derecho, las normas sobre interpretación de contratos del código de comercio y del código civil, junto con métricas de fiabilidad y obligación de reporte de pruebas antidrifting entre otras. Además, es necesario que se tenga en cuenta el cumplimiento de normativa de protección de datos fijada por la Circular 002 de 2024 de la Superintendencia de Industria y Comercio y la existencia de cláusulas de indemnidad contra demandas de derechos de autor con base en violación de estos mediante le entrenamiento del modelo. Todo esto con el fin de demostrar una debida diligencia por parte de los administradores societarios como es requerido por el articulo 24 de la ley 222 de 1995.
El SLA (Service Level Agreement) es el principal instrumento en las relaciones comerciales B2B de servicios digitales; estos documentos caracterizan la obligación, estableciendo los deberes a cargo de cada parte y el tipo de prestación que esperan a cambio. En negocios de SaaS, el Uptime fija el porcentaje de tiempo que el servidor o la aplicación debe permanecer disponible, estableciendo el parámetro de cumplimiento.
Sin embargo, las relaciones de tipo AIaaS (AI as a Service) requieren determinar la obligación del prestador más allá de una ventana operativa, dado que la calidad de la respuesta importa tanto o más que la disponibilidad. Una IA operativa al 99.9% que alucine el 50% de las respuestas es sustancialmente más peligrosa y dañina que un sistema con intermitencias, pero con una tasa de fiabilidad mayor.
Esta fiabilidad se mide mediante métricas de desempeño estadístico como el Accuracy, la Precision, el Recall o el F_1 Score. Estos instrumentos son esenciales, ya que caracterizan la obligación y permiten al comprador determinar el cumplimiento efectivo de lo pactado. Es imperativo establecer por escrito el umbral mínimo de fiabilidad que el prestador debe mantener. Esto reviste altísima importancia dado que, si bien no existe regulación explícita sobre este tipo contractual, el régimen de atipicidad de los contratos mercantiles y la remisión por integración normativa del Artículo 822 del Código de Comercio entrarán a dirimir controversias; por lo tanto, es vital determinar si la obligación es de medio o de resultado. Lo cual genera una serie de implicaciones que pueden verse en mayor profundidad en el siguiente link.
El Drifting es un fenómeno intrínseco de los sistemas probabilísticos como la Inteligencia Artificial; este mide el nivel de degradación que un Large Language Model (LLM) sufre con el tiempo. El fenómeno se origina por dos causas principales: primero, el Data Shift (o Deriva de Datos), que ocurre por la inserción de información no contemplada en el entrenamiento original; y segundo, el Concept Drift (o Deriva de Concepto), que sucede cuando eventos externos —crisis económicas, sanitarias o políticas— cambian la relación de causalidad en el mundo real, dejando obsoleta la lógica del modelo. Ambos escenarios rompen la idoneidad técnica del sistema.
Por tal razón, la práctica de pruebas técnicas como el Population Stability Index – PSI o el Kolmogorov-Smirnov KS, junto con su reporte periódico, se torna un deber inexcusable del prestador bajo el Principio de Buena Fe (Art. 1603 del Código Civil y Art. 871 del Código de Comercio). En contratos de está naturaleza la omisión de estos reportes de transparencia impide verificar si el proveedor está mitigando activamente la degradación o si el cliente está operando bajo una esquema de “Caja Negra” que genera riesgos patrimoniales ciegos. Algunas consecuencias derivadas de fenómeno técnico pueden verse en el siguiente link.
La privacidad y el desarrollo de modelos de Inteligencia Artificial tienen un importante punto de fricción en el uso de datos para el entrenamiento de futuros modelos tecnológicos. Este escenario envuelve mayor importancia cuando se insertan datos personales de terceros como clientes, trabajadores y proveedores en sistemas, dado que es necesario demostrar que dicho tratamiento está acorde con el marco jurídico colombiano. Es importante recordar que en los negocios AI as a Service (AIaaS), en los que el proveedor no es dueño de la tecnología, sino que actúa como un Applied Artificial Intelligence Provider (AAIP) —es decir, como un proveedor de servicios específicos mediante la infraestructura de un gran desarrollador como Anthropic o Google—, la configuración de privacidad y el enmascaramiento de datos depende de la arquitectura de estos últimos. Sin embargo, las fallas de privacidad que ocasionen violación de la normativa de habeas data pueden generar sanciones tanto para el proveedor como para sus clientes.
Esta sanción por violación de las normas de protección de datos personales se fundamenta en la calidad de Responsable y Encargado que adquieren el cliente de servicios de IA y su proveedor. Mientras que la empresa que recolecta los datos y decide su uso en la herramienta de IA se considera Responsable (al definir los fines y medios del tratamiento), el proveedor de esas herramientas que realiza el tratamiento por orden de aquel se considera Encargado (bajo el Decreto 1377 de 2013). Por tal motivo, es innegociable fijar cláusulas de No-Training que prohíban que los datos e inputs del cliente alimenten los modelos, ya sea del proveedor directo (AAIP) o del desarrollador de la infraestructura. Así, es indispensable que los contratos contemplen reglas para el cumplimiento de la Circular 002 de 2024 y otras normas pertinentes de las cuales se habla con algo más de precisión en el siguiente link.
El entrenamiento de modelos de IA por las grandes tecnológicas se ha basado en la técnica de scraping (extracción masiva de datos), generando una controversia global sobre la infracción de obras protegidas. Mientras que en jurisdicciones anglosajonas se ha invocado la doctrina del Fair Use para legitimar este actuar, en Colombia rige la Decisión 351 de 1993, que establece un régimen de excepciones de derechos de autor taxativo (numerus clausus), dentro del cual no se contempla la transformación de obras para entrenamiento de IA. Esta asimetría normativa crea un riesgo de infracción directa para los clientes finales que utilizan estas herramientas en territorio colombiano.
Ante este riesgo, proveedores como Anthropic, Google y OpenAI han implementado cláusulas de indemnidad de IP que funcionan como escudos patrimoniales. No obstante, la efectividad de estos escudos está condicionada a excepciones críticas: el uso obligatorio de filtros de seguridad, la licitud de los datos en procesos de Fine-tuning y la ausencia de infracciones marcarias. En una relación comercial mediante un Applied Artificial Intelligence Provider (AAIP), la gestión de estas medidas de seguridad queda bajo control de dicho proveedor intermedio. Por consiguiente, es vital que el contrato con el AAIP exija el cumplimiento estricto de las condiciones impuestas para no invalidar el escudo de indemnidad y permitir, de ser necesario, un Llamamiento en Garantía efectivo. Los detalles sobre este blindaje procesal pueden verse con mayor precisión en el siguiente link.
Contenido elaborado el [26/03/2026] por William Bernal Mateus, abogado tecnológico. Esta información es exclusivamente informativa y no constituye asesoría jurídica ni consulta legal vinculante.