Evaluar un proveedor de IA: 12 preguntas antes de firmar
Evaluar un proveedor de IA exige preguntar quién es dueño del código, cómo accede a los datos, cuál es el criterio de éxito del piloto y qué pasa al final.
En resumen
- La pregunta que más información aporta sobre un proveedor de IA es una sola: si mañana termina la relación, ¿sigue funcionando lo construido?
- Un piloto de IA sin criterio de éxito escrito antes de empezar —una métrica de negocio, un umbral y una fecha— es una demostración larga que siempre concluye que hace falta invertir más.
- La propiedad del código, de la configuración y de las definiciones del negocio se negocia en el contrato inicial; discutirla años después es discutirla sin poder de negociación.
- Las preguntas técnicas sobre acceso a los datos —solo lectura verificable en la credencial, permisos aplicados al construir la consulta y registro de uso— tienen respuestas concretas, y una respuesta vaga en cualquiera de ellas es información.
- Conviene desconfiar del proveedor de IA que no nombra ningún caso donde su solución no es la adecuada: los límites no declarados se descubren durante la implementación.
Para evaluar un proveedor de IA hay que obtener respuestas precisas en cuatro frentes: quién es dueño del código y de las definiciones del negocio, cómo accede el sistema a los datos, cuál es el criterio de éxito escrito del piloto y qué sigue funcionando si termina la relación. Importa más la precisión de esas respuestas que la demostración.
Evaluar proveedores de inteligencia artificial es difícil por un motivo específico: las demostraciones son buenas. Casi todas funcionan, casi todas impresionan, y ninguna revela lo que va a pasar en el mes ocho. Estas doce preguntas están ordenadas por cuánta información aportan. Igniten es proveedor, así que corresponde la advertencia: nuestras respuestas a varias de ellas están publicadas en este mismo sitio, y el lector puede juzgar si son consistentes.
¿Qué hay que evaluar en un proveedor de IA?
Un proveedor de IA se evalúa en cuatro dimensiones, cada una con sus preguntas de control:
| Dimensión | Qué se busca saber | Preguntas |
|---|---|---|
| Propiedad | Si lo construido le pertenece a la empresa | 1 a 4 |
| Acceso a los datos | Qué puede leer, escribir y enviar el sistema | 5 a 8 |
| Piloto y alcance | Cómo se sabe si funcionó y dónde no aplica | 9 a 11 |
| Evidencia | Qué dicen quienes ya lo contrataron | 12 |
¿Quién es dueño de lo que construye el proveedor?
La empresa debería ser dueña del código, de la configuración y de las definiciones del negocio, y eso tiene que estar escrito en el contrato inicial.
1. ¿Quién queda como dueño del código fuente y de la propiedad intelectual al finalizar?
La respuesta que conviene escuchar es una que se pueda escribir en el contrato. «El cliente es dueño» y «el cliente tiene una licencia de uso» son cosas distintas, y la diferencia solo se nota cuando la relación termina. En la modalidad de optimización de procesos con IA que usa Igniten en consultoría, el producto, el código y la propiedad intelectual quedan del lado del cliente.
2. Si mañana termina la relación, ¿sigue funcionando lo construido?
Es la pregunta que resume a todas las demás. Si la respuesta tiene condiciones —que se mantenga una suscripción, que exista una conexión con la infraestructura del proveedor, que alguien renueve una licencia—, lo que se está contratando es acceso, no una solución. Puede ser razonable, pero conviene saberlo.
3. ¿Quién es dueño de las definiciones del negocio que se construyan?
El activo más duradero de un proyecto de datos no es el software, sino la capa de definiciones: cómo se calcula cada métrica, qué significa cada campo, qué reglas aplican. Sobrevive al proveedor y a la tecnología. Si queda del lado del proveedor, la empresa alquila indefinidamente su propio conocimiento del negocio.
4. ¿El mantenimiento posterior es obligatorio u opcional?
Un mantenimiento opcional indica que lo entregado funciona sin el proveedor. Uno obligatorio indica lo contrario, con independencia de cómo esté redactado el contrato. Es la señal más directa de vendor lock-in.
¿Cómo accede el proveedor de IA a los datos de la empresa?
El acceso debería ser de solo lectura, con permisos por usuario aplicados en la consulta y con un registro completo de lo que se ejecutó. Las cuatro preguntas de esta sección son las que el área de sistemas debería hacer siempre.
5. ¿El acceso a nuestras fuentes es de solo lectura, verificable a nivel de credencial?
Una política dice «no vamos a escribir»; una credencial de solo lectura hace que escribir sea imposible. Pida ver la configuración, no la promesa. Es la aplicación directa del principio de menor privilegio: cada acceso enumerado y justificado, ninguno concedido por comodidad.
6. ¿En qué momento se aplican los permisos de cada usuario?
La respuesta correcta es «al construir la consulta». Si los permisos se aplican filtrando el resultado, el sistema sí leyó la información restringida antes de decidir no mostrarla, y esa diferencia importa tanto para el riesgo como para el cumplimiento.
7. ¿Qué datos salen de nuestra infraestructura, hacia dónde, qué queda almacenado fuera y se usa para entrenar modelos?
Pregunta específica, respuesta específica, y conviene documentarla: condiciona el análisis de transferencia internacional bajo la normativa local. En Colombia, ese análisis se hace bajo la Ley 1581 de 2012.
8. ¿Qué queda registrado de cada consulta y de cada acción, y por cuánto tiempo?
Quién preguntó, qué se ejecutó y cuándo. Sirve para auditar y para investigar un resultado dudoso. Si el sistema es un agente de IA que además puede actuar —enviar un correo, modificar un registro—, conviene preguntar también si alguna acción ocurre sin confirmación humana y cómo se protege contra el prompt injection, las instrucciones escondidas en el contenido que el agente lee. La postura de Igniten sobre ese punto está explicada en por qué nuestro asistente no puede ejecutar nada sin que alguien lo confirme.
¿Cómo se define el éxito de un piloto de IA?
El éxito de un piloto se define por escrito antes de empezar, con una métrica de negocio observable, un umbral y una fecha.
9. ¿Cuál es el criterio de éxito del piloto, por escrito y antes de empezar?
Sin esos tres elementos, una prueba de concepto siempre concluye que hace falta una etapa más: hay algo funcionando, nadie quiere haber perdido la inversión y la conversación sobre si sirvió no llega a darse. Conviene además acordar qué pasa si el criterio no se cumple. Un proveedor que acepta de antemano que en ese caso lo correcto es detenerse está diciendo algo sobre cómo entiende su negocio.
10. ¿En qué casos su solución no es la mejor opción?
Toda solución tiene un límite, y un proveedor con experiencia de terreno lo conoce y lo puede nombrar. Cuando la respuesta es que sirve para todo, los límites igual existen: se descubren durante la implementación, con la inversión ya hecha.
11. ¿Qué necesitamos tener resuelto de nuestro lado antes de empezar?
Un proveedor que responde «nada, nosotros nos encargamos» está simplificando para vender o no trabajó con empresas parecidas. En proyectos de datos, la condición previa habitual es de gobernanza de datos: definiciones de métricas acordadas entre áreas. Un proveedor que lo menciona sin que se lo pregunten conoce el terreno.
¿Qué evidencia pedirle a un proveedor de IA?
La evidencia útil es una conversación con clientes parecidos, no una lista de logos.
12. ¿Con qué empresas parecidas a la nuestra trabajaron, y podemos hablar con ellas?
La pregunta más útil para esa conversación no es si están conformes, sino qué salió peor de lo esperado y cómo se resolvió. Una referencia que describe un problema concreto y su solución informa más que cualquier recomendación general.
¿Cómo leer las respuestas de un proveedor de IA?
El criterio más útil es prestar más atención a la precisión de la respuesta que a su contenido. Algunos contrastes típicos:
| Tema | Respuesta verificable | Respuesta que no responde |
|---|---|---|
| Mantenimiento | «Es opcional, se cotiza aparte y ustedes deciden cada año si lo renuevan» | «Trabajamos con un modelo flexible según cada cliente» |
| Acceso | «Usuario de solo lectura; les mostramos la configuración» | «Nuestra plataforma es segura» |
| Datos | «Estas tablas, estos campos, procesados en estos países» | «Cumplimos con todas las normativas» |
| Piloto | «Si en seis semanas no se alcanza el umbral, recomendamos detenerse» | «Vamos ajustando sobre la marcha» |
Lo mismo con los límites. La incomodidad de decir «esto no es para ustedes» es real, y un proveedor dispuesto a asumirla en la etapa comercial probablemente también la asuma cuando haya que decir que una etapa del proyecto no justificó su inversión.
¿Cuáles son las señales de alerta al contratar IA?
Estas señales, por sí solas, justifican pedir más información antes de firmar:
- El código o las definiciones del negocio quedan en manos del proveedor.
- El sistema pide acceso de escritura o credenciales de administrador sin una justificación escrita.
- No hay criterio de éxito del piloto, o aparece recién después de empezar.
- No se puede responder qué datos salen de la empresa ni hacia dónde.
- Las preguntas de seguridad se contestan con adjetivos en lugar de mecanismos.
Ordenar esta evaluación antes de contratar es parte del nivel de diagnóstico y proveedores del servicio de gobernanza. Las respuestas de Igniten a las preguntas de seguridad están en la sección de IA del cuestionario de proveedores; las de propiedad y contratación, en consultoría de IA y en qué es la optimización de procesos con IA y cómo evita el lock-in. El marco completo está en la guía de gobernanza de IA para empresas medianas de América Latina.