Qué hacer si tu proyecto de IA no dio resultado

Por qué la mayoría no sabe qué hacer cuando el proyecto de IA no funcionó

Cuando un proyecto de IA no entrega lo prometido, en la mayoría de las empresas pasa una de dos cosas, y las dos son igual de dañinas. La primera: el comité decide en silencio que “la IA no era para nosotros”, archiva el tema completo y deja pasar uno o dos años sin volver a intentarlo, mientras la competencia sí avanza. La segunda: alguien insiste en repetir el mismo proyecto, con el mismo proveedor, con el mismo caso de uso, cambiando solo la fecha de entrega, esperando que la segunda vuelta sea distinta sin haber cambiado nada de fondo.

Ninguna de las dos reacciones nace de un diagnóstico. Nacen del cansancio del comité o de la necesidad política de alguien de mostrar que “algo se está haciendo”. El problema no es que el proyecto haya fallado, eso le pasa a la mayoría de los primeros proyectos de IA en empresas que recién empiezan. El problema es no saber por qué falló antes de decidir el siguiente paso.

Esta guía no explica cómo evitar que un proyecto de IA falle, eso ya lo cubren otras entradas de este centro de conocimiento sobre elección de caso de uso y auditoría de proveedores. Esta guía asume que el proyecto ya se implementó, ya se gastó el presupuesto y ya no dio el resultado esperado, y explica qué hacer a partir de ahí: cómo diagnosticar la causa real, cómo elegir entre tres caminos concretos, y cómo volver a presentarse ante el comité sin repetir el mismo error de diagnóstico.

Qué significa hacer esto bien (y qué no)

Hacer esto bien no es encontrar rápido a quién culpar para cerrar el tema en la próxima reunión. Es separar, con evidencia concreta, si el problema estuvo en la tecnología entregada, en los datos que la alimentaban, en el caso de uso elegido desde el inicio o en cómo el equipo terminó usándola, y solo después de eso decidir qué camino tomar.

• Culpar al proveedor de forma automática porque es el actor más fácil de señalar y el que menos cuesta políticamente dentro de la empresa.
• Culpar “a la IA” en abstracto, como si la tecnología fuera responsable de un caso de uso mal elegido o de datos que nunca estuvieron listos.
• Repetir el mismo proyecto con el mismo proveedor y el mismo alcance, cambiando solo el nombre del responsable o la fecha de entrega.
• Archivar el tema por vergüenza institucional, sin dejar registro de qué se aprendió, para que el próximo intento cometa exactamente el mismo error.

El diagnóstico honesto: las cuatro causas raíz que hay que descartar, en orden

Antes de decidir si retomas, archivas o cambias de proveedor, hay que aislar cuál de estas cuatro causas explica realmente el resultado. Casi siempre es una combinación de dos, rara vez una sola, pero hay que nombrarlas por separado porque cada una apunta a un camino distinto.

• ¿Fue el proveedor? Revisa si lo entregado cumplía técnicamente lo firmado en el contrato o la propuesta: precisión prometida, tiempos de respuesta, integración con los sistemas existentes. Si el sistema nunca funcionó de forma estable ni en ambiente controlado, o el proveedor no pudo sostener soporte y ajustes después de la entrega, la causa raíz está de su lado, no del negocio.
• ¿Fueron los datos sucios o insuficientes? Verifica si la información que el sistema necesitaba para decidir estaba centralizada, actualizada y limpia antes de arrancar, o si vivía repartida entre hojas de cálculo, sistemas que no conversaban entre sí y criterios distintos por área. Un sistema de IA construido sobre datos sucios no falla por mala tecnología, falla porque nunca tuvo con qué trabajar.
• ¿Se eligió mal el primer caso de uso? Revisa si el proceso elegido tenía volumen suficiente, dolor real medible y un dueño con nombre dispuesto a defenderlo, o si se eligió porque sonaba bien en una presentación de directorio. Un caso de uso elegido por entusiasmo y no por viabilidad estaba condenado desde antes de escribir la primera línea de código.
• ¿Fue un problema de adopción del equipo, no de tecnología? Revisa si el sistema funcionaba técnicamente pero el equipo dejó de usarlo, volvió a su proceso manual de siempre o lo saboteó de forma pasiva por no haber sido consultado ni entrenado. Esta causa es la que menos se diagnostica porque es la más incómoda de admitir: la tecnología funcionaba, la empresa no estaba lista para sostenerla.

