Contratos con proveedores de IA y adquisición de IA empresarial: guía legal para empresas

La inteligencia artificial está entrando en las empresas por muchas puertas.

Algunas herramientas de IA las aprueba la dirección. Otras las introducen los departamentos de informática. Otras vienen integradas en el software existente. Otras las usan equipos de marketing, departamentos de recursos humanos, desarrolladores, equipos de atención al cliente, consultores o empleados que experimentan con herramientas de IA generativa. Esto crea un nuevo problema jurídico: una empresa puede estar usando IA antes de haber revisado debidamente el contrato.

El riesgo no es teórico. Un proveedor de IA puede tratar datos personales, conservar prompts, usar las entradas para mejorar los modelos, limitar su responsabilidad, declinar toda garantía de exactitud, restringir la titularidad de los resultados, recurrir a subencargados extranjeros, reservarse derechos de suspensión, cambiar el producto, integrar modelos de terceros o exigir al cliente que asuma una amplia responsabilidad por la conducta de los usuarios. Para el software corriente, estas cuestiones son importantes; para la IA, pueden volverse centrales.

Por ello, la adquisición de IA debería tratarse como un proceso jurídico estratégico, no como una compra rutinaria de suscripción. Esta guía explica qué deberían revisar las empresas antes de adquirir, desplegar o escalar herramientas de IA.

1. La adquisición de IA no es una adquisición de software corriente

La adquisición de software tradicional suele centrarse en la funcionalidad, el alcance de la licencia, el precio, los niveles de servicio, el soporte, la seguridad y la terminación. La adquisición de IA requiere todo eso, pero también más. La empresa debería entender qué datos usa el sistema de IA, si se tratan datos personales, si puede introducirse información confidencial, si se conservan los prompts y los resultados, si los datos del cliente se usan para entrenar el modelo, si los resultados pueden usarse comercialmente, si el proveedor ofrece compromisos de exactitud, si la herramienta puede producir contenido infractor, si se requiere revisión humana, si el sistema afecta a personas, si se aplican obligaciones regulatorias, quién responde si el resultado causa un daño, y si la empresa puede explicar el sistema a reguladores, clientes o inversores.

La diferencia clave es que los sistemas de IA pueden generar resultados en lugar de limitarse a ejecutar funciones predefinidas. Eso dificulta el reparto de la responsabilidad jurídica. Una empresa no debería firmar un contrato de IA como si comprara software de oficina corriente.

2. Empezar por el caso de uso

Antes de revisar el contrato, la empresa debería definir el caso de uso. La misma herramienta de IA puede entrañar un riesgo distinto según cómo se use. Una herramienta de IA usada para resumir notas de reuniones internas es distinta de una usada para cribar candidatos a un puesto, evaluar el riesgo crediticio, recomendar tratamientos médicos, apoyar el análisis jurídico, revisar reclamaciones de seguros, generar consejos a clientes, monitorizar el rendimiento de los empleados, analizar datos de menores, tratar información sensible de salud, automatizar decisiones de cumplimiento o interactuar directamente con consumidores.

La revisión jurídica debería empezar con cinco preguntas: ¿Qué hará el sistema de IA? ¿Qué datos tratará? ¿Quién confiará en el resultado? ¿Qué podría salir mal? ¿Y quién responderá si así ocurre? Sin un caso de uso claro, el contrato no puede valorarse adecuadamente.

3. Identificar el papel del proveedor de IA

Una empresa debería identificar el papel del proveedor antes de firmar. El proveedor puede ser proveedor del modelo, plataforma SaaS, proveedor de API, integrador de sistemas, revendedor, proveedor de nube, encargado del tratamiento, responsable independiente, subcontratista, desarrollador de un modelo a medida o proveedor de un modelo de un tercero envuelto dentro de su propio producto.

