Por qué fallan los proyectos de IA: lo que se comprueba antes de firmar

Si buscas «por que fallan los proyectos de ia» en Google, la primera página repite un patrón: listas de causas a posteriori. «Datos malos», «objetivos difusos», «falta de gobernanza». Todo cierto, pero casi nadie propone una verificación sencilla antes de firmar. Eso se puede comprobar en una tarde.

Yo uso tres preguntas. Se contestan con quien paga y con quien usará el sistema. No hace falta prototipo ni contrato. Solo claridad. Si alguna no tiene respuesta concreta, el riesgo de fracaso es alto. Aquí explico cuáles son, cómo las planteo y qué señales busco.

Pregunta 1: ¿Quién lo usará mañana y qué cambia en su rutina?

No pregunto por una «persona usuaria» abstracta. Pido un nombre de rol y un momento concreto. «El responsable de soporte a las 9:00 del lunes». ¿Qué abre primero? ¿Qué dato ve que hoy no tiene? ¿Qué decide distinto? El primer uso real define el proyecto. Sin ese primer uso, no hay caso de negocio, hay una intención.

La comprobación es directa. Pido que describan el flujo del primer día en tres minutos. Entrada, acción, salida. Si no sale en voz alta y en lenguaje simple, la fricción operativa llegará igual, pero tarde y cara. Un guion útil es este: antes el equipo recorre cinco pantallas para responder un correo; después envía una respuesta propuesta con la evidencia ya reunida. Si nadie puede decir «qué hace a las 9:00 del primer lunes», el proyecto no está listo para firmar.

Pregunta 2: ¿Qué dato entra, de dónde sale y con qué permisos?

La segunda pregunta no es técnica, es logística. ¿Cuál es la fuente primaria? ¿Quién la controla? ¿Con qué latencia llega? ¿Se puede usar para este fin? Si el dato clave llega con retraso o sin permiso, el modelo podrá ser brillante y el resultado seguirá siendo inútil. La IA solo escala sobre tuberías que existen.

Hago una «prueba del cubo de agua». No entreno nada. Tomo un subconjunto pequeño y lo paso por el recorrido completo. Un expediente, diez correos, tres chats. ¿Se extraen sin intervención de alguien que está de guardia? ¿Se entienden los campos? ¿Hay duplicados? ¿Qué ocurre con un archivo dañado? Esta pasada corta revela dónde se atasca el flujo y quién tiene la llave. Si para conseguir esos diez ejemplos hay que pedir favores, el proyecto se clavará en el primer sprint.

También verifico los bordes. ¿Hay términos de uso que limiten llamadas a APIs? ¿Se exige consentimiento explícito? ¿Se firma ajuste de finalidad? Si la respuesta es «ya lo vemos con legal», paro ahí. Aquí conviene decidir el primer caso con menos fricción. En esta línea encaja una guía práctica: por dónde empezar en una empresa para evitar cuellos de botella de datos, y cómo elegir un alcance que no dependa de integraciones imposibles.

Pregunta 3: ¿Cuándo lo cortamos y con qué plan B?

Antes de firmar, se define el punto de corte. Métrica, fecha y quién decide. Sin eso, el proyecto se estira, gasta y nadie sabe por qué sigue vivo. Propongo fijar el umbral con un escenario explícito: «si en cuatro semanas el tiempo de respuesta no baja frente a la línea base manual, se detiene y se documenta lo aprendido». Es un ejemplo, no una regla universal. Lo importante es que exista un criterio verificable.

El plan B no es rendirse. Es describir qué se rescata si no se alcanza el umbral. Prompts depurados, esquema de datos, políticas de calidad, conectores reutilizables. Fallar barato y con activos transferibles es una victoria. Si el contrato no permite cortar limpio, o si nadie se hace cargo de la decisión, el riesgo operativo se multiplica. Un proyecto de IA sin salida definida acaba siendo un gasto recurrente sin dueño.

Cómo se resuelven en una tarde

El formato es simple. Una reunión con el responsable del área, dos usuarios reales y quien tiene la llave de los datos. Cuarenta y cinco minutos por pregunta. Se toma nota en una página. No hay demo. No hay diapositivas. El objetivo es tensión positiva: o se confirma el encaje, o se descubre antes el bloqueo.

En esa sesión pido dos entregables ligeros. Uno, el guion del primer lunes: tres pasos, antes y después. Dos, el mapa mínimo de datos: origen, permiso, latencia. Con eso se redacta un inicio pequeño y medible. Si aparece un hueco grave, se aparca el caso y se busca otro. Un equipo que dedica veinte horas al mes a limpiar planillas ya tiene una señal: sin automatizar ese saneo, cualquier modelo cuesta más de lo que devuelve.

Señales verdes y rojas que he visto repetirse

Verde: el usuario opera ya con un checklist y desea quitar pasos, no añadir pantallas. Verde: hay un campo con etiqueta, dueño y definición clara. Verde: el sponsor se anima a fijar punto de corte con su métrica, no con la del proveedor. Con tres verdes, el arranque suele ir derecho, incluso si el modelo inicial es básico.

Roja: «lo pueden usar todos» y nadie lo reclama en voz alta. Roja: datos que llegan por correo y cambian de formato cada semana. Roja: objetivos definidos por jerga y no por acciones («mejorar la inteligencia comercial»). Cuando hay rojas en las tres preguntas, lo responsable es parar. Es más barato ajustar el caso que insistir en un encargo que nacerá ahogado.

Por qué esto predice mejor que un listado de causas

Las listas post mortem describen síntomas. Estas tres preguntas fuerzan decisiones previas: quién cambia su rutina, qué tubo de datos ya existe y qué hito corta la inercia. Son palancas de realidad. No dependen de modelos ni de marcas. Se validan en voz alta y se firman en el contrato.

Además, alinean incentivos. El área usuaria se compromete con un primer uso concreto. Sistemas valida que no se promete lo que no se puede extraer. Dirección sabe cuándo cortar si no hay mejora. Si el proveedor acepta estas reglas, hay confianza. Si se incomoda, mejor saberlo antes. La IA funciona cuando encaja con el trabajo, no cuando suena bien en una presentación.

Publico automatizaciones funcionando en @WhatsMarketing_es.

Si quieres que mire tu caso, escríbeme. Trabajo desde Buenos Aires, siendo malagueño, con clientes en Ciudad de México, Argentina, el resto de Latinoamérica y España.