En esta nota
En resumen
- Las cinco causas comparten una raíz: se empezó por la tecnología y no por el trabajo.
- El piloto diseñado para impresionar nace sin destino. El que sobrevive es aburrido de mostrar.
- Si nadie puede decir si la salida está bien, no hay proyecto: hay una apuesta.
- Importa menos quién construye que quién mantiene. Los procesos cambian siempre.
- Medí la corrección, no el ahorro. Un sistema que hay que corregir siempre no ahorró nada.
Hay un patrón que se repite: la demo sale bien, la dirección se entusiasma, se arma un piloto, el piloto "funciona"… y seis meses después nadie sabe decir qué pasó con aquello. No hubo un momento de fracaso. Simplemente se fue apagando.
Cuando uno mira de cerca varios de estos casos, las causas son sorprendentemente parecidas, y ninguna es técnica.
1. El piloto se diseñó para impresionar, no para servir
Un piloto pensado para demostrar que la tecnología funciona es un piloto que ya nació sin destino. Se elige el caso más vistoso, se lo prepara con datos limpios, se lo muestra en una reunión y todos aplauden. Después alguien pregunta quién lo va a usar todos los días y no hay respuesta.
El piloto que sobrevive se diseña al revés: se elige la tarea más aburrida y más frecuente, y el éxito no se mide por el asombro que genera sino por si alguien la extraña cuando se cae.
Buena señal de que un piloto va en serio: es aburrido de mostrar y alguien se queja cuando deja de funcionar.
Hay una asimetría incómoda acá. El piloto vistoso consigue presupuesto más fácil; el aburrido consigue resultados. En empresas con varios niveles de decisión, esa tensión explica una buena parte de los proyectos que mueren.
2. Nadie puede decir si la salida está bien
Este es el más silencioso de todos. El sistema produce resultados, nadie los revisa con criterio, y durante meses parece funcionar. Hasta que un error llega a un cliente.
Antes de automatizar cualquier cosa conviene contestar: ¿quién mira esta salida y con qué criterio dice que está bien? Si la respuesta es "nadie, confiamos", no hay proyecto: hay una apuesta.
Y el criterio tiene que ser explícito. "Que esté bien redactado" no sirve, porque cada persona entiende algo distinto. "Que incluya el plazo de entrega, el precio con IVA y el nombre correcto del contacto" sí: eso se verifica en diez segundos y dos personas distintas llegan al mismo veredicto.
3. El sistema vive donde el trabajo no ocurre
Si para usar la herramienta hay que abrir otra pestaña, entrar con otra clave y acordarse de que existe, compite contra la costumbre. La costumbre gana.
Los sistemas que se adoptan son los que aparecen donde la persona ya está trabajando: el mismo WhatsApp donde llegan los pedidos, la misma planilla que ya abre todos los días, el mismo correo. No es un detalle de comodidad: es la diferencia entre que se use y que no.
Esto tiene una consecuencia práctica en el diseño. A veces conviene una solución técnicamente peor que viva en el lugar correcto, antes que una excelente que viva en una pestaña nueva.
4. Nadie quedó a cargo de mantenerlo
Los procesos cambian. Cambia un proveedor, cambia una regla, cambia el formato de un documento. Un sistema que nadie mantiene no falla de golpe: se va degradando hasta que alguien decide que era más fácil hacerlo a mano.
Por eso importa menos quién construye que quién mantiene. Un sistema hecho por un tercero que después nadie adentro sabe tocar tiene fecha de vencimiento desde el día uno. Y esa fecha suele ser el primer cambio importante del proceso.
| Pregunta que casi nadie hace | Por qué importa |
|---|---|
| ¿Quién lo toca cuando cambie el proceso? | Si la respuesta es "el proveedor", cada cambio cuesta plata y tiempo de espera. |
| ¿Alguien adentro entiende cómo funciona? | Sin eso, el sistema es una caja negra que nadie se anima a modificar. |
| ¿Qué pasa si la persona que lo armó se va? | Es el caso más común de muerte silenciosa. |
| ¿Cómo nos enteramos si deja de andar? | Las automatizaciones fallan calladas: dejan de ejecutarse y todo parece normal. |
La última fila merece atención especial. Un sistema roto que nadie nota puede estar sin funcionar durante semanas, y cuando alguien se da cuenta ya se perdió la confianza.
5. Se mide el ahorro y no la corrección
La métrica que todos usan es cuánto tiempo se ahorró. Es la equivocada, o al menos está incompleta.
Lo que hay que medir es cuántas veces alguien tuvo que corregir la salida. Si un sistema genera veinte borradores por día pero hay que reescribir dieciocho, no ahorró tiempo: lo movió, y encima agregó el paso de revisar. Ese proyecto figura como exitoso en la planilla y como una molestia en la vida real del equipo.
Un sistema que funciona baja la cantidad de correcciones con el tiempo. Si después de tres meses se corrige lo mismo que el primer día, el problema no era de ajuste fino.
Esa contradicción (bien en la planilla, mal en la práctica) explica buena parte de los proyectos que se apagan sin que nadie los apague. Nadie declara que dejó de usarlo: simplemente vuelve a hacerlo a mano.
El patrón detrás de las cinco
Las cinco causas comparten una raíz: se empezó por la tecnología y no por el trabajo. Cuando el punto de partida es la herramienta, todo lo demás (quién la usa, quién la evalúa, quién la mantiene) aparece después, si aparece.
Cuando el punto de partida es un proceso concreto que le duele a alguien, esas preguntas se contestan solas, porque la persona a la que le duele está ahí para responderlas.
La IA no reemplaza al que construye: lo potencia. Pero potencia lo que hay. Si el sistema atrás está mal pensado, lo que se acelera es el desorden.
Seba Chuffer · LAB AI
Cómo detectarlo mientras todavía se puede corregir
Cinco preguntas, respondidas de frente, dicen bastante sobre el estado real de un proyecto:
- ¿Quién usa esto todos los días? Si no hay un nombre, no hay proyecto.
- ¿Con qué criterio se juzga la salida? Si no está escrito, no existe.
- ¿Dónde vive? Si es una pestaña aparte, la adopción va a costar el triple.
- ¿Quién lo arregla si se rompe el martes? Si es "el proveedor", presupuestá las esperas.
- ¿Cuántas correcciones hubo esta semana comparado con el primer mes? Si no bajó, hay algo estructural.
Si tres de las cinco no tienen respuesta, el proyecto no está fallando por la tecnología.
En el LAB se empieza por el proceso
Doce semanas en vivo donde cada participante trabaja sobre los procesos reales de su negocio: los elige, los describe y sale con tres funcionando. Con mentores que revisan y corrigen el rumbo antes de que el proyecto se apague solo.
Conocer el LAB AI ›Preguntas frecuentes
¿Por qué la mayoría de los pilotos de IA no llega a producción?
Porque el piloto se diseña para demostrar que la tecnología funciona, no para resolver un problema del negocio. Un piloto exitoso en esos términos puede terminar sin dueño, sin presupuesto de mantenimiento y sin nadie que lo use todos los días.
¿Conviene empezar con un proveedor externo o con equipo propio?
Lo que define el resultado no es quién construye sino quién mantiene. Un sistema construido por un tercero que después nadie adentro sabe tocar se degrada apenas cambia el proceso, y los procesos cambian siempre.
¿Cómo sé si un proyecto de IA está funcionando?
Midiendo cuántas veces alguien tiene que corregir la salida del sistema, y si ese número baja con el tiempo. Si la corrección es constante, el trabajo no se eliminó: se mudó de lugar y encima se agregó el paso de revisar.
¿Se puede recuperar un proyecto que ya se apagó?
A veces, y conviene empezar por distinguir si falló la herramienta o la elección del proceso. Muchas veces el sistema funcionaba bien y el proceso elegido nunca fue buen candidato. Sin esa distinción, el siguiente intento repite el error.
Escrito a partir de lo que vemos en las sesiones del LAB AI, el programa en vivo donde cada participante implementa IA en los procesos reales de su negocio.