La narrativa dominante en AI es que hay que moverse rápido. Construir, iterar, lanzar. Y en muchos casos es cierto. Pero nadie habla de los proyectos que la decisión correcta fue no empezar.
En Redstone Labs hemos dicho “no” a proyectos de AI más veces de las que hemos dicho “sí.” No porque no pudiéramos construirlos. Sino porque construirlos habría sido un error.
Acá van tres ejemplos reales (con los detalles cambiados por confidencialidad) de proyectos que evaluamos, rechazamos, y por qué fue la decisión correcta.
Proyecto 1: El chatbot para atención al cliente
El pedido: Una empresa de servicios financieros quería un chatbot con AI para manejar el 80% de las consultas de sus clientes.
Por qué sonaba bien: Tenían 15 personas en call center, las consultas eran repetitivas, y el costo operativo era alto. El caso de negocio en papel era impecable.
Por qué dijimos no: Cuando analizamos las conversaciones reales, el 80% de las consultas “repetitivas” tenían matices que cambiaban completamente la respuesta. “¿Cuándo me llega mi tarjeta?” parece simple, pero la respuesta dependía de si era tarjeta nueva, reposición por fraude, renovación, o cambio de producto. Cada caso tenía un flujo distinto.
Un chatbot que respondiera correctamente el 70% del tiempo y mal el 30% iba a generar más problemas que los que resolvía. En servicios financieros, una respuesta incorrecta no es una molestia. Es un riesgo regulatorio.
Lo que recomendamos: Antes de automatizar las respuestas, estructurar la información. Construir una base de conocimiento interna bien organizada para que los agentes humanos encontraran la respuesta correcta más rápido. Menos emocionante, más efectivo.
Proyecto 2: Predicción de demanda con machine learning
El pedido: Una empresa de distribución quería predecir la demanda de sus productos para optimizar inventario. Clásico caso de ML.
Por qué sonaba bien: Tenían 3 años de datos de ventas, márgenes ajustados, y pérdidas significativas por sobre-stock y faltantes.
Por qué dijimos no: Los datos existían, pero estaban en 4 sistemas distintos que no se hablaban entre sí. Las categorías de productos habían cambiado dos veces en 3 años. Había meses completos sin datos por migración de ERP. Y lo más importante: las decisiones de compra las tomaba un gerente con 20 años de experiencia que ajustaba todo “a ojo” basándose en factores que no estaban en ningún sistema (clima, feriados locales, competencia directa).
Entrenar un modelo con esos datos no iba a producir predicciones. Iba a producir ruido con formato bonito.
Lo que recomendamos: Primero, unificar los datos en un solo sistema con categorías consistentes. Segundo, documentar los criterios de decisión del gerente experimentado (eso que estaba en su cabeza y en ningún sistema). En 6 meses, con datos limpios y criterios explícitos, un modelo de predicción tendría sentido. Antes de eso, era quemar dinero.
En ecología le llaman carrying capacity: la cantidad máxima de organismos que un ecosistema puede sostener. Si tu ecosistema de datos no puede sostener un modelo de ML, forzarlo no va a funcionar. Primero enriquece el ecosistema.
Proyecto 3: Visión computacional para control de calidad
El pedido: Una manufacturera quería usar cámaras con AI para detectar defectos en su línea de producción.
Por qué sonaba bien: Las tasas de defectos eran del 3-4%, la inspección manual era lenta, y los ejemplos de visión computacional en manufactura son abundantes.
Por qué dijimos no: El producto tenía variaciones naturales de color, textura y forma que eran normales pero indistinguibles de algunos defectos para un sistema automatizado. Entrenar un modelo requería miles de imágenes etiquetadas correctamente, y la definición de “defecto” variaba entre los inspectores humanos. Lo que uno aprobaba, otro rechazaba.
No era un problema de AI. Era un problema de definición de calidad que la empresa no había resuelto internamente. Un sistema de visión computacional habría automatizado la inconsistencia, no la calidad.
Lo que recomendamos: Estandarizar los criterios de calidad primero. Crear un manual visual con ejemplos claros de lo que es aceptable y lo que no. Entrenar a los inspectores humanos con esos criterios. Después, cuando la consistencia humana mejorara, usar esas inspecciones consistentes como datos de entrenamiento para el modelo.
El patrón
Los tres proyectos tienen algo en común: el problema no era técnico. Era organizacional. Los datos no estaban listos, los procesos no estaban definidos, o las expectativas no estaban alineadas con la realidad.
La tentación es decir “la AI lo resolverá.” Pero la AI no resuelve problemas organizacionales. Los amplifica. Si tu proceso es inconsistente, la AI lo será. Si tus datos son malos, los resultados serán malos. Si tus expectativas son irreales, la decepción será real.
Por qué esto importa
Decir “no” a un proyecto no es perder un cliente. Es ganar credibilidad. Los tres clientes de estos ejemplos volvieron después con proyectos mejor definidos, mejor preparados, y con resultados reales.
La honestidad no vende en el pitch. Pero vende en el largo plazo. Y en consultoría, el largo plazo es lo único que importa.