Esto importa porque la responsabilidad depende del control. Un revendedor puede no controlar el modelo subyacente; una plataforma puede depender del proveedor de otro modelo fundacional; un integrador de sistemas puede configurar una herramienta sin ser su titular; un proveedor de IA orientada al cliente puede usar varios subencargados. El contrato debería hacer visible la cadena. Si algo sale mal, la empresa debería saber quién es responsable del modelo, la plataforma, el tratamiento de datos, la integración, la seguridad y el soporte.

4. Due diligence del proveedor de IA

Antes de firmar, las empresas deberían realizar la due diligence del proveedor de IA. No tiene por qué ser innecesariamente gravosa para herramientas de bajo riesgo, pero para casos de uso críticos para el negocio o sensibles, la revisión del proveedor es esencial. La empresa debería preguntar quién aporta el modelo subyacente, si la herramienta es propia o se basa en un modelo de un tercero, dónde se alojan los datos, si los datos del cliente se usan para entrenamiento, si ese uso puede desactivarse, si se almacenan los prompts y los resultados, cuánto tiempo se conservan los registros, qué certificaciones de seguridad existen, si los subencargados están enumerados y pueden cambiar sin aviso, si el proveedor atiende solicitudes de supresión, si existen derechos de auditoría o de información, si el sistema se ha probado en cuanto a sesgo o exactitud, si existe documentación para usos de alto riesgo o regulados, si el proveedor cuenta con procedimientos de respuesta a incidentes, y qué ocurre si el servicio se suspende o se descontinúa.

La due diligence del proveedor no es desconfianza. Es contratación profesional.

5. Acuerdo de protección de datos

Si la herramienta de IA trata datos personales, puede requerirse un acuerdo de protección de datos. El acuerdo debería abordar los papeles de las partes, la finalidad del tratamiento, las categorías de datos personales y de interesados, las instrucciones del cliente, la confidencialidad, las medidas de seguridad, los subencargados, las transferencias transfronterizas, la asistencia con las solicitudes de los interesados, la notificación de brechas, la supresión o devolución de datos, las auditorías, la conservación, el uso para entrenamiento y las medidas técnicas y organizativas.

La IA crea complicaciones especiales porque los datos pueden aparecer en prompts, documentos cargados, historial de chat, embeddings, registros, conjuntos de datos de ajuste fino, analítica y registros de resultados. El contrato no debería limitarse a decir «se aplica la normativa de protección de datos»: debería explicar cómo trata realmente los datos el sistema de IA.

6. Datos del cliente y entrenamiento del modelo

Una de las cuestiones más importantes es si el proveedor puede usar los datos del cliente para entrenar o mejorar los modelos. Esto debería revisarse con cuidado. Los datos del cliente pueden incluir prompts, documentos cargados, registros internos, información de clientes, datos de empleados, datos comerciales, archivos confidenciales, código, documentos jurídicos, datos de salud, datos financieros, comentarios y resultados.

El contrato debería indicar si el proveedor puede usar estos materiales para entrenar el modelo, para ajuste fino, para mejorar el servicio, para analítica, para depuración, para monitorización de abusos, para seguridad o para desarrollo de producto. Si la empresa no quiere que sus datos se usen para el entrenamiento, el contrato debería decirlo con claridad. Un acuerdo de IA empresarial debería ofrecer, idealmente, controles más fuertes que una herramienta de IA de consumo.

7. Confidencialidad y secreto profesional

Las herramientas de IA pueden crear riesgos de confidencialidad, sobre todo para las empresas que manejan expedientes de clientes, materiales del consejo, documentos jurídicos, estados financieros, datos personales, registros de empleados, información médica, código fuente, secretos comerciales, objetivos de adquisición, materiales de litigios, reclamaciones de seguros, propiedad intelectual o planes estratégicos. El contrato con el proveedor debería incluir obligaciones de confidencialidad lo bastante sólidas para la sensibilidad de la información.

Las empresas de servicios profesionales, servicios jurídicos, finanzas, seguros, sanidad, tecnología y consultoría deberían ser especialmente cuidadosas. La empresa también debería decidir internamente qué no puede cargarse nunca en herramientas de IA salvo que existan salvaguardas aprobadas. La confidencialidad contractual y la política interna de IA deberían funcionar juntas.

