1. Introducción

La automatización robótica de procesos hizo una promesa modesta y, durante un tiempo, la cumplió. Allí donde una persona trasladaba datos entre sistemas que no podían comunicarse entre sí, iniciando sesión en un portal, copiando cifras a una hoja de cálculo, tecleándolas en un ERP, se podía enseñar a un bot de RPA a hacer lo mismo, pulsando los mismos botones en el mismo orden, más rápido y sin cansarse. El atractivo era que no requería cambio alguno en los sistemas subyacentes: el bot manejaba las pantallas existentes exactamente como lo hacía una persona, de modo que un departamento podía automatizar un proceso en semanas sin esperar a que TI construyera una interfaz. Sobre esa base, la RPA se convirtió en una de las tecnologías empresariales de más rápida adopción de la última década.

El problema está en la palabra robótica. Un bot de RPA no comprende la tarea; repite una grabación. Sabe que el total de la factura está en la tercera casilla de la segunda pestaña, no qué es el total de una factura, de modo que cuando se rediseña el portal y la casilla se mueve, el bot no se adapta: falla, y si falla en silencio sigue registrando el número equivocado hasta que alguien lo nota. Todo proceso que ejecuta una organización se asienta en un entorno que se desvía: el software se actualiza, los formularios se rediseñan, los proveedores envían una nueva maquetación, una normativa añade un campo, llega un caso límite que la grabación nunca vio. Frente a un entorno cambiante, un conjunto de reglas congeladas es un activo que se deprecia. El nombre que la industria da a la consecuencia es mantenimiento de bots, y es el escándalo silencioso del campo: una gran parte del esfuerzo de un programa de RPA maduro no va a automatizar trabajo nuevo, sino a reparar automatizaciones que el mundo ha roto, de modo que el coste operativo aumenta con el tiempo y el caso de negocio se erosiona por debajo.

Este artículo trata de qué reemplaza a la RPA, y por qué el reemplazo es una clase de cosa distinta en lugar de un bot más rápido. Un agente de IA capaz, un modelo que puede leer una pantalla o un documento, razonar sobre para qué sirve, invocar herramientas y comprobar su propio trabajo, puede hacer la tarea administrativa que hacía la RPA, pero esa no es la afirmación interesante, porque hacer lo mismo de forma igual de frágil con un motor más caro no es un avance. La afirmación interesante es que un agente puede hacer lo que un bot estructuralmente no puede: puede mejorar la automatización a partir de su propia ejecución. Cada vez que maneja un caso genera evidencia, qué hizo, si el resultado fue aceptado, dónde dudó o fue corregido, y esa evidencia puede retroalimentarse para revisar cómo se comporta la automatización la próxima vez. La automatización deja de ser una grabación hecha una sola vez y que se degrada en adelante, y pasa a ser un bucle que mejora cuanto más se ejecuta. A esto lo llamamos automatización recursiva, y es la primera de las dos piedras angulares del artículo.

La segunda piedra angular es la que hace segura a la primera, y sin ella la recursión es una carga más que un activo. Un bucle que cambia su propio comportamiento a partir de sus propias salidas es, en términos de control, un sistema de retroalimentación, y los sistemas de retroalimentación pueden converger o pueden descontrolarse. Un agente que se deja ajustar contra una señal ruidosa perseguirá el ruido, optimizará la medida que se le dio en lugar del resultado que debía servir, y retrocederá de maneras que nadie eligió. La disciplina que convierte un bucle que se mejora a sí mismo de un peligro en un motor fiable de mejora no es nueva; la industria la tiene desde la década de 1920 y la ha formalizado durante los últimos treinta años como Six Sigma, cuyo núcleo operativo es el ciclo DMAIC: Definir el objetivo y las tolerancias, Medir lo que realmente ocurre, Analizar las fuentes de error y variación, Mejorar mediante un cambio deliberado, y Controlar para que la ganancia se mantenga y no se pierda. Leído como una metodología de proyecto, DMAIC es familiar. Leído como la estructura de control de una automatización que se mejora a sí misma, ejecutada de forma continua y no una sola vez, es exactamente el gobernador que el bucle recursivo necesita, y ese emparejamiento es el tema de este artículo.

