6 min de lectura
Un equipo automatiza la extracción de datos de facturas. Escribe reglas: buscar el número de factura donde suele estar, extraer el importe siguiendo el formato conocido, marcar como "revisar" cualquier caso que no encaje. El sistema resuelve 8 de cada 10 facturas sin intervención humana. Las 2 restantes las revisa una persona.
Meses después cambia el proveedor principal. Los formatos se multiplican. Las reglas empiezan a fallar más seguido. Se incorpora un extractor con IA, entrenado sobre miles de facturas escaneadas. El sistema ahora procesa 9,5 de cada 10. La persona que antes revisaba 2 casos al día ahora revisa 10.
Nada falló técnicamente. El sistema con IA hace menos errores y procesa más volumen que las reglas anteriores. La aritmética se rompe en otro lugar. Cambió el tipo de revisión que exige el sistema, y nadie diseñó el flujo humano que corresponde a esa nueva exigencia. A partir de ello, la pregunta es dónde termina viviendo el trabajo humano cuando la automatización cambia de reglas a modelos, y cómo diseñar ese lugar antes de que el sistema entre en producción.
Dónde vive el humano en un proceso con reglas
En un proceso automatizado con reglas, el trabajo humano tiene una ubicación predecible, que son las excepciones. Lo que la regla no supo clasificar cae en una cola de revisión. La persona resuelve el caso, y cuando el proceso está bien diseñado, esa resolución alimenta la regla para que la próxima vez esa variante quede cubierta automáticamente.
El humano actúa solo sobre lo que el sistema marcó explícitamente como dudoso. Sabe que lo que llega a su bandeja es raro y vale la pena mirarlo con atención. Sabe además cómo va a reaccionar el sistema, porque la regla es determinista. Dado el mismo input produce el mismo output, siempre. Con el tiempo, si el proceso está bien diseñado, el volumen de excepciones tiende a bajar. Cada caso revisado es una oportunidad de refinar la regla.
Dónde vive el humano en un proceso con IA
Con IA la geografía del trabajo humano cambia. El sistema devuelve una respuesta para casi todos los casos, incluidos los que antes habrían caído en la cola de revisión. Cada respuesta viene con una incertidumbre implícita que las reglas no tenían.
El humano ya no interviene solo cuando el sistema marcó un caso como dudoso. Interviene también cuando el sistema respondió, para verificar si respondió bien. Y ese trabajo de verificación no puede hacerse por muestreo negativo, porque los errores del sistema con IA no siempre se anuncian. Un extractor que infiere el importe de una factura puede confundir el subtotal con el total. La factura sale procesada, nada falla técnicamente, y el error aparece semanas después cuando el sistema de pagos genera una discrepancia con el proveedor. Para que ese error no llegue a producción hay que validar antes, y esa validación tiene un costo en tiempo de personas.
El humano termina trabajando más, sobre casos que el sistema considera resueltos, usando criterio que antes solo se reservaba para las excepciones. El tipo de revisión que exige la IA es distinto al que exigen las reglas, y si el proceso se diseñó para el segundo, el primero lo desborda.
Lo que pasa cuando la validación no se diseña
El error más caro en un proyecto de automatización con IA suele ser la ausencia de un lugar humano bien definido a su lado. Cuando la validación se piensa después de implementar el sistema, aparece en una de dos formas.
En la primera, alguien decide revisar todo. La persona revisa cada salida del sistema, una por una. El proceso manual tenía un volumen; el nuevo tiene ese mismo volumen más el tiempo de ejecutar el sistema y esperar su resultado. La automatización no redujo el trabajo, lo reorganizó con un paso adicional.
En la segunda, alguien decide no revisar nada. Los errores del sistema entran al flujo de datos sin ser detectados. Semanas después algún reporte no cuadra, algún cliente reclama, algún pago se hace con el importe incorrecto. La organización pierde confianza en el sistema, y el proceso vuelve a ser manual con la convicción adicional de que "la IA no funciona".
Las dos conclusiones son prevenibles. Se evitan diseñando desde el principio dónde va a estar el humano y con qué criterio va a intervenir.
El umbral como decisión de negocio
Un pipeline con IA que funciona en producción tiene piezas explícitas desde el principio: el modelo que devuelve la respuesta, una medida de confianza asociada a cada respuesta, y un umbral que separa lo que el sistema resuelve solo de lo que pasa a validación humana.
Ese umbral es una decisión de negocio que determina cuánto trabajo humano se acepta y qué nivel de error es tolerable cuando la validación no ocurre. Se puede empezar conservador, con un umbral alto que manda muchos casos a revisión, y ajustarlo a medida que el sistema demuestra ser confiable en ciertos tipos de caso. O se puede arrancar con un umbral más bajo, aceptando un porcentaje de errores conocido a cambio de velocidad de procesamiento.
Lo que no funciona es no tomar esa decisión. Un sistema en producción sin umbral explícito y sin flujo humano definido descubre su propio funcionamiento sobre la operación real, y esa exploración se paga en horas de personas resolviendo consecuencias que el diseño del sistema generó. El costo aparece cuatro semanas después de haber puesto el sistema en marcha.
El pipeline mixto como arquitectura por defecto
La mayoría de los procesos que vale la pena automatizar no son puramente de reglas ni puramente de IA. Son mixtos: una parte determinista que las reglas resuelven bien, y una parte con variabilidad que requiere un modelo. El diseño consiste en identificar dónde termina una y empieza la otra.
Las reglas cubren lo predecible: formatos conocidos, validaciones de estructura, umbrales numéricos. La IA cubre lo variable: formatos que las reglas nunca vieron, ambigüedad de contenido, casos que se reconocen pero no se pueden enumerar por adelantado. El humano se coloca en el punto de mayor incertidumbre, donde el sistema tiene menos confianza en su propia salida. Ahí calibra el sistema y valida la frontera entre lo que el modelo resuelve con confianza y lo que necesita revisión. Es un trabajo de menor volumen que el de las excepciones antiguas, pero de mayor responsabilidad por caso.
La pregunta que estructura este diseño es dónde va a estar el humano, y qué va a ver cuando interviene. Responder esa pregunta antes de construir el sistema determina si el resultado es un proceso más eficiente o uno más complicado con el mismo costo de operación que el manual que reemplazó.