En la industria del software hay un nombre para esto, y existe desde mucho antes de que llegara la IA: swivel chair, o trabajo de silla giratoria. Describe a la persona que abre una pantalla, copia un dato, gira hacia otra pantalla y lo vuelve a escribir. Es el trabajo que aparece exactamente en el hueco entre dos sistemas que no se hablan entre sí.

La industria le puso nombre porque es un patrón conocido, documentado y bastante viejo. Lo que casi nadie mide es cuánto de un equipo financiero moderno sigue dedicado a hacer exactamente eso, ni por qué las tres olas de tecnología que prometieron eliminarlo —el ERP, el RPA y ahora los copilots de IA— dejaron el problema básicamente intacto.

Este artículo intenta responder eso con datos, no con opiniones.

Primero: cuánto trabajo es, en realidad

Ese 30% no es una anomalía de empresas mal gestionadas. Es el estado normal de la mayoría de los departamentos financieros, y hay varias mediciones independientes que apuntan en la misma dirección.

El costo no termina en las horas. El 45% de los equipos financieros dedica más de diez horas al mes solo a corregir errores y discrepancias entre sistemas, y el 35% de las organizaciones tiene que reabrir libros o reformular cifras al menos una vez por trimestre por errores detectados después del cierre.

Y esto se traduce directamente en el indicador que sí le importa a la dirección: la velocidad del cierre. Según el benchmark de APQC sobre 2.300 organizaciones, la mediana de un cierre mensual es de ocho días. El estudio de Ledge encontró que solo el 18% de los equipos cierra en tres días o menos, mientras que la mitad necesita seis días hábiles o más. Para una empresa mediana con procesos manuales, diez a quince días no es inusual.

Sigan una factura y el problema se vuelve visible

Los porcentajes son abstractos. Un proceso concreto lo es menos. Este es el recorrido típico de una factura de proveedor en una empresa mediana, con el detalle de quién hace cada paso:

De cinco pasos, tres los ejecuta una persona a mano. El ERP aparece únicamente en el último eslabón, cuando toda la información ya fue recolectada, comparada y validada por alguien más. Y no es un defecto del ERP: un ERP es un sistema de registro, no un sistema de ejecución. Fue diseñado para ser la fuente de verdad, no para ir a buscar la verdad a otros sistemas.

Ese hueco tiene un costo adicional que rara vez se contabiliza. La Asociación Americana de Psicología ha documentado que el cambio constante de tarea puede reducir la productividad hasta en un 40%. La persona que salta entre el ERP, el portal del banco y el portal fiscal no solo pierde el tiempo de cada tarea: pierde también el costo de reconstruir el contexto cada vez que cambia de pantalla.

Entonces, ¿por qué no lo resolvió RPA?

Un bot de RPA replica una secuencia de clics. No entiende por qué esos clics existen. Mientras nada cambie, funciona bien. El día que el portal del banco rediseña su interfaz, o que llega una factura con un formato distinto, o que aparece una excepción que nadie previó al programarlo, el bot se detiene o —peor— falla en silencio y sigue registrando datos incorrectos.

La consecuencia se ve en los datos de escalamiento: más de la mitad de los proyectos de RPA no logra crecer más allá de diez bots, y más del 70% se estanca por debajo de cincuenta. Además, análisis de HfS Research indican que la licencia del software representa apenas entre el 25% y el 30% del costo total de propiedad de un despliegue de RPA. El 70% a 75% restante se va en implementación, mantenimiento y soporte, es decir, en mantener vivos los bots que se rompen cada vez que algo cambia.

Dicho de otra forma: RPA no eliminó el trabajo manual, lo transformó en trabajo de mantenimiento de bots.

¿Y los copilots de IA?

Aquí el problema es distinto, y más sutil, porque los copilots sí son genuinamente útiles para lo que fueron diseñados: redactar, resumir, explicar, sugerir. El problema aparece cuando se les pide ejecutar trabajo financiero con números reales.

El benchmark FinanceBench muestra el mismo patrón desde otro ángulo: los modelos alcanzan alrededor del 89% de precisión cuando la recuperación de información es perfecta, pero fallan más del 80% de las veces bajo condiciones reales de RAG empresarial. Y una evaluación de 2026 sobre seis modelos líderes encontró que cuatro de los seis fabrican datos financieros cuando se les entregan documentos incompletos; dos de ellos lo hacen sin advertirlo y en un formato que parece autoritativo.

Ese último punto es el verdaderamente peligroso. Investigación del MIT encontró que los modelos tienden a usar lenguaje más seguro —un 34% más— justamente cuando la información que generan es incorrecta. En un cierre contable, un error que se anuncia a sí mismo es un inconveniente. Un error que suena convincente es un problema de auditoría.

Lo interesante es que la comunidad académica ya identificó cuál es la salida. Un trabajo publicado en 2026 sobre verificación de estados financieros propone explícitamente arquitecturas neuro-simbólicas con registros de hechos determinísticos, argumentando que hay que relevar quirúrgicamente al modelo de lenguaje de la responsabilidad aritmética y delegarla a una capa de reglas verificable. Es, casi palabra por palabra, la tesis sobre la que construimos Pantera.

Las tres capas, comparadas

Qué cambia cuando el trabajo se aprende mirando, no explicando

La diferencia práctica de un trabajador digital no está en tener más inteligencia artificial, sino en dos decisiones de diseño concretas.

1. Se le enseña mostrando, no documentando

En lugar de levantar requerimientos, escribir un manual o redactar un prompt largo, alguien del equipo graba su pantalla haciendo el proceso como lo hace todos los días, con sus excepciones incluidas. Esto importa más de lo que parece: la evidencia de RPA muestra que buena parte de los proyectos fracasa porque las empresas intentan automatizar procesos que nadie había entendido del todo, y las excepciones aparecen recién durante la implementación. Grabar el proceso real elimina la brecha entre el proceso documentado y el proceso que de verdad ocurre.

2. Aprende la regla, no la coreografía

Un modelo de lenguaje puro copiaría los clics. La capa simbólica extrae la lógica: por qué se comparó ese monto contra esa orden de compra, bajo qué condición esa factura necesitó revisión adicional. Por eso el proceso sobrevive a un cambio de interfaz, y por eso cada decisión queda con su regla asociada, lista para auditoría. Y cuando aparece un caso que ninguna regla cubre, no se improvisa una respuesta: se escala a una persona.

• El humano no desaparece del proceso, cambia de lugar. Deja de ejecutar los pasos repetitivos y pasa a resolver las excepciones, que es donde su criterio realmente vale.
• El ERP sigue siendo la fuente de verdad. Nada de esto lo reemplaza. Lo que cambia es quién hace el trabajo alrededor de él.
• La evidencia se genera sola. Cada acción queda registrada con el dato de origen y la regla que la motivó, en lugar de reconstruirse a mano cuando llega la auditoría.

Tu ERP registra el trabajo.
Pantera hace el trabajo.

Preguntas frecuentes