Última actualización: 30 de julio de 2026.
Elegir un proveedor de inteligencia artificial no debería consistir únicamente en comparar funciones, precios y opiniones de otros usuarios.
Una herramienta puede parecer adecuada durante una demostración y, sin embargo, presentar problemas cuando se utiliza con datos reales, se conecta a sistemas internos o empieza a influir en decisiones de la empresa.
Antes de contratarla conviene conocer:
- Qué sistema se está adquiriendo realmente.
- Quién lo desarrolla.
- Qué modelo utiliza.
- Para qué finalidades está diseñado.
- Qué datos recibe.
- Si utiliza esos datos para entrenar o mejorar sus modelos.
- Dónde se almacena la información.
- Qué empresas intervienen.
- Qué medidas de seguridad existen.
- Qué errores y limitaciones son conocidos.
- Qué controles puede aplicar la empresa.
- Qué documentación proporciona el proveedor.
- Qué ocurrirá si cambia el modelo o las condiciones.
- Cómo pueden recuperarse los datos al finalizar el contrato.
La evaluación debe ser proporcional.
Una herramienta que corrige textos públicos no requiere el mismo análisis que un sistema conectado al correo, un chatbot que consulta pedidos o una solución que ayuda a seleccionar candidatos.
Evaluación de proveedores de IA: resumen rápido
Antes de contratar una solución de inteligencia artificial, una empresa debería:
- Definir la finalidad exacta.
- Identificar los datos que recibirá.
- Determinar quiénes pueden verse afectados.
- Comprobar el papel de cada organización.
- Analizar si el sistema puede ser de alto riesgo.
- Revisar las condiciones de privacidad.
- Comprobar si los datos se utilizan para entrenamiento.
- Identificar subencargados y transferencias internacionales.
- Revisar las medidas de seguridad.
- Analizar la precisión y las limitaciones.
- Comprobar la supervisión humana.
- Revisar logs y trazabilidad.
- Evaluar las integraciones y permisos.
- Analizar las obligaciones de transparencia.
- Revisar propiedad intelectual y confidencialidad.
- Negociar obligaciones contractuales.
- Preparar un plan de salida.
- Realizar una prueba controlada antes del despliegue completo.
- Documentar la decisión.
- Revisar periódicamente al proveedor.
La pregunta correcta no es:
¿Este proveedor cumple el AI Act?
La pregunta útil es:
¿Qué obligaciones corresponden a este sistema, qué evidencias aporta el proveedor y qué controles seguirá teniendo que implantar nuestra empresa?
Proveedor comercial y proveedor conforme al AI Act
En el lenguaje habitual, se llama proveedor a cualquier empresa que vende software o presta un servicio.
El concepto jurídico de proveedor del AI Act es más específico. Se refiere, de forma general, a quien desarrolla un sistema de IA o encarga su desarrollo y lo comercializa o pone en servicio bajo su propio nombre o marca.
La empresa que vende o integra la solución también podría actuar como:
- Proveedor.
- Importador.
- Distribuidor.
- Integrador.
- Encargado del tratamiento.
- Responsable independiente.
- Subencargado.
- Prestador de servicios tecnológicos.
No debe darse por supuesto que la empresa que firma el contrato es quien ha desarrollado el modelo o asume todas las obligaciones del AI Act.
Además, un distribuidor, importador, responsable del despliegue u otro tercero puede convertirse en proveedor de un sistema de alto riesgo cuando coloca su nombre o marca, realiza una modificación sustancial o cambia la finalidad prevista de forma que el sistema pase a considerarse de alto riesgo.
La empresa compradora no transfiere toda la responsabilidad
Contratar una solución conocida no elimina las obligaciones de la empresa que decide utilizarla.
La empresa compradora debe determinar:
- Si el sistema es adecuado para la finalidad.
- Qué datos pueden utilizarse.
- Qué personas pueden acceder.
- Qué revisión humana se necesita.
- Qué información debe facilitarse.
- Qué riesgos permanecen bajo su control.
- Qué medidas debe aplicar durante el uso.
En protección de datos, la empresa que determina la finalidad y los medios esenciales del tratamiento puede actuar como responsable aunque utilice tecnología de un tercero. Si el proveedor trata datos por cuenta de la empresa, sus obligaciones deben establecerse en un contrato u otro acto jurídico vinculante. Ese contrato debe regular, entre otros aspectos, qué sucede con los datos cuando finaliza la prestación.
Para sistemas de alto riesgo, los responsables del despliegue deben utilizarlos conforme a las instrucciones, asignar supervisión humana competente, controlar su funcionamiento, gestionar adecuadamente los datos de entrada cuando corresponda y conservar determinados registros bajo su control.
Antes de contactar con proveedores: definir el caso de uso
Una evaluación no puede realizarse correctamente sin conocer para qué se quiere utilizar la herramienta.
No es suficiente indicar:
Queremos implantar inteligencia artificial para mejorar la productividad.
Debe concretarse:
Queremos una herramienta que genere primeros borradores de respuestas comerciales utilizando únicamente información pública y que no envíe mensajes sin revisión humana.
Otro ejemplo:
Queremos un chatbot que responda sobre pedidos y devoluciones, consulte el estado del envío y derive al personal las reclamaciones o solicitudes no previstas.
La finalidad permite determinar:
- Qué funciones son necesarias.
- Qué datos recibirá.
- Qué integraciones necesita.
- Qué autonomía puede concederse.
- Qué errores serían aceptables.
- Qué consecuencias tendría un fallo.
- Qué obligaciones pueden resultar aplicables.
- Qué información debe exigirse al proveedor.
Preparar una ficha previa de necesidades
Antes de comparar servicios conviene documentar:
| Campo | Ejemplo |
|---|---|
| Finalidad | Preparar borradores de respuestas comerciales |
| Usuarios | Equipo comercial |
| Personas afectadas | Clientes potenciales |
| Datos | Información de contacto y consultas |
| Fuentes | Catálogo y documentación pública |
| Resultado | Borrador de correo |
| Autonomía | Sin envío automático |
| Revisión humana | Obligatoria |
| Integraciones | CRM |
| Disponibilidad | Horario laboral |
| Riesgo de error | Medio |
| Responsable | Dirección comercial |
Esta ficha evita escoger una herramienta únicamente porque ofrece muchas funciones.
Evaluación proporcional al riesgo
No todos los proveedores requieren el mismo nivel de diligencia.
Evaluación básica
Puede ser suficiente para:
- Corrección ortográfica.
- Generación de ideas.
- Resumen de información pública.
- Creación de esquemas.
- Traducción de textos no sensibles.
- Tareas internas sin efectos significativos.
Evaluación intermedia
Conviene cuando:
- Se tratan datos personales.
- Se utilizan documentos internos.
- La herramienta genera contenido público.
- Existe interacción con clientes.
- Se conecta con programas corporativos.
- Se utiliza de forma habitual por varios departamentos.
Evaluación reforzada
Debe realizarse cuando:
- Se tratan datos sensibles.
- Se evalúan personas.
- Se utiliza en recursos humanos.
- Interviene en educación, crédito, salud o servicios esenciales.
- Puede ejecutar acciones.
- Accede a sistemas críticos.
- La empresa comercializará el sistema bajo su marca.
- Existe la posibilidad de que sea un sistema de alto riesgo.
- Un error puede causar daños importantes.
Primera comprobación: ¿qué producto se está contratando?
El proveedor debería identificar claramente:
- Nombre del producto.
- Versión o plan.
- Funciones incluidas.
- Modelo o modelos utilizados.
- Proveedor del modelo base.
- Componentes de terceros.
- Integraciones.
- Ubicación del servicio.
- Funciones experimentales.
- Diferencias entre planes.
- Frecuencia de cambios.
En muchas soluciones intervienen varias capas:
- Un modelo de propósito general.
- Una plataforma que ofrece acceso al modelo.
- Un integrador.
- Una base de conocimiento.
- Conectores con sistemas internos.
- Una interfaz propia.
- Servicios de alojamiento.
- Subcontratistas.
La empresa debe saber a quién exigir información y quién controla cada parte.
Determinar la finalidad prevista
Pregunta al proveedor:
- ¿Para qué usos se ha diseñado el sistema?
- ¿Qué usos quedan excluidos?
- ¿Qué sectores no están permitidos?
- ¿Puede utilizarse para tomar decisiones?
- ¿Está diseñado para apoyar o sustituir tareas humanas?
- ¿Qué usuarios pueden operarlo?
- ¿Qué conocimientos necesitan?
- ¿Qué datos se consideran adecuados?
- ¿Qué situaciones pueden reducir su precisión?
Para sistemas de alto riesgo, el proveedor debe facilitar instrucciones claras y completas que permitan interpretar y utilizar correctamente los resultados. Estas instrucciones deben incluir la finalidad prevista, capacidades, limitaciones, precisión, robustez, ciberseguridad, riesgos conocidos y circunstancias que puedan afectar al rendimiento.
Aunque el sistema no sea de alto riesgo, estas preguntas siguen siendo útiles.
Comprobar el papel de la empresa y del proveedor
La evaluación debería responder:
- ¿Quién es el proveedor del sistema conforme al AI Act?
- ¿Quién ha desarrollado el modelo?
- ¿Quién lo comercializa?
- ¿Quién decide la finalidad?
- ¿Quién configura el sistema?
- ¿Quién mantiene la base de conocimiento?
- ¿Quién controla los datos?
- ¿Quién atiende los incidentes?
- ¿Quién comunica los cambios?
- ¿Quién asume responsabilidades contractuales?
También debe comprobarse si la empresa compradora podría convertirse en proveedora por:
- Comercializar el sistema bajo su marca.
- Cambiar la finalidad prevista.
- Modificar sustancialmente el sistema.
- Integrarlo en un producto propio.
- Ofrecerlo a terceros como solución propia.
Clasificación conforme al AI Act
No debería pedirse al proveedor únicamente una declaración general de cumplimiento.
Conviene preguntar:
- ¿Considera que la solución es un sistema de IA?
- ¿Qué definición y versión normativa ha aplicado?
- ¿Cuál es su finalidad prevista?
- ¿Ha analizado las prácticas prohibidas?
- ¿Está sujeto a obligaciones de transparencia?
- ¿Puede clasificarse como alto riesgo?
- ¿En qué artículo o anexo basa la clasificación?
- ¿Qué documentación respalda su conclusión?
- ¿Qué cambios podrían modificar la clasificación?
- ¿Qué obligaciones asume cada parte?
La respuesta:
Nuestra plataforma cumple totalmente el AI Act.
no proporciona información suficiente.
Una respuesta más útil sería:
Para la finalidad indicada, la solución se comercializa como sistema de apoyo y no debe utilizarse para adoptar decisiones laborales. El proveedor la ha clasificado de esta forma, identifica sus limitaciones y aporta documentación sobre los controles disponibles.
La empresa debe revisar si esa clasificación coincide con el uso que pretende realizar.
Prácticas prohibidas
Pregunta si el sistema utiliza o permite:
- Manipulación engañosa.
- Técnicas subliminales.
- Explotación de vulnerabilidades.
- Puntuación social.
- Reconocimiento de emociones.
- Categorización biométrica.
- Reconocimiento facial.
- Elaboración de perfiles sensibles.
- Vigilancia de trabajadores.
- Inferencias sobre personas vulnerables.
El proveedor debería explicar:
- Qué funciones están bloqueadas.
- Qué configuraciones podrían generar riesgo.
- Qué limitaciones contractuales existen.
- Qué controles impiden usos prohibidos.
- Cómo detecta usos indebidos.
Una cláusula que prohíbe determinados usos no es suficiente si el producto los facilita técnicamente y el caso de uso real depende de ellos.
Datos introducidos en el sistema
La empresa debe conocer qué sucede con:
- Prompts.
- Conversaciones.
- Archivos.
- Imágenes.
- Audios.
- Vídeos.
- Bases de datos.
- Información obtenida mediante integraciones.
- Resultados generados.
- Metadatos.
- Registros de actividad.
- Comentarios enviados al soporte.
Pregunta:
- ¿Se almacenan?
- ¿Dónde?
- ¿Durante cuánto tiempo?
- ¿Con qué finalidad?
- ¿Quién puede acceder?
- ¿Se utilizan para supervisión humana?
- ¿Se utilizan para mejorar el servicio?
- ¿Se utilizan para entrenar modelos?
- ¿Puede desactivarse ese uso?
- ¿La configuración es la misma en todos los planes?
- ¿Se borran las copias y registros auxiliares?
- ¿Qué sucede al cancelar el contrato?
Uso de datos para entrenamiento
No basta con preguntar:
¿Entrenáis la IA con nuestros datos?
La respuesta puede depender de:
- El plan contratado.
- La configuración.
- El tipo de información.
- La función utilizada.
- La existencia de una API.
- La activación de comentarios.
- El soporte técnico.
- La prevención de abusos.
- La retención temporal.
- Los subproveedores.
Pregunta de forma separada:
- ¿Se utilizan los datos de entrada para entrenar modelos?
- ¿Se utilizan los resultados?
- ¿Se utilizan las conversaciones?
- ¿Se utilizan los comentarios del usuario?
- ¿Se revisan manualmente?
- ¿Se utilizan para evaluar el producto?
- ¿Se comparten con el proveedor del modelo?
- ¿Puede desactivarse cada finalidad?
- ¿La exclusión queda recogida contractualmente?
- ¿Qué ocurre con datos ya utilizados?
El Comité Europeo de Protección de Datos señala que la legalidad de los modelos debe analizarse caso por caso. La consideración de un modelo como anónimo, el uso del interés legítimo y las consecuencias de haber utilizado datos personales de forma ilícita durante su desarrollo dependen de las circunstancias concretas y de las medidas adoptadas.
Por eso, una afirmación genérica como “el modelo no contiene datos personales” debe ir acompañada de información que permita evaluarla.
Roles de protección de datos
Debe determinarse si el proveedor actúa como:
- Encargado del tratamiento.
- Responsable independiente.
- Corresponsable.
- Subencargado.
- Una combinación de varios papeles según la función.
El contrato no puede resolver esta cuestión únicamente asignando una etiqueta.
Los papeles dependen de quién determina realmente las finalidades y los medios esenciales. La AEPD ha advertido que las funciones descritas contractualmente deben coincidir con la realidad del tratamiento.
Si el proveedor trata datos por cuenta de la empresa, debe existir un contrato conforme al artículo 28 del RGPD.
Qué debe revisar el contrato de encargo
El contrato debería regular:
- Objeto.
- Duración.
- Naturaleza.
- Finalidad.
- Tipos de datos.
- Categorías de personas.
- Instrucciones.
- Confidencialidad.
- Seguridad.
- Subencargados.
- Ayuda para atender derechos.
- Incidentes.
- Evaluaciones de impacto.
- Auditorías.
- Devolución o eliminación.
- Información necesaria para demostrar el cumplimiento.
La Comisión Europea ofrece cláusulas contractuales tipo para relaciones entre responsables y encargados conforme al artículo 28 del RGPD.
La existencia de un contrato estándar no elimina la necesidad de comprobar que refleja las funciones y riesgos reales del servicio.
Subencargados
Pregunta:
- ¿Qué empresas intervienen?
- ¿Qué servicio presta cada una?
- ¿Dónde están establecidas?
- ¿A qué datos acceden?
- ¿Con qué frecuencia cambia la lista?
- ¿Cómo se notifican los cambios?
- ¿Puede la empresa oponerse?
- ¿Qué sucede si se opone?
- ¿Se aplican las mismas obligaciones?
- ¿Quién responde ante un incidente?
Una lista formada únicamente por nombres comerciales, sin funciones ni ubicaciones, puede ser insuficiente para valorar el riesgo.
Transferencias internacionales
Debe comprobarse:
- En qué países se almacenan los datos.
- Desde qué países puede acceder el personal.
- Dónde están los subencargados.
- Qué mecanismo legitima cada transferencia.
- Si existe una decisión de adecuación.
- Si se utilizan cláusulas contractuales tipo.
- Qué medidas adicionales se aplican.
- Si el proveedor responde a solicitudes de autoridades.
- Qué información facilita sobre estas solicitudes.
La Comisión ha adoptado cláusulas contractuales tipo para transferencias de datos desde la UE o el EEE hacia organizaciones situadas en terceros países cuando resulte necesario este mecanismo.
La expresión “datos alojados en Europa” no demuestra por sí sola que no existan accesos o transferencias desde otros países.
Plazos de conservación
Pregunta separadamente por:
- Conversaciones.
- Archivos.
- Resultados.
- Logs.
- Copias de seguridad.
- Datos de facturación.
- Información de soporte.
- Datos de seguridad.
- Datos utilizados para detectar abusos.
- Datos eliminados por el usuario.
- Datos tras finalizar el contrato.
La empresa debe poder configurar o conocer:
- El plazo.
- La finalidad.
- Las excepciones.
- El proceso de eliminación.
- La duración de las copias.
- La posibilidad de borrado anticipado.
Derechos de las personas
Cuando se traten datos personales, el proveedor debería explicar cómo ayuda a:
- Acceder a los datos.
- Rectificarlos.
- Suprimirlos.
- Limitar el tratamiento.
- Facilitar la portabilidad.
- Gestionar oposiciones.
- Identificar datos dentro del sistema.
- Eliminar información de historiales o bases de conocimiento.
Debe comprobarse si técnicamente es posible localizar y eliminar datos que han sido:
- Introducidos en conversaciones.
- Indexados.
- Incorporados a una base vectorial.
- Utilizados en evaluaciones.
- Incluidos en registros.
- Enviados a subproveedores.
Seguridad del proveedor
La evaluación debe analizar la seguridad del servicio, no solo la seguridad general de la empresa.
Pregunta por:
- Cifrado en tránsito.
- Cifrado en reposo.
- Gestión de claves.
- Separación entre clientes.
- Control de acceso.
- Autenticación multifactor.
- Inicio de sesión único.
- Gestión de privilegios.
- Logs.
- Copias de seguridad.
- Recuperación.
- Pruebas de penetración.
- Gestión de vulnerabilidades.
- Desarrollo seguro.
- Comunicación de incidentes.
- Continuidad.
- Eliminación segura.
ENISA recomienda integrar la ciberseguridad en la contratación y gestión de la cadena de suministro, definiendo requisitos, responsabilidades, vigilancia y condiciones contractuales durante todo el ciclo de vida del proveedor.
Seguridad específica de sistemas de IA
Además de los controles tecnológicos habituales, deben revisarse riesgos como:
- Prompt injection.
- Instrucciones ocultas en documentos.
- Extracción de información.
- Fugas entre clientes.
- Manipulación de la base de conocimiento.
- Envenenamiento de datos.
- Uso indebido de herramientas.
- Generación de código inseguro.
- Suplantación.
- Abuso de integraciones.
- Acciones no autorizadas.
- Dependencia excesiva del resultado.
Pregunta:
- ¿Cómo se aíslan las instrucciones del sistema?
- ¿Cómo se filtran documentos no confiables?
- ¿Qué controles existen sobre las herramientas conectadas?
- ¿Cómo se limita el acceso a datos?
- ¿Cómo se detectan comportamientos anómalos?
- ¿Qué pruebas se realizan?
- ¿Qué debe configurar el cliente?
Certificaciones y auditorías
El proveedor puede aportar:
- ISO 27001.
- Informes SOC.
- Certificaciones de privacidad.
- Auditorías independientes.
- Pruebas de seguridad.
- Evaluaciones sectoriales.
- Declaraciones de conformidad.
Estos documentos pueden ser útiles, pero no deben aceptarse como respuesta universal.
Comprueba:
- Qué entidad está certificada.
- Qué producto incluye.
- Qué centros están dentro del alcance.
- Qué periodo cubre.
- Qué controles se excluyen.
- Si el documento está vigente.
- Si puede consultarse el informe completo o un resumen suficiente.
Una certificación general de la empresa no demuestra necesariamente que una nueva función de IA haya sido evaluada.
Precisión y calidad del sistema
Pregunta:
- ¿Cómo se mide la precisión?
- ¿Sobre qué datos?
- ¿En qué idiomas?
- ¿En qué sectores?
- ¿Qué errores son conocidos?
- ¿Qué situaciones reducen el rendimiento?
- ¿Qué pruebas puede realizar el cliente?
- ¿Cómo se comunican cambios?
- ¿Existe un umbral mínimo?
- ¿Qué ocurre cuando el sistema no sabe la respuesta?
Para sistemas de alto riesgo, las instrucciones deben informar sobre el nivel de precisión, sus métricas, robustez, ciberseguridad y circunstancias conocidas o previsibles que puedan afectar al rendimiento.
Para otras herramientas, la empresa puede exigir información similar de forma contractual.
Respuestas inventadas
En soluciones generativas, el proveedor debería explicar:
- Qué medidas reducen las alucinaciones.
- Si pueden restringirse las fuentes.
- Si se muestran referencias.
- Si se diferencia información recuperada y generada.
- Qué ocurre cuando no existe una respuesta.
- Cómo se evalúa la exactitud.
- Cómo se corrige contenido erróneo.
- Cómo se actualiza la base de conocimiento.
No debería aceptarse la precisión general del modelo como garantía de que responderá correctamente sobre los documentos concretos de la empresa.
Sesgos y discriminación
Cuando el sistema clasifica, puntúa o recomienda decisiones sobre personas, pregunta:
- Qué variables utiliza.
- Qué datos se excluyen.
- Qué grupos se han evaluado.
- Qué métricas de equidad se aplican.
- Qué sesgos se han identificado.
- Qué controles puede configurar el cliente.
- Cómo se investigan resultados desiguales.
- Qué información se facilita a las personas.
- Cómo puede revisarse una decisión.
La ausencia de variables sensibles no elimina automáticamente la discriminación, porque otras variables pueden funcionar como aproximaciones indirectas.
Supervisión humana
Debe comprobarse si las personas responsables pueden:
- Comprender el resultado.
- Consultar información relevante.
- Ver advertencias.
- Rechazar una recomendación.
- Modificar la decisión.
- Detener el sistema.
- Limitar sus permisos.
- Solicitar ayuda.
- Registrar la intervención.
En sistemas de alto riesgo, el diseño debe permitir una supervisión humana efectiva, incluida la capacidad de controlar, interpretar, ignorar o revertir el resultado y detener el sistema cuando sea necesario.
Logs y trazabilidad
Pregunta:
- Qué eventos se registran.
- Quién puede acceder.
- Cuánto tiempo se conservan.
- Si pueden exportarse.
- Si incluyen cambios de configuración.
- Si registran acciones.
- Si permiten investigar incidentes.
- Si contienen datos personales.
- Qué controles evitan su manipulación.
- Qué sucede al finalizar el contrato.
Para sistemas de alto riesgo, los proveedores y responsables del despliegue tienen obligaciones específicas relacionadas con los registros automáticos. Los responsables del despliegue deben conservar los logs bajo su control durante al menos seis meses, salvo que otra norma establezca un periodo diferente.
Transparencia ante usuarios
Si el sistema interactúa con personas o genera contenidos, pregunta:
- ¿Puede mostrarse claramente que se utiliza IA?
- ¿Puede personalizarse el aviso?
- ¿Se muestra desde la primera interacción?
- ¿Pueden identificarse contenidos sintéticos?
- ¿Existe marcado legible por máquina?
- ¿Puede mantenerse el marcado al exportar?
- ¿Cómo se gestionan deepfakes?
- ¿Cómo se identifican voces artificiales?
- ¿Qué documentación aporta el proveedor?
El artículo 50 establece obligaciones específicas para determinados sistemas interactivos y contenidos sintéticos. Entre ellas se encuentra la información a las personas que interactúan directamente con una IA y la identificación de determinados contenidos generados o manipulados.
Integraciones y permisos
Una herramienta aislada presenta un riesgo diferente a una herramienta conectada con:
- Correo.
- Calendario.
- CRM.
- ERP.
- Almacenamiento.
- Recursos humanos.
- Plataforma de pagos.
- Base de clientes.
- Sistemas de soporte.
- Repositorios de código.
Pregunta:
- Qué permisos solicita.
- Si pueden limitarse.
- Si utiliza acceso de lectura o escritura.
- Si puede borrar o modificar.
- Si admite cuentas de servicio.
- Si registra cada acción.
- Si puede actuar automáticamente.
- Si existen límites económicos.
- Si puede exigirse confirmación.
- Si es posible revocar el acceso inmediatamente.
IA agéntica
Cuando la solución puede planificar y ejecutar acciones, la evaluación debe ser reforzada.
La AEPD destaca que la IA agéntica puede incorporar distintos niveles de automatización y que el responsable debe decidir qué acciones pueden permitirse sin supervisión, qué intervención humana existirá y qué medidas controlarán esas decisiones de diseño.
Pregunta:
- ¿Qué objetivos puede recibir?
- ¿Qué herramientas puede utilizar?
- ¿Qué acciones puede ejecutar?
- ¿Qué límites se aplican?
- ¿Cuándo necesita aprobación?
- ¿Puede crear nuevas tareas?
- ¿Puede delegar en otros agentes?
- ¿Cómo se detiene?
- ¿Cómo se revierte una acción?
- ¿Cómo se investiga lo ocurrido?
Propiedad intelectual
El contrato debería aclarar:
- Derechos sobre los datos introducidos.
- Derechos sobre los resultados.
- Licencias concedidas.
- Uso de los datos por el proveedor.
- Restricciones de publicación.
- Uso de marcas.
- Contenido de terceros.
- Reclamaciones.
- Obligaciones de cooperación.
- Condiciones de indemnización, cuando se negocien.
No debe darse por supuesto que la frase “el usuario es propietario del resultado” resuelve todos los riesgos.
Puede seguir existiendo:
- Contenido similar a obras de terceros.
- Material introducido sin autorización.
- Limitaciones del modelo base.
- Derechos de imagen.
- Marcas.
- Información confidencial.
Confidencialidad
Pregunta si:
- El personal del proveedor puede acceder.
- En qué circunstancias.
- Con qué autorización.
- Qué obligaciones de confidencialidad tiene.
- Si se utilizan revisores externos.
- Si se anonimizan las conversaciones.
- Si el acceso queda registrado.
- Si puede desactivarse la revisión manual.
La empresa debería exigir obligaciones coherentes con la sensibilidad de la información tratada.
Cambios de modelo y servicio
Los sistemas de IA pueden cambiar sin que la empresa modifique su integración.
El contrato debería indicar:
- Qué cambios pueden realizarse.
- Con qué aviso.
- Si puede sustituirse el modelo.
- Si pueden desaparecer funciones.
- Cómo se comunican cambios de precisión.
- Si pueden modificarse los plazos de retención.
- Qué ocurre con subencargados nuevos.
- Si existe una versión estable.
- Si puede aplazarse una actualización.
- Qué derecho tiene la empresa a resolver el contrato.
Una modificación puede alterar:
- El comportamiento.
- La precisión.
- Los datos tratados.
- La ubicación.
- La clasificación de riesgo.
- Las obligaciones de transparencia.
- Los controles disponibles.
Soporte e incidentes
Pregunta:
- Qué soporte se incluye.
- Horarios.
- Idiomas.
- Tiempo de respuesta.
- Canal para incidentes críticos.
- Tiempo de notificación.
- Información que se facilitará.
- Cooperación con autoridades.
- Análisis de causa.
- Medidas correctoras.
- Comunicación posterior.
- Responsable de contacto.
El contrato debería distinguir entre:
- Error funcional.
- Incidente de seguridad.
- Violación de datos.
- Resultado dañino.
- Caída del servicio.
- Uso indebido.
- Cambio regulatorio.
Responsabilidad contractual
Revisa:
- Límites de responsabilidad.
- Exclusiones.
- Responsabilidad por subencargados.
- Incumplimientos de privacidad.
- Incidentes de seguridad.
- Infracciones de propiedad intelectual.
- Falta de disponibilidad.
- Pérdida de datos.
- Incumplimiento de instrucciones.
- Cooperación ante reclamaciones.
Un contrato puede limitar ampliamente la responsabilidad del proveedor mientras la empresa compradora conserva la relación directa con clientes, trabajadores o autoridades.
Las cláusulas deben valorarse según el riesgo real, no solo según el precio del servicio.
Nivel de servicio
Cuando la herramienta es importante, define:
- Disponibilidad.
- Tiempo máximo de caída.
- Respuesta ante incidencias.
- Recuperación.
- Copias.
- Soporte.
- Mantenimiento.
- Avisos.
- Compensaciones.
- Exclusiones.
- Escalado.
La promesa de “alta disponibilidad” sin cifras ni consecuencias resulta difícil de exigir.
Continuidad y dependencia
Pregunta:
- ¿Puede exportarse la información?
- ¿En qué formato?
- ¿Puede recuperarse la configuración?
- ¿Pueden exportarse los prompts del sistema?
- ¿Puede trasladarse la base de conocimiento?
- ¿Qué sucede si el proveedor cierra?
- ¿Existe un periodo de transición?
- ¿Se presta asistencia de salida?
- ¿Cuándo se eliminan los datos?
- ¿Qué componentes son propietarios?
Una solución muy integrada puede generar una dependencia difícil de revertir.
Prueba piloto
Antes del despliegue completo conviene realizar una prueba limitada.
El piloto debería definir:
- Duración.
- Usuarios.
- Datos permitidos.
- Datos prohibidos.
- Casos de prueba.
- Métricas.
- Errores esperados.
- Criterios de suspensión.
- Personas responsables.
- Resultado necesario para aprobar.
Debe utilizar datos ficticios, anonimizados o de bajo riesgo siempre que sea posible.
Casos de prueba recomendados
Prueba:
- Preguntas normales.
- Preguntas ambiguas.
- Datos incompletos.
- Errores ortográficos.
- Información contradictoria.
- Solicitudes fuera de alcance.
- Intentos de obtener datos.
- Instrucciones maliciosas.
- Contenido desactualizado.
- Casos de personas vulnerables.
- Diferentes idiomas.
- Situaciones que requieren derivación humana.
No evalúes únicamente ejemplos preparados por el proveedor.
Criterios de aprobación
La empresa debería definir antes del piloto:
- Qué errores son tolerables.
- Qué errores son críticos.
- Qué precisión mínima necesita.
- Qué documentación debe recibir.
- Qué cláusulas deben aceptarse.
- Qué controles son obligatorios.
- Qué riesgos pueden mitigarse.
- Qué riesgos impiden contratar.
Señales de alerta
Conviene detener o reforzar la evaluación cuando el proveedor:
- No identifica el modelo utilizado.
- No explica qué hace con los datos.
- Cambia la respuesta según el interlocutor.
- No proporciona contrato de tratamiento.
- No identifica subencargados.
- Afirma que no existe ningún riesgo.
- Garantiza un cumplimiento absoluto.
- No permite eliminar los datos.
- No informa de la ubicación.
- No ofrece mecanismos de supervisión.
- No permite exportar logs.
- No comunica cambios de modelo.
- No dispone de proceso de incidentes.
- Impide probar el sistema.
- Utiliza información del cliente para entrenamiento por defecto.
- Exige permisos excesivos.
- No permite desactivar acciones automáticas.
- Presenta una certificación sin aclarar su alcance.
- Promete precisión total.
- No acepta documentar compromisos comerciales importantes.
Una respuesta pendiente no implica necesariamente descartar al proveedor.
La ausencia reiterada de transparencia sí puede indicar que la empresa no podrá gestionar adecuadamente el servicio.
Cómo documentar la evaluación
El expediente puede incluir:
- Ficha del caso de uso.
- Proveedores comparados.
- Cuestionarios recibidos.
- Documentación técnica.
- Evaluación de privacidad.
- Evaluación de seguridad.
- Clasificación preliminar del AI Act.
- Contratos.
- Lista de subencargados.
- Resultado del piloto.
- Riesgos detectados.
- Controles exigidos.
- Decisión.
- Condiciones de aprobación.
- Fecha de revisión.
Posibles decisiones
Aprobado
El proveedor ofrece información suficiente y el riesgo resulta aceptable con los controles previstos.
Aprobado con condiciones
Puede utilizarse si:
- Se limita la finalidad.
- Se excluyen ciertos datos.
- Se activa una configuración.
- Se añade revisión humana.
- Se renegocia una cláusula.
- Se realiza formación.
- Se limita una integración.
Piloto restringido
Falta información o evidencia, pero puede probarse sin datos reales ni efectos sobre personas.
Pendiente
No puede decidirse hasta recibir documentación adicional.
Rechazado
El riesgo no puede reducirse razonablemente o el proveedor no ofrece garantías suficientes.
Revisión periódica
El proveedor debe revisarse cuando:
- Cambia el modelo.
- Cambian las condiciones.
- Se añaden subencargados.
- Se incorporan integraciones.
- Se amplía la finalidad.
- Se utilizan nuevos datos.
- Se produce un incidente.
- Cambia la normativa.
- Se modifica la clasificación.
- Se renueva el contrato.
Como regla interna:
- Bajo impacto: revisión anual.
- Impacto medio: cada seis meses.
- Alto impacto: cada tres meses o ante cada cambio relevante.
Ejemplo: herramienta generativa de productividad
Una pyme quiere utilizar una herramienta empresarial para preparar borradores.
Debería revisar:
- Exclusión del entrenamiento.
- Uso de cuentas empresariales.
- Datos permitidos.
- Retención.
- Subencargados.
- Revisión humana.
- Propiedad intelectual.
- Exportación.
- Gestión de usuarios.
- Cambios del modelo.
Puede aprobarse con una política que prohíba datos sensibles y exija revisar los resultados.
Ejemplo: chatbot de atención al cliente
Además:
- Transparencia.
- Protección de datos.
- Base de conocimiento.
- Precios y condiciones.
- Derivación humana.
- Registro de conversaciones.
- Acciones permitidas.
- Pruebas frente a manipulación.
- Incidentes.
- Accesibilidad.
Ejemplo: selección de personal
La evaluación debe ser reforzada.
Debe analizar:
- Clasificación de alto riesgo.
- Datos utilizados.
- Variables.
- Sesgos.
- Información a candidatos.
- Supervisión humana.
- Decisiones automatizadas.
- Logs.
- Documentación técnica.
- Pruebas.
- Responsabilidades.
- Posibilidad de impugnación.
No debería contratarse únicamente a partir de una demostración comercial.
Errores frecuentes
Elegir por marca o popularidad
Una herramienta conocida puede no ser adecuada para el caso concreto.
Revisar únicamente el RGPD
También deben analizarse AI Act, seguridad, propiedad intelectual, transparencia y contratos.
Aceptar respuestas comerciales sin evidencia
Las promesas deben respaldarse con documentación o cláusulas.
No distinguir planes
La versión gratuita y empresarial pueden tener condiciones distintas.
No analizar integraciones
El riesgo cambia cuando la IA accede a sistemas internos.
No preparar la salida
La empresa puede quedar atrapada en el proveedor.
No repetir la evaluación
Los sistemas cambian constantemente.
Confiar en certificaciones genéricas
El alcance puede no incluir el producto contratado.
No probar casos adversos
Una demostración controlada no representa el uso real.
No registrar la decisión
La empresa no puede explicar después por qué eligió la herramienta.
Preguntas frecuentes
¿Es obligatorio evaluar a todos los proveedores de IA?
No existe un único procedimiento general obligatorio para cualquier herramienta, pero la empresa debe aplicar la diligencia necesaria según el riesgo, especialmente cuando trata datos personales o despliega sistemas regulados.
¿El proveedor debe firmar un contrato de encargado?
Cuando trata datos personales por cuenta de la empresa y actúa como encargado, debe existir un contrato u otro acto jurídico conforme al artículo 28 del RGPD.
¿Que los servidores estén en Europa garantiza el cumplimiento?
No. También deben revisarse accesos, subencargados, transferencias, finalidades, seguridad y contratos.
¿Puede el proveedor utilizar nuestros datos para entrenamiento?
Depende del contrato, configuración, finalidad y base jurídica. Debe analizarse antes de introducir información.
¿Una certificación ISO 27001 es suficiente?
No. Es una evidencia útil de seguridad, pero debe comprobarse su alcance y evaluar los riesgos específicos del producto de IA.
¿Hay que conocer el modelo utilizado?
Es muy recomendable. El modelo puede afectar a funciones, datos, limitaciones, ubicación, precisión y condiciones.
¿Puede cambiar el proveedor el modelo sin avisar?
Depende del contrato. Conviene negociar obligaciones de notificación para cambios relevantes.
¿Debe realizarse una prueba piloto?
Es recomendable antes de tratar datos sensibles, conectar sistemas o afectar a personas.
¿Quién debe participar en la evaluación?
Según el riesgo: responsable del área, tecnología, seguridad, protección de datos, dirección, legal, recursos humanos o especialistas sectoriales.
¿Qué ocurre si el proveedor no responde?
La ausencia de información debe registrarse como riesgo. Puede limitarse el uso, realizar un piloto restringido o descartar la herramienta.
¿Una pequeña empresa necesita un cuestionario tan completo?
No para todas las herramientas. Puede utilizar una versión reducida para usos de bajo impacto y ampliar la evaluación según los datos, autonomía y personas afectadas.
Evalúa un proveedor de inteligencia artificial
La herramienta incluida a continuación permite valorar:
- Claridad del proveedor.
- AI Act.
- Protección de datos.
- Seguridad.
- Funcionamiento.
- Contrato y continuidad.
El resultado identifica:
- Áreas suficientemente documentadas.
- Preguntas pendientes.
- Controles críticos.
- Documentación que conviene solicitar.
Evalúa un proveedor de inteligencia artificial
Responde según la información proporcionada por el proveedor. Obtendrás una valoración por áreas y una lista de documentación pendiente.
Evaluación del proveedor
El caso de uso requiere una evaluación reforzada
Controles esenciales sin resolver
Resultado por áreas
Documentación pendiente
Acciones recomendadas
Decisión orientativa
Esta evaluación es orientativa. No certifica al proveedor ni sustituye una revisión jurídica, técnica, contractual o de seguridad.
Conclusión
Evaluar un proveedor de inteligencia artificial no significa exigirle que elimine cualquier riesgo.
Significa comprender:
- Qué ofrece.
- Qué no ofrece.
- Qué datos utiliza.
- Qué obligaciones asume.
- Qué obligaciones conserva la empresa.
- Qué controles están disponibles.
- Qué puede salir mal.
- Cómo se responderá.
- Cómo puede abandonarse el servicio.
La mejor herramienta no es necesariamente la que tiene más funciones.
Es la que permite a la empresa alcanzar su finalidad manteniendo un nivel de control, transparencia y seguridad adecuado.
Aviso: Este contenido tiene una finalidad exclusivamente informativa y divulgativa. No constituye asesoramiento jurídico, técnico o de ciberseguridad ni certifica la idoneidad de ningún proveedor.