La forma de aislar cuál de las cuatro pesó más no es preguntarle al proveedor ni al gerente que impulsó el proyecto. Es entrevistar a quien lo usó (o dejó de usarlo) todos los días, revisar los registros técnicos reales del sistema y comparar contra el contrato original línea por línea. Si no puedes citar evidencia concreta para la causa que estás señalando, todavía no terminaste el diagnóstico.

Cómo decidir entre retomar, archivar o cambiar de proveedor

Con la causa raíz identificada, hay tres caminos posibles y ninguno es automáticamente el correcto. El error más común en esta etapa es elegir el camino por comodidad política, no por lo que dice el diagnóstico.

Camino 1: Retomar y rediseñar la misma idea con mejor base

Este camino aplica cuando la causa raíz fue datos sucios o un caso de uso mal delimitado, pero el dolor de negocio original sigue siendo real y prioritario. No se retoma el proyecto tal cual estaba: se retoma el dolor, con datos ya ordenados o con un alcance más pequeño y verificable. Retomar sin corregir la causa raíz específica es el error que más empresas cometen en su segundo intento.

Camino 2: Cortar pérdidas y archivar el proyecto

Este camino aplica cuando el dolor de negocio que motivó el proyecto ya no es prioridad, cuando el volumen del proceso resultó ser menor de lo estimado, o cuando la causa raíz es estructural (falta de datos que tomaría más de un año construir, o un proceso que la empresa está a punto de rediseñar por completo de otra forma). Archivar no es fracasar; es reconocer que insistir ahí consume presupuesto y crédito político que rinden más en otro caso de uso.

Camino 3: Cambiar de proveedor, manteniendo el caso de uso

Este camino aplica cuando el diagnóstico señala claramente al proveedor: no cumplió lo contratado, no tuvo la capacidad técnica que ofreció en la venta, o desapareció en soporte después del primer pago. Antes de firmar con un proveedor nuevo, hay que auditar el contrato anterior punto por punto y exigir al nuevo proveedor evidencia concreta de que resuelve exactamente lo que el anterior no pudo, no una propuesta genérica repetida.

Cómo recuperar la confianza del comité para un segundo intento

El obstáculo más grande para el segundo intento casi nunca es técnico, es político: el comité o dirección ya gastó presupuesto y paciencia en un proyecto que no entregó nada, y la reacción natural es desconfianza hacia cualquier propuesta nueva de IA.

• Presenta el diagnóstico antes que la propuesta. El comité necesita ver primero por qué falló el intento anterior, con evidencia citada, antes de escuchar cualquier plan nuevo. Saltar directo a la propuesta suena a que no se aprendió nada.
• Nombra la causa raíz sin suavizarla ni exagerarla. Decir “el proveedor no cumplió el contrato en tiempos de respuesta” es más creíble y más útil que “hubo desafíos de implementación”. El comité respeta precisión, no diplomacia vacía.
• Muestra qué cambia esta vez, en concreto. No alcanza con decir “esta vez va a ser distinto”. Hay que mostrar el dato específico que se corrigió: datos ya centralizados, un caso de uso más pequeño y verificable, o un proveedor auditado con referencias reales.
• Propón un alcance más chico y verificable para el segundo intento. Pedir el mismo presupuesto y el mismo plazo ambicioso que el proyecto que falló es pedirle al comité que repita la misma apuesta. Un alcance reducido, con un número medible en semanas, reconstruye confianza más rápido que una promesa grande.
• Fija de antemano el criterio de éxito y quién lo audita. El comité necesita saber, antes de aprobar el segundo intento, exactamente qué número se va a medir y en qué fecha se va a revisar, para no depender otra vez de la palabra de quien propone el proyecto.