8. Seguridad de la información

Las herramientas de IA deberían revisarse en cuanto a seguridad: cifrado en tránsito y en reposo, controles de acceso, autenticación, controles de administrador, registros, segregación de datos, gestión de vulnerabilidades, pruebas de penetración, respuesta a incidentes, acceso del personal del proveedor y de subcontratistas, copias de seguridad y recuperación, supresión de datos, certificaciones de seguridad, notificación al cliente, informes de auditoría, seguridad de la API, límites de uso y prevención de abusos.

La revisión de seguridad debería ajustarse al riesgo. Un asistente público de escritura con IA usado para borradores de marketing no confidenciales puede no requerir la misma revisión que una herramienta usada para historiales médicos, datos financieros, monitorización de empleados o documentos jurídicos, pero la empresa debería hacer esa distinción de forma deliberada.

9. Transferencias transfronterizas y alojamiento en la nube

Las herramientas de IA suelen estar basadas en la nube, y los datos pueden alojarse, consultarse o tratarse en varias jurisdicciones. Esto importa para las empresas que operan en Turquía, el norte de Chipre, el Reino Unido, la Unión Europea u otros mercados transfronterizos. El contrato debería identificar la ubicación del alojamiento, las ubicaciones de acceso de soporte, los subencargados, el mecanismo y las salvaguardas de la transferencia transfronteriza, el riesgo de acceso gubernamental, las opciones de residencia de los datos y las ubicaciones de copia de seguridad y de recuperación ante desastres.

Las empresas no deberían presumir que los datos permanecen en local solo porque el servicio se vende en local. Un usuario puede acceder a la plataforma desde Turquía mientras los datos se alojan en Europa, se tratan a través de un proveedor de modelo radicado en EE. UU. y reciben soporte de un equipo global. Esa estructura puede ser aceptable, pero debe entenderse.

10. Titularidad de los resultados y uso comercial

Las empresas adquieren herramientas de IA en parte porque quieren resultados: textos, código, imágenes, diseños, informes, traducciones, resúmenes, recomendaciones, analítica, planes de negocio, respuestas a clientes, descripciones de producto, borradores jurídicos o de cumplimiento y materiales de marketing. El contrato debería abordar si la empresa puede usar los resultados comercialmente.

Entre las cuestiones clave están quién es titular del resultado, si el proveedor cede o retiene derechos, qué restricciones de uso se aplican, si pueden generarse resultados similares para otros usuarios, si los resultados están protegidos por el derecho de propiedad intelectual, si el cliente es responsable de revisar los resultados, si el proveedor ofrece alguna indemnización por propiedad intelectual y qué ocurre si un resultado infringe derechos de terceros. Una empresa debería ser cauta a la hora de usar resultados generados por IA, sin revisión, para activos de marca de alto valor, código de software, campañas publicitarias, asesoramiento regulado o entregables a clientes. El resultado de la IA debería tratarse como un borrador hasta que se verifique jurídica y comercialmente.

11. Riesgo de propiedad intelectual de terceros

Los sistemas de IA pueden generar contenido que se asemeje a material protegido de terceros o lo incorpore, creando disputas sobre derechos de autor, marcas, secretos comerciales, derechos sobre bases de datos, licencias de software, derechos de imagen, información confidencial o derechos de diseño. El contrato debería abordar si el proveedor garantiza la no infracción, si ofrece una indemnización, si la indemnización excluye los prompts del usuario, si hay topes a las reclamaciones, si se excluyen ciertos casos de uso, si el cliente debe seguir la documentación, si existe filtrado de resultados y si el proveedor asiste en la defensa de las reclamaciones.

Muchos contratos con proveedores de IA limitan la responsabilidad por los resultados. Una empresa no debería presumir que el proveedor la protegerá plenamente si un tercero alega una infracción.

