Automatización de procesos con IA en el trabajo administrativo que nadie quiere hacer

Es hacer que un proceso de trabajo se ejecute solo, de principio a fin, usando inteligencia artificial únicamente en los pasos donde hay que interpretar información: leer una factura en PDF, entender un correo escrito por un cliente o clasificar una petición que no sigue ningún formato. El resto del flujo funciona con reglas e integraciones entre sistemas, como la automatización de siempre.

La diferencia con la RPA es que la RPA imita los clics de una persona en una pantalla y solo funciona con información estructurada y pantallas que no cambian. La IA permite automatizar procesos que antes obligaban a que alguien leyera cada caso.

Los más habituales son la entrada de facturas y albaranes en el ERP, la clasificación de correos de buzones compartidos (pedidos, soporte, administración), la creación de registros en el CRM a partir de correos o formularios, las conciliaciones entre cobros y facturas, las altas y bajas de empleados y los informes periódicos que combinan datos de varios sistemas. Los mejores candidatos se repiten mucho, siguen un criterio que alguien sabría explicar y hoy dependen de que una persona lea algo y lo pase a otro sistema.

Siempre que la entrada llegue estructurada y las reglas sean fijas. Si los pedidos entran por un formulario con campos definidos, o si el fichero del proveedor tiene siempre las mismas columnas, un flujo tradicional lo resuelve de forma más rápida, más barata y, sobre todo, más predecible: hace exactamente lo mismo cada vez.

La IA aporta cuando hay que interpretar algo que no viene estructurado —un PDF con maquetación distinta según el proveedor, un correo escrito en lenguaje natural, una descripción libre que hay que clasificar— o cuando las excepciones son tantas que describirlas con reglas resulta inviable. Añadirla donde no hace falta introduce variabilidad, coste por ejecución y una fuente de errores que antes no existía.

En bastantes proyectos la conclusión del análisis es que el 80 % del flujo es automatización clásica y sólo un paso concreto necesita un modelo. Ese reparto es buena señal, no una decepción.

Más de lo que la mayoría de empresas presupuesta, y ese es el motivo habitual de que un flujo montado hace dos años ya no se use. El coste tiene tres partes: la ejecución (consumo de la plataforma y del modelo, si lo hay), la adaptación cuando cambian los sistemas conectados —una actualización del ERP, un cambio de API, una migración de correo— y la revisión cuando cambian tus criterios de negocio.

Nuestra recomendación es reservar desde el principio una partida anual de mantenimiento y decidir con ese número en la mano si el proceso merece automatizarse. Un flujo que ahorra dos horas al mes rara vez lo justifica; uno que ahorra dos horas al día casi siempre sí.

Se diseña asumiendo que va a ocurrir. Los puntos que tocan dinero, clientes o compromisos legales llevan validación humana antes de ejecutar, y el resto lleva umbrales: por debajo de cierta confianza, el caso se aparta a una bandeja de revisión en lugar de seguir adelante. Además todo queda registrado, de modo que si un dato aparece mal en el sistema se puede reconstruir de dónde salió. El riesgo real no es que falle, es que falle sin que nadie se entere durante meses.

A menudo sí, pero conviene evaluarlo antes de comprometer nada. Las vías habituales son el acceso directo a la base de datos en lectura, la importación y exportación de ficheros que el propio ERP ya soporta, o un proceso intermedio que actúa como puente. La automatización de interfaz, simulando clics de usuario, funciona pero es frágil: cualquier cambio de pantalla la rompe, así que sólo la proponemos cuando no hay alternativa y el proceso es estable. Si ninguna vía es viable, es mejor saberlo en el análisis que a mitad de proyecto.

Por un proceso con volumen alto, reglas razonablemente estables y un responsable claro que pueda decidir sobre las excepciones. Los procesos con mucho volumen pero criterio difuso, o con volumen bajo aunque sean muy molestos, son malos primeros candidatos: el primero se atasca en discusiones internas y el segundo no devuelve la inversión. El primer proyecto paga los accesos, las integraciones y el aprendizaje del equipo; a partir del segundo el coste marginal baja mucho.

Un proceso acotado suele estar en pruebas en cuestión de semanas. Lo que marca el ritmo casi nunca es la construcción del flujo, sino conseguir los accesos a los sistemas, entender las excepciones que nadie había documentado y encontrar hueco en la agenda de las personas que deben validar los resultados. Por eso pedimos desde el principio un interlocutor con capacidad de decisión sobre el proceso.