Resumen
La automatización suele medirse por el trabajo visible que consigue retirar de una operación: menos pasos manuales, menos tiempos de espera, menos intervención humana. Esa contabilidad es útil, pero deja fuera una parte decisiva del problema. Cuando una organización automatiza un proceso durante años, no solo cambia quién lo ejecuta; cambia también quién conserva el conocimiento necesario para comprenderlo cuando deja de comportarse como se esperaba. Este ensayo sitúa esa pérdida de continuidad entre ejecución y comprensión en una tradición que va desde las ironías de la automatización de Lisanne Bainbridge y el problema out-of-the-loop de Endsley y Kiris hasta trabajos recientes sobre supervisión humana significativa, deuda cognitiva e intent debt. Sobre ese marco se emplean dos formulaciones propias del ensayo —la paradoja de la excepción y la continuidad de contexto— como instrumentos para analizar qué sucede cuando los casos normales desaparecen de la experiencia humana y la responsabilidad permanece. La discusión parte de una escena ficticia técnicamente verosímil y recorre desde los triggers de bases de datos hasta las arquitecturas actuales basadas en agentes de inteligencia artificial. La tesis no cuestiona la conveniencia de automatizar; cuestiona que baste con conservar a una persona formalmente dentro del circuito si esa persona ya no dispone del contexto que hace posible una supervisión real.
El lunes en el que todo estaba en “verde”
A las 9:17 de un lunes cualquiera, Marta abrió el panel de seguimiento y tardó unos segundos en comprender que aquello no era un error de pantalla: trescientos ochenta y seis expedientes aparecían en un estado que no les correspondía. No estaban bloqueados ni incompletos, sino que figuraban como tramitados. El detalle resultaba todavía más desconcertante porque el proceso nocturno, responsable de actualizar miles de registros durante la madrugada, había terminado a las 4:06 con un impecable «OK». El planificador estaba en verde, la base de datos respondía con normalidad y la consola de integración no mostraba ninguna alarma. Técnicamente, la noche había sido perfecta.
Marta era analista funcional y conocía el procedimiento mejor que nadie desde el punto de vista de negocio. Por eso no necesitó mucho tiempo para saber que los datos estaban mal; lo que no sabía era cómo habían llegado hasta allí. Escribió un mensaje en el canal del proyecto, adjuntó una captura y telefoneó a Javier, el responsable técnico. Dos minutos después la conversación había dejado de parecer una consulta rutinaria. La pregunta que terminó de cambiar el tono de la mañana no fue quién había cometido el error, sino otra bastante más incómoda: «¿Esto se puede deshacer?».
Durante la primera media hora nadie tuvo una respuesta completa. El proceso nocturno ejecutaba un paquete de base de datos que seleccionaba los expedientes considerados aptos para avanzar de estado. El paquete no mostraba errores y, repetido sobre los datos de prueba, se comportaba como debía. Después apareció la primera pista: al actualizar la tabla principal, un trigger AFTER UPDATE insertaba ciertos cambios de estado en una cola de integración. Un servicio independiente consumía aquella cola, enviaba el evento a un sistema externo y confirmaba su recepción. Una vez aceptado el mensaje por el sistema de destino, corregir el registro de origen ya no bastaba; había acciones fuera de la transacción inicial que no podían deshacerse con un simple rollback.
A las 10:03 el equipo ya tenía localizada la cadena técnica. Lo difícil seguía siendo entender la razón. Una condición dentro de un procedimiento clasificaba como válidos unos expedientes que, según el nuevo criterio de negocio, debían haberse detenido. La línea de código llevaba allí años. Git permitió saber cuándo apareció; el gestor de incidencias conservaba el ticket asociado y hasta el nombre de quienes participaron en el cambio. En el ticket se hablaba de una excepción introducida para resolver una campaña concreta, pero no constaba, sin embargo, si aquella excepción debía ser temporal, qué supuesto exacto la justificaba ni qué otro componente del sistema dependía de ella. La automatización había conservado con una fidelidad extraordinaria una decisión que la organización ya no recordaba del todo, porque la persona que la implementó había abandonado la empresa unos meses antes.
La escena es ficticia, pero no especialmente exótica. Cualquiera que haya trabajado durante años con sistemas empresariales reconocerá sus ingredientes: procesos que funcionan durante tanto tiempo que dejan de llamar la atención; personas que cambian de proyecto; documentación que explica cómo operar un mecanismo y dice mucho menos acerca de por qué se diseñó de ese modo; reglas de negocio que nacieron como excepción y acabaron sedimentadas en la arquitectura. El incidente no interesa porque una automatización haya fallado; interesa porque, hasta esa mañana, había funcionado —tal vez— demasiado bien.
Lo que estaba empezando a romperse no era la capacidad de ejecutar el proceso. Esa permanecía intacta y, de hecho, superaba con mucho lo que podría hacer un equipo humano. Lo que se había ido erosionando era otra cosa: la continuidad entre el comportamiento del sistema y la memoria de quienes debían responder por él. Ese desplazamiento —silencioso mientras todo va bien y costoso cuando aparece una anomalía— es el hilo que recorre este ensayo.
El sistema seguía sabiendo hacer su trabajo. La organización empezaba a olvidar por qué lo hacía de esa manera.
Lo que realmente automatizamos
Una parte del entusiasmo contemporáneo por la inteligencia artificial parte de una intuición razonable. Si un trabajo se desarrolla íntegramente delante de una pantalla, sus herramientas, entradas y resultados ya se encuentran en un espacio que el software puede habitar. Un modelo puede leer documentos, consultar bases de datos, escribir código, invocar APIs, clasificar expedientes o redactar un informe sin abandonar el entorno digital. Desde esa perspectiva, parece lógico suponer que las ocupaciones de oficina —y en particular las de naturaleza técnica— serán más fáciles de sustituir que aquellas que exigen actuar físicamente sobre el mundo.
El razonamiento deja de ser tan limpio cuando abandonamos la tarea individual y observamos el sistema que la rodea. Procesar un documento es una tarea; decidir qué hacer cuando dos fuentes ofrecen datos incompatibles pertenece ya al proceso. Determinar qué efectos puede producir una decisión, qué permisos son aceptables, qué excepciones merecen escalarse y qué consecuencias deben poder revertirse pertenece al sistema, y cuando ese sistema produce un resultado que afecta a terceros, aparece todavía otra dimensión que no desaparece porque el código se haya escrito solo: alguien deberá poder explicarlo, corregirlo o asumirlo.
Que un agente pueda escribir código, elegir una herramienta o proponer un plan no hace desaparecer esa capa de decisiones. En un proyecto real siempre queda alguien —una persona, un equipo o la propia organización— que acepta que el sistema actúe sobre determinados datos, con determinados permisos y hasta determinado límite. Esa responsabilidad suele hacerse visible justo donde termina la demostración brillante y empieza la explotación diaria: cuando cambia una regla, falla una integración, un permiso resulta excesivo o hay que decidir si una acción puede ejecutarse sin revisión. En estos y otros casos la IA puede abaratar mucho la construcción; no vuelve innecesarias esas decisiones.
Por eso medir el efecto de la automatización únicamente por el número de pasos manuales eliminados puede resultar engañoso. Es una métrica razonable para estimar eficiencia, pero pobre para estimar comprensión. La pregunta interesante no es solo cuántas operaciones ha dejado de realizar una persona, sino cuánto conocimiento sigue siendo accesible cuando esas operaciones ya no forman parte de la experiencia cotidiana del equipo.
La «paradoja de la excepción»
En 1983, Lisanne Bainbridge publicó un artículo que continúa pareciendo vigente, más de cuatro décadas después, cada vez que una nueva oleada tecnológica promete retirar al ser humano del «trabajo». En Ironies of Automation observó que los sistemas automáticos tendían a quedarse con el funcionamiento normal mientras reservaban a las personas las situaciones anómalas. La ironía era evidente: cuanto menos participaba el operador en el día a día, más difícil podía resultarle intervenir precisamente cuando el sistema abandonaba su comportamiento habitual.[1]
A mediados de los noventa, Mica Endsley y Esin Kiris estudiaron experimentalmente el llamado out-of-the-loop performance problem. El problema no era una supuesta incapacidad general de los operadores, sino algo más concreto: la pérdida de conciencia situacional y el aumento del tiempo necesario para recuperar el control después de haber pasado de una participación activa a una supervisión más pasiva.[2] Parasuraman y Riley ampliaron después el mapa de dificultades al analizar el uso, mal uso, desuso y abuso de la automatización, incluida la sobreconfianza en sistemas que suelen comportarse correctamente.[3]
La inteligencia artificial no invalida aquellas observaciones; las traslada a un terreno más amplio. Pensemos en un equipo que gestiona cien casos diarios: ochenta responden a patrones previsibles y veinte requieren criterio, negociación o diagnóstico. Si automatizamos los ochenta primeros, el balance empresarial es magnífico: se ha retirado de la intervención humana el ochenta por ciento del volumen. Para la persona que sigue dentro del proceso, sin embargo, el reparto se ha invertido, pues casi todo lo que llega hasta ella pertenece ahora al grupo difícil.
A esta inversión la llamaré aquí, sin pretensión de acuñar un término académico, la paradoja de la excepción. Automatizar la normalidad reduce la cantidad de intervención humana, pero aumenta la proporción de anomalías dentro del trabajo que permanece. Y las anomalías llegan acompañadas de una dificultad adicional: ocurren poco. El profesional que antes recorría cada día las rutas ordinarias del sistema deja de verlas, de reconocer pequeñas desviaciones y de mantener fresco un conocimiento que muchas veces nunca estuvo completamente escrito.
No presento la paradoja de la excepción como un fenómeno distinto de esa tradición, sino como una forma de condensarla y trasladarla al trabajo digital actual. Bainbridge mostró la ironía de reservar al operador las condiciones anómalas después de automatizar la normalidad; Endsley y Kiris describieron qué puede ocurrir cuando ese operador pierde conciencia situacional al quedar fuera de la práctica cotidiana. La paradoja nombra aquí el resultado organizativo de ambas cosas: cada avance en la automatización de lo rutinario eleva el peso relativo de lo excepcional dentro del trabajo humano que permanece.
En ese sentido, la rutina tenía una función que rara vez aparecía en los cuadros de productividad: mantenía entrenada la comprensión. Quien procesaba casos normales veía cómo evolucionaban los datos, conocía la secuencia de estados, reconocía una salida extraña antes de que se convirtiera en un problema y aprendía, casi sin proponérselo, qué partes del procedimiento merecían desconfianza. La automatización elimina con razón buena parte de ese trabajo mecánico, pero puede llevarse con él una porción del mecanismo informal mediante el que una organización conservaba su conocimiento operativo.
Human in the Loop, Out of Context
De ahí que la expresión Human in the Loop me resulte cada vez menos tranquilizadora cuando se utiliza como garantía en sí misma. Saber que existe una persona en algún punto del circuito dice poco sobre la calidad de su intervención. Puede haber un revisor obligado a aprobar una decisión y, al mismo tiempo, desconocer de dónde proceden los datos, qué transformaciones han sufrido, qué herramientas se han invocado antes de que el resultado llegue a su pantalla o qué acciones han sido ejecutadas ya de manera irreversible.
El NIST —el Instituto Nacional de Estándares y Tecnología de Estados Unidos— aborda este problema en su marco de gestión de riesgos para inteligencia artificial al señalar que las responsabilidades humanas y los mecanismos de supervisión deben definirse y documentarse expresamente.[5] En 2026, Liming Zhu y sus coautores propusieron una distinción especialmente útil para este debate: la IA puede conservar agencia operativa —capacidad para ejecutar y orientar una tarea— mientras la persona debe conservar agencia evaluativa, es decir, capacidad real para comprender, verificar, redirigir o sustituir la solución propuesta.[8] La presencia humana, por sí sola, no garantiza esa segunda capacidad.
La preocupación por esa asimetría es anterior a los agentes generativos. Madeleine Clare Elish introdujo el concepto de moral crumple zone —«zona moral de deformación»— para describir situaciones en las que el ser humano termina absorbiendo la responsabilidad moral o jurídica por el fallo de un sistema automatizado aunque su control efectivo sobre ese sistema fuese limitado.[10] La imagen resulta incómoda precisamente porque invierte la promesa habitual del Human in the Loop: la persona puede permanecer cerca de la responsabilidad y, al mismo tiempo, lejos de la capacidad real de intervenir.
El debate ha dado un paso más en 2026. En un artículo de posición (position paper) todavía reciente, Margaret Mitchell, Avijit Ghosh y Samir Passi sostienen que determinados diseños de agentes no solo dificultan la supervisión humana, sino que pueden degradar con el uso las propias capacidades cognitivas que esa supervisión necesita: criterio, conocimiento operativo y habilidad para detectar que algo se está desviando.[11] La idea enlaza de forma casi directa con Bainbridge y Endsley, pero trasladada a sistemas que ya no se limitan a ejecutar una secuencia fija.
En ese punto se sitúa el título Human in the Loop, Out of Context. No pretende proponer una nueva categoría cerrada, sino llamar la atención sobre una contradicción concreta: podemos conservar a una persona en el diagrama, incluso atribuirle responsabilidad formal sobre la decisión, y haberla alejado al mismo tiempo de la historia que permite juzgarla. El humano sigue dentro del circuito, pero recibe el último fotograma de una película que no ha visto.
Eso no exige convertir al supervisor en autor del sistema. Es decir, no necesita conocer cada línea de código ni los detalles internos de un modelo de lenguaje; necesita algo mucho más práctico: poder averiguar de dónde sale el resultado que tiene delante y qué margen conserva para actuar. Si debe aprobar una decisión, debería poder reconstruir los datos utilizados, los pasos relevantes que ocurrieron antes, qué parte del recorrido fue automática y qué efectos ya se han producido fuera de su alcance. Sin esa información, su firma puede seguir siendo obligatoria, pero su capacidad de control se parece poco a una supervisión real.
No basta con mantener al humano dentro del circuito. Hay que conservar también el contexto que hace útil su presencia.
Las deudas que no aparecen en el balance: automatización, cognición e intención
La ingeniería de software lleva décadas hablando de deuda técnica: decisiones que permiten avanzar hoy a cambio de encarecer el cambio de mañana. Con las automatizaciones empieza a ocurrir algo parecido, aunque el pasivo no siempre reside en la calidad del código. Workflows, scripts, robots, integraciones y agentes pueden crecer más deprisa que la capacidad de una organización para inventariarlos, probarlos, documentarlos y saber quién responde por ellos. En el vocabulario profesional reciente ha empezado a aparecer para este fenómeno la expresión automation debt o deuda de automatización.[9]
La metáfora es útil porque recuerda que el coste no tiene por qué manifestarse inmediatamente. Una automatización puede ser barata de crear y muy cara de abandonar. Puede comenzar como una solución menor, acumular excepciones, convertirse en una dependencia crítica y llegar a un punto en el que nadie se atreve a tocarla sin antes localizar a la persona que «sabe cómo funciona». El pasivo se descubre tarde, generalmente cuando hay que modificar, auditar o recuperar aquello que llevaba años trabajando en silencio.
A esa deuda operativa se superpone otra más difícil de ver. Margaret-Anne Storey acaba de proponer en 2026 un modelo que, junto a la deuda técnica, distingue la deuda cognitiva y la intent debt.[6] La primera aparece cuando se erosiona el entendimiento compartido del sistema; la segunda, que podríamos traducir como deuda de intención, cuando dejan de estar bien externalizados los objetivos, restricciones y razones que explican por qué se diseñó de determinada manera. Thoughtworks ha incorporado también la noción de codebase cognitive debt para describir la brecha entre una implementación que cambia cada vez más rápido y la comprensión colectiva que el equipo conserva de ella.[7]
Volvamos por un momento a las 10:03 del lunes, en la narrativa del principio: el equipo ya había encontrado la condición que permitía avanzar a los expedientes, y eso resolvía una parte del misterio, pero no la más incómoda. Saber qué sentencia se ejecutó no explicaba por qué aquella sentencia existía.
Ahí la distinción de Storey resulta especialmente útil. La deuda cognitiva aparece cuando se erosiona la comprensión compartida de cómo funciona el sistema; la deuda de intención, cuando los objetivos, límites y razones que guiaron su diseño dejan de estar disponibles de forma clara. Storey formula ese modelo pensando en la salud del software en la era de la IA.[6] En este ensayo propongo leer el mismo problema a escala del proceso automatizado: no solo importa que alguien pueda entender el código, sino que la organización conserve el razonamiento que explica por qué el proceso toma determinadas decisiones. Mientras todo sigue funcionando, esa pérdida puede pasar inadvertida durante años; se vuelve visible cuando cambia una norma, llega una auditoría o aparece una excepción y alguien necesita responder algo mejor que «siempre se ha hecho así».
Los triggers los carga el diablo
Hace años escuché por primera vez aquello de que «los triggers los carga el diablo». No recuerdo quién me lo dijo y sospecho que tampoco aquella persona era la autora de la frase... Desde entonces la he oído muchas veces, casi siempre después de dedicar más tiempo del razonable a descubrir por qué una operación aparentemente sencilla había provocado algo que nadie esperaba.
La sentencia es injusta con los triggers. Un trigger bien utilizado puede proteger una auditoría o reaccionar de forma muy eficaz ante un cambio de estado. El problema aparece cuando una parte importante de la lógica queda repartida entre efectos secundarios que no son visibles desde el punto donde comienza la operación. Un desarrollador ejecuta un UPDATE; el cambio activa un trigger; el trigger inserta un registro en otra tabla; un proceso detecta esa inserción y llama a un servicio; el servicio modifica un estado en otro sistema… Cada pieza, observada por separado, puede ser razonable.
Ese tipo de depuración enseña una lección que conviene recordar ahora: los sistemas no se vuelven difíciles de comprender únicamente porque contengan algoritmos sofisticados, también pueden volverse opacos por acumulación de causalidad distribuida. En esos casos, saber leer el código no basta; hay que saber perseguir acontecimientos.
El incidente que narrábamos al comienzo resume bien el problema: el paquete nocturno solo actualizó un estado; el trigger convirtió ese cambio en un evento y otros componentes llevaron la consecuencia fuera de la base de datos. Cuando apareció la condición discutible, ya no bastaba con mirar la sentencia original; había que reconstruir la cadena.
Por eso los triggers funcionan tan bien como precedente de lo que ahora empezamos a construir con agentes. Llevamos décadas comprobando que una arquitectura puede ser determinista y, aun así, resultar hostil para quien intenta explicar por qué ocurrió algo. La inteligencia artificial no inventa esa dificultad; añade —acaso— nuevas formas de ampliarla.
Cuando la causalidad aprende a hablar
Imaginemos una versión contemporánea de la misma cadena: un documento llega a un buzón; un evento activa un workflow; el workflow entrega el contenido a un agente que lo clasifica mediante un modelo de lenguaje; el agente consulta una base documental, decide que necesita un dato adicional, invoca una API, actualiza un registro y genera una instrucción para un segundo agente; este último ejecuta una acción sobre otro sistema… Para el usuario final, quizá todo se resume en una frase tan inocente como «el expediente ha sido tramitado».
La semejanza con la cascada de triggers es evidente, pero hay una diferencia que no conviene minimizar: en buena parte de la automatización clásica podíamos, con suficiente paciencia, reproducir el camino de ejecución línea por línea; en una arquitectura agéntica intervienen además modelos probabilísticos, contexto recuperado en tiempo de ejecución, prompts, herramientas externas y estados que pueden variar entre una llamada y la siguiente.
La observabilidad tiene entonces que contar una historia, no limitarse a confirmar que un componente terminó sin error. Necesitamos conservar la procedencia de los datos, las versiones relevantes, las herramientas invocadas, las decisiones intermedias y los efectos producidos fuera del alcance inmediato del agente. También necesitamos distinguir qué parte de la cadena responde a una regla determinista y cuál depende de una inferencia que podría haber producido otra salida bajo un contexto distinto. Cuanta más inteligencia trasladamos al background, más importante resulta hacer visible su causalidad.
La disciplina de Site Reliability Engineering —SRE, el enfoque de ingeniería de fiabilidad de servicios popularizado por Google— lleva años insistiendo en que la automatización es un multiplicador, no una garantía de acierto. Puede escalar una buena práctica y puede escalar un defecto con idéntica eficacia.[4] La advertencia adquiere una dimensión especial cuando el sistema no solo ejecuta instrucciones, sino que selecciona herramientas, interpreta información y decide qué camino seguir, como el caso de la IA agéntica.
La velocidad, en ese escenario, es ambivalente: un operador puede equivocarse en un expediente y advertir una anomalía antes del siguiente; un proceso nocturno puede modificar miles de registros antes de que alguien abra el correo; un agente con permisos de escritura puede encadenar varias acciones correctas según su propio contexto y, sin embargo, producir en segundos un resultado global que nadie había previsto. Automatizar no exige desconfiar de la máquina, pero exige diseñar sabiendo que los errores también pueden viajar a velocidad de máquina.
Automatizar sin perder la memoria: continuidad de contexto
La respuesta a estos problemas no puede ser automatizar menos por principio, pues sería difícil defenderlo después de décadas en las que la automatización ha eliminado trabajo repetitivo, reducido errores y permitido operar sistemas que serían inviables de forma manual. La cuestión es otra: cómo automatizar sin destruir, al mismo tiempo, las condiciones que permitirán comprender el sistema cuando cambie el contexto.
En esa tarea hay propiedades conocidas —observabilidad, trazabilidad, reversibilidad y responsabilidad— y otras a las que quizá prestamos menos atención. La observabilidad permite saber qué está ocurriendo; la trazabilidad reconstruye de dónde viene cada efecto; la reversibilidad obliga a pensar antes de automatizar qué puede deshacerse y qué se convierte en irreversible en cuanto cruza el límite de otro sistema; la responsabilidad determina quién tiene autoridad para detener, corregir o asumir una decisión.
Añadiría una quinta propiedad, que en este ensayo llamaré «continuidad de contexto». No la propongo como una categoría consolidada, sino como un criterio de diseño que reúne una preocupación repetida en los trabajos anteriores: que la persona responsable pueda conservar o recuperar la historia necesaria para comprender el sistema. No se trata de producir más documentación por obligación ni de llenar repositorios de manuales que nadie consulta. Se trata de preservar, de forma utilizable, las razones: qué hipótesis se daban por ciertas, qué excepción motivó una regla, qué riesgos se aceptaron, qué decisiones se consideraron temporales y qué componentes se diseñaron contando con ellas.
Esta idea tiene una consecuencia práctica. Ante una acción automatizada relevante, una organización debería poder contestar algo más que «qué proceso la ejecutó». Debería saber qué la inició, con qué datos, bajo qué criterios, qué versión estaba activa, qué componentes tomaron decisiones y qué efectos salieron ya del ámbito reversible. Y debería poder hacerlo sin depender de que siga disponible la única persona que estuvo presente cuando se diseñó la solución.
Esa prueba no convierte la automatización en burocracia; al contrario, permite que la autonomía crezca sin que la comprensión retroceda al mismo ritmo. Si la única estrategia de recuperación consiste en llamar a quien construyó el sistema hace cinco años, no tenemos resiliencia; tenemos memoria externalizada en una persona.
El trabajo que queda
Todo esto devuelve la discusión al punto de partida: qué ocurrirá con los trabajos que hoy realizamos delante de un ordenador. Parece difícil imaginar que la generación de código repetitivo, determinadas pruebas, la clasificación documental, la preparación de informes o muchas transformaciones rutinarias de datos conserven exactamente el mismo peso profesional que tenían antes de la expansión de la inteligencia artificial. Negarlo sería confundir la defensa de una profesión con la defensa de cada una de sus tareas históricas.
Pero también conviene desconfiar del razonamiento inverso: si una máquina puede producir código, entonces comprender sistemas perderá valor… o puede suceder justamente lo contrario: si crear software cuesta menos, tendremos más software; si automatizar procesos resulta más barato, proliferarán las automatizaciones; si conectar agentes con APIs, bases de datos y herramientas empresariales se vuelve trivial, aumentará el número de relaciones y efectos que alguien tendrá que gobernar. La abundancia de construcción puede convertir la comprensión, y no la producción, en el recurso escaso.
Esto debería influir en la formación técnica. Aprender programación no pierde sentido porque una máquina sea capaz de escribir código, del mismo modo que aprender bases de datos no perdió sentido cuando los ORM ocultaron buena parte del SQL cotidiano. Cambia el centro de gravedad, porque aunque memorizar sintaxis importe ya menos que comprender transacciones, consistencia, concurrencia, seguridad, rendimiento, integración o arquitectura, saber formular una hipótesis cuando un sistema deja de comportarse como debería puede valer más que producir con rapidez una solución que nadie sabrá explicar dentro de dos años.
El desplazamiento puede ser incluso intelectualmente exigente para quienes permanezcan «dentro del circuito». Cuanto mayor sea la proporción de normalidad absorbida por la automatización, mayor será la proporción de su trabajo dedicada a excepciones, decisiones ambiguas y fallos que atraviesan varias capas. Preparar a las personas únicamente para ejecutar procedimientos equivale, en ese contexto, a formarlas para la parte del trabajo que más fácilmente podrá desaparecer.
Volver a las 9:17
Pasado el mediodía, el equipo de Marta consiguió reconstruir la secuencia completa. La regla que había abierto el camino a los expedientes no era absurda: años atrás resolvía un problema real, cuando durante una campaña concreta ciertos registros llegaban con un dato incompleto y era necesario permitir que avanzasen si cumplían otras condiciones. La excepción se añadió, se probó, funcionó y quedó incorporada al proceso; nadie pudo determinar después en qué momento dejó de ser temporal. El trigger tampoco había hecho nada inesperado: reaccionó exactamente al cambio para el que fue diseñado, el servicio de integración consumió la cola y el sistema externo aceptó el mensaje. Cada componente había cumplido su contrato. El incidente no podía atribuirse cómodamente a una pieza defectuosa; el problema estaba en otro lugar: la intención original se había ido separando de la arquitectura que todavía la ejecutaba.
Es difícil imaginar una metáfora mejor de la deuda cognitiva. El sistema no había olvidado nada. Había sido la organización quien había olvidado.
Con agentes de inteligencia artificial, esa distancia puede crecer sin necesidad de que nadie tome una decisión irresponsable: basta con que aumenten la velocidad de cambio, el número de automatizaciones, las dependencias y las capas que median entre una acción y su consecuencia. La paradoja de la excepción, la pérdida de conciencia situacional descrita por Endsley, la zona moral de deformación de Elish y las deudas cognitiva y de intención de Storey apuntan, desde ángulos distintos, al mismo problema de fondo: conservar responsabilidad humana resulta insuficiente si no conservamos también las condiciones que permiten ejercerla con conocimiento.
Por eso el debate sobre automatización no debería agotarse en calcular qué porcentaje de tareas puede asumir una máquina. Esa pregunta seguirá siendo importante para la economía, para las empresas y para quienes intentamos anticipar cómo cambiarán nuestras profesiones, pero, desde la arquitectura y desde la experiencia de quienes tendrán que mantener esos sistemas cuando algo se tuerza, aparece otra pregunta quizá menos espectacular y bastante más incómoda:
El verdadero problema no será decidir cuánto podemos automatizar. Será decidir cuánto podemos automatizar sin perder la capacidad humana de comprender aquello que hemos automatizado.