La contribución es un argumento y un modelo reducido, no un banco de pruebas. La Sección 2 sitúa la afirmación frente al historial de la RPA, la automatización inteligente, la mejora continua y los agentes de IA. La Sección 3 expone por qué un bot de reglas fijas se degrada, con un modelo de desviación y mantenimiento. La Sección 4 describe el bucle recursivo que un agente hace posible. La Sección 5 es el corazón del artículo: DMAIC como la estructura de control que hace converger el bucle, con la fase de Controlar como un trinquete de no regresión. La Sección 6 deriva la condición de sustitución, un único número que indica cuándo el agente supera al bot. La Sección 7 sigue un caso construido de cuentas por pagar; las Secciones 8 a 11 extraen las consecuencias para cómo se gestiona una función de automatización, responden objeciones, exponen límites y concluyen. La pregunta que recorre todo es: una vez que la automatización puede aprender de su propia ejecución, ¿qué la mantiene aprendiendo lo correcto, y cuándo hace eso obsoleto al bot grabado?

2. Antecedentes

2.1 La RPA y su techo

La RPA se caracterizó en la literatura de sistemas de información como automatización «ligera»: software que opera la capa de presentación de los sistemas existentes en lugar de sus datos o su lógica, de modo que lo despliega el negocio, al margen del proyecto de TI tradicional, contra back ends inalterados (van der Aalst, Bichler & Heinzl, 2018; Hofmann, Samp & Urbach, 2020). La evidencia temprana de casos fue genuinamente positiva en cuanto a coste y rapidez (Lacity & Willcocks, 2016; Willcocks, Lacity & Craig, 2015). La misma literatura, a medida que el campo maduró, nombró el techo. Syed et al. (2020), al revisar el estado de la investigación y la práctica de la RPA, identifican la dependencia de entradas estables y estructuradas y la fragilidad de los bots ante cambios de interfaz y de proceso como temas recurrentes y no resueltos, y sitúan el mantenimiento y la gobernanza entre los retos centrales del campo; Wewerka y Reichert (2023), al mapear el campo de forma sistemática, catalogan el manejo limitado de excepciones y el esfuerzo de mantenimiento entre sus problemas persistentes. El techo no es un defecto de un producto concreto; es intrínseco a automatizar por imitación de la superficie. Un bot codifica cómo una persona competente resultó hacer clic, no qué requiere la tarea, y la brecha entre ambas cosas es exactamente el margen que el entorno tiene para romperlo.

2.2 De la RPA a la automatización inteligente y agéntica

Los profesionales respondieron acoplando inteligencia al bot: reconocimiento óptico de caracteres para leer documentos, un clasificador para ordenarlos, un modelo para manejar la entrada no estructurada que la RPA no podía. Esta automatización inteligente o hiperautomatización amplió el rango de entradas que una canalización podía aceptar, pero dejó intacta la estructura de control, una orquestación fija con componentes más inteligentes conectados en posiciones fijas, y así heredó la misma fragilidad un nivel más arriba. El cambio más reciente es de otra índole. Un agente de IA no ocupa una posición fija en un flujo dibujado a mano; se le da un objetivo y un conjunto de herramientas, y decide los pasos, lo que le permite absorber la variación que habría roto una orquestación fija y, como razona sobre la tarea en lugar de reproducir una grabación, se le puede pedir que explique, compruebe y revise lo que hizo. La literatura sobre agentes en aprendizaje automático aporta la mecánica: intercalar razonamiento con uso de herramientas (Yao et al., 2023), reflexionar sobre intentos fallidos para hacerlo mejor en el siguiente (Shinn et al., 2023), y el estudio más amplio sobre agentes autónomos (Wang et al., 2024). Nuestro interés no es el mecanismo en abstracto, sino una consecuencia para las operaciones: la ejecución de un agente produce evidencia inspeccionable, y la evidencia es lo que un bucle necesita para mejorar.

2.3 La mejora continua es más antigua que la máquina

La idea de que un proceso debe medirse y mejorarse a partir de su propia salida no es una idea de la IA; es el fundamento de la gestión de la calidad del siglo XX, y el artículo se apoya en ella deliberadamente. Shewhart (1931) distinguió la variación inherente a un proceso estable, la causa común, de la variación asignable, la causa especial, que señala que algo ha cambiado, y dio el gráfico de control como el instrumento que las distingue, de modo que uno reaccione a cambios reales y no al ruido, exactamente el modo de fallo de un bucle de aprendizaje no gobernado; el tratamiento estadístico moderno es Montgomery (2024). Deming (1986) construyó el sistema de gestión en torno a ello y popularizó el ciclo Planificar–Hacer–Estudiar–Actuar de mejora iterativa. Six Sigma (Harry & Schroeder, 2000; Pyzdek & Keller, 2023) empaquetó la práctica en DMAIC y la ligó a una tasa de defectos cuantificada; los tratamientos académicos le dan una teoría (Linderman et al., 2003) y un relato franco de su tensión con la innovación (Benner & Tushman, 2003). Una línea está especialmente cerca de este artículo: la operación evolutiva de Box (1957), que gestionaba un proceso de producción como un experimento lento y continuo, ajustando sus parámetros y conservando lo que mejoraba de forma medible el rendimiento, es auto-mejora recursiva bajo control estadístico, décadas antes del término, y es el antepasado correcto de lo que un agente hace ahora a la velocidad del software.

