Cómo evaluar un proveedor de IA: checklist para empresas

Evaluar un proveedor de inteligencia artificial consiste en comprobar si su solución resuelve un caso definido con la calidad, seguridad, coste y continuidad que necesita la empresa. Una presentación comercial puede enseñar una respuesta correcta. La diligencia debida debe demostrar qué ocurre con datos reales, usuarios distintos, errores, cambios de modelo y finalización del contrato.

La pregunta «¿qué modelo utiliza?» es insuficiente. El resultado depende del sistema completo: fuentes, instrucciones, recuperación, permisos, herramientas, interfaz, registros, revisión humana y operación. Dos proveedores que usan el mismo modelo pueden ofrecer riesgos y resultados muy diferentes.

Empieza por el caso de uso, no por la lista de funciones

Describe la tarea antes de solicitar propuestas. Indica entrada, resultado, volumen, usuarios, datos, sistemas conectados, errores actuales y criterio de aceptación. Separa requisitos obligatorios de preferencias.

Por ejemplo, «automatizar facturas» puede significar extraer cinco campos para revisión o aprobar y contabilizar documentos. El segundo alcance añade identidad, reglas contables, integración, segregación de funciones y reversión. Comparar ambos como si fueran el mismo producto distorsiona precio y riesgo.

El perfil de IA generativa de NIST recomienda actualizar la evaluación de proveedores para incluir propiedad intelectual, privacidad, seguridad, componentes de terceros, monitorización y continuidad. También propone inventariar terceros con acceso al contenido de la organización y mantener alternativas frente a fallos de sistemas de alto riesgo.

Prepara una ficha por caso:

• proceso y responsable;
• usuarios y personas afectadas;
• datos y clasificación;
• decisiones y acciones permitidas;
• volumen normal y pico;
• calidad, latencia y disponibilidad mínimas;
• intervención humana;
• integraciones;
• métricas y periodo de prueba;
• restricciones legales, sectoriales y contractuales.

Esta ficha evita comprar una plataforma potente para un problema que podría resolverse con una regla, una mejora de proceso o una función ya incluida en las herramientas actuales.

Quién es el proveedor y de qué depende

La guía rápida de diligencia debida de NIST SP 1326, publicada en julio de 2026 para proveedores tecnológicos, organiza la investigación alrededor de propiedad y control, procedencia, resiliencia, prácticas básicas de ciberseguridad y niveles de la cadena de suministro. No es una certificación de proveedores de IA ni una obligación general para empresas españolas, pero ofrece una estructura útil para no limitar la revisión a una marca.

Identifica entidad contractual, país, subencargados, infraestructura, modelos, fuentes externas, soporte e integradores. Pregunta qué componentes son propios y cuáles dependen de terceros. Un servicio puede cambiar de comportamiento o disponibilidad cuando cambia una API, modelo o licencia fuera del control directo del vendedor.

Solicita estados financieros o evidencia de continuidad proporcional al impacto del servicio, referencias verificables cuando proceda, historial de incidentes comunicado y proceso de soporte. No uses el tamaño o la notoriedad como sustituto de la evaluación técnica.

Cadena de suministro de la solución

Dibuja modelo, alojamiento, base de datos, búsqueda, observabilidad, conectores y canales. Registra región y proveedor de cada componente. Pregunta qué ocurriría si uno deja de estar disponible, sube precios o retira una versión.

La dependencia no se elimina por usar software abierto. Un modelo descargable puede depender de una licencia, hardware, mantenedor, librería o integrador. La empresa necesita saber quién actualiza, corrige y opera cada capa.

Datos: qué entra, dónde va y para qué se usa

Pide un diagrama de flujo de datos. Debe cubrir prompts, archivos, respuestas, registros, copias, telemetría, soporte y datos derivados. Verifica región, retención, borrado, cifrado, subencargados y uso para entrenamiento o mejora.

Pregunta qué datos necesita realmente el caso. Un proveedor no debería copiar todo el almacenamiento si la tarea requiere una carpeta. Revisa permisos por usuario, grupo, fuente y acción; comprueba que los cambios de acceso en el sistema original se reflejan en la solución.

Solicita un procedimiento para ejercer derechos, responder a incidentes, exportar y eliminar. Si el proveedor afirma que no conserva datos, pide que precise qué ocurre con registros de seguridad, copias y soporte. Diferencia contenido, metadatos y métricas agregadas.

Nuestra guía sobre datos preparados para IA ayuda a evaluar calidad, contexto, permisos y linaje. Para decidir entre infraestructura propia y servicio gestionado, consulta IA local, nube o híbrida.

Seguridad: controles y evidencia

