Por qué la mayoría de los proyectos de IA no llegan a nada
Si estás acá leyendo esto es porque seguramente hay un modelo de machine learning, una prueba de concepto con IA o un dashboard en algún lugar de tu empresa que absolutamente nadie usa. Y muy probablemente hayas visto esos informes, posteos y artículos que hablan de como la IA es el invento más revolucionario desde la imprenta, pero también los informes, posteos y artículos que hablan sobre el casi inexistente ROI que suelen generar. ¿Cómo pueden convivir ambas cosas?
En los últimos años hablamos con más de cien empresas sobre proyectos de datos e IA, y hay un patrón que se repite una y otra vez: no es que los proyectos fallen técnicamente (de hecho ese es el punto de una prueba de concepto, demostrar que algo tiene potencial), sino que quedan ahí, como una promesa de algo que no fue. El experimento funcionó, la prueba tuvo éxito; pero cuando llega el momento de sacarle el jugo a todo ese esfuerzo las cosas se ponen más complicadas, o bien porque directamente no llegan a producción o porque nadie los adopta.
¿Querés evitar que esto le pase a tu empresa? Te compartimos cuatro errores muy comunes al momento de encarar un proyecto de esta magnitud, que los vimos muchas más veces de lo que imaginás.
Buscar una pregunta a una respuesta
También conocido como “vos mandale IA y después vemos”, es el error clásico de quienes se enamoran de la solución y no del problema. De la tecnología, y no de lo que esta habilita a hacer. Contra todo tipo de criterio, más de una vez nos hemos encontrado con equipos que primero construyen una solución y después ven para qué usarla.
El escenario típico arranca cuando alguien del equipo de datos identifica una oportunidad, arma una demo, la muestra en una reunión y hay entusiasmo. Se ordenan las voluntades, se alinean los astros y el proyecto arranca, pero recién un par de semanas o meses después, alguien mira el monitor y pregunta: ¿qué decisión de negocio cambia con esto? ¿Cómo me hace crecer esto?
Sabemos que la IA es maravillosa (¡por algo trabajamos de esto!), pero si no sabés contestar las preguntas de la frase anterior, cualquier proyecto en la que la emplees termina en la nada, o incluso peor, siendo directamente una pesadilla. Un proyecto de data + IA mal encarado tiene el potencial de alterar flujos operativos y de trabajo que no debían ser intervenidos de esa manera y generando una sensación muy amarga en quienes se la jugaron por incorporar un cambio tecnológico en sus organizaciones.
Dejar desamparado al desarrollo
La segunda razón es mucho menos obvia a simple vista, y se da en organizaciones que no tienen un ownership técnico tan sólido sobre la solución que les fue entregada. Más de una vez nos hemos topado con equipos que tienen una caja negra en la mano sobre la cual se monta todo el negocio. ¿Y por qué caja negra? Una de dos: o porque nadie sabe qué hay adentro y por qué hace lo que hace, o porque nadie sabe cómo operarla. La tecnología en estos casos se convierte en una suerte de “mirame pero no me toques”, donde cualquier cambio posible (o necesario) es imposible.
Aunque esto es cierto en el desarrollo de software en general, esto es aún más crítico en lo que hace a data + IA, dado que, dicho de una forma un tanto poética, el desarrollo “está vivo”. Desde la materia prima (los datos) hasta la tecnología con la que se la explota, estamos en un rubro que cambia ya no mes a mes, sino semana a semana.
¿Qué pasa cuando necesitás un reentrenamiento de un modelo, cuando los datos cambian de formato o cuando algo falla de maneras inesperadas y/o ininteligibles, y no tenés nadie interno que pueda resolverlo? El problema ahí está en que la solución nunca fue tal, sino una cadena que mantiene tu empresa atada a un proveedor externo.
La pregunta que le tenés que hacer a cualquier consultora antes de contratar no es “¿pueden construirlo?”. Es “¿con qué capacidad nos quedamos nosotros cuando terminen?”.
No definir cuándo el desarrollo fue exitoso
Una razón un tanto sorprendente pero muy frecuente: muchas veces hemos visto proyectos que empezaron pero nadie definió qué quiere decir que el proyecto funcione. Sin necesariamente ponernos filosóficos, ¿qué quiere decir el éxito? ¿Es cuando mejorás en un 10%, en un 15$, en un 20%? ¿Cuál es la métrica de negocio que se está viendo impactada como consecuencia de la métrica técnica del desarrollo? ¿Quién decide que el resultado es lo suficientemente bueno para salir del laboratorio y entrar a la cancha?
Cuando esta conversación no pasa al inicio, pasa en el peor momento posible: en el final, cuando ya hay inversión comprometida, expectativas creadas y ningún espacio para decir “esto no está listo todavía”. Así, estos proyectos quedan en un limbo donde si bien técnicamente anda, el peso de las cosas no dichas hace que nadie lo use para tomar decisiones reales.
Se contrató ejecución cuando el problema era diagnóstico
La cuarta razón es la más difícil de ver desde adentro y es la que más duele: la ayuda que contrataste no es la que necesitabas. O aún peor: te convencieron de construir una torre de 10 pisos sobre arenas movedizas.
Hay momentos en los que una organización necesita entender el problema antes de construir la solución, y eso tiene un nombre: honestidad. El rol de alguien externo a una organización es el de decir las cosas como son, usando criterio profesional. En este rubro, involucra ver qué datos existen, en qué estado están, qué casos de uso son viables en el contexto de la organización y cuáles directamente no lo son. Y el problema es que en más de una ocasión hay empresas que quieren hacer cosas para las que sencillamente aún no están en condiciones, y requiere mucha entereza saber decir que no.
Esto pasa cuando las empresas no terminan de valorar la importancia de un diagnóstico, de un lado y del otro del mostrador. El resultado suele ser el mismo: proyectos que parecen avanzar, pero en realidad son técnicamente muy sólidos pero totalmente equivocados para la resolución del problema.
Vale la pena también mencionar que lo contrario también pasa (aunque en nuestra experiencia, no es tan frecuente). En este caso, hay empresas atrapadas en procesos de consultoría estratégica con diagnósticos cada vez más elaborados pero sin jamás arrancar la construcción, en una búsqueda eterna de lograr la solución más absoluta e inmutablemente perfecta. Pero eso no existe: en algún momento hay que empezar a construir para terminar de entender.
El diagnóstico y la ejecución son momentos distintos, y confundirlos tiene costos.
Qué tienen en común los proyectos que sí funcionan
Los proyectos que funcionan son los que hacen las preguntas incómodas antes de arrancar. Los “para qué” de las cosas.
¿Qué decisión de negocio va a cambiar con este modelo? ¿Quién en la organización va a cambiar su comportamiento en función de los resultados y cómo se va a acompañar a esa persona en dicho cambio? ¿Cómo vamos a medir el éxito en términos de negocio? ¿Con qué capacidad queda el equipo interno cuando el proyecto termina?
Si estás evaluando un proyecto de datos o IA, o eligiendo con quién hacerlo, estas son las preguntas que tendrías que poder responder (y que quien te proponga el proyecto también tendría que poder responder) antes de firmar cualquier cosa.
Por todo esto, hay una frase que nosotros tenemos como mantra: buscamos que quienes confían en nosotros y nos eligen para acompañarlos quieran hacerlo, no que se vean obligados a hacerlo.
Si querés entender primero dónde estás parado antes de construir cualquier cosa, así es como arrancamos nosotros.