2.4 Retroalimentación, variedad y los límites de una regla fija

La cibernética aporta la razón por la que un bot fijo debe perder frente a un mundo cambiante. La ley de la variedad requerida de Ashby (1956) sostiene que un regulador puede absorber perturbación solo en proporción a la variedad que él mismo puede producir: solo la variedad puede destruir la variedad. Un bot de RPA tiene, por construcción, casi ninguna, una respuesta por cada ruta grabada, de modo que solo puede regular un entorno que nunca abandone esas rutas, y todo entorno real acaba haciéndolo. Un agente gobernado por un bucle de aprendizaje fabrica variedad a demanda, generando una respuesta a un caso para el que no fue construido explícitamente, y por eso puede seguir un objetivo móvil que una regla fija no puede. Wiener (1948) dio el relato fundacional del control por retroalimentación, y la tradición del aprendizaje automático de aprender de una señal de recompensa (Sutton & Barto, 2018) y de las organizaciones que aprenden corrigiendo el error (Argyris & Schön, 1978) son el mismo principio a otras escalas. La contribución aquí es juntar estos dos viejos cuerpos de conocimiento sobre un objeto nuevo: el agente aporta la variedad, y DMAIC aporta el control que mantiene la variedad apuntada hacia el objetivo.

3. Por qué un bot de reglas fijas se degrada

El argumento contra la RPA no es que falle el primer día; es que está construido para ser óptimo el primer día y degradarse cada día posterior. Fija un proceso y despliega un bot que maneja correctamente una parte de sus casos. El entorno entonces se desvía, a cierto ritmo, del estado contra el que se grabó el bot: los formularios cambian, los sistemas se actualizan, llegan nuevas variantes de entradas, las políticas añaden un paso. Cada incremento de desviación convierte algunos casos que el bot solía manejar en casos que ahora maneja mal, de modo que la tasa de error del bot sube aproximadamente en proporción a la desviación acumulada. Entre intervenciones,

donde $\varepsilon_0$ es la tasa de error en el despliegue, $t$ es el tiempo, y $\delta$ es el ritmo de desviación, el paso al que el mundo deja atrás la grabación. Lo único que reduce $\varepsilon^{\mathrm{rpa}}$ es una persona: un ingeniero advierte la avería, vuelve a grabar la ruta y restablece la tasa de error hacia $\varepsilon_0$, con un coste, y hasta la siguiente desviación. El bot traza por tanto un diente de sierra, subiendo con la desviación y cayendo en cada reparación manual, y sin mejorar nunca sobre su diseño original, porque nada en él aprende. Su error medio a lo largo de la vida lo determinan la rapidez con que se mueve el mundo ($\delta$) y la frecuencia con que la organización puede permitirse enviar a alguien a repararlo.

Dos rasgos de este cuadro importan. Primero, el mantenimiento es reactivo e ilimitado: a medida que un parque de bots crece, la desviación que acumulan en conjunto crece con él, de modo que el esfuerzo de mantenimiento aumenta con el número de automatizaciones y no con el trabajo nuevo que se automatiza, que es el mecanismo por el cual el coste operativo de un programa de RPA supera a sus ahorros. Segundo, el fallo suele ser silencioso: un bot que registra un valor del campo equivocado no lanza un error, produce un resultado plausible y erróneo, y el coste de ello está acotado solo por cuánto tiempo pasa inadvertido. Una regla fija en un mundo en movimiento no es meramente limitada; es una carga cuyo tamaño la organización no controla.

4. Automatización recursiva: el bucle que un bot no puede cerrar

Un agente cambia el cuadro porque su ejecución es una fuente de información que puede volverse sobre la propia automatización. Cuando un agente procesa un caso deja un rastro: la entrada que vio, los pasos que eligió, las llamadas a herramientas que hizo, la salida que produjo y, de forma crucial, la señal posterior de si esa salida fue aceptada, corregida o revertida. Ese rastro es evidencia sobre dónde la automatización es fuerte y dónde es débil, y como el comportamiento del agente se expresa en cosas que pueden editarse, sus instrucciones, los ejemplos que se le dan, las herramientas y comprobaciones que debe usar, el enrutamiento de los casos difíciles, esa evidencia puede retroalimentarse como una revisión. La automatización mejora a partir de su propia ejecución. Donde la ecuación (1) solo tiene una mano externa para bajar el error, el bucle recursivo lo baja desde dentro, en cada ciclo:

