En esta nota
En resumen
- El número de partida se toma antes de empezar. Después no se recupera.
- La métrica que no se puede inflar es la tasa de corrección, y sobre todo si baja con el tiempo.
- Un sistema perfecto que nadie usa vale cero. La adopción se mide aparte.
- El tiempo de revisar las salidas es un costo. Restalo del ahorro.
Pasan seis meses del proyecto y alguien pregunta si sirvió. Se arma una reunión, cada uno da su impresión, y la conclusión termina dependiendo de quién habla más fuerte. Eso pasa porque nadie tomó números al principio, no porque el proyecto fuera bueno o malo.
Medir bien un proyecto de inteligencia artificial no requiere tableros ni consultores. Requiere tres números y la disciplina de anotarlos antes de empezar.
El número de partida, que se toma antes
Esta es la parte que no se puede recuperar después. Una vez que el sistema está andando, ya nadie se acuerda con precisión de cuánto llevaba la tarea antes.
Durante una semana, antes de tocar nada, que quien hace la tarea anote tres cosas:
| Qué anotar | Cómo |
|---|---|
| Cuántas veces ocurre | Una marca por vez. Sin categorías ni detalles. |
| Cuánto tiempo lleva | Redondeado a cinco minutos. La precisión no importa. |
| Cuántas veces sale mal | Marca aparte cuando hubo que rehacer o corregir. |
Una semana de registro manual vale más que cualquier estimación. La memoria sobreestima lo que molesta y subestima lo que es rutina, y las dos distorsiones juegan en contra al momento de evaluar.
Si ya empezaste sin tomar el número de partida, todavía se puede: elegí un proceso parecido que siga haciéndose a mano y medilo. Sirve como referencia comparable.
La métrica que dice la verdad
El tiempo ahorrado tiene un problema: es fácil de mostrar y difícil de verificar. La métrica que no se puede inflar es la tasa de corrección.
Cuántas veces, sobre el total, alguien tuvo que arreglar lo que produjo el sistema. Es un número entre cero y cien y se cuenta sin instrumentos.
Por qué importa más que el ahorro: si un sistema genera veinte borradores por día y hay que reescribir dieciocho, no ahorró nada. Movió el trabajo de lugar y agregó el paso de revisar. En la planilla ese proyecto figura como exitoso y en la vida real del equipo figura como una molestia, y esa contradicción explica la mayoría de los proyectos que se apagan solos.
Hay algo más importante todavía: la dirección de la curva. Un sistema sano corrige menos con el tiempo, porque se va ajustando. Si después de tres meses se corrige lo mismo que el primer día, el problema no era de ajuste fino y agregar semanas no lo va a resolver.
Un sistema que produce veinte salidas por día y necesita dieciocho correcciones figura como exitoso en el reporte de ahorro y como una molestia en la vida real del equipo. Esa contradicción es la que hay que detectar.
El número que nadie mira: si lo usan
Un sistema que anda perfecto y nadie usa vale cero. Y es más común de lo que parece, porque sigue encendido y nadie declara que dejó de usarse.
Se mide contando cuántas veces por semana se usa de verdad, comparado contra cuántas veces ocurre la tarea. Si la tarea pasa cuarenta veces por semana y el sistema se usó ocho, hay un problema de adopción y ningún ajuste técnico lo va a resolver.
Las causas de baja adopción casi siempre son las mismas tres:
- Vive donde el trabajo no ocurre. Hay que abrir otra pestaña, entrar con otra clave, acordarse de que existe. Compite contra la costumbre y la costumbre gana.
- Falla en los casos que importan. Anda bien con lo fácil y se cae justo en los casos raros, que son los que más tiempo consumen.
- Nadie explicó para qué sirve. Se anunció en una reunión y se dio por sentado el resto.
El cálculo completo, con los costos verdaderos
Para poner el retorno en pesos hacen falta los dos lados, y el lado del costo casi siempre se subestima.
| Costos | Beneficios |
|---|---|
| Herramientas por mes | Horas liberadas por mes |
| Horas de armado (una vez) | Errores evitados |
| Horas de mantenimiento por mes | Respuestas más rápidas al cliente |
| Horas de revisión de las salidas | Trabajo que antes no se hacía por falta de tiempo |
La fila que más se olvida es la última del lado izquierdo: el tiempo de revisar. Si el sistema produce veinte cosas por día y alguien las revisa todas, ese tiempo es parte del costo y hay que restarlo del ahorro.
Y la última del lado derecho merece atención: a veces el mayor beneficio no es ahorrar tiempo sino hacer cosas que antes no se hacían. Seguimientos que nadie alcanzaba, análisis que quedaban pendientes. Eso no aparece como ahorro pero cambia el negocio más que las horas.
Cuándo evaluar
Entre seis y ocho semanas de uso real, no de pruebas. Antes de eso los números están contaminados por el aprendizaje del equipo, que al principio tarda más y corrige de más.
Y un límite del otro lado: pasados tres meses sin mejora en la tasa de corrección ni en la adopción, esperar más rara vez cambia el resultado.
Cuándo apagarlo
Apagar un proyecto a tiempo es una decisión sana y casi nadie la toma, porque admitir que no funcionó cuesta más que dejar la suscripción corriendo.
- La tasa de corrección no baja después de dos o tres meses de ajustes.
- El equipo dejó de usarlo aunque siga encendido.
- Mantenerlo consume más horas de las que libera.
Apagarlo libera dos cosas: el gasto y, más importante, la credibilidad para el próximo intento. Un proyecto que nadie usa pero nadie apaga hace más daño al siguiente que un fracaso reconocido.
Antes de apagar, una pregunta: ¿el problema era el sistema o el proceso que se eligió? Muchas veces la herramienta funcionaba y el proceso elegido nunca fue buen candidato. Esa distinción decide si el próximo intento repite el error.
El resumen
- Tomá el número de partida una semana antes de empezar.
- Medí la tasa de corrección, y mirá si baja.
- Medí si lo usan. Un sistema perfecto sin uso vale cero.
- Contá el tiempo de revisión como costo.
- Evaluá a las seis u ocho semanas de uso real.
- Apagá lo que no funciona, distinguiendo si falló la herramienta o la elección.
En el LAB los números se toman desde la semana uno
Doce semanas en vivo donde cada participante elige sus procesos, toma la línea de base y sale con tres sistemas funcionando y medidos. Con mentores que revisan si el proceso elegido era buen candidato antes de invertir el trabajo.
Conocer el LAB AI ›Preguntas frecuentes
¿Cuál es la métrica más importante en un proyecto de IA?
La tasa de corrección: cuántas veces alguien tiene que arreglar la salida del sistema, y si ese número baja con el tiempo. Si un sistema genera veinte borradores por día y hay que reescribir dieciocho, no ahorró tiempo: lo movió de lugar y encima agregó el paso de revisar.
¿Cómo mido si nunca medí el proceso anterior?
Tomando el número de partida antes de tocar nada: durante una semana, que quien hace la tarea anote cuánto le lleva y cuántos errores aparecen. Una semana de registro manual vale más que cualquier estimación, porque la memoria sobreestima lo que molesta y subestima la rutina.
¿Cuánto hay que esperar antes de evaluar un proyecto?
Entre seis y ocho semanas de uso real, no de pruebas. Antes de eso las cifras están contaminadas por el aprendizaje del equipo. Después de tres meses, si nada mejoró, esperar más rara vez ayuda.
¿Cuándo conviene apagar un proyecto de IA?
Cuando la tasa de corrección no baja después de dos o tres meses, cuando el equipo dejó de usarlo aunque siga andando, o cuando mantenerlo consume más horas de las que libera. Apagarlo a tiempo libera presupuesto y credibilidad para el siguiente intento.
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.