Checklist para seleccionar un proveedor de IA

Una buena demo responde a una pregunta muy limitada: si el proveedor puede mostrar algo convincente durante una reunión. No demuestra que la solución funcione con tus casos, tus datos, tus excepciones ni tus controles.

Esta guía ayuda a comparar proveedores con evidencia común, detectar condiciones no negociables y evitar que una presentación brillante o un precio inicial bajo decidan por sí solos.

Primero identifica qué estás comprando

«Proveedor de IA» puede describir relaciones muy distintas. La evaluación cambia según el objeto de la compra:

Una empresa puede ocupar varios papeles a la vez. Pide que la propuesta nombre cada dependencia y aclare quién responde frente a ti cuando intervienen subencargados, modelos externos o servicios cloud.

La preparación del comprador también se evalúa

No envíes una petición genérica como «queremos incorporar IA». Entrega a todos los candidatos el mismo documento con:

• problema y frontera del flujo;
• usuarios y propietario operativo;
• volumen, línea base y resultado esperado;
• datos, sistemas y restricciones conocidos;
• acciones permitidas y prohibidas;
• casos normales, difíciles y excepciones;
• decisión que deberá tomarse al final de la prueba.

Si estos elementos no existen, contrata primero descubrimiento y diagnóstico, no una implantación grande. La metodología práctica de implantación de INSTINTIA explica por qué la integración, la evaluación, la adopción y la operación forman parte del proyecto desde el inicio.

1. Experiencia y equipo real

1. ¿Puede demostrar proyectos comparables en proceso, riesgo y complejidad? El mismo sector ayuda, pero no sustituye la similitud operativa. Pide contexto, alcance, participación del proveedor y límites del resultado.
2. ¿Permite hablar con clientes de referencia adecuados? Prepara preguntas sobre cambios de alcance, incidentes, transferencia, mantenimiento y qué harían diferente; no te limites a confirmar que el proyecto existió.
3. ¿Explica proyectos que no funcionaron y lo que cambió después? Una respuesta concreta sobre fallos, límites y aprendizaje resulta más útil que una colección sin matices de casos de éxito.
4. ¿El equipo propuesto es el que ejecutará el trabajo? Registra nombres o perfiles, dedicación, responsabilidades, sustituciones y acceso al responsable técnico. Aclara qué tareas se subcontratan.

2. Método y evidencia

5. ¿Empieza por el proceso y la línea base? Desconfía de una arquitectura cerrada antes de entender entradas, decisiones, excepciones y resultado empresarial.
6. ¿Define una primera prueba acotada y falsable? Debe indicar usuarios, casos, duración, entregables, métrica y señales para corregir o detenerse.
7. ¿Presenta un plan de evaluación antes de construir? Pide conjunto de pruebas, rúbrica, casos adversos, método de revisión y separación entre ajuste y evaluación final.
8. ¿Distingue métricas del modelo, del sistema y del negocio? Una respuesta correcta en laboratorio no demuestra resolución del flujo, adopción ni ahorro neto de revisión.

La evaluación debe representar el trabajo concreto. OpenAI señala que las evaluaciones de frontera no capturan todos los matices de un flujo empresarial y recomienda traducir objetivos de negocio a criterios reproducibles en su guía sobre evals para empresas.

3. Arquitectura, datos e integración

9. ¿Existe un diagrama de flujo de datos completo? Debe mostrar fuentes, modelos, regiones, almacenamiento, registros, subencargados, retención y eliminación.
10. ¿Aclara si tus datos o resultados entrenan modelos? La respuesta debe cubrir configuración, contrato, servicios de terceros y cambios futuros; una afirmación comercial genérica no basta.
11. ¿Separa lectura, propuesta y ejecución? Pide permisos mínimos, identidad del sistema, aprobaciones y trazas para cada integración. Un conector no es solo comodidad: amplía la superficie de acción.
12. ¿La solución puede cambiar de modelo o proveedor sin rehacerse? Solicita interfaces, componentes acoplados, pruebas de regresión y costes de migración. «Agnóstico» debe demostrarse en la arquitectura y el contrato.

