Escenario ilustrativo. Una gestoría quiere que un agente concilie los cobros de sus clientes. Pregunta a Marta, que lleva doce años haciéndolo, cómo lo hace. «Es fácil —dice—, cuadras el extracto con las facturas.» Se construye el agente con esa descripción y, en las primeras semanas, falla justo donde Marta no se paraba a pensar: el cliente que paga tres facturas en una sola transferencia, el importe que siempre llega con un descuento acordado de palabra, el cierre de trimestre en el que no se toca nada hasta que llega un correo. Nada de eso estaba escrito. Marta tampoco sabía que lo sabía.
La tesis en una línea: antes de automatizar un proceso hay que sacar de la cabeza de quien lo hace lo que nunca se escribió, y a menudo ese paso ya aporta más que la automatización misma.
¿Por qué hay que documentar procesos antes de automatizar con IA?
Porque un agente ejecuta lo que le cuentas, no lo que la empresa hace de verdad. La diferencia entre las dos cosas es el conocimiento tácito: criterios, excepciones y atajos que quien hace el trabajo aplica sin darse cuenta y, por eso mismo, no sabe explicar. Si le preguntas «¿cómo lo haces?», te devuelve la versión oficial, la que cabe en una frase. El agente se construye sobre esa versión y se rompe en todo lo demás.
No es un detalle de implantación. El análisis de RAND sobre por qué fracasan los proyectos de IA, basado en entrevistas con ingenieros y científicos de datos, sitúa entre las causas más habituales que el problema a resolver se entendió o se comunicó mal (RAND, 2024). Es el mismo patrón que describimos en por qué fracasan los proyectos de automatización con IA: el proyecto no falla en la demo, falla en el hueco entre lo que cada parte daba por entendido.
¿Cómo saber si un proceso solo existe en la cabeza de una persona?
Hay señales bastante fiables, y no hace falta una auditoría para verlas.
- Dos personas lo hacen distinto y las dos dicen que lo hacen bien. Cada una aplica su propio criterio y nadie los ha puesto nunca uno al lado del otro.
- Cuando falta esa persona, el proceso se para o se degrada. Si las vacaciones de alguien son un riesgo operativo, el proceso vive en su cabeza (el mismo problema, visto desde el agente, en qué pasa con tu agente cuando se va quien lo montó).
- La explicación empieza por «depende». Cuando cada paso lleva un «depende» y nadie sabe de qué, hay reglas sin escribir.
- Las excepciones se resuelven por teléfono o por mensaje. Lo que se decide fuera del sistema no queda en el sistema, y el agente solo ve el sistema.
¿Cómo se extrae el proceso real en una semana?
No con un cuestionario ni con una reunión de dos horas. Con casos reales, observados por alguien que no sea quien ejecuta el trabajo. Un método que cabe en cinco días:
- Lunes: elige un proceso y una persona. Un solo proceso, el que más vueltas da, y a quien lo ejecuta a diario. Dile desde el principio que no se la evalúa: se trata de entender, no de auditar.
- Martes: observa casos, no preguntes cómo se hace. Siéntate con ella mientras resuelve casos reales, incluidos los raros, y anota cada decisión. Una muestra de los últimos casos vale más que cualquier descripción.
- Miércoles: pregunta por qué en cada decisión. «¿Por qué este y no aquel?», «¿qué habría pasado con otro importe?». Aquí salen los criterios que ella creía obvios.
- Jueves: escribe la regla de negocio, no los clics. Condición, excepción y a quién se avisa, en una página por proceso. El formato está en cómo documentar automatizaciones.
- Viernes: contrasta con casos que no ha visto. Dale casos nuevos sin enseñarle la regla y compara su decisión con lo escrito. Cada diferencia es una regla que faltaba.
| Lo que dice la versión oficial | Lo que hace la persona en realidad | Cómo aflora |
|---|---|---|
| «Cuadro el extracto con las facturas» | Agrupa pagos, aplica descuentos pactados de palabra y deja en espera a ciertos clientes | Observando casos reales, no describiéndolos |
| «Se aprueba si cumple la política» | Aprueba cosas fuera de política cuando conoce al cliente | Preguntando por qué en cada excepción |
| «Se revisa antes de enviar» | Revisa solo lo que huele raro, según una intuición que no sabe nombrar | Dándole casos nuevos y comparando su decisión con la regla escrita |
Fíjate en la última columna: en ningún caso la solución es preguntar más, es mirar más. Quien describe su trabajo describe el ideal; quien lo hace delante de ti enseña el real. Y el real es el único que un agente va a encontrarse el lunes por la mañana, con los casos que nadie previó en la reunión de arranque.
¿Y si al documentar descubres que no conviene automatizarlo?
Pasa más de lo que se admite. Al documentar aparecen inconsistencias entre personas, pasos que nadie recuerda por qué existen y decisiones que dependen de un juicio que no se deja reducir a reglas. Con eso hay tres salidas: simplificar el proceso antes de tocar nada, automatizar solo la parte que ya es regla y dejar la parte de juicio en manos de una persona, o decidir que ese proceso no es para un agente (el razonamiento de fondo está en cuándo no automatizar con IA). Cualquiera de las tres sale más barata que descubrirlo con el agente ya en producción.
Y la parte de juicio no desaparece: marca cuánta autonomía puedes darle al agente. Eso se decide con los niveles de autonomía de un agente, y solo se puede decidir si antes sabes dónde está el juicio.
¿Cuándo no compensa documentar el proceso primero?
Cuando el proceso es corto, reversible y barato de equivocar: tres pasos, sin dinero ni datos personales de por medio. Ahí se prueba directamente y se corrige sobre la marcha. Tampoco compensa documentar con tanto detalle un proceso que cambia cada mes; en ese caso lo que se escribe son los principios estables, no cada paso (más en automatizar un proceso que cambia cada mes).
Si tienes varios candidatos y no sabes por cuál empezar, auditar tus procesos para IA responde primero a cuál merece el esfuerzo; el ejercicio de esta semana es lo que haces después, con el elegido.
La línea para llevarte: el proceso que vas a automatizar no es el del manual, es el que hace la persona, y mientras ese no esté escrito, el agente se construye sobre una suposición.
Fuentes (consultadas el 28 de octubre de 2026): «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed», RAND Corporation (2024), usada de forma cualitativa. El escenario del inicio es ilustrativo, no un caso real.