12. Exactitud, alucinación y confianza en los resultados

Los sistemas de IA pueden producir resultados seguros pero inexactos. A menudo se describe como alucinación, pero jurídicamente es algo más que una cuestión técnica: puede llevar a decisiones erróneas, declaraciones engañosas, servicios defectuosos, negligencia profesional, daño al consumidor o incumplimiento contractual. El contrato debería abordar si el proveedor ofrece compromisos de exactitud, si los resultados se proporcionan «tal cual», si se requiere revisión humana, si la herramienta es apta para el uso previsto, si el proveedor excluye el uso regulado o profesional, si el sistema está pensado solo como asistencia, si se conservan los registros de resultados y si los errores deben comunicarse.

La empresa debería definir cuándo puede confiarse en los resultados de la IA y cuándo es obligatoria la revisión humana. Para las decisiones de alto riesgo, la IA no debería convertirse en un decisor invisible.

13. Supervisión humana

La supervisión humana debería integrarse tanto en el contrato como en el proceso interno. Las preguntas relevantes: ¿Quién revisa los resultados de la IA? ¿La revisión es obligatoria u optativa? ¿Qué cualificación debe tener quien revisa? ¿Puede quien revisa anular el sistema? ¿Se le da información suficiente? ¿Se marcan los resultados como generados por IA? ¿Existe una vía de escalado? ¿Se documentan las decisiones? ¿Y pueden las personas afectadas impugnar los resultados?

La supervisión humana carece de sentido si la persona se limita a refrendar el sistema de IA. Para los casos de uso regulados o sensibles, la supervisión debería estar estructurada, registrada y ser auditable.

14. Cláusulas de responsabilidad

Los contratos de IA suelen contener fuertes limitaciones de responsabilidad del proveedor. Un proveedor puede excluir o limitar la responsabilidad por resultados inexactos, pérdida de datos, daño indirecto, lucro cesante, interrupción del negocio, reclamaciones de propiedad intelectual, sanciones regulatorias, uso indebido por el usuario, fallo del modelo de un tercero, incidentes de seguridad, funciones beta, uso profesional y decisiones adoptadas con base en los resultados. La empresa debería revisar si el tope de responsabilidad es apropiado: una cuota de suscripción baja puede venir con un tope comercialmente irrisorio frente al riesgo.

Para la IA crítica para el negocio, la empresa debería plantearse negociar topes más altos; responsabilidad sin tope por brechas de confidencialidad y de protección de datos; indemnización por propiedad intelectual; responsabilidad por brechas de seguridad; cooperación regulatoria; bonificaciones por servicio; derechos de terminación; y requisitos de seguro. El riesgo debería seguir al control: si el proveedor controla el modelo, la seguridad y el tratamiento de datos, el proveedor debería asumir la responsabilidad correspondiente.

15. Indemnizaciones

Las indemnizaciones son especialmente importantes en los contratos de IA. La empresa debería plantearse si necesita indemnizaciones por infracción de propiedad intelectual de terceros, brecha de protección de datos causada por el proveedor, vulneración de la confidencialidad, incidente de seguridad, infracción regulatoria causada por el sistema del proveedor, incumplimiento de las garantías del proveedor, uso no autorizado de los datos del cliente para entrenamiento, reclamaciones derivadas de los materiales del proveedor y reclamaciones derivadas de actos de subcontratistas. El proveedor también puede exigir indemnizaciones del cliente por datos de entrada ilícitos, uso indebido de la plataforma, vulneración de la política de uso aceptable, violación de derechos de terceros, uso en sectores prohibidos y falta de revisión de los resultados.

Las indemnizaciones deberían ser equilibradas y vincularse al control. Un cliente no debería asumir la responsabilidad por riesgos creados únicamente por el sistema del proveedor.

16. Políticas de uso aceptable

