Checklist antes de lanzar un proyecto de IA (7 comprobaciones)

La mayoría de los proyectos de IA no fracasan por la tecnología. Fracasan porque nadie escribió, antes de gastar, qué problema resolvían, cuánto costaban de verdad, quién respondía si salía mal y en qué momento había que pararlo. Esta es la checklist de siete comprobaciones que uso para responder esas preguntas antes de firmar un presupuesto. Si no puedes contestar a las siete, todavía no tienes un proyecto: tienes una idea con entusiasmo alrededor.

Va dirigida a quien decide, no a quien programa. No hace falta que sepas de tecnología. Cada término técnico lo explico en cuanto aparece.

¿Para qué sirve una checklist antes de un proyecto de IA?

Sirve para convertir el entusiasmo en una decisión que puedas revisar más tarde. La IA genera una presión rara dentro de las empresas: todo el mundo tiene la sensación de que hay que hacer “algo con IA” ya, y esa prisa es justo la que hace que se aprueben proyectos que nadie ha pensado. La checklist mete un freno breve. No para decir que no a todo, sino para empezar por el no y obligar a que la idea se gane el sí.

Las siete comprobaciones siguen el orden en el que fallan los proyectos reales. Se empieza por el problema y se termina por la persona que responde. Si una comprobación se queda en blanco, esa casilla vacía es tu mayor riesgo.

1. El caso de uso: ¿qué problema concreto resuelve?

Nombra la tarea, no la tecnología. “Queremos usar IA” no es un caso de uso. “Queremos que el equipo de atención al cliente deje de copiar a mano los datos de cada correo al sistema de pedidos” sí lo es. El primero es un deseo; el segundo es un problema con dueño, con horas medibles y con un antes y un después.

La señal de alarma es fácil de detectar. Si cuando preguntas para qué la respuesta empieza por la herramienta (“para meter un chatbot”, “para usar un LLM”), todavía no hay caso de uso. Un LLM es un modelo de lenguaje, un programa que genera texto probable a partir de lo que le pides. Es un medio. El problema de negocio va primero, siempre. Si tienes dudas sobre dónde encaja de verdad la IA en tu empresa, ese mapa está en la guía de casos de uso de IA en empresas.

2. El coste real: ¿cuánto cuesta de verdad?

El coste real de un proyecto de IA casi nunca es la licencia. La licencia del proveedor suele ser la parte pequeña y la más fácil de ver. Debajo hay otras que se ignoran en la primera reunión y aparecen todas juntas en la tercera.

Hay que presupuestar la integración con tus sistemas actuales, la preparación de los datos que la IA va a usar (que casi nunca están tan limpios como crees), el mantenimiento cuando el proveedor cambie el modelo, y la supervisión humana que hará falta durante meses. Y hay un coste que descoloca a quien viene del software tradicional: muchos servicios de IA cobran por uso. Cada consulta cuesta un poco. Si el proyecto funciona y se dispara el volumen, la factura sube con él. Eso es bueno para el negocio y conviene tenerlo en el presupuesto desde el principio, no como sorpresa.

No hace falta que tengas la cifra exacta hoy. Sí hace falta que sepas que estas partidas existen y que preguntes por cada una. Un presupuesto que solo contempla la licencia está infravalorando el proyecto, probablemente en uno o dos órdenes de magnitud.

3. El riesgo: ¿qué pasa cuando se equivoca?

La pregunta no es si la IA se va a equivocar, sino qué ocurre cuando lo haga. Y se va a equivocar. Conviene entender dos palabras antes de seguir.

La IA generativa no es determinista. Un programa normal, ante la misma entrada, devuelve siempre la misma salida: dos más dos, cuatro, hoy y mañana. Un modelo de lenguaje, ante la misma pregunta, puede darte respuestas distintas en dos intentos. Y puede alucinar: inventar un dato, una cifra o una referencia con apariencia perfectamente creíble, dicho con total seguridad. No es un fallo que se arregle con una actualización. Es cómo funciona la tecnología.

