Automatización de procesos con IA: qué se puede automatizar de verdad y qué no

Buena parte de lo que se vende hoy como automatización de procesos con IA es una demo grabada en una tarde: alguien conecta ChatGPT a Make, procesa tres facturas de ejemplo y monta un vídeo. Funciona. Lo que no cuentan es qué pasa cuando entra la factura número cuatro, la que viene torcida, sin importe claro, con el proveedor mal escrito. Ahí es donde una automatización de verdad se separa de un truco de feria. Y ahí es donde llevo más de veinte años trabajando: en el "qué pasa cuando".

La respuesta corta, antes de entrar en materia: hoy la IA automatiza bien leer, clasificar y resumir documentos y texto desordenado. Los cálculos exactos y las decisiones con consecuencias siguen siendo trabajo de código, no de un modelo de lenguaje. Todo lo demás son matices, y los matices son justo lo que se paga.

Qué es la automatización de procesos con IA (y en qué se diferencia de la de siempre)

Automatizar un proceso es hacer que una tarea repetitiva ocurra sin que nadie la empuje a mano. Eso existe desde hace décadas: una hoja de cálculo con macros, un script que mueve archivos, un ERP que genera un asiento. Todo eso es automatización determinista. Le das la misma entrada y te da exactamente la misma salida, siempre. Es fiable porque es aburrida.

Lo que añade un modelo de lenguaje (un LLM, como el que hay detrás de ChatGPT) es la capacidad de entender texto y documentos que no tienen una estructura fija. Un albarán escaneado, un correo de un cliente cabreado, un currículum, una reseña. Cosas que antes exigían que una persona los leyera y decidiera. El LLM no ejecuta reglas: interpreta. Y esa es exactamente su virtud y su peligro.

Porque hay una diferencia que ninguna landing comercial te va a explicar: un LLM no es determinista. La misma entrada puede darte salidas distintas en dos llamadas seguidas. Eso, que para escribir un borrador de correo es irrelevante, para calcular un importe es descalificatorio. Toda la ingeniería seria de la automatización con IA consiste en saber dónde esa naturaleza probabilística es un regalo y dónde es una bomba.

Dónde un modelo de IA es la herramienta correcta

Un LLM brilla en cuatro tareas concretas, y conviene tenerlas claras porque son las que rentan:

• Extraer datos de documentos no estructurados. Sacar el número de factura, la fecha, las líneas y los importes de un PDF que cada proveedor maquetó a su manera. Aquí el modelo hace en segundos lo que a una persona le lleva minutos. Es el caso estrella, y lo cuento paso a paso en cómo automatizar facturas y albaranes con IA.
• Clasificar. Leer un correo entrante y decidir si es una incidencia, una consulta comercial o una factura. Etiquetar tickets, enrutar mensajes, ordenar una bandeja de entrada caótica.
• Resumir. Condensar un hilo de veinte correos, una reunión transcrita o un informe largo en tres líneas útiles.
• Redactar borradores. Preparar una primera respuesta, un texto de producto, un correo de seguimiento. Insisto en la palabra borrador: el punto de partida que una persona revisa, no el envío final.

¿Qué tienen en común las cuatro? Que trabajan sobre lenguaje, que admiten cierto margen de error sin que se caiga el mundo, y que una persona puede revisar el resultado más rápido de lo que lo habría hecho desde cero. Ese último punto es el que separa una automatización rentable de un juguete caro.

Dónde la IA es la herramienta equivocada

Aquí es donde tengo que ser desagradable, porque es lo que casi nadie dice. Hay procesos donde meter un LLM no es que sea peor: es una irresponsabilidad.

Cálculos exactos. Un modelo de lenguaje predice la siguiente palabra probable; no "sabe" sumar. Si le pides que calcule un IVA, un total o un prorrateo, a veces acierta y a veces se inventa un número con toda la seguridad del mundo. Los importes se calculan con código determinista, no con un LLM. El modelo puede leer el importe de una factura; el que comprueba que las líneas cuadran con el total es una función que suma, no la IA.

Decisiones sin supervisión donde una equivocación cuesta dinero. Aprobar un pago, conceder un crédito, aplicar una regla fiscal, borrar registros. Un LLM alucina: genera respuestas falsas con el mismo tono aplomado que las verdaderas. Si esa alucinación dispara una transferencia o modifica la contabilidad, el ahorro de la automatización se lo come el primer error.