Los proveedores de IA suelen adjuntar políticas de uso aceptable que pueden prohibir el uso para actividades ilegales, discriminación, identificación biométrica, vigilancia, armas, engaño, asesoramiento regulado, decisiones de alto riesgo, asesoramiento médico o jurídico, calificación crediticia, decisiones laborales, persuasión política, tratamiento relacionado con menores, scraping, spam automatizado o contenido dañino. La empresa debería revisarlas con cuidado.

Un negocio puede usar sin saberlo una herramienta de IA de un modo que vulnere la política de uso aceptable del proveedor, lo que puede dar lugar a suspensión, terminación, pérdida de acceso o denegación de soporte. Si el uso previsto por la empresa está cerca de un área restringida, debería obtenerse una aclaración por escrito antes del despliegue.

17. Niveles de servicio y continuidad del negocio

Las herramientas de IA pueden volverse importantes operativamente. Si una empresa integra IA en la atención al cliente, la revisión de documentos, la programación, la logística, el cumplimiento o la analítica, el tiempo de inactividad puede afectar al negocio. El contrato debería abordar los compromisos de disponibilidad, las ventanas de mantenimiento, los tiempos de respuesta del soporte, los niveles de gravedad de los incidentes, los procedimientos de copia de seguridad, la recuperación ante desastres, la disponibilidad de la API, los límites de uso, la disponibilidad del modelo, los cambios en los modelos, la retirada de funciones, las bonificaciones por servicio y la terminación por fallos reiterados.

Una empresa también debería preguntarse si puede seguir operando si el servicio de IA deja de estar disponible. La adquisición de IA debería incluir una planificación de la continuidad del negocio.

18. Cambios en el modelo y cambios en el producto

Los sistemas de IA cambian. El proveedor puede actualizar modelos, retirar funciones, cambiar los filtros de seguridad, alterar el comportamiento de los resultados, modificar los precios, cambiar los límites de la API, introducir nuevos subencargados o descontinuar ciertas funciones, y estos cambios pueden afectar al negocio del cliente. El contrato debería abordar el aviso de cambios sustanciales, la posibilidad de rechazar cambios, el control de versiones, las actualizaciones de la documentación, las pruebas antes de cambios importantes, la compatibilidad con versiones anteriores, los derechos de terminación del cliente, la exportación de datos y la asistencia en la migración.

Para usos de bajo riesgo, los cambios de modelo pueden ser aceptables. Para la IA regulada, integrada u orientada al cliente, los cambios no controlados pueden crear riesgo jurídico y operativo.

19. Derechos de auditoría y documentación

Las empresas pueden necesitar documentación para satisfacer a clientes, inversores, reguladores o a su propia gobernanza interna. El contrato debería considerar si el proveedor facilita documentación de seguridad, información sobre el tratamiento de datos, documentación del modelo, evaluaciones de riesgo, informes de auditoría, certificaciones de cumplimiento, listas de subencargados, historial de incidentes, información sobre pruebas de sesgo, documentación relacionada con el Reglamento de IA cuando proceda, especificaciones técnicas y registros de cambios.

Es posible que los grandes proveedores de IA no concedan derechos de auditoría plenos, pero la empresa debería igualmente procurar información suficiente para valorar el riesgo. Un cliente que no puede explicar su cadena de suministro de IA puede tener dificultades durante la due diligence, la revisión regulatoria o un litigio.

20. Exposición al Reglamento de IA de la UE en los contratos con proveedores

El Reglamento de IA de la UE crea obligaciones para distintos actores según su papel y el nivel de riesgo del sistema de IA. Una empresa fuera de la UE puede tener que considerar igualmente la exposición al Reglamento de IA si suministra sistemas, servicios o resultados basados en IA a los mercados de la UE. Por ello, los contratos con proveedores de IA deberían considerar si el sistema de IA puede ser de alto riesgo, si la empresa es proveedora o responsable del despliegue, si el proveedor facilita la documentación exigida, si existen herramientas de supervisión humana, si se conservan registros, si se proporcionan instrucciones de uso, si hay información de gestión de riesgos disponible, si el proveedor coopera con las solicitudes de cumplimiento y si la herramienta es apta para el uso previsto orientado a la UE.