Aquí $\varepsilon_k$ es la tasa de error después de $k$ ciclos, $g \in (0,1)$ es la ganancia de mejora, la fracción del error remediable que un ciclo elimina, y $\varepsilon_\ast$ es el piso irreducible, el residuo que el proceso no puede desprender porque refleja ambigüedad genuina, información faltante o juicio irreducible, la dificultad esencial y no accidental de la tarea. Iterar la ecuación (2) da la forma cerrada

una caída geométrica desde el error inicial hasta el piso. Esta es la forma que la tradición de la calidad siempre ha buscado y la forma que un bot nunca puede trazar, porque un bot no tiene $g$: su ganancia de mejora es cero, y la ecuación (2) se reduce a una constante interrumpida solo por restablecimientos manuales. La diferencia entre la RPA y la automatización agéntica, en este modelo, es la diferencia entre $g = 0$ y $g > 0$: entre una automatización que solo puede repararse desde fuera y una que se mejora a sí misma desde dentro.

Tres condiciones hacen que $g$ sea positivo y lo mantienen así, y las tres son cosas que la ejecución del agente aporta y la de un bot no. Debe haber una señal: un resultado medible para cada caso, de modo que puedan distinguirse lo mejor y lo peor. Debe haber evidencia atribuible: rastros lo bastante ricos para localizar por qué un caso salió mal, no solo que salió mal. Y debe haber una superficie editable: palancas, instrucciones, prompts, ejemplos, herramientas, enrutamiento, que una revisión pueda efectivamente mover. Un agente produce las tres como subproducto de trabajar; un bot grabado no produce ninguna, que es la razón más profunda por la que no puede aprender. Pero un $g$ positivo no es todavía un $g$ seguro. Un bucle que se revisa a sí mismo contra una señal puede con igual facilidad subir el error que bajarlo, si la señal es ruidosa, la atribución es errónea o el cambio es una regresión. Hacer que $g$ sea fiablemente positivo, ciclo tras ciclo, es el trabajo de la estructura de control, y eso es DMAIC.

5. DMAIC como la estructura de control

La afirmación central del artículo es que la disciplina que convierte un bucle que se mejora a sí mismo de un riesgo en un motor fiable ya existe, plenamente elaborada, en el ciclo DMAIC de Six Sigma, siempre que se lea no como un proyecto de mejora puntual sino como la estructura de control permanente de la automatización, ejecutada de forma continua. Cada fase aporta algo que el bucle recursivo de la Sección 4 necesita para mantener positiva su ganancia y veraz su dirección; la Figura 1 dibuja el ciclo y la Tabla 3 asocia cada fase a su papel.

Definir. El bucle necesita un objetivo que no sea el sustituto que estará tentado de perseguir. Definir enuncia el resultado al que sirve la automatización, las tolerancias que cuentan como éxito y una estimación honesta del piso $\varepsilon_\ast$ por debajo del cual todo esfuerzo adicional es desperdicio, de modo que el bucle optimice el resultado de negocio y no un sustituto cómodo de él. La mayoría de los fallos de retroalimentación descontrolada son fallos de Definir: el bucle mejoró exactamente lo que se le dijo, que era lo que no debía.

Medir. No hay ganancia de mejora sin una señal, y Medir es la fase que la fabrica, instrumentando cada caso para que el resultado, las correcciones y los puntos de duda queden registrados, no muestreados por anécdota. Esta es la forma moderna de la idea de Shewhart de que no se puede mejorar lo que no se mide, y es también donde la minería de procesos (van der Aalst, 2016) gana su lugar, reconstruyendo lo que el proceso realmente hizo a partir de sus propios registros de eventos y no de cómo se imaginó que funcionaba.

Analizar. El error característico de un bucle de aprendizaje es reaccionar al ruido como si fuera señal, reajustándose contra la dispersión normal de un proceso estable y agitándose sin rumbo. Analizar es la salvaguarda: separa la variación de causa común, que debe dejarse en paz, de la variación de causa especial, sobre la que debe actuarse, y atribuye el error accionable a una causa lo bastante específica para corregirla. Esta es la distinción de Shewhart (1931) haciendo exactamente el trabajo para el que se inventó, protegiendo ahora a una automatización de perseguir su propia cola.