Pide arquitectura, autenticación, control de acceso, segregación de clientes, gestión de secretos, cifrado, registros, copias, pruebas de recuperación y respuesta a incidentes. Las certificaciones pueden aportar evidencia sobre un alcance concreto; comprueba entidad, servicio, fecha, excepciones y vigencia.

Para agentes, revisa identidad y permisos de herramientas. El sistema debe distinguir leer, proponer y ejecutar. Establece límites de importe, volumen, destinatario y frecuencia. Las acciones sensibles deben requerir aprobación o una condición determinista externa al modelo.

Prueba acceso horizontal y vertical: un usuario no debe ver datos de otro cliente ni ejecutar acciones reservadas a otro rol. Introduce contenido malicioso en documentos y mensajes para comprobar si altera instrucciones. El artículo sobre prompt injection detalla pruebas y controles.

No aceptes «seguridad empresarial» como respuesta. Pide quién hace qué, cómo se verifica y qué evidencia recibe tu equipo.

Calidad: evaluar la tarea, no el benchmark general

Un benchmark público no representa automáticamente documentos, idioma, herramientas o criterios de tu empresa. Construye un conjunto de casos reales anonimizados con resultado esperado. Incluye entradas normales, incompletas, contradictorias, adversas y fuera de alcance.

Mide por tarea:

• resultado aceptado sin corrección;
• fuente correcta y trazable;
• abstención cuando falta evidencia;
• errores críticos y menores;
• éxito de herramientas y acciones;
• latencia mediana, P90 y P99;
• intervención humana;
• coste por resultado aceptado.

Define el umbral antes de recibir el resultado. Un promedio puede ocultar un fallo grave en una intención sensible. Separa categorías y asigna errores que bloquean el lanzamiento.

Pregunta cómo evalúa el proveedor tras cambios de modelo, prompts, fuentes o conectores. Solicita versiones, historial de cambios y posibilidad de aplazar una actualización. Si el servicio cambia sin regresión sobre tus casos, la prueba inicial pierde valor.

Supervisión humana y límites operativos

La frase «human in the loop» debe convertirse en un punto de control. Define quién revisa, qué ve, qué criterio aplica, cuánto tiempo tiene y si puede rechazar o revertir. Una bandeja con cientos de aprobaciones sin contexto no es supervisión efectiva.

La documentación del Procurement Agent de Microsoft, todavía en preview, ofrece un ejemplo concreto: identifica pedidos sin confirmar o entregas tardías y prepara correos para que el comprador los revise. Su FAQ de IA responsable recomienda revisar correo, intención y datos antes de tomar decisiones o aplicar cambios.

El ejemplo muestra un patrón de compra útil: empezar con borradores y análisis, conservar aprobación y ampliar solo tras observar errores. La disponibilidad de una función de proveedor no demuestra que encaje con el proceso o controles propios.

Integración: demostrar el flujo completo

Lista APIs, eventos, identidades, límites, formatos y propietario de cada sistema. Pide un entorno de prueba. Simula timeout, respuesta duplicada, dato inválido, permiso revocado y sistema no disponible.

Comprueba idempotencia: repetir una solicitud no debe duplicar un pago, pedido o ticket. Define reconciliación entre el agente y el sistema de registro. Una respuesta generada correctamente no compensa una actualización fallida en el ERP o CRM.

Aclara qué integración forma parte del producto, cuál requiere desarrollo y quién la mantiene. Incluye cambios de API, versiones y pruebas en el contrato. La integración de sistemas debe presupuestarse como parte del caso, no como una nota posterior.

Coste total: licencia, consumo y operación

Separa implantación, licencia, usuarios, consumo, modelos, almacenamiento, búsqueda, conectores, observabilidad, soporte, evaluación, revisión y mantenimiento. Añade costes de salida y dependencia.

Solicita precios para volumen bajo, previsto y pico. Define cómo se mide entrada, salida, sesión, acción o crédito. Pregunta qué ocurre con reintentos, caché, pruebas y tareas fallidas. Verifica límites y sobrecostes.

Ejemplo hipotético: un proveedor cobra 1.500 euros mensuales de plataforma y 0,30 por ejecución. Con 8.000 ejecuciones, el coste directo es 3.900 euros. La empresa añade 1.600 euros de revisión, 900 de operación y 1.200 de amortización de integración: 7.600 euros.

Si 5.000 resultados son aceptados, el coste por resultado aceptado es 1,52 euros. Dividir por las 8.000 ejecuciones daría 0,95 y ocultaría fallos y revisión. Compara 1,52 con el coste y calidad del proceso actual. El ejemplo explica el método; no es una tarifa real.

Contrato: convertir promesas en compromisos

El contrato debe reflejar alcance, datos, seguridad, soporte, disponibilidad, cambios, incidentes, propiedad intelectual, auditoría, subencargados, uso aceptable, límites de responsabilidad y terminación. La revisión jurídica depende del caso y jurisdicción.