Aun cuando el Reglamento de IA no se aplique directamente, puede convertirse en un estándar comercial en la contratación transfronteriza. Los clientes internacionales pueden esperar documentación de gobernanza de IA como parte de la due diligence del proveedor.

21. Adquisición específica por sector

La adquisición de IA debería ser más estricta en ciertos sectores: sanidad, finanzas, seguros, empleo, educación, servicios jurídicos, inmobiliario, transporte, ciberseguridad, sector público, infraestructuras críticas, servicios para menores y plataformas orientadas al consumidor. En estos sectores, el contrato debería abordar las obligaciones específicas del sector.

Por ejemplo, la IA sanitaria puede requerir revisión clínica, de privacidad y de seguridad; la IA financiera puede requerir explicabilidad, equidad y pistas de auditoría; la IA de seguros puede afectar a la suscripción, las reclamaciones y el riesgo de discriminación; la IA de empleo puede requerir transparencia y evaluación de sesgos; la IA jurídica puede requerir confidencialidad y revisión profesional; y la IA educativa puede implicar a menores y datos sensibles de estudiantes. Unas condiciones de IA genéricas rara vez bastan para los casos de uso regulados.

22. Política interna de adquisición de IA

Las empresas deberían adoptar una política interna de adquisición de IA que defina quién puede aprobar herramientas de IA, qué herramientas están prohibidas, cuándo se requiere revisión jurídica, de protección de datos, de seguridad y de la dirección, cuándo se necesita un cuestionario del proveedor, cuándo es obligatoria la supervisión humana, qué datos no pueden cargarse, cómo comunican los empleados los incidentes de IA, cómo se conservan los contratos y quién es responsable del inventario de IA.

Sin una política interna, la adquisición de IA se fragmenta: distintos departamentos pueden comprar distintas herramientas, aceptar condiciones incoherentes y crear riesgo oculto. Un proceso central de adquisición de IA no tiene por qué frenar la innovación; protege a la empresa al tiempo que permite una adopción responsable.

23. IA en la sombra y uso por los empleados

Los empleados pueden usar herramientas de IA antes de que la dirección lo sepa: uno de los riesgos más comunes. Algunos ejemplos son cargar documentos de clientes en herramientas de IA públicas, usar IA para resumir contratos, generar código con un riesgo de licencia desconocido, usar IA para redactar respuestas a clientes, traducir documentos confidenciales, analizar datos de empleados, crear contenido de marketing con un estatus de propiedad intelectual incierto y usar cuentas personales para el trabajo de la empresa.

La empresa debería abordar la IA en la sombra directamente. Una política realista debería identificar las herramientas aprobadas, prohibir ciertas entradas de datos, explicar las reglas de confidencialidad, exigir revisión humana, ofrecer formación, crear un canal de notificación, evitar prohibiciones generales poco realistas y dar a los empleados alternativas seguras. Los empleados suelen usar IA porque les ayuda a trabajar más rápido; la solución jurídica no es la negación, sino la adopción controlada.

24. Estrategia de salida y devolución de datos

Las empresas deberían considerar el fin de la relación con el proveedor de IA antes de firmar. El contrato debería abordar los derechos de terminación, la exportación de datos, la exportación de resultados, la supresión de los datos del cliente, los certificados de supresión, la asistencia en la transición, la subsistencia de la confidencialidad, el uso continuado de los resultados, un periodo de desconexión, la eliminación de los conjuntos de datos de entrenamiento cuando sea posible, el cierre de la cuenta, la conservación de registros por el proveedor y la supresión por los subcontratistas.

La salida es especialmente importante cuando el sistema de IA queda integrado en las operaciones. Una empresa no debería quedar atada a un proveedor sin la posibilidad de recuperar los datos, conservar las pruebas y hacer una transición segura.

25. Señales de alarma en los contratos de IA