Mejorar. Solo ahora se hace un cambio: una revisión de las instrucciones del agente, sus ejemplos, sus herramientas, sus comprobaciones o el enrutamiento que envía una clase de caso difícil a una persona o a una ruta especializada. Mejorar es el paso de mutación del bucle, el lugar donde la ganancia $g$ se realiza efectivamente, y está deliberadamente aguas abajo de la medición y el análisis para que el cambio responda a una causa diagnosticada y no a una corazonada.

Controlar. Controlar es la fase que hace seguro todo el conjunto, y es donde la automatización recursiva difiere más netamente tanto de un bot como de un sistema de aprendizaje no gobernado. Un cambio propuesto no se adopta porque parezca mejor; se adopta solo si se mide, contra casos reservados, que no empeora el resultado, y en caso contrario se rechaza y se conserva la versión anterior. Formalmente, escribiendo $\widehat{\varepsilon}(m)$ para el error medido de una revisión candidata $m$,

donde $\gamma \ge 0$ es un margen de confianza que impide que la compuerta sea engañada por el ruido. La compuerta tiene un efecto preciso sobre el bucle: hace que la secuencia de error sea monótona en esperanza,

de modo que la mejora se acumula y nunca se devuelve. Esto es lo que convierte la recursión en bruto de la ecuación (2) de un paseo aleatorio que podría desviarse a cualquier parte en un trinquete que solo se aprieta, y es la disciplina que el Control Estadístico de Procesos aportó a la manufactura hace un siglo, aplicada ahora a una automatización que se reescribe a sí misma. Controlar hace también la otra mitad, menos vistosa, de su trabajo: estandariza y mantiene la ganancia, fijando en su sitio la versión mejorada con sus salvaguardas para que el siguiente ciclo parta del nuevo piso y no del antiguo.

El emparejamiento es la clave. La recursión sin DMAIC es un bucle que puede mejorar o arruinar con igual facilidad; DMAIC sin recursión es el proyecto de mejora periódico que los equipos de calidad siempre han ejecutado a mano, acotado por la frecuencia con que las personas pueden reunirse. Un agente que ejecuta DMAIC como su propia estructura de control permanente obtiene ambas cosas: la velocidad y el alcance de la mejora por software y la garantía de convergencia del control estadístico.

6. La condición de sustitución

Ahora podemos decir con precisión cuándo el agente supera al bot. Las dos automatizaciones se enfrentan al mismo mundo cambiante, al mismo ritmo de desviación $\delta$. El bot no tiene ganancia interna y, por tanto, según la ecuación (1), su error sube con la desviación hasta que una persona lo restablece. El agente ejecuta su bucle DMAIC con tiempo de ciclo $\tau$, el tiempo para medir, analizar, proponer y filtrar una revisión, y ganancia por ciclo $g$, mientras la misma desviación $\delta$ empuja su error hacia arriba. A lo largo del tiempo continuo, las dos fuerzas se combinan:

un término de aprendizaje que tira del error hacia abajo, hacia el piso, y un término de desviación que lo empuja hacia arriba. Su estado estacionario, donde el bucle mantiene exactamente el paso del mundo, es

de modo que la automatización se mantiene a una distancia acotada por encima del piso, fijada por la razón entre la rapidez con que el mundo se desvía y la rapidez con que el bucle aprende. El bot, con $g \to 0$, no tiene estado estacionario finito en absoluto: su error está acotado solo por el calendario de mantenimiento. Defínase el número de sustitución adimensional

la razón entre el error que un ciclo elimina y el error que la desviación añade a lo largo de ese mismo ciclo. Cuando $\Sigma > 1$ el bucle elimina el error más rápido de lo que el entorno lo inyecta y la automatización converge a una banda estrecha por encima del piso; cuando $\Sigma \gg 1$ se asienta esencialmente en el piso. El agente sustituye al bot precisamente cuando puede ejecutar un bucle gobernado con $\Sigma > 1$, lo cual es una afirmación sobre tres cantidades controlables: eleva la ganancia $g$ con mejor medición y atribución, acorta el ciclo $\tau$ con la automatización del propio bucle, y el agente vence a cualquier bot fijo en cualquier entorno cuya desviación $\delta$ sea finita. La Figura 2 contrasta las dos trayectorias. La lectura práctica es que la sustitución no es cuestión de si el agente es más listo que el bot el primer día, a menudo no lo es, sino de si su bucle gira, bajo control, más rápido de lo que gira el mundo; y una vez que lo hace, el diente de sierra del bot y el descenso del agente divergen para siempre.

7. Un caso construido: cuentas por pagar