4. Seguridad, privacidad y cumplimiento

13. ¿Entrega evidencias de seguridad proporcionales al riesgo? Políticas, controles de acceso, cifrado, gestión de vulnerabilidades, pruebas, continuidad y notificación de incidentes deben corresponder al servicio real, no solo a la empresa matriz.
14. ¿Permite auditar acciones y reconstruir incidentes? Comprueba qué registra, durante cuánto tiempo, quién accede, cómo se exporta y qué información queda fuera de la traza.
15. ¿Clasifica su papel y el tuyo en la cadena de IA? En la Unión Europea, desarrollar, comercializar, integrar o desplegar bajo nombre propio puede implicar responsabilidades distintas. El contrato debe aportar la documentación necesaria para que cada parte cumpla las suyas.
16. ¿Contempla transparencia, supervisión y alfabetización? Desde el 2 de agosto de 2026 son aplicables determinadas obligaciones de transparencia del artículo 50 del AI Act. Además, el artículo 4 exige medidas de alfabetización de IA para personal y otras personas que operan sistemas por cuenta de proveedores y desplegadores. El alcance concreto depende del uso.

No conviertas una checklist comercial en asesoramiento jurídico. La clasificación y las obligaciones deben validarse con EUR-Lex, la Comisión Europea y especialistas adecuados al caso.

5. Operación, contrato y capacidad de salida

17. ¿Está claro quién opera y mantiene después del lanzamiento? Incluye monitorización, incidencias, cambios en fuentes, permisos, modelos, instrucciones y conjuntos de evaluación.
18. ¿El precio refleja el coste total? Compara implantación, licencias, consumo, integraciones, almacenamiento, observabilidad, soporte, evaluación, supervisión humana y evolución. Revisa también mínimos y escalones de volumen.
19. ¿La propiedad intelectual y los derechos de uso están definidos? Separa código previo, código específico, configuraciones, datos, evaluaciones, prompts, documentación y artefactos producidos.
20. ¿Existe un plan de salida verificable? Debe ser posible exportar datos, configuraciones, trazas y documentación en formatos utilizables, conocer el coste y plazo de transición y eliminar copias según lo acordado.

La prueba comparativa que recomendamos

No pidas a cada candidato su demo favorita. Entrega un paquete idéntico y limitado:

1. Entre 20 y 50 casos representativos, con una parte reservada para la evaluación final.
2. Una rúbrica que distinga respuesta correcta, incompleta, peligrosa y escalado adecuado.
3. Dos o tres excepciones que exijan reconocer incertidumbre o pedir aprobación.
4. El mismo límite de tiempo, integraciones y presupuesto de prueba.
5. Un informe de resultados que incluya correcciones humanas, latencia, coste y fallos, no solo ejemplos acertados.

No compartas datos personales o confidenciales sin la base, el contrato y los controles necesarios. Cuando el objetivo sea comparar capacidad, comienza con información sintética o anonimizada que conserve la dificultad relevante.

Matriz de decisión de 100 puntos

Los pesos siguientes son una propuesta inicial de INSTINTIA. Adáptalos antes de recibir ofertas y evita modificarlos después de ver las puntuaciones.

Puntúa cada dimensión de 0 a 5 y multiplica por su peso. Conserva junto a la nota el enlace o documento que la respalda. No permitas que la suma compense una condición no negociable: incumplir un requisito de datos, seguridad, capacidad de auditoría o salida puede excluir una propuesta aunque su total sea alto.

Señales de alerta

• Promete un ROI o plazo sin pedir línea base, volumen ni excepciones.
• Solo enseña casos seleccionados por el propio proveedor.
• Evita concretar qué equipo hará el trabajo o qué terceros intervienen.
• Trata seguridad, cumplimiento, adopción u operación como fases posteriores.
• No explica cómo falla la solución ni cuándo debe escalar a una persona.
• Utiliza «propietario», «privado» o «agnóstico» sin reflejarlo en documentos verificables.
• Hace costosa o impracticable la exportación y sustitución del servicio.

Preguntas frecuentes