Las empresas deberían ser cautas cuando las condiciones del proveedor prevean que los datos del cliente pueden usarse para el entrenamiento sin una opción clara de exclusión; el proveedor tiene amplios derechos para usar las entradas y los resultados; la responsabilidad está casi por completo excluida; no se ofrece indemnización por propiedad intelectual; las obligaciones de confidencialidad son débiles; la supresión de datos es poco clara; los subencargados pueden cambiar sin aviso; las transferencias transfronterizas no se explican; los compromisos de seguridad son vagos; el proveedor declina toda responsabilidad por la exactitud; los resultados no pueden usarse comercialmente; el servicio puede suspenderse de forma amplia; la política de uso aceptable es demasiado amplia o poco clara; no se ofrece soporte ni respuesta a incidentes; se permiten cambios unilaterales sin un aviso significativo; la ley aplicable y el foro son inadecuados; o el uso empresarial se apoya en condiciones de nivel de consumo.

Una señal de alarma no siempre significa que el contrato no pueda firmarse. Significa que el riesgo debería entenderse, negociarse o gestionarse internamente.

26. Una lista de comprobación práctica para la adquisición de IA

Antes de adquirir una herramienta de IA, las empresas deberían preguntarse: ¿Cuál es el caso de uso previsto y la herramienta es interna o está orientada al cliente? ¿Trata datos personales o información confidencial? ¿Pueden usarse los datos del cliente para entrenar el modelo? ¿Dónde se alojan los datos y hay subencargados y transferencias transfronterizas, y son lícitas? ¿Quién es titular de las entradas y los resultados, y pueden usarse los resultados comercialmente? ¿Existe protección frente a la infracción de propiedad intelectual? ¿Son claras las limitaciones de exactitud y se requiere revisión humana? ¿Son aceptables los topes de responsabilidad y están equilibradas las indemnizaciones? ¿Es suficiente la documentación de seguridad y existen derechos de auditoría o de información? ¿Se usa la herramienta en un sector regulado y podría surgir exposición al Reglamento de IA de la UE? ¿Existe una política interna de IA, están formados los empleados y se controla la IA en la sombra? ¿Qué ocurre si el servicio se suspende y pueden devolverse o suprimirse los datos a la salida? ¿Y se ha completado la revisión jurídica, de protección de datos y de seguridad?

Las respuestas deberían entonces orientar la decisión de adquisición: si firmar, negociar, restringir el caso de uso o declinar.

Preguntas frecuentes

¿Por qué los contratos con proveedores de IA son distintos de los contratos de software corrientes?

Las herramientas de IA pueden tratar datos sensibles, generar resultados impredecibles, usar los datos del cliente para mejorar el modelo, crear riesgo de propiedad intelectual, afectar a personas y depender de cadenas complejas de subcontratistas. Estas cuestiones exigen una revisión jurídica más cuidadosa que una adquisición de software corriente.

¿Puede un proveedor de IA usar los datos de nuestra empresa para entrenar su modelo?

Depende de las condiciones del proveedor. Las empresas deberían revisar si los prompts, los documentos cargados, los resultados o los comentarios pueden usarse para entrenamiento o mejora del servicio, y si existen opciones de exclusión o protecciones empresariales.

¿Quién es titular de los resultados generados por IA?

La titularidad depende de las condiciones de la herramienta de IA, la ley aplicable y la naturaleza del resultado. Las empresas no deberían presumir que son titulares de los resultados ni que pueden usarlos comercialmente sin revisar el contrato.

¿Cuáles son los principales riesgos jurídicos en la adquisición de IA?

Entre los riesgos clave están la protección de datos, la confidencialidad, la infracción de propiedad intelectual, los resultados inexactos, los límites de responsabilidad del proveedor, las transferencias transfronterizas, la seguridad, la IA en la sombra, la exposición en sectores regulados, la relevancia del Reglamento de IA de la UE y unos derechos de salida poco claros.

¿Deberían las empresas tener una política interna de IA?