Reglas que ya están escritas. Si tu proceso es "si el pedido supera 500 euros, aplica el descuento del 10 %", eso es un if. Meterle un modelo de IA por encima es pagar por token para hacer lo que una línea de código hace gratis, más rápido y sin margen de fallo.

La regla que uso es sencilla: si el resultado tiene que ser exacto y verificable, no es trabajo para un LLM; es trabajo para código clásico. El modelo se queda en la frontera borrosa, entender el documento, interpretar el texto, y en cuanto hay un número o una decisión con consecuencias, el control pasa a lógica determinista y, si hace falta, a una persona.

Cómo decido qué proceso automatizar primero

La mayoría de empresas se equivocan aquí: automatizan lo que más ruido hace, no lo que más renta. Yo priorizo con una cuenta muy tonta que casi nunca falla:

frecuencia × tiempo por caso × tasa de error actual

• Frecuencia: cuántas veces al mes ocurre. Automatizar algo que pasa dos veces al año no compensa jamás.
• Tiempo por caso: cuántos minutos le cuesta a una persona cada vez.
• Tasa de error: con qué frecuencia se cuela un fallo cuando lo hace una persona a mano, cansada, a las siete de la tarde.

Un proceso que ocurriera 300 veces al mes, costara 6 minutos cada uno y fallara 1 de cada 20 veces sería oro. Uno que ocurre 5 veces al mes y ya sale casi perfecto no lo toques: gastarás más en montarlo que lo que ahorras en años.

A esa cuenta le añado un cuarto filtro cualitativo: cuánto duele el error. Un fallo al clasificar un correo se corrige en un clic. Un fallo al calcular una nómina acaba en el despacho de un abogado. Cuanto más caro es el error, más determinista y más supervisado tiene que ser el diseño, y menos protagonismo le doy al LLM.

Con esos cuatro números encima de la mesa, la conversación deja de ser "¿qué puede hacer la IA?" y pasa a ser "qué proceso concreto tuyo sale rentable primero". Que es la única pregunta que importa.

Cómo se monta un sistema en serio y no como una demo

Aquí está casi todo el trabajo real y casi nada de lo que se habla. Conectar un modelo a un flujo es la parte fácil. Que ese flujo aguante meses procesando cosas raras sin romperse ni duplicar nada es lo que se paga. Estos son los elementos que separan un sistema de una demo:

Colas y reintentos. Los documentos no se procesan en el momento en que llegan: entran en una cola y se procesan de uno en uno, con orden. Si la llamada al modelo falla, y falla, porque las APIs se caen, el sistema reintenta con una espera creciente en vez de rendirse o bloquearse.

Idempotencia. Esta es la palabra que nadie menciona y la que más disgustos evita. Si un webhook avisa dos veces de la misma factura (y lo hará), el sistema tiene que reconocer que ya la procesó y no volver a crearla. Sin esto, un reintento inocente te duplica un asiento contable. La idempotencia se diseña desde el primer día, no se parchea después.

Timeouts y plan para cuando el modelo no responde. ¿Qué pasa si la API tarda cuarenta segundos o devuelve un error? El proceso no se puede quedar colgado esperando eternamente ni tirar el documento a la basura. Se define un tiempo máximo, y si se supera, el caso va a una cola de revisión en vez de perderse en silencio.

Human-in-the-loop, como diseño y no como adorno. Este es el corazón de un sistema honesto. El modelo devuelve, junto a cada resultado, una señal de confianza. Por encima de cierto umbral, el flujo sigue solo. Por debajo, el caso se frena y espera a que una persona lo revise. No es un fallo del sistema: es el sistema funcionando bien. La meta no es "cero intervención humana", esa frase vende cursos, no resuelve procesos; la meta es que la persona solo toque lo dudoso y el resto pase solo. Diseñar esa cola de aprobación, con su umbral y su pantalla de revisión, es la mitad del proyecto.

Nada de esto se ve en un vídeo de demostración. Todo esto es lo que hace que el sistema siga en pie el mes que viene.

Evaluar con casos reales antes de confiar

No saco un flujo a producción "a ojo". Antes reúno un conjunto de casos reales de la empresa, cincuenta, cien facturas, correos o documentos de verdad, y los etiqueto a mano con la respuesta correcta. Eso se llama un set de evaluación, y es la vara de medir.