Errores comunes al decidir qué hacer después de un proyecto de IA fallido

• Culpar al proveedor sin auditar el contrato original ni los registros técnicos reales, solo porque es la explicación más cómoda para el comité interno.
• Retomar el mismo proyecto sin corregir la causa raíz identificada, esperando que la insistencia sola resuelva lo que un diagnóstico deficiente dejó sin resolver.
• Archivar el tema de IA por completo durante uno o dos años, en vez de archivar solo ese caso de uso y seguir con otro más viable.
• Cambiar de proveedor manteniendo exactamente el mismo caso de uso mal elegido desde el inicio, repitiendo el error de fondo con otro nombre en el contrato.
• Presentar el segundo intento ante el comité sin mostrar antes el diagnóstico del primero, como si el fracaso anterior nunca hubiera pasado.
• No dejar registro escrito de la causa raíz diagnosticada, de forma que un tercer intento fallido, si llega a pasar, vuelva a partir de cero.

Cómo se ve esto en la práctica

Una empresa de retail mediana, en Perú, alrededor de 300 empleados, había implementado un sistema de recomendación de productos para su canal de e-commerce, con la promesa de subir el ticket promedio. Seis meses después del lanzamiento, el ticket promedio no se había movido y el comité comercial ya estaba listo para declarar “la IA no funciona para nuestro negocio” y volver a las promociones manuales de siempre.

Antes de archivar el proyecto, se ejecutó un diagnóstico de causa raíz con evidencia. El sistema técnicamente funcionaba: generaba recomendaciones y las entregaba a tiempo, así que el proveedor no era la causa. El problema apareció en dos lugares a la vez: el catálogo de productos tenía categorías inconsistentes desde hacía años, cargadas por distintas personas con criterios distintos, así que el sistema recomendaba con información parcial; y el equipo de e-commerce nunca fue entrenado para interpretar ni ajustar las recomendaciones, así que las trataba como una función más de la web que nadie revisaba.

El diagnóstico descartó archivar el proyecto: el dolor de negocio (ticket promedio bajo) seguía siendo real y medible, y la causa raíz (datos y adopción, no tecnología ni proveedor) era corregible en semanas, no en años. Se retomó el mismo caso de uso, con el catálogo reordenado por un criterio único y con dos personas del equipo comercial capacitadas para leer y ajustar las recomendaciones cada semana. El comité aprobó el segundo intento después de ver el diagnóstico completo, con un alcance más chico (una sola categoría de producto primero) y una fecha concreta para revisar el número.

Mi criterio

Cómo saber si hiciste bien el diagnóstico y la decisión

El proceso de decidir qué hacer después de un proyecto de IA fallido se puede evaluar con la misma disciplina que le exigirías al proyecto siguiente.

• Puedes nombrar la causa raíz del fracaso anterior con evidencia citada (contrato, registros técnicos, entrevistas), no con una impresión general de “no funcionó”.
• El camino elegido (retomar, archivar o cambiar de proveedor) responde directamente a esa causa raíz, no a quién tenía más poder político en la sala al momento de decidir.
• Si el camino fue retomar o cambiar de proveedor, existe una corrección concreta y verificable de lo que falló antes, no solo una promesa de que “esta vez va a ser distinto”.
• El comité o dirección vio el diagnóstico completo antes de aprobar cualquier segundo intento, y no se les pidió confianza sin evidencia detrás.
• El segundo intento arrancó con un alcance más chico y un criterio de éxito medible fijado por adelantado, no con la misma ambición que el proyecto que falló.

Si tu proceso cumple esto, ya no importa tanto que el primer proyecto haya fallado. Importa que la empresa aprendió a diagnosticar antes de decidir, que es exactamente lo que la mayoría de los competidores todavía no hace.