Sí. Una política interna de IA ayuda a controlar el uso por los empleados, las herramientas aprobadas, las entradas prohibidas, la revisión humana, la confidencialidad, la protección de datos, la aprobación de adquisiciones y la notificación de incidentes.

¿Es relevante el cumplimiento del Reglamento de IA de la UE fuera de la UE?

Puede ser relevante cuando se suministran sistemas, resultados o servicios basados en IA al mercado de la UE o cuando los usan clientes de la UE. También puede influir en las expectativas comerciales en la contratación internacional.

¿Deberían los contratos de IA incluir disposiciones de supervisión humana?

Para casos de uso sensibles o de alto impacto, sí. El contrato y el proceso interno deberían dejar claro cuándo se requiere revisión humana y quién es responsable de verificar los resultados.

¿Qué deberían hacer las empresas antes de firmar un acuerdo con un proveedor de IA?

Deberían definir el caso de uso, realizar la due diligence del proveedor y revisar el tratamiento de datos, la confidencialidad, la propiedad intelectual, la responsabilidad, la seguridad, las transferencias transfronterizas, el uso aceptable, los derechos de auditoría, la exposición regulatoria y las condiciones de salida.

Conclusión

La adquisición de IA se está convirtiendo en una cuestión jurídica a nivel de consejo. Una empresa que adopta IA sin revisar las condiciones del proveedor puede exponerse a riesgos de protección de datos, vulneraciones de la confidencialidad, reclamaciones de propiedad intelectual, resultados inexactos, uso indebido por los empleados, escrutinio regulatorio, quejas de clientes y dependencia operativa.

El enfoque más sólido no es evitar la IA, sino adquirirla con disciplina. Las empresas deberían entender el sistema, revisar el contrato, controlar los datos, definir la supervisión humana, repartir la responsabilidad, conservar las pruebas, formar a los empleados y planificar la salida. La IA solo puede crear valor si la estructura jurídica que la sostiene es lo bastante sólida para soportar el riesgo.

Cómo puede ayudar Terziolu & Partners

Terziolu & Partners asesora a empresas, inversores, emprendedores y clientes privados en asuntos jurídicos de Turquía, el norte de Chipre y transfronterizos. Nuestro trabajo puede incluir la revisión de contratos con proveedores de IA; el asesoramiento sobre adquisición de IA empresarial; la preparación de listas de comprobación de due diligence de proveedores de IA; la redacción de condiciones de IA SaaS y de cliente; la preparación de políticas internas de adquisición de IA; el asesoramiento sobre cuestiones de protección de datos relacionadas con la IA; la revisión de los riesgos de confidencialidad y de datos de entrenamiento; el asesoramiento sobre titularidad de los resultados de IA y exposición de propiedad intelectual; la evaluación del riesgo contractual relacionado con el Reglamento de IA de la UE; el apoyo a la due diligence jurídica relacionada con la IA en inversiones y adquisiciones; y la coordinación con asesores técnicos, de protección de datos y abogados extranjeros cuando sea necesario.

Comente un contrato con un proveedor de IA, una adquisición de IA empresarial o un asunto de gobernanza de IA con nuestro equipo.

Este artículo se ofrece únicamente con fines informativos generales y no constituye asesoramiento jurídico. Los riesgos de la adquisición de IA y de los contratos con proveedores pueden variar según el sistema de IA, las condiciones del proveedor, los datos tratados, el sector, la jurisdicción, la estructura contractual, la exposición regulatoria, la base de clientes, el uso previsto y el momento del asesoramiento. No debería adoptarse ni omitirse ninguna acción basándose únicamente en esta publicación. Debería obtenerse asesoramiento jurídico, técnico, de protección de datos, de ciberseguridad y comercial específico antes de adquirir, desplegar, integrar o confiar en un sistema de IA. La presentación de una consulta a Terziolu & Partners no crea una relación abogado-cliente, salvo que el encargo se acepte formalmente por escrito y hasta ese momento.