El caso es construido, no observado: sus cifras son ilustrativas e internamente consistentes, y pretende mostrar las cantidades del modelo tomando valores plausibles, no reportar un resultado. Considérese la función de cuentas por pagar de un grupo de tamaño medio que recibe facturas de proveedores en muchos formatos a través de varios portales y debe cotejar cada una con una orden de compra y un albarán de recepción, codificarla y registrarla para su pago. Es el objetivo arquetípico de la RPA, de alto volumen, describible por reglas, tedioso, y la decepción arquetípica de la RPA, porque los formatos se desvían constantemente y cada proveedor es una excepción a punto de ocurrir.

El parque de RPA del grupo maneja las maquetaciones de proveedor más limpias y enruta todo lo demás a personas. En el despliegue registraba de forma directa alrededor del 55 por ciento de las facturas, pero a lo largo de dieciocho meses tres actualizaciones de portal y una oleada de nuevos proveedores hicieron bajar la tasa de procesamiento directo y subir la tasa de error silencioso, de modo que un equipo permanente dedica buena parte de su semana a volver a grabar bots rotos y a perseguir registros erróneos; la Tabla 1 da la columna del antes. Reemplazar los bots grabados por un agente que lee cada factura por lo que es, la coteja razonando en lugar de por coordenadas fijas, y enruta las excepciones genuinas a una persona, y envolver ese agente en un bucle DMAIC permanente, la tasa de procesamiento directo es lo que Medir rastrea, las correcciones de cada semana son la evidencia sobre la que trabaja Analizar, los prompts, ejemplos y comprobaciones de cotejo del agente son lo que Mejorar revisa, y una muestra reservada es la compuerta que Controlar aplica, cambia tanto el nivel como su dirección. El agente empieza solo un poco mejor que el bot pero, como su bucle gira más rápido de lo que los portales se desvían ($\Sigma > 1$), su tasa de excepciones cae ciclo a ciclo hacia el piso fijado por las facturas que genuinamente necesitan juicio humano, mientras la carga de mantenimiento se invierte: en lugar de ingenieros reparando grabaciones, el trabajo pasa a ser revisar los cambios propuestos por el bucle en la compuerta de Controlar. La Tabla 1 sigue las cantidades del modelo a través del caso.

8. Qué cambia para el modelo operativo

Sustituir un agente por un bot no es un cambio equivalente de motores bajo el mismo capó; cambia lo que hace la función de automatización y en qué debe ser buena. La Tabla 2 las pone una junto a otra. El mayor cambio es a dónde va el esfuerzo humano. Bajo la RPA el trabajo humano recurrente es reparar: encontrar y volver a grabar los bots que el mundo ha roto, una tarea reactiva que escala con el tamaño del parque y no produce nada nuevo. Bajo un agente gobernado por DMAIC el trabajo humano recurrente es la compuerta de Controlar: revisar las revisiones propuestas por el bucle y decidir qué incorporar, una tarea que escala con el ritmo de mejora y no con el tamaño del parque, y que produce una automatización mejor cada vez que se hace. Las competencias cambian en consecuencia, de programar robots contra pantallas a definir resultados, instrumentar procesos y juzgar evidencia, es decir, de la ingeniería de automatización hacia la disciplina de la gestión de la calidad, llevada a cabo ahora a la velocidad del software.

Hay un segundo cambio, en la gobernanza. Un sistema que reescribe su propio comportamiento es más poderoso que una grabación y exige más rendición de cuentas, no menos, y DMAIC aporta el rastro de auditoría como subproducto: todo cambio incorporado responde a una causa medida, pasó por una compuerta registrada, y puede atribuirse y revertirse, de modo que una automatización que se mejora a sí misma es, bien gestionada, más inspeccionable que el bot opaco al que reemplaza, no menos. La fase de Controlar es tanto un instrumento de cumplimiento como de calidad. Esto importa sobre todo allí donde la automatización toca trabajo regulado, y es la misma disciplina, cambio medido tras una compuerta, que hemos defendido en otra parte de nuestra investigación sobre TI regulada.

9. Objeciones y respuestas

Un agente es mucho más caro por caso que un bot. Por caso, hoy, a menudo sí, y para una tarea estrecha, estable y de alto volumen cuyo entorno genuinamente no se desvía, un bot grabado puede seguir siendo la opción económica, y nada aquí dice lo contrario. El argumento muerde allí donde el entorno se desvía, que es la mayoría de los sitios, porque allí el coste real del bot no es su precio por caso sino su cola de mantenimiento y sus errores silenciosos, y el bucle del agente paga su mayor coste unitario eliminando ambos. La comparación que hay que hacer es el coste a lo largo de la vida frente a un entorno cambiante, no el coste unitario del primer día.