Precisa propiedad y derechos sobre entradas, salidas, configuraciones, evaluaciones y desarrollos. Evita asumir que «tus datos son tuyos» resuelve el uso del proveedor, la portabilidad o la eliminación.

Incluye notificación de cambios materiales: modelo, región, subencargado, retención, precio o función. Define qué evidencia puede pedir la empresa y cómo se gestionan vulnerabilidades. NIST sugiere cláusulas que permitan evaluar procesos y estándares de terceros; el mecanismo contractual debe adaptarse al riesgo real.

Salida y continuidad desde el primer día

Pide formatos de exportación, plazo, coste, asistencia y eliminación. Comprueba si puedes recuperar datos, configuraciones, prompts, evaluaciones, registros y conocimiento. Un PDF de respuestas no permite reconstruir una integración.

Define una alternativa si el servicio falla o termina: proceso manual, proveedor secundario o modo limitado. Ensaya recuperación y revocación de credenciales. Mantén interfaces claras entre datos, reglas e integración para reducir el coste de cambio.

La continuidad también cubre personas. Documenta propietarios, soporte y conocimiento necesario para operar. Si solo el proveedor entiende la configuración, existe dependencia aunque los datos sean exportables.

Piloto de compra en cinco fases

1. Requisitos y baseline

Documenta proceso, volumen, calidad, tiempos, costes e incidentes actuales. Define obligatorios y criterio de éxito.

2. Solicitud de evidencia

Envía el mismo cuestionario a todos los proveedores. Pide documentos y respuestas con responsable y fecha. Marca desconocidos; no los conviertas en aprobados.

3. Prueba técnica

Usa los mismos casos y criterios. Ejecuta fallos, permisos y carga. Conserva resultados reproducibles.

4. Operación limitada

Prueba con usuarios reales, datos controlados y revisión. Mide resultados aceptados, excepciones, coste y soporte.

5. Decisión y condiciones

Compara evidencia, riesgos residuales, coste total y salida. Registra por qué se elige y cuándo se revisa. La mejor puntuación no compensa un requisito obligatorio incumplido.

Matriz de decisión

Una matriz sencilla puede ponderar:

• ajuste al caso y calidad: 25 %;
• datos y privacidad: 15 %;
• seguridad y permisos: 15 %;
• integración y operación: 15 %;
• coste total: 10 %;
• continuidad y salida: 10 %;
• soporte y capacidad del proveedor: 10 %.

Los pesos son un ejemplo. Define requisitos de exclusión aparte: una opción que no cumple residencia obligatoria o control de acceso no debe ganar por precio. Documenta la evidencia que justifica cada nota.

Repite la evaluación periódicamente y ante cambios materiales. Comprar IA no es aprobar un proveedor para siempre; es gestionar un servicio que cambia.

Niter Agency es una consultora de inteligencia artificial con base en Madrid. Ayudamos a definir requisitos, comparar soluciones, preparar pruebas y estimar el coste total sin convertir la herramienta preferida en la conclusión. Puedes revisar la consultoría de IA para empresas, la auditoría tecnológica, la política interna de IA y nuestra metodología. Para evaluar una compra, contacta con el equipo indicando proceso, datos, usuarios y proveedores considerados.

Preguntas frecuentes al evaluar proveedores de IA

¿Qué documentos hay que pedir a un proveedor de IA?

Arquitectura y flujos de datos, condiciones de tratamiento, subencargados, controles de seguridad, informes o certificaciones aplicables, SLA, política de cambios, respuesta a incidentes, precios, exportación y eliminación. El alcance depende del riesgo del caso.

¿Una certificación demuestra que la solución es segura?

No por sí sola. Comprueba entidad, servicio, alcance, fecha y excepciones. Combínala con arquitectura, permisos, pruebas y obligaciones contractuales del caso concreto.

¿Cómo se comparan modelos y proveedores distintos?

Con el mismo conjunto de tareas, datos, criterios, carga y errores. Mide resultado aceptado, fuentes, abstención, acciones, latencia y coste total. Los benchmarks generales sirven como referencia, no como prueba del flujo empresarial.

¿Cuánto debe durar un piloto?

Lo suficiente para cubrir volumen, excepciones y usuarios representativos. Un periodo de cuatro a ocho semanas suele permitir observar operación, pero la duración debe ajustarse a frecuencia y riesgo. Los criterios se fijan antes.

¿Cómo evitar la dependencia del proveedor?

Separa datos, reglas e integración; exige exportación; conserva evaluaciones y documentación; usa interfaces conocidas; define alternativa operativa y prueba la terminación. La portabilidad debe demostrarse, no asumirse.