Así que el riesgo se mide con tres preguntas sobre el error. ¿Es reversible o deja daño permanente? ¿Es visible antes de llegar al cliente o se cuela sin que nadie lo vea? ¿Es barato de corregir o caro? Redactar un borrador interno que un humano revisa es riesgo bajo. Enviar respuestas automáticas a clientes sin que nadie las mire es riesgo alto. La misma tecnología, dos proyectos completamente distintos. Estas preguntas de riesgo las desarrollo una a una en las cuatro preguntas antes de usar IA.

4. Las mitigaciones: ¿cómo reducimos el daño del error?

Una mitigación es cualquier medida que reduce el daño cuando la IA falla. Como el error es inevitable, este punto no es opcional: si un proyecto no tiene mitigaciones, no está listo para salir.

Las que mejor funcionan son sencillas. Poner a una persona a revisar antes de que la salida llegue al cliente, lo que se llama tener un humano en el bucle. Acotar el alcance para que la IA toque solo una tarea pequeña y bien delimitada en lugar de un proceso entero. Mostrar siempre la fuente para que quien recibe la respuesta pueda comprobarla. Y una decisión que conviene tomar temprano: qué datos entran y qué datos no. Meter información personal o confidencial en un servicio externo sin pensarlo es donde empiezan los problemas serios, incluidos los legales.

Aquí toca una nota de prudencia. En la Unión Europea, el tratamiento de datos personales está regulado por el RGPD, y el uso de sistemas de IA por un reglamento europeo específico que ordena las obligaciones según el nivel de riesgo del sistema. No voy a citar artículos ni fechas concretas, porque esto no es asesoramiento jurídico y cada caso es distinto. La comprobación para la checklist es más simple: antes de lanzar, alguien con criterio legal tiene que haber mirado qué datos usa el proyecto y bajo qué obligaciones cae.

5. La métrica de éxito: ¿cómo sabemos si funciona?

Define la medida del éxito antes de arrancar, no después. Este es el punto donde más proyectos se engañan a sí mismos, porque la IA es espectacular en las demos. Una demostración de quince minutos deja a todo el mundo impresionado. Eso no significa nada para el negocio.

La métrica tiene que ser un número que ya te importaba antes de que existiera la IA: las horas que tu equipo dedica a una tarea repetitiva, el tiempo de respuesta a un cliente, los errores de transcripción al mes o las reclamaciones que llegan por un dato mal copiado. Si el proyecto mueve ese número en la dirección correcta, funciona. Si solo “parece muy avanzado” pero el número no se mueve, no funciona, por muy bien que quede en la reunión de dirección. Escribe la métrica y su valor de partida el primer día. Sin ese valor de partida no podrás demostrar ninguna mejora, ni a favor ni en contra.

6. El criterio de parada: ¿cuándo lo cancelamos?

Decide de antemano qué resultado te haría cancelar el proyecto, y ponle fecha. Esta es la comprobación que casi nadie hace, y la que más dinero salva. Sin un criterio de parada, un proyecto sin resultados no se cancela: se queda en un limbo, consumiendo presupuesto y atención mes tras mes porque nadie se atreve a decir que no ha salido.

El criterio combina dos cosas: un umbral y un plazo. “Si en tres meses la métrica no ha mejorado al menos hasta aquí, paramos y hacemos balance.” Esto no te vuelve pesimista. Te deja arriesgar con tranquilidad, porque sabes que la pérdida máxima está acotada. Un proyecto con criterio de parada es un experimento controlado. Uno sin criterio de parada es una apuesta abierta que puede sangrar durante un año.

7. El responsable: ¿quién responde por esto?

Tiene que haber una persona con nombre y apellidos que responda por el proyecto. No un comité, no un departamento, no “el equipo de innovación”. Cuando la responsabilidad es de todos, en la práctica no es de nadie, y eso se nota el día que algo falla y hay que decidir rápido.

El responsable no tiene que ser quien programa ni quien entiende el modelo por dentro. Tiene que ser quien puede parar el proyecto, quien mira la métrica cada semana y quien da la cara cuando la IA se equivoca de cara a un cliente. Si nadie quiere ese papel, esa es la información más honesta que vas a recibir sobre las ganas reales que hay de sacar esto adelante.