Esto no es más que RPA con un modelo acoplado, que los proveedores ya venden. Es lo contrario. Acoplar un modelo a una orquestación fija, la automatización inteligente tal como se vende habitualmente, conserva la estructura de control frágil y hace sus componentes más inteligentes, de modo que eleva un poco el techo y hereda la degradación. La afirmación aquí es sobre la estructura de control en sí: reemplazar la orquestación fija por un bucle gobernado que reescribe la automatización a partir de su propia salida. El motor es la mitad menor del cambio; el bucle es la mayor.

Un sistema que se mejora a sí mismo y cambia su propio comportamiento es un riesgo que no se puede gobernar. Es un riesgo, y sin gobierno es uno serio, que es toda la razón por la que la segunda piedra angular del artículo es una disciplina de control y no un modelo. Un agente que se reajusta contra una señal ruidosa sin fase de Analizar y sin compuerta de Controlar, en efecto se desviará y retrocederá. La respuesta no es prohibir el bucle, sino gobernarlo con el método que la manufactura ha usado para gobernar procesos autoajustables durante un siglo: medir, separar la señal del ruido, cambiar contra una causa diagnosticada, e incorporar solo lo que una compuerta demuestre que no empeora las cosas. Un bucle gobernado es más responsable que un bot, no menos.

Su modelo es demasiado simple; el error real no cae geométricamente. El modelo es una simplificación deliberada y sus constantes no están medidas; su propósito es hacer legible la estructura, que un bot tiene $g = 0$ y un agente gobernado tiene $g > 0$, y que la sustitución depende de si el bucle le gana a la desviación. La forma geométrica es el comportamiento genérico de un controlador proporcional frente a un piso, no una ley empírica precisa, y la Sección 10 así lo dice. El número de sustitución $\Sigma$ pretende ser una forma de pensar, no una cifra para citar con tres decimales.

10. Limitaciones

Este es un argumento dirigido a profesionales con un modelo deliberadamente simple, y sus límites deberían ser claros. El modelo de las Secciones 3 a 6 es ilustrativo: la desviación lineal de la ecuación (1), la ganancia constante de la ecuación (2) y el piso único $\varepsilon_\ast$ son simplificaciones elegidas por legibilidad, y la desviación real es irregular, la ganancia real disminuye a medida que se acerca el piso, y el propio piso se mueve a medida que la tarea cambia; el número de sustitución $\Sigma$ es una lente, no una cantidad medida, y no lo hemos estimado contra datos de campo. El argumento se circunscribe a procesos que se desvían y que portan una señal de resultado utilizable; una tarea genuinamente estacionaria y de alto volumen puede seguir favoreciendo a un bot grabado, y un proceso sin resultado medible priva al bucle de la señal de la que depende todo el mecanismo. La afirmación es sobre una estructura de control, no un producto, y la tecnología de agentes concreta es temprana y se mueve rápido; un lector debería conservar la estructura, un bucle recursivo gobernado vence a una regla congelada en un mundo en movimiento, y reexaminar los componentes a medida que cambien. Por último, la ganancia es solo tan honesta como las fases de Medir y Controlar: una organización que instrumenta mal, o que deja que la compuerta se degrade en un sello de goma, obtendrá los riesgos de la recursión sin su convergencia, lo cual es una razón para tomarse en serio la disciplina, no un defecto de la idea.

11. Conclusión

La automatización robótica de procesos hizo algo útil al grabar cómo una persona maneja un sistema y reproducirlo, pero automatizó la superficie de una tarea y la congeló, y una regla congelada en un mundo en movimiento se degrada: su error sube con la desviación, su factura de mantenimiento crece con su parque, y sus peores fallos son silenciosos. Los agentes de IA la sustituyen no reproduciendo las mismas reglas con un motor más caro, sino cerrando un bucle que una grabación no puede cerrar, mejorando la automatización a partir de su propia ejecución, ciclo tras ciclo. Esa recursión es la primera piedra angular y, por sí sola, tanto peligro como ayuda. La segunda piedra angular es lo que la hace fiable: el ciclo DMAIC, entendido no como un proyecto puntual sino como la estructura de control permanente de la automatización, Definir el objetivo y el piso, Medir cada caso, Analizar la señal del ruido, Mejorar contra una causa diagnosticada, y Controlar con una compuerta que incorpora solo lo que, de forma medible, no empeora las cosas, de modo que la mejora se vuelve un trinquete y no una apuesta. En el modelo del artículo la diferencia es la diferencia entre una ganancia de mejora de cero y una ganancia mantenida fiablemente positiva, y el agente supera al bot exactamente cuando su bucle gobernado elimina el error más rápido de lo que el mundo lo inyecta. La ingeniería que sigue trata menos del modelo que lee la factura que del bucle construido a su alrededor, y la disciplina que ese bucle necesita es una que la industria ha poseído durante un siglo y ahora puede ejecutar a la velocidad del software. Automatiza la tarea, mide lo que ocurre, mejora contra lo que mides, y no dejes que nada cambie la automatización que una compuerta no haya demostrado ser mejor. Un bot es una fotografía de un proceso; un agente gobernado es el proceso aprendiendo. Esa es la sustitución, y es toda ella.