Con ese set puedo responder a la única pregunta que importa antes de confiar en la automatización: ¿cuántas veces acierta de cada cien? Si el modelo acierta noventa y seis de cien y las cuatro dudosas caen por debajo del umbral de confianza y van a revisión humana, tengo un sistema fiable. Si acierta setenta y no sé cuáles falla, tengo una ruleta.

Este paso es el gran ausente de casi todo lo que he visto vender como automatización con IA, y es precisamente el que convierte una promesa en un dato. Sin evaluación con casos reales no estás automatizando: estás cruzando los dedos con más pasos.

Qué pasa cuando cambia el modelo y cuánto cuesta cada mes

Dos realidades incómodas que descubres cuando esto lleva tiempo funcionando.

La primera: el modelo cambia bajo tus pies. Los proveedores actualizan y retiran versiones. Un flujo afinado durante semanas para una versión concreta puede degradarse en silencio cuando el proveedor la sustituye por otra "mejor". Nadie te avisa, y los resultados empeoran sin que salte ninguna alarma. Por eso fijo la versión del modelo de forma explícita y vuelvo a pasar el set de evaluación cada vez que toca cambiarla. Versionar el modelo y reevaluar no es una manía: es lo que evita que un martes cualquiera tu automatización empiece a fallar sin motivo aparente.

La segunda: esto cuesta dinero cada mes, y hay que saber calcularlo. Los modelos cobran por token, que es, en bruto, por cantidad de texto que entra y sale. Un documento largo cuesta más que uno corto. La cuenta que hago es el coste por caso procesado: si extraer los datos de una factura cuesta unos céntimos y ahorra minutos de una persona, renta con holgura. Pero con volúmenes muy altos, un modelo grande y caro puede dejar de compensar frente a uno más pequeño, o frente a reglas clásicas de toda la vida. Parte de mi trabajo es decirte cuándo la IA es la opción rentable y cuándo estás pagando por token algo que un script haría gratis.

Ese coste operativo recurrente es un número que va en la ecuación desde el primer día. No es lo mismo que lo que cuesta construir el sistema, y casi nadie te enseña a estimarlo.

No-code o software a medida: cuándo basta Make y cuándo no

Seré justo con las herramientas no-code: Make, Zapier y n8n son excelentes para prototipar y para procesos de bajo volumen y bajo riesgo. Si quieres que cuando llegue un formulario se cree una fila en una hoja y se envíe un correo, no me llames: móntalo tú en una tarde y te ahorras el dinero.

El no-code se queda corto cuando aparece cualquiera de estas tres cosas: fiabilidad (necesitas idempotencia real, reintentos finos, control de qué pasa cuando algo falla a las tres de la mañana), coste (a partir de cierto volumen, pagar por operación en una plataforma sale más caro que tener el proceso en tu propio servidor) o integración (tienes que meterte dentro de tu ERP, tu base de datos o tu lógica de negocio, no solo conectar cajitas por fuera).

Cuando pasa eso, lo construyo a medida con Laravel, Node o Python: el mismo diseño, colas, idempotencia, human-in-the-loop, evaluación, pero sobre código propio que controlas tú, que no depende de la tarifa de un tercero y que se integra donde de verdad vive tu negocio. Puedes ver con qué trabajo y cómo y el alcance real de los proyectos en el portfolio.

Por dónde empezar

Si te llevas una sola idea, que sea esta: la automatización de procesos con IA no es magia ni humo, es ingeniería con una herramienta nueva que hay que colocar en su sitio exacto. El LLM entiende documentos y texto desordenado como nada anterior; en cuanto hay un número que tiene que cuadrar o una decisión que cuesta dinero, el mando vuelve a código determinista y, cuando toca, a una persona.

Mi criterio en tres líneas: automatiza primero lo que más frecuencia, tiempo y error acumula; usa el modelo solo para interpretar, nunca para calcular ni decidir a solas; y móntalo con colas, idempotencia, revisión humana y evaluación con tus casos reales, porque sin eso tienes una demo, no un sistema.

Trabajas directamente conmigo en todo esto: un único responsable senior, sin juniors aprendiendo con tu presupuesto ni intermediarios. El análisis funcional inicial y la primera consulta no los cobro, así que la conversación en la que decidimos qué proceso tuyo sale rentable no te compromete a nada. Si tienes una tarea repetitiva que sospechas que la IA podría quitarte de encima, cuéntame tu caso y te digo con franqueza si merece la pena o si estarías pagando por token algo que un script haría gratis.