habiendo pasado mi carrera trabajando en una amplia gama de industrias, desde pequeñas empresas emergentes hasta corporaciones globales, desde empresas de tecnología que priorizan la IA hasta bancos fuertemente regulados. A lo largo de los años, he visto muchas iniciativas de IA y ML tener éxito, pero también he visto un número sorprendente de fracasos. Las razones del fracaso a menudo tienen poco que ver con los algoritmos. La causa fundamental es casi siempre la forma en que las organizaciones abordan la IA.
Esta no es una lista de verificación, un manual de instrucciones ni una lista de reglas estrictas y rápidas. Es una revisión de los errores más comunes con los que me he encontrado y algunas especulaciones sobre por qué ocurren y cómo creo que se pueden evitar.
1. Falta de una base de datos sólida
En ausencia de datos deficientes o escasos, lo que con demasiada frecuencia se debe a una baja madurez técnica, los proyectos de IA/ML están destinados al fracaso. Esto ocurre con demasiada frecuencia cuando las organizaciones forman equipos de DS/ML antes de haber establecido hábitos sólidos de ingeniería de datos.
Una vez un gerente me dijo: “Las hojas de cálculo no generan dinero”. Sin embargo, en la mayoría de las empresas ocurre exactamente lo contrario: las “hojas de cálculo” son la única herramienta que puede impulsar las ganancias. No hacerlo significa caer presa del clásico aforismo del ML: “basura entra, basura sale”.
Solía trabajar en una empresa regional de entrega de alimentos. Los sueños para el equipo de DS estaban por las nubes: sistemas de recomendación de aprendizaje profundo, Gen AI, etc. Pero los datos eran un desastre: demasiada arquitectura antigua, por lo que las sesiones y las reservas no podían vincularse de manera confiable porque no había una única identificación de clave; Las identificaciones de platos de los restaurantes rotaban cada dos semanas, por lo que era imposible asumir con seguridad qué pedían realmente los clientes. Este y muchos otros problemas significaron que cada proyecto tenía un 70% de soluciones alternativas. No hay tiempo ni recursos para soluciones elegantes. Pero para un puñado de ellos, ninguno de los proyectos había dado resultados en un año porque fueron concebidos sobre la base de datos en los que no se podía confiar.
Conclusión: invierta en ingeniería de datos y monitoreo de la calidad de los datos antes del aprendizaje automático. Mantenlo sencillo. Las victorias tempranas y los “frutos al alcance de la mano” no necesariamente requieren datos de alta calidad, pero la IA definitivamente sí lo hará.
2. No hay un caso comercial claro
El aprendizaje automático generalmente se realiza porque está de moda y no para resolver un problema real, especialmente teniendo en cuenta el revuelo de LLM y Agentic AI. Las empresas crean casos de uso en torno a la tecnología y no al revés, y terminan creando soluciones demasiado complicadas o redundantes.
Piense en un asistente de IA en una aplicación de pago de facturas de servicios públicos donde los clientes solo presionan tres botones, o en un traductor de paneles de control de IA cuando la solución debería ser hacer que los paneles sean comprensibles. Una búsqueda rápida en Google de ejemplos de asistentes de IA fallidos mostrará numerosos casos de este tipo.
Uno de esos casos en mi vida laboral fue un proyecto para crear un asistente en una aplicación de descubrimiento y reserva de restaurantes (un agregador de restaurantes, digamos). Los LLM estaban de moda y había FOMO desde arriba. Decidieron desarrollar un servicio seguro de baja prioridad con un asistente de chat orientado al usuario. El asistente proponía restaurantes según solicitudes como “muéstrame buenos lugares con descuentos”, “quiero una cena elegante con mi novia” o “busca lugares que admitan mascotas”.
El equipo dedicó un año a desarrollarlo: se diseñaron cientos de escenarios, se ajustaron las barreras de seguridad y se hizo el backend a prueba de balas. Pero la esencia del asunto era que este asistente no resolvió ningún problema real del usuario. Un porcentaje muy pequeño de usuarios incluso intentó utilizarlo y entre ellos sólo un número estadísticamente insignificante de sesiones dieron lugar a reservas. El proyecto se abandonó anticipadamente y no se amplió a otros servicios. Si el equipo hubiera comenzado con la confirmación del caso de uso en lugar de las funciones del asistente, tal destino no se habría podido alcanzar.
Conclusión: comience siempre con el problema. Comprenda profundamente el problema, asigne su valor en números y solo entonces comience el viaje de desarrollo.
3. Persiguiendo la complejidad antes de entender lo básico
La mayoría de las comunidades saltan a la última versión sin detenerse a ver si los métodos más simples serían suficientes. Una talla única no sirve para todos. Un enfoque incremental, que comienza de manera simple e incrementa según sea necesario, casi siempre genera un mayor retorno de la inversión. ¿Por qué hacerlo más complejo de lo necesario cuando la regresión lineal, los modelos previamente entrenados o la simple heurística serán suficientes? Comenzar de manera simple proporciona ideas: aprende sobre el problema, descubre por qué no tuvo éxito y tiene una base sólida para repetirlo más adelante.
Implementé un proyecto para diseñar un widget de acceso directo en la página de inicio de una aplicación multiservicio que incluye viajes compartidos. La idea era simple: predecir si un usuario había iniciado la aplicación para solicitar un viaje y, de ser así, predecir a dónde iría probablemente para que el usuario pudiera reservarlo con un solo toque. La dirección decretó que la solución debía ser una red neuronal y no podía ser nada más. Cuatro meses de dolorosa evolución después, descubrimos que las predicciones funcionaron sorprendentemente bien para quizás el 10% de los pasajeros con un profundo historial de viajes compartidos. Incluso para ellos, las predicciones fueron terribles. Y el problema finalmente se solucionó en una noche mediante un conjunto de reglas comerciales. Se podrían haber evitado meses de esfuerzos desperdiciados si la empresa hubiera comenzado de manera conservadora.
Conclusión: camina antes de correr. Utilice la complejidad como último recurso, no como punto de partida.
4. Desconexión entre los equipos de ML y la empresa
En la mayoría de las organizaciones, la ciencia de datos es una isla. Los equipos crean soluciones técnicamente sorprendentes que nunca llegan a ver la luz porque no resuelven los problemas correctos o porque las partes interesadas del negocio no confían en ellos. Lo contrario no es mejor: cuando los líderes empresariales intentan dictar el desarrollo técnico en su totalidad, establecen expectativas inalcanzables e impulsan soluciones fallidas que nadie puede defender. El equilibrio es la respuesta. El aprendizaje automático prospera mejor cuando es un ejercicio de colaboración entre expertos en el dominio, ingenieros y tomadores de decisiones.
He visto esto con mayor frecuencia en grandes empresas no nativas de TI. Se dan cuenta de que la IA/ML tiene un enorme potencial y crean “laboratorios de IA” o centros de excelencia. El problema es que estos laboratorios a menudo trabajan completamente aislados de la empresa y sus soluciones rara vez se adoptan. Trabajé para un banco grande que tenía un laboratorio de este tipo. Allí había expertos muy experimentados, pero nunca se reunieron con las partes interesadas del negocio. Peor aún, el laboratorio se creó como una filial independiente y el intercambio de datos era imposible. La empresa no estaba tan interesada en el trabajo del laboratorio, que acabó destinándose a trabajos de investigación para académicos, pero no a los procesos reales de la empresa.
Conclusión: mantenga las iniciativas de aprendizaje automático estrechamente alineadas con las necesidades comerciales. Colabore temprano, comuníquese con frecuencia e interactúe con las partes interesadas, incluso si eso ralentiza el desarrollo.
5. Ignorar MLOps
Los trabajos cron y los scripts torpes funcionarán a pequeña escala. Dicho esto, a medida que la empresa crece, esta es una receta para el desastre. Sin MLOps, los pequeños ajustes requieren la participación de los desarrolladores originales en cada paso del camino, y los sistemas se reescriben por completo una y otra vez.
La inversión temprana en MLOps rinde exponencialmente. No se trata únicamente de tecnología, sino de tener una cultura de ML estable, escalable y sostenible.
Invertir temprano en MLOps rinde frutos exponencialmente. No se trata sólo de tecnología; se trata de crear una cultura de aprendizaje automático confiable, escalable y mantenible. No dejes que el caos te sobrevenga. Establezca buenos procesos, plataformas y capacitación antes de que los proyectos de aprendizaje automático se vuelvan locos.
Trabajé en una filial de telecomunicaciones que se dedicaba a AdTech. La plataforma ofrecía publicidad en Internet y era la que generaba mayores ingresos para la empresa. Como era nueva (solo tenía un año), la solución de aprendizaje automático era desesperadamente frágil. Los modelos simplemente se empaquetaron en C++ y un solo ingeniero los introdujo en el código del producto. Las integraciones solo se realizaban si ese ingeniero estaba presente, nunca se realizaba un seguimiento de los modelos y, una vez que el autor original se marchaba, nadie tenía idea de cómo estaban funcionando. Si el ingeniero de turno también se hubiera ido, toda la plataforma habría quedado fuera de servicio permanentemente. Esta exposición podría haberse evitado con buenos MLOps.
6. Falta de pruebas A/B
Algunas empresas evitan las pruebas A/B debido a su complejidad y optan por pruebas retrospectivas o por intuición. Eso permite que los malos modelos lleguen a producción. Sin una plataforma de prueba, no se puede saber qué modelos funcionan realmente. Se requieren marcos de experimentación adecuados para la mejora iterativa, especialmente a escala.
Lo que tiende a frenar la adopción es la sensación de complejidad. Pero un proceso de prueba A/B sencillo y optimizado puede funcionar bien en los primeros días y no requiere una gran inversión inicial. La alineación y el entrenamiento son realmente las claves más importantes.
En mi caso, sin una forma sólida de medir el impacto en el usuario, depende de qué tan bien un gerente pueda venderlo. Los buenos lanzamientos se financian, se defienden fervientemente y, a veces, perduran incluso cuando el número se reduce. Las métricas se manipulan simplemente comparando las cifras anteriores y posteriores al lanzamiento. Si aumentaron, entonces el proyecto es un éxito, aunque resultó ser una tendencia general al alza. En las empresas en crecimiento, hay millones de proyectos deficientes ocultos detrás del crecimiento general porque no existen pruebas A/B para separar continuamente los éxitos de los fracasos.
Conclusión: cree capacidad de experimentación desde el principio. Pruebe las grandes implementaciones necesarias y permita que los equipos interpreten los resultados correctamente.
7. Gestión poco capacitada
Una gestión de ML poco capacitada puede interpretar mal las métricas, los resultados de los experimentos y cometer errores estratégicos. Es igualmente crucial educar a los tomadores de decisiones como lo es educar a los equipos de ingeniería.
Una vez trabajé con un equipo que tenía toda la tecnología que necesitaban, además de MLOps sólidos y pruebas A/B, pero los gerentes no sabían cómo usarlos. Utilizaron pruebas estadísticas incorrectas, cancelaron experimentos después de un día en que se había alcanzado la “significancia estadística” (generalmente con muy pocas observaciones) y lanzaron funciones sin ningún impacto mensurable. El resultado: muchos lanzamientos tuvieron un impacto negativo. Los propios directivos no eran malas personas, simplemente no sabían cómo utilizar sus herramientas.
8. Métricas desalineadas
Si bien las organizaciones de ML/DS deben estar alineadas con el negocio, eso no implica que deban tener instintos comerciales. Los practicantes de ML también se alinearán con las métricas que se les proporcionen si consideran que son correctas. Si los objetivos de ML no están alineados con metas firmes, el resultado será perverso. Por ejemplo, si lo que la empresa quiere es rentabilidad, pero maximizar la conversión de nuevos usuarios es un objetivo de la organización de ML, maximizarán el crecimiento no rentable agregando usuarios con malas economías unitarias que nunca regresan.
Este es un punto débil para muchas empresas. Una empresa de reparto de comida deseaba crecer. La gerencia observó que la baja conversión de nuevos usuarios era el problema que impedía que la empresa aumentara sus ingresos. Se pidió al equipo de DS que lo resolviera con personalización y mejora de la experiencia del cliente. El verdadero problema fue la retención, los usuarios convertidos no regresaron. En lugar de retener, el equipo se centró en la conversión, llenando eficazmente con agua un balde que goteaba. Aunque la tasa de conversión aumentó, no se tradujo en un crecimiento sostenible. Estos errores no son específicos del tamaño de una empresa o industria; son errores universales.
Aún así se pueden prevenir. La IA y el ML funcionan cuando se elaboran según principios sólidos, se diseñan para resolver problemas reales y se implementan cuidadosamente en los negocios. Cuando todas las condiciones son adecuadas, la IA y el aprendizaje automático se convierten en tecnologías disruptivas con el potencial de trastornar negocios enteros.
Conclusión: haga que las métricas de aprendizaje automático se alineen con los verdaderos objetivos comerciales. Lucha contra las causas, no contra los síntomas. Valore el desempeño a largo plazo, no las métricas a corto plazo.
Conclusión
El camino hacia el éxito de la IA/ML tiene menos que ver con algoritmos de vanguardia y más con la madurez organizacional. Los patrones son evidentes: los fracasos surgen de precipitarse hacia la complejidad, desalinear incentivos e ignorar la infraestructura fundamental. El éxito exige paciencia, disciplina y apertura para empezar poco a poco.
La noticia positiva es que todos estos errores son completamente evitables. Las empresas que implementen primero la infraestructura de datos, mantengan una estrecha coordinación entre los equipos técnicos y comerciales y no se distraigan con las modas pasajeras descubrirán que AI/ML hace precisamente lo que promete. La tecnología funciona, pero tiene que estar sobre bases firmes.
Si hay un principio que une todo esto, es este: AI/ML es una herramienta, no un destino. Comience con el problema, confirme la necesidad, desarrolle de forma iterativa y mida siempre. Las empresas que lo abordan con esta mentalidad no sólo no fracasan. En cambio, crean diferenciadores competitivos a largo plazo que se agravan con el tiempo.
El futuro no pertenece a las empresas con los modelos más nuevos, sino a las que tienen la disciplina de aplicarlos con sensatez.