¿Qué es la contratación y adquisición de IA?
Gobernanza, riesgo y aseguramiento
La contratación y adquisición de IA es el proceso de comprar IA a un tercero de forma que los riesgos, las obligaciones legales y las expectativas operativas se conviertan en condiciones exigibles. Abarca la diligencia previa a la adjudicación, las preguntas del pliego, las declaraciones, las cláusulas sobre datos y propiedad intelectual, los derechos de auditoría, el registro de actividad, la notificación de incidentes, el control de cambios, la supervisión humana y la planificación de salida. En la práctica, es el mecanismo por el que un comprador hace que un sistema de IA de terceros sea gobernable antes de su uso y controlable tras su implantación.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La adquisición de IA no es simplemente la compra habitual de software con terminología nueva. Cuando una organización adquiere una herramienta de IA, un modelo, una API, una función de plataforma o un sistema a medida de un tercero, puede estar dependiendo de datos de entrenamiento que no ha recopilado, de modelos que no puede inspeccionar plenamente y de ciclos de actualización que no controla. Eso plantea un problema de compra diferente al de la adquisición estándar de tecnología.
La parte de adquisición es la fase inicial. Pregunta si la IA es adecuada en absoluto, qué uso se pretende dar, cuál es el nivel de riesgo de ese uso, qué debe revelar el proveedor y qué evidencia necesita el comprador antes de la adjudicación. La parte contractual es el instrumento jurídico que traslada esas respuestas a obligaciones, derechos, restricciones y requisitos de evidencia.
También es más acotada que un programa completo de gestión de riesgos de IA de terceros. La gestión de riesgos de IA de terceros abarca todo el ciclo de vida. La contratación y adquisición de IA es el momento en que la organización traduce las expectativas generales de gobernanza en preguntas concretas al proveedor, anexos, aprobaciones, controles y vías de escalada.
Por qué importa
Muchas organizaciones utilizan hoy IA que no han desarrollado internamente. Eso puede ser eficiente, pero también significa que decisiones de diseño importantes pueden quedar fuera del control directo del comprador. El comprador puede seguir cargando con la responsabilidad práctica si el sistema es inexacto, injusto, inseguro, difícil de explicar, difícil de desactivar o incompatible con la protección de datos, el derecho público o las expectativas del sector.
Por eso la adquisición de IA es relevante en materia de regulación y gobernanza. Es uno de los principales mecanismos que convierte obligaciones abstractas, como la transparencia, la supervisión humana, el registro de actividad, la privacidad, la seguridad, la documentación y la rendición de cuentas, en algo operativo. Si esos controles no se incorporan al proceso de compra y al contrato, la organización puede acabar siendo responsable de los efectos de un sistema sin contar con el poder de negociación ni la evidencia necesaria para gestionarlo.
Cómo funciona
Comenzar con el caso de uso y el mapa de roles
La adquisición de IA comienza por definir qué se está comprando exactamente y cómo se utilizará. Un comprador puede estar adquiriendo acceso a un modelo a través de una API, una aplicación terminada, una función de IA integrada en otro producto, un desarrollo a medida o una capa de integración que combina varios componentes de terceros. Estas opciones parecen similares en un proceso de venta, pero generan dependencias distintas y roles jurídicos diferentes.
Ese mapa de roles importa porque las leyes de IA y los marcos de control suelen asignar obligaciones al rol que se desempeña, no solo a la etiqueta del producto. En virtud del EU AI Act, las responsabilidades se distribuyen entre proveedores, responsables del despliegue, importadores, distribuidores y otras partes de la cadena de valor. Un tercero que modifique el propósito previsto, realice una modificación sustancial o ponga su propio nombre en un sistema de alto riesgo puede pasar a asumir las obligaciones del proveedor. Para un comprador, esto significa que la adquisición debe identificar desde el principio si la organización es únicamente responsable del despliegue o si sus decisiones de integración podrían situarla en una posición de cumplimiento más exigente.
En esta fase, la organización también debe decidir si la adquisición requiere controles reforzados. Los factores desencadenantes habituales incluyen el uso en decisiones sobre personas, el uso en servicios públicos, el uso de datos personales, la dependencia de un modelo de uso general o de múltiples subencargados, la dificultad de explicabilidad, las implicaciones para la seguridad, la transferencia transfronteriza de datos o una dependencia crítica del proveedor para el seguimiento y el mantenimiento.
La responsabilidad suele recaer en los responsables de adquisición o comerciales y en el asesor jurídico, pero el contenido debe provenir de un grupo multidisciplinar. En la práctica, eso incluye a los responsables técnicos, privacidad, seguridad, gestión documental, operaciones de servicio y el equipo de negocio que utilizará el sistema en producción.
Convertir el riesgo de IA en preguntas del pliego
Una vez definido el uso previsto, la organización convierte el riesgo en diligencia estructurada. Las orientaciones oficiales son notablemente coherentes en este punto. Los compradores deben preguntar no solo qué hace el sistema, sino cómo está construido, de qué datos depende, cómo se prueba, cómo evoluciona con el tiempo y qué restricciones se aplican a la inspección, la impugnación y la salida.
Para muchas adquisiciones, las preguntas fundamentales son estables. Cuál es el tipo de modelo y la arquitectura del sistema. Qué modelos, datos, herramientas o complementos de terceros subyacen a él. Qué categorías de datos se utilizaron para el entrenamiento, el ajuste fino o la recuperación de referencias. Qué información puede facilitarse sobre procedencia, licencias y derechos. Qué pruebas de rendimiento se han realizado, en qué condiciones y con qué limitaciones. Qué instrucciones de uso, documentación técnica, registros y contactos de soporte estarán disponibles. Qué prácticas de alojamiento, transferencia geográfica, retención o uso secundario se aplican. Qué supuestos de supervisión humana asume el sistema. Cómo se notifican los incidentes, las vulnerabilidades y los cambios materiales. Qué alternativas existen si el servicio se degrada, se retira o deja de ser adecuado.
Una buena adquisición de IA también evalúa la madurez operativa del proveedor, no solo la descripción del producto. El manual de NIST y su perfil de IA generativa orientan a los compradores hacia la documentación de componentes de terceros, los procesos de prueba y verificación independientes, los planes de seguimiento, las comprobaciones de cumplimiento legal, la conciencia sobre los ciclos de publicación y la gestión clara de vulnerabilidades y dependencias externas. Las orientaciones del gobierno del Reino Unido también dirigen a los compradores hacia preguntas sobre el modelo y los datos, la explicabilidad, la auditoría independiente cuando sea útil y la consideración temprana de la dependencia del proveedor, la responsabilidad, la formación y el fin de vida útil.
Este es el momento en que la organización debe decidir qué evidencia debe existir antes de la firma del contrato. Eso suele incluir documentación técnica y de usuario, evaluaciones de riesgos, materiales de privacidad cuando se traten datos personales, materiales de seguridad, respuestas del proveedor sobre las limitaciones del modelo, información sobre subencargados y una vía de escalada documentada para incidentes y cambios.
Redactar cláusulas que asignen responsabilidad, no solo riesgo
Un contrato de IA sólido hace más que trasladar la responsabilidad. Hace que el sistema sea gobernable. En la práctica, esto significa utilizar el contrato para definir el propósito, la transparencia, los puntos de control, la generación de evidencia y las obligaciones de cooperación.
La primera categoría de cláusulas abarca las declaraciones del proveedor y los compromisos de hecho. Según el caso de uso, los compradores suelen buscar declaraciones sobre la autoridad del proveedor para suministrar el sistema, los derechos asociados a los datos y los componentes del modelo que incorpora al servicio, la exactitud de la información facilitada durante la adquisición, la existencia de limitaciones materiales conocidas y la capacidad del proveedor para respaldar afirmaciones importantes sobre rendimiento, seguridad o procedencia. Para la IA generativa, NIST orienta específicamente a los compradores hacia la titularidad, los derechos de uso, los estándares de calidad, los requisitos de seguridad, las expectativas de procedencia, la diligencia debida en materia de propiedad intelectual y riesgo de privacidad, y los controles contractuales de riesgo, incluidas cláusulas de indemnización y mecanismos de resolución de disputas cuando proceda.
La segunda categoría abarca los datos y la privacidad. Si el proveedor trata datos personales por cuenta del comprador, las condiciones ordinarias de adquisición no son suficientes. El contrato también necesita cláusulas de responsable-encargado del tratamiento. El artículo 28 del GDPR es el ejemplo más claro y maduro de lo que eso implica: instrucciones documentadas, confidencialidad, medidas de seguridad, controles sobre subencargados, asistencia con solicitudes de derechos y evaluaciones de impacto, devolución o supresión de datos al finalizar el servicio y acceso a la información necesaria para auditorías e inspecciones. Si los datos salen del ámbito jurídico pertinente, también pueden ser necesarias cláusulas de transferencia internacional. Aquí es donde las cuestiones de residencia y soberanía de los datos entran en el contrato, aunque no sean el mismo tema que la adquisición de IA en sí.
La tercera categoría abarca la documentación específica de IA y los controles operativos. El comprador de IA suele necesitar documentación técnica, instrucciones de uso, disposiciones de registro, requisitos de supervisión humana, umbrales de exactitud y robustez, expectativas de ciberseguridad, notificación de incidentes y control de cambios. Las cláusulas modelo del comprador público de la UE son útiles porque exponen estos temas con claridad: gestión de riesgos, datos y gobernanza de datos, documentación técnica, mantenimiento de registros, transparencia, supervisión humana, exactitud, robustez, ciberseguridad, derechos sobre conjuntos de datos, traspaso e indemnizaciones. Incluso cuando esas cláusulas no se utilizan directamente, muestran la anatomía actual de un contrato de IA serio.
La cuarta categoría abarca la propiedad intelectual, los conjuntos de datos y la salida. La adquisición de IA suele fallar cuando los compradores se centran en el acceso durante la vigencia del contrato pero ignoran qué ocurre al final. Los derechos sobre los conjuntos de datos, el acceso a registros exportables, el traspaso de los datos del comprador, los derechos a seguir utilizando la documentación, el apoyo a la transición, la transferencia de conocimiento y las obligaciones de desmantelamiento deben diseñarse desde el principio. Eso importa no solo para la continuidad, sino también para reducir la dependencia del proveedor y preservar la evidencia necesaria para auditorías o impugnaciones posteriores.
Hacer reales la auditoría, el seguimiento y el control de cambios
Los derechos de auditoría en los contratos de IA son importantes, pero a menudo se malinterpretan. No se refieren únicamente al acceso al código fuente y no son útiles si se dejan como texto estándar vago. La pregunta real es qué debe poder inspeccionar o verificar el comprador para operar de forma legal y segura en su contexto.
Un modelo de auditoría proporcionado suele funcionar mejor. Para usos de menor riesgo, puede significar el derecho a revisar políticas, documentación, registros, avisos de incidentes, resúmenes de pruebas, instrucciones del sistema y listas de subencargados. Para usos de mayor riesgo, puede extenderse a información técnica más detallada, acceso para evaluadores independientes, acceso a registros en tiempo real o periódico, validación de los controles de cambios y evidencia de que el proveedor mantiene los controles prometidos en la adjudicación. El manual de NIST es especialmente claro en que la IA de terceros debe estar documentada, probada, supervisada y sometida a controles de riesgo documentados. También señala que la transparencia debe apoyarse sin forzar la divulgación innecesaria de algoritmos propietarios.
El seguimiento tras la firma es tan importante como la diligencia previa a la adjudicación. Muchos sistemas de IA cambian mediante reentrenamiento, ajuste, sustitución de modelos, actualizaciones de funciones, modificación de umbrales o variación de dependencias externas. Los contratos, por tanto, necesitan un régimen práctico de gestión de cambios. Los compradores suelen necesitar notificación de cambios materiales, el derecho a reevaluar el impacto cuando el sistema cambia, la posibilidad de pausar o restringir el uso cuando el riesgo aumenta y un proceso alternativo si un modelo o servicio crítico queda deshabilitado. Para la IA generativa en particular, NIST apunta a la planificación de contingencias, la respuesta a incidentes, la gestión de dependencias de terceros y la revisión de condiciones no estándar del proveedor que puedan ampliar o diferir la responsabilidad de formas inesperadas.
Esta capa de seguimiento es también donde la retención de registros se convierte en un activo de gobernanza. Una buena adquisición y contratación debe generar un rastro de evidencia, no solo un acuerdo firmado. Esa evidencia suele incluir respuestas al pliego, anexos técnicos, anexos de privacidad, evaluaciones de riesgos, aprobaciones, registros, avisos de cambios, registros de incidentes, informes de revisión, registros de formación y materiales de salida. En conjunto, esos registros ayudan a la organización a responder ante reguladores, auditores, clientes, órganos de gobierno y revisores internos.
Adaptar el conjunto de controles al sector público y a los usos de alto impacto
Los entornos del sector público y otros de alto impacto suelen necesitar más estructura porque el comprador debe poder justificar el uso de IA en contextos administrativos o que afectan a derechos, no solo llevar a cabo un proceso de adquisición.
Las orientaciones del gobierno del Reino Unido sobre adquisición de IA muestran un camino posible. Tratan la compra de IA como un ejercicio multidisciplinar, exigen una evaluación de datos antes de salir al mercado, esperan que los compradores permanezcan abiertos a enfoques sin IA, piden transparencia sobre los modelos y los datos de entrenamiento, fomentan la reflexión sobre auditorías independientes, se oponen a la dependencia de sistemas opacos y llevan la responsabilidad, la formación, el mantenimiento y el fin de vida útil al diseño de la adquisición. Se trata de orientaciones y no de derecho vinculante, pero son influyentes porque traducen objetivos generales de gobernanza en práctica concreta de adquisición.
El marco federal de Canadá añade una capa de evaluación más formal para los sistemas automatizados de decisión administrativa. La Evaluación de Impacto Algorítmico es obligatoria para los sistemas en su ámbito de aplicación, asigna niveles de impacto y vincula esos niveles a requisitos escalonados. Las orientaciones oficiales esperan consultas de privacidad y jurídicas, evidencia documental para las respuestas a la evaluación, actualizaciones cuando cambia la funcionalidad o el alcance del sistema y cláusulas de privacidad adecuadas en los contratos con proveedores externos. Las orientaciones sobre revisión por pares añaden otra capa operativa al exigir la publicación de la revisión por pares para proyectos en nivel de impacto 2 o superior y al enumerar los tipos de documentación que deben recibir los revisores, incluidos registros de auditoría, documentación del sistema y del modelo, procedencia de los datos, mitigación de riesgos, materiales de seguridad de la cadena de suministro y detalles de adquisición para sistemas desarrollados o adquiridos externamente.
En la UE, la posición jurídica es aún más sólida. El AI Act impone obligaciones vinculantes a los proveedores y responsables del despliegue de sistemas de alto riesgo, incluidos acuerdos escritos a lo largo de la cadena de valor, medidas técnicas y organizativas para el uso conforme a las instrucciones, supervisión humana, seguimiento, retención de registros y, en algunos casos, una evaluación de impacto sobre los derechos fundamentales antes del despliegue. El derecho a la explicación de determinadas decisiones individuales ofrece a los compradores otra razón para contratar suficiente transparencia y cooperación que permita explicar cómo el sistema influyó en una decisión. Las cláusulas modelo del comprador público de la UE no son derecho y están redactadas para organizaciones públicas, pero constituyen un puente práctico entre las obligaciones legales del AI Act y la compra cotidiana.
Conocer qué puede y qué no puede hacer este mecanismo
La contratación y adquisición de IA es poderosa, pero no es mágica. Un contrato no puede hacer explicable un sistema opaco si el proveedor no puede dar soporte técnico a esa explicación. No puede subsanar una gobernanza interna débil. No puede eliminar la necesidad de evaluaciones de impacto, registro de actividad, formación del personal, revisión humana o seguimiento posterior al despliegue. Solo puede asegurar los derechos, las obligaciones, la evidencia y la cooperación que la organización necesita para gobernar el sistema adecuadamente.
También requiere proporcionalidad. No toda función de IA justifica un conjunto de cláusulas de alto riesgo. El comentario del comprador público de la UE es útil aquí porque reconoce explícitamente variantes más ligeras y más completas, y explica que incluso los usos que no son de alto riesgo pueden requerir cláusulas contractuales sobre gestión de riesgos, gobernanza de datos, documentación técnica, derechos sobre conjuntos de datos y registros. El objetivo no es copiar la redacción más exigente en cada acuerdo, sino adaptar el conjunto de controles al caso de uso.
Por último, el estatus jurídico varía según los instrumentos. El marco y los perfiles de NIST son voluntarios. Las orientaciones de adquisición del Reino Unido son un conjunto de herramientas gubernamentales. El marco federal de Canadá es un instrumento de política del sector público. El EU AI Act y el GDPR son regímenes jurídicos vinculantes. Una buena adquisición de IA reconoce esa combinación y utiliza el material voluntario para operacionalizar el material vinculante, no para sustituirlo.
Ejemplos
Una autoridad pública de la UE quiere adquirir un sistema que quedará clasificado como de alto riesgo en virtud del AI Act. Antes del despliegue, necesita información suficiente del proveedor para utilizar el sistema conforme a las instrucciones, asignar una supervisión humana significativa, mantener registros y, cuando el AI Act lo exija, completar una evaluación de impacto sobre los derechos fundamentales. El comprador público puede utilizar las cláusulas modelo de la UE como plantilla de redacción para la gestión de riesgos, la gobernanza de datos, la documentación técnica, la transparencia, la supervisión humana, la ciberseguridad, los derechos sobre conjuntos de datos y el traspaso.
Un departamento federal canadiense quiere adquirir una herramienta de decisión automatizada para un proceso administrativo. El equipo del proyecto completa la Evaluación de Impacto Algorítmico en la fase de diseño y de nuevo antes de la puesta en producción. Si el proyecto alcanza el nivel de impacto 2 o superior, encarga una revisión por pares y publica la revisión o un resumen en lenguaje claro antes de que el sistema entre en funcionamiento. Se espera que el paquete de revisión incluya registros de auditoría, documentación del modelo y del sistema, procedencia de los datos, materiales de privacidad, mitigación de riesgos, información de seguridad de la cadena de suministro para el software desarrollado o adquirido externamente y detalles de adquisición para sistemas de terceros.
Un organismo público del Reino Unido está considerando una herramienta de IA suministrada externamente para apoyar la clasificación de servicios. Antes del pliego, realiza una evaluación de datos, documenta por qué la IA es pertinente para el problema y mantiene el requisito lo suficientemente abierto para que los proveedores puedan proponer enfoques diferentes. En la invitación a licitación, pregunta sobre algoritmos, origen de los datos, limitaciones del modelo, explicabilidad, posible auditoría independiente, acuerdos de propiedad intelectual, formación, soporte y fin de vida útil. A continuación, traslada esos puntos al contrato para que las promesas del proveedor no desaparezcan tras la adjudicación.
Malentendidos frecuentes
Un malentendido habitual es pensar que si el proveedor dice ser "conforme", el comprador queda cubierto. En realidad, los compradores suelen mantener sus propias obligaciones como responsables del despliegue, responsables del tratamiento, empleadores, prestadores de servicios o empresas reguladas. El cumplimiento del proveedor ayuda, pero no sustituye las obligaciones del comprador.
Otro error es tratar la adquisición de IA principalmente como una revisión de seguridad. La seguridad importa, pero los contratos de IA también necesitan documentación, gobernanza de datos, supervisión humana, explicabilidad, registro de actividad, control de cambios, propiedad intelectual y planificación de salida.
Algunos equipos asumen que los derechos de auditoría siempre implican acceso al código fuente. No es así. Un modelo de auditoría viable puede ser escalonado y proporcionado. Puede basarse en documentación, registros, registros de pruebas, garantías independientes y notificación de incidentes, reservando el acceso más profundo para los casos de mayor riesgo.
También es un error pensar que la adquisición concluye cuando se firma el contrato. Los sistemas de IA pueden cambiar materialmente tras la adjudicación. El seguimiento, la reactivación de evaluaciones, la revisión de versiones y la conservación de evidencia forman parte de la lógica de control de la adquisición, no son un complemento opcional.
Por último, muchos equipos creen que esto solo importa para usos del sector público o claramente de alto riesgo. La intensidad jurídica es mayor en esos casos, pero la misma lógica de adquisición también es relevante para despliegues de menor riesgo cuando el sistema implica datos personales, datos confidenciales, procesos de negocio importantes, contenido orientado al cliente o dependencias difíciles de sustituir.
Riesgos y límites
La contratación y adquisición de IA no es lo mismo que una política de IA, un sistema de gestión de IA o un programa completo de gestión de riesgos de IA de terceros. Es un mecanismo dentro de ese conjunto más amplio de gobernanza. Si la aprobación interna, el seguimiento, los registros, la escalada y la formación del personal son débiles, incluso un contrato bien redactado tendrá un rendimiento inferior al esperado.
También existen límites de transparencia difíciles de superar. Algunos proveedores, especialmente en torno a los modelos de uso general y generativos, pueden no estar en condiciones o no estar dispuestos a facilitar información detallada sobre los datos de entrenamiento, los componentes internos del modelo o las dependencias de la cadena de suministro. Eso no significa que el comprador deba aceptar esa laguna. Significa que el comprador debe decidir si un uso más limitado, una revisión humana más sólida, una exposición de datos más restringida o la no adquisición es la opción más segura.
Las cláusulas modelo públicas también tienen límites. El comentario de las MCC-AI de la UE establece claramente que las cláusulas modelo no constituyen un acuerdo completo. No sustituyen al resto del contrato en materia de pago, entrega, ley aplicable, aceptación o responsabilidad general. Tampoco fueron redactadas específicamente para la adquisición de IA de uso general, aunque pueden seguir proporcionando una estructura útil.
Algunos detalles jurídicos y operativos siguen evolucionando. En virtud del EU AI Act, las normas armonizadas están aún en desarrollo y la Oficina de IA puede publicar condiciones modelo voluntarias para contratos en cadenas de valor de IA de alto riesgo. Eso significa que los compradores deben evitar suponer que una sola plantilla resolverá todas las cuestiones para cada tipo de modelo o jurisdicción.
Qué hacer a continuación
En primer lugar, decidir qué adquisiciones necesitan un proceso reforzado de adquisición de IA. No toda función de IA requiere el mismo nivel de diligencia. Conviene crear un proceso de clasificación sencillo que evalúe el uso previsto, el impacto sobre personas, la sensibilidad de los datos, las dependencias externas, las exigencias de explicabilidad y la dificultad de sustitución.
En segundo lugar, crear una biblioteca reutilizable de cláusulas y evidencias. Separar las condiciones básicas del proveedor de los anexos de IA reforzados para que los equipos puedan escalar los controles hacia arriba o hacia abajo. Incluir, cuando proceda, cláusulas de tratamiento de datos, registro de actividad, aviso de incidentes, control de cambios, supervisión humana, documentación, derechos sobre conjuntos de datos, derechos de auditoría y apoyo a la salida.
En tercer lugar, exigir evidencia, no garantías genéricas. Preguntar qué documentación estará disponible antes de la adjudicación, qué registros se conservarán durante el uso, qué cambios deben notificarse y qué entregará el proveedor al finalizar el contrato. Si el sistema es demasiado importante para confiar en él ciegamente, es lo suficientemente importante como para documentarlo adecuadamente.
En cuarto lugar, vincular el proceso de compra al resto de la gobernanza. La adquisición debe alimentar la política de IA, el sistema de gestión de IA, la revisión de IA de terceros, las decisiones sobre ubicación de datos y el enfoque de retención de registros. Si estos elementos están en silos, los controles contractuales se desconectarán de la realidad operativa.
Por último, formar a las personas que compran y gestionan contratos. Los equipos comerciales, jurídicos, de privacidad, seguridad y producto necesitan un vocabulario compartido sobre riesgo de modelos, derechos sobre datos, explicabilidad, seguimiento y desmantelamiento. La adquisición de IA solo se vuelve repetible cuando la organización sabe qué preguntas hacer y qué evidencia es aceptable.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es la adquisición de IA simplemente la adquisición de software con una etiqueta nueva?
No. Incluye la compra de software, pero también aborda la opacidad de los modelos, los datos de entrenamiento y de referencia, el comportamiento cambiante del sistema, la supervisión humana, la retención de evidencia y las dependencias de la cadena de valor que los contratos de software ordinarios suelen dejar implícitas.
¿Quién debe ser responsable de la contratación y adquisición de IA dentro de una organización?
Habitualmente, los equipos de adquisición o comerciales y jurídicos son los responsables del proceso, pero no deben trabajar solos. Una responsabilidad efectiva también requiere aportaciones técnicas, de privacidad, seguridad, gestión documental, operaciones y negocio.
¿Cuáles son las cláusulas mínimas específicas de IA que hay que considerar?
Como mínimo, conviene considerar el propósito previsto, la documentación, el uso de datos, el registro de actividad, la notificación de incidentes, el control de cambios, la supervisión humana, las pruebas de rendimiento, los subencargados, el acceso de auditoría y la salida o el traspaso. El uso de datos personales también puede requerir un anexo de tratamiento de datos específico.
¿Siempre se necesitan derechos de auditoría?
No siempre en la misma forma, pero algún derecho de verificación suele ser razonable. Cuanto mayor sea el impacto y menos transparente sea el sistema, más sólido será el argumento a favor de la revisión documental, el acceso a registros, la garantía independiente y la notificación estructurada de cambios.
¿En qué se diferencia esto de un acuerdo de tratamiento de datos?
Un acuerdo de tratamiento de datos cubre las obligaciones de privacidad cuando el proveedor trata datos personales por cuenta del comprador. La contratación y adquisición de IA es más amplia. También abarca la documentación del modelo, la explicabilidad, el rendimiento, la revisión humana, la gestión de incidentes, la propiedad intelectual, la continuidad y la salida.
¿Qué ocurre si el proveedor depende de modelos fundacionales u otros proveedores de la cadena de suministro?
En ese caso, el contrato debe abordar directamente el riesgo de dependencia de la cadena de suministro. Conviene preguntar sobre subencargados, sustituciones de modelos, ciclos de publicación, planes alternativos, aviso de cambios, uso de datos por parte de los proveedores de la cadena de suministro y qué transparencia puede trasladar de forma realista el proveedor.
¿Cuándo se debe rechazar a un proveedor?
Un comprador debe estar dispuesto a rechazar a un proveedor cuando este no pueda ofrecer el nivel de documentación, control, cooperación ante incidentes o apoyo a la salida que el caso de uso requiere, especialmente cuando el sistema afecta a personas, funciones públicas, datos sensibles u operaciones críticas.