Las empresas llevan treinta años automatizando procesos sin inteligencia artificial, y muchos de los que mejor funcionan hoy siguen sin llevarla. Así que la pregunta útil no es «cómo automatizo con IA», sino qué parte de mi proceso mejora al meter un modelo y qué parte empeora.
La respuesta corta: la IA sirve donde hay variabilidad e interpretación, y estorba donde hay reglas claras y consecuencias caras. Este artículo desarrolla dónde está esa frontera, cómo se construye un proceso con IA que no se rompa a las dos semanas, y qué criterio usar para decidir cuándo pasa a producción.
La diferencia real: reglas frente a criterio
Una automatización clásica ejecuta reglas: si pasa esto, haz aquello. Es determinista, se puede auditar línea a línea y falla siempre igual, lo que la hace fácil de depurar. Su límite es que necesita que el mundo llegue en el formato previsto.
Un proceso con IA introduce una pieza que interpreta. Eso permite absorber entradas que no vienen estructuradas —un correo escrito por una persona, una factura de un proveedor nuevo, un mensaje ambiguo— pero a cambio pierdes el determinismo: la misma entrada puede producir salidas ligeramente distintas.
La última fila es la que más cara sale cuando se ignora. Una automatización por reglas que falla, se para y te enteras. Un modelo que falla devuelve una respuesta que parece correcta, y si no hay validación, sigue su camino hasta el cliente.
Dónde aporta la IA, y dónde sobra
Aporta: entradas que no vienen en formato
Cincuenta proveedores mandan la factura con cincuenta maquetaciones distintas. Con reglas necesitas una plantilla por proveedor y mantenerlas todas. Un modelo extrae los campos sin plantilla y solo levanta la mano cuando algo no cuadra contra el pedido.
Aporta: clasificar y priorizar
Decidir si un correo entrante es una incidencia urgente, una consulta comercial o una factura. O puntuar un lead cruzando señales que no caben en una fórmula. Son juicios con matices, que es exactamente donde una regla rígida se queda corta.
Aporta: redactar el texto de salida
El resumen semanal, la respuesta a una consulta frecuente, el borrador de una propuesta. El dato lo pone tu sistema; el modelo lo convierte en algo legible.
Sobra: cálculos y validaciones
Un total, un IVA, una comprobación de que un IBAN es válido. Meter un modelo aquí es pagar por hacer peor lo que una función hace exacto y gratis. Se ve más de lo que parece, y siempre acaba mal.
Sobra: decisiones con consecuencia legal o económica directa
Aprobar un pago, cerrar contabilidad, comprometer un plazo contractual. El modelo puede preparar la decisión y presentarla; firmarla es de una persona.
Las cinco piezas de un proceso con IA
Los proyectos que se sostienen en el tiempo tienen las cinco. Los que se rompen a las dos semanas suelen tener tres.
- El disparador. Qué evento arranca el proceso: un correo, un formulario, una hora del día, un cambio de estado en el CRM.
- El contexto. Qué datos de tu negocio necesita el modelo para decidir bien. Es la pieza que más se subestima: un modelo sin acceso a tu histórico responde con generalidades.
- La instrucción. Qué se le pide exactamente, con qué formato de salida y qué debe hacer cuando no está seguro. Esa última parte es la que evita las respuestas inventadas.
- La acción. Qué escribe o modifica en qué sistema. Aquí conviene ser restrictivo: cuantos menos permisos de escritura, menos daño puede hacer un error.
- La supervisión. Cómo se detecta que algo va mal, quién recibe el aviso y cuál es el procedimiento manual mientras se arregla.
El criterio para pasar a producción
Este es el punto donde más proyectos se precipitan. La forma que nos funciona es sencilla y tiene una fase intermedia que casi nadie hace:
El sistema decide, pero no ejecuta. Durante dos a cuatro semanas, el modelo propone la acción y una persona la valida antes de que ocurra nada. Se registra cuántas veces coinciden. Cuando el acuerdo entre el sistema y la persona supera el 95% de forma sostenida, se le permite ejecutar solo. Si no llega, no es que el modelo sea malo: casi siempre es que el proceso no estaba tan claro como se creía.
Ese periodo tiene un beneficio añadido que no se ve venir: genera un conjunto de casos reales etiquetados por tu propio equipo, que es lo que después te permite mejorar las instrucciones con fundamento en lugar de a base de intuiciones.
Por qué el 95% no siempre es suficiente
Un acierto del 95% suena bien hasta que lo multiplicas por el volumen. Con 2.000 ejecuciones al mes, eso son 100 errores mensuales. La pregunta que decide si el proceso es apto no es la tasa de acierto, sino cuánto cuesta cada uno de esos 100 fallos.
El coste que aparece en producción
Durante las pruebas, un proceso con IA cuesta céntimos. Esa cifra engaña, porque el desarrollo hace decenas de ejecuciones y producción hace miles. Con volúmenes altos y un modelo grande, la factura mensual pasa a ser una partida real del presupuesto.
Tres medidas que cambian el orden de magnitud:
- Modelo pequeño para tareas simples. Clasificar en cuatro categorías no necesita el modelo más caro del catálogo.
- Cachear lo repetido. Si la misma pregunta entra cien veces, se responde una y se guarda.
- Filtrar antes de llamar. Una regla barata descarta el 80% de los casos y el modelo solo ve el 20% que de verdad requiere interpretación.
Un proceso completo, de principio a fin
Vale la pena ver las cinco piezas aplicadas a un caso concreto, porque en abstracto todo parece fácil. Tomemos la recepción de facturas de proveedor, que es el proceso con IA que más veces hemos montado.
Disparador. Llega un correo a la dirección de facturación con un PDF adjunto.
Contexto. El sistema recupera del ERP el pedido asociado a ese proveedor, las condiciones pactadas y el histórico de facturas anteriores. Sin este paso, el modelo solo puede leer el papel; con él, puede comprobar si lo que dice el papel tiene sentido.
Instrucción. Se le pide extraer emisor, CIF, número, fecha, base, IVA, total y líneas de detalle, en un formato fijo. Y una regla explícita: si algún campo no aparece con claridad, se marca como «no encontrado» en lugar de deducirlo. Esa frase es la que evita que rellene huecos por su cuenta.
Acción. Si el total cuadra con el pedido dentro de un margen definido, se registra el asiento y se programa el pago. Si no cuadra, o si algún campo salió como «no encontrado», se crea una tarea para una persona con el PDF y la discrepancia señalada.
Supervisión. Un informe semanal indica cuántas facturas pasaron solas, cuántas se escalaron y por qué motivo. Si el porcentaje de escaladas sube de golpe, algo ha cambiado: normalmente un proveedor que ha modificado su formato.
Nótese que la IA solo interviene en un punto de los cinco. El resto es integración y reglas. Es la proporción habitual en los proyectos que funcionan.
Con qué se construye
Las piezas del stack se eligen por dos criterios: cuánta lógica propia necesitas y si tus datos pueden salir de tu infraestructura.
La capa de registro es la que más se omite en los proyectos que después dan problemas. Cuando un cliente reclama que el sistema le dijo algo raro, sin trazas no hay forma de saber si ocurrió ni por qué.
Cómo elegir por dónde empezar
Con tres preguntas, en este orden:
- ¿Cuántas veces al mes ocurre? Por debajo de unas decenas, el mantenimiento se come el ahorro.
- ¿Sabría explicárselo a alguien nuevo en una página? Si no, el proceso no está claro y hay que rediseñarlo antes.
- ¿Qué pasa si se equivoca? Determina si va solo, con muestreo o con validación previa.
El candidato ideal es alto en la primera, claro en la segunda y barato en la tercera. Empezar por el proceso más doloroso en lugar de por el más apto es la causa habitual de que el primer proyecto salga mal y la empresa concluya que «esto no funciona».
Lo que exige el marco regulatorio
Dos obligaciones afectan de lleno a los procesos automatizados con IA en Europa. La primera, transparencia: si un sistema interactúa con personas, tienen derecho a saber que es automático. La segunda, y la que más se pasa por alto, es que si tratas datos personales tienes que saber por dónde pasan: qué proveedor los procesa, con qué contrato y durante cuánto tiempo se conservan.
Práctica mínima: contratos de encargado de tratamiento firmados con cada proveedor implicado, anonimización de lo que se pueda antes de enviarlo, registro de qué se envía y a dónde, y un responsable con nombre. No es burocracia opcional: es lo primero que se pide cuando hay una inspección.
Preguntas frecuentes
¿Necesito IA para automatizar mis procesos?
En la mayoría de pymes, los primeros tres o cuatro procesos que conviene automatizar no la necesitan: son reglas claras entre sistemas. La IA entra cuando aparece la variabilidad, normalmente en la lectura de documentos y en la atención al cliente. Empezar por la IA porque está de moda es la vía rápida a un proyecto caro que no resuelve nada.
¿Qué diferencia hay con el RPA?
El RPA imita a una persona usando una interfaz: hace clic, copia, pega. Es útil cuando el sistema de origen no tiene API, y es frágil porque cualquier cambio en la pantalla lo rompe. La automatización moderna trabaja contra APIs, y la IA se suma para interpretar lo que llega. No compiten: el RPA es un parche para sistemas cerrados.
¿Cuánto tarda en verse el retorno?
En procesos administrativos bien elegidos, entre 30 y 90 días. Si a los 90 no hay mejora medible en horas, errores o días de cobro, conviene revisar el proceso antes de seguir invirtiendo en él.
¿Qué hago con los procesos que ya no usa nadie?
Apagarlos. Las automatizaciones zombi consumen coste, siguen escribiendo en sistemas vivos y nadie recuerda qué hacen. Una revisión trimestral de qué flujos siguen aportando valor evita que en dos años tengas un parque de procesos que nadie se atreve a tocar.