Una empresa me escribió en marzo con un problema muy concreto: se les iba Martín. Martín no era el gerente de sistemas ni el director de innovación. Era un analista de veintiocho años que había aprendido a usar bien las herramientas de IA y que, sin que nadie se lo pidiera formalmente, había terminado resolviendo con ellas media docena de tareas de tres áreas distintas.
Cuando renunció, nadie sabía qué hacía exactamente ni cómo. Los informes que él armaba en veinte minutos volvieron a llevar medio día. Y lo peor: nadie podía explicar por qué antes salían bien.
La diferencia entre una excepción y un sistema
Todo lo que Martín había construido era una excepción: funcionaba porque él estaba. Un sistema es lo contrario — funciona porque está escrito, tiene dueño y se puede transferir. La distinción parece obvia enunciada así, pero en la práctica cuesta verla, porque una excepción que funciona muy bien se parece bastante a un sistema.
| Dimensión | Excepción | Sistema |
|---|---|---|
| Quién sabe cómo se hace | Una persona | Al menos dos, y está escrito |
| Dónde vive el conocimiento | En su cabeza y en su historial de chats | En un repositorio que el resto puede abrir hoy |
| Si esa persona falta tres semanas | La tarea vuelve al método anterior o no se hace | Otro la toma con una hora de lectura |
| Cómo mejora | Cuando a esa persona se le ocurre algo | Cualquiera propone un cambio y se revisa en la reunión |
| Cómo se detecta un error | Cuando explota | Hay un control definido y alguien que lo mira |
Si tu adopción de IA depende de una persona, no tenés una capacidad instalada. Tenés un talento contratado, y los talentos se van.
Qué documentación importa de verdad
Acá hay una trampa. Cuando una empresa se asusta con esto, la reacción típica es pedir «documentación», y lo que llega son cuarenta páginas explicando cómo se usa una herramienta que además cambia cada tres meses. Eso no sirve y nadie lo lee.
Lo que hay que documentar es mucho más corto y mucho más específico de tu empresa:
- La instrucción que funciona, y por qué. El texto exacto que se usa, pegado tal cual, con dos renglones explicando qué se probó antes y por qué esta versión quedó. El «por qué» es lo que permite adaptarla cuando algo cambie.
- Qué información entra y cuál no. Qué archivos, de qué sistema, en qué formato. Y explícitamente qué no se carga nunca.
- Qué se revisa antes de que salga. El control humano concreto: qué mira una persona antes de mandar el resultado a un cliente, a un proveedor o al sistema contable.
- Qué se probó y se descartó. Es la parte que más se olvida y la que más tiempo ahorra. Sin esto, el reemplazo de Martín va a pasar tres semanas redescubriendo los mismos callejones sin salida.
- Dónde está el error típico. En qué casos falla, cómo se nota y qué hacer cuando pasa.
Son cinco puntos y entran en una página por proceso. La regla que uso: si documentar un proceso lleva más de treinta minutos, probablemente el proceso todavía no está lo suficientemente entendido como para documentarlo.
Roles, no héroes
El otro pilar es que las responsabilidades estén repartidas por rol y no concentradas en quien más entusiasmo tiene. Con tres roles alcanza para una PyME:
| Rol | Qué decide | Cuánto tiempo pide |
|---|---|---|
| Referente de adopción | Sostiene el método: convoca la reunión, mantiene el tablero y el repositorio, persigue lo trabado. No decide qué se prueba: garantiza que se decida | 3 o 4 horas por semana |
| Dueño de proceso | Es de cada área. Decide si el cambio se adopta en su proceso, porque después va a convivir con él todos los días | 2 horas por semana mientras hay una prueba activa en su área |
| Dirección | Prioriza entre áreas, habilita recursos y ratifica los cierres. Aparece cada quince días | 1 hora cada dos semanas |
Lo importante de esta tabla no son los roles sino la última columna. Un rol sin horas asignadas es un título honorífico: la persona lo va a atender con lo que le sobre, y en una PyME nunca sobra nada.
La prueba de las tres semanas
Hay una manera muy simple de saber si tenés un sistema o una excepción, y no requiere que se te vaya nadie: mandá de vacaciones a la persona que más sabe y no la llames.
Si a las tres semanas los procesos siguen funcionando —quizás un poco más lento, con alguna consulta—, tenés un sistema. Si a los tres días alguien la está llamando por WhatsApp para preguntarle cómo se hacía algo, tenés una excepción muy bien disfrazada. Y es mejor descubrirlo mientras esa persona todavía trabaja con vos.
El principio 10-20-70 de BCG dice que el 70 % del valor de la IA sale de personas, procesos y cultura. Lo que casi nunca se aclara es que ese 70 % es también la parte más frágil: los algoritmos no renuncian, la gente sí. Por eso la meta no puede ser que alguien de la casa sepa mucho de IA. Tiene que ser que la empresa sepa — que es una cosa distinta y bastante más difícil de construir.