La checklist de una página

Esta es la versión para llevar a la reunión. Una pregunta por fila y, al lado, la señal de alarma que indica que esa casilla todavía no está resuelta.

Comprobación	Pregunta	Señal de alarma
Caso de uso	¿Qué tarea concreta mejora?	La respuesta empieza por la herramienta, no por el problema
Coste real	¿Qué cuesta además de la licencia?	El presupuesto solo tiene una línea
Riesgo	¿Qué pasa cuando se equivoca?	”No se va a equivocar”
Mitigaciones	¿Cómo reducimos el daño del fallo?	Nadie revisa antes de llegar al cliente
Métrica	¿Qué número del negocio se mueve?	”Impresiona en la demo”
Criterio de parada	¿Cuándo lo cancelamos?	No hay umbral ni fecha
Responsable	¿Quién responde por esto?	”Es cosa del equipo”

Cada una de estas siete comprobaciones es un tema con su propio criterio, y trabajarlas con cabeza es justo lo que enseña, pregunta por pregunta, el curso IA sin hype. Y cuando tengas un piloto que sí pasa la checklist, el siguiente paso, llevarlo de la prueba a algo que use toda la empresa, lo cuento en el plan de adopción de IA en una empresa.

Un concepto nuevo cada semana

Suscribirme

Errores que repite todo el mundo

Empezar por la herramienta. Alguien vio una demo, quiere “un chatbot”, y se busca el problema después. El orden correcto es el inverso: el problema manda y decide si la IA es siquiera la respuesta.

Presupuestar solo la licencia. Es el error de coste más caro, porque descubres las otras partidas cuando ya has arrancado y es tarde para echarse atrás con dignidad.

Confundir la demo con el resultado. Una demo impresionante y un número de negocio que mejora son cosas distintas, y la distancia entre ambas es donde mueren los proyectos que “prometían mucho”.

No poner criterio de parada. Así nace el proyecto zombi: ni funciona ni se cancela, solo consume. Un umbral y una fecha escritos el primer día lo evitan.

Diluir la responsabilidad. “Es de todos” es la forma educada de decir que no es de nadie. El día del fallo, esa frase se paga cara.

Preguntas frecuentes

¿Necesito saber de tecnología para usar esta checklist de proyecto de IA?

No. Está pensada justo para lo contrario: para que una persona que decide, sin base técnica, pueda interrogar un proyecto de IA sin depender de que el proveedor le traduzca. Las siete preguntas son de negocio, no de ingeniería. Si el equipo técnico no sabe responderlas en lenguaje llano, esa ya es una señal.

¿Cuánto debería costar un primer proyecto de IA?

Depende tanto del caso que cualquier cifra concreta sería mentira. La regla sana es otra: empieza por un piloto pequeño, acotado y barato, con su criterio de parada, antes de comprometer un presupuesto grande. El primer proyecto no está para transformar la empresa. Está para aprender si esto te sirve, gastando lo mínimo para averiguarlo.

¿Y si el proveedor me dice que su IA no se equivoca?

Es la mayor señal de alarma de toda la lista. Cualquier IA generativa puede equivocarse y puede alucinar, y quien te vende lo contrario o no entiende la tecnología o prefiere que tú no la entiendas. Un buen proveedor te habla de los errores y de cómo los mitiga, no de que no existen.

¿Esto vale para una pyme o solo para empresas grandes?

Vale para cualquier tamaño, y una pyme lo necesita todavía más. Una empresa grande puede absorber un proyecto fallido; una pyme siente cada euro mal gastado. El criterio de parada y el piloto acotado protegen precisamente a quien tiene menos margen para equivocarse, así que llamarlos burocracia de empresa grande es entenderlos al revés.

¿Qué hago con la checklist una vez rellena?

No la archives. Es un documento vivo que se revisa el día que toca el criterio de parada. Ahí comparas lo que escribiste al principio con lo que ha pasado de verdad: si la métrica se movió, si el coste era el previsto, si el responsable sigue mirando. Esa revisión honesta, hecha a tiempo, es la que decide si sigues, ajustas o paras.