Apéndice A. Ejecutar DMAIC como el bucle de control de una automatización

Las prácticas siguientes son lo que mantiene una automatización recursiva convergiendo en lugar de desviándose. Ninguna es novedosa para la IA; cada una es la tradición de la calidad aplicada a una automatización que se reescribe a sí misma.

Referencias

Argyris, C., & Schön, D. A. (1978). Organizational learning: A theory of action perspective. Addison-Wesley. ISBN 978-0-201-00174-3.

Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall. http://pcp.vub.ac.be/books/IntroCyb.pdf

Benner, M. J., & Tushman, M. L. (2003). Exploitation, exploration, and process management: The productivity dilemma revisited. Academy of Management Review, 28(2), 238–256. https://doi.org/10.2307/30040711

Box, G. E. P. (1957). Evolutionary operation: A method for increasing industrial productivity. Journal of the Royal Statistical Society: Series C (Applied Statistics), 6(2), 81–101. https://doi.org/10.2307/2985505

Deming, W. E. (1986). Out of the crisis. MIT Center for Advanced Engineering Study. ISBN 978-0-911379-01-0.

Harry, M. J., & Schroeder, R. (2000). Six Sigma: The breakthrough management strategy revolutionizing the world’s top corporations. Currency/Doubleday. ISBN 978-0-385-49437-3.

Hofmann, P., Samp, C., & Urbach, N. (2020). Robotic process automation. Electronic Markets, 30(1), 99–106. https://doi.org/10.1007/s12525-019-00365-8

Lacity, M., & Willcocks, L. P. (2016). Robotic process automation at Telefónica O2. MIS Quarterly Executive, 15(1), 21–35. https://aisel.aisnet.org/misqe/vol15/iss1/4/

Linderman, K., Schroeder, R. G., Zaheer, S., & Choo, A. S. (2003). Six Sigma: A goal-theoretic perspective. Journal of Operations Management, 21(2), 193–203. https://doi.org/10.1016/S0272-6963(02)00087-6

Montgomery, D. C. (2024). Introduction to statistical quality control (8th ed.). Wiley. ISBN 978-1-119-72309-7.

Pyzdek, T., & Keller, P. A. (2023). The Six Sigma handbook (6th ed.). McGraw-Hill. ISBN 978-1-26-514399-2.

Shewhart, W. A. (1931). Economic control of quality of manufactured product. D. Van Nostrand. ISBN 978-0-87389-076-2 (ASQ reprint).

Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023). https://arxiv.org/abs/2303.11366

Sutton, R. S., & Barto, A. G. (2018). Reinforcement learning: An introduction (2nd ed.). MIT Press. ISBN 978-0-262-03924-6.

Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T., & Reijers, H. A. (2020). Robotic process automation: Contemporary themes and challenges. Computers in Industry, 115, 103162. https://doi.org/10.1016/j.compind.2019.103162

van der Aalst, W. M. P. (2016). Process mining: Data science in action (2nd ed.). Springer. https://doi.org/10.1007/978-3-662-49851-4

van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269–272. https://doi.org/10.1007/s12599-018-0542-4

Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., Zhao, W. X., Wei, Z., & Wen, J.-R. (2024). A survey on large language model based autonomous agents. Frontiers of Computer Science, 18(6), 186345. https://doi.org/10.1007/s11704-024-40231-1

Wewerka, J., & Reichert, M. (2023). Robotic process automation: A systematic mapping study and classification framework. Enterprise Information Systems, 17(2), 1986862. https://doi.org/10.1080/17517575.2021.1986862

Wiener, N. (1948). Cybernetics: Or control and communication in the animal and the machine. MIT Press. ISBN 978-0-262-73009-9.

Willcocks, L. P., Lacity, M., & Craig, A. (2015). The IT function and robotic process automation (The Outsourcing Unit Working Research Paper Series). London School of Economics and Political Science, LSE Research Online item 64519. http://eprints.lse.ac.uk/64519/

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR 2023). https://arxiv.org/abs/2210.03629