Economía de la verificación

Un sistema que ejecuta trabajo por delegación tiene un problema que no es de ingeniería sino de incentivos: la persona que delegó dejará de mirar. No porque sea negligente ni porque la interfaz esté mal dibujada, sino porque mirar cuesta y no mirar sale gratis casi siempre. Cualquier diseño de supervisión que suponga lo contrario está diseñando para un usuario que no existe. Este ensayo trata de qué se sigue de aceptarlo, y de en qué puntos concretos el código de ALLAN hace hoy lo contrario de lo que su propio diseño pedía.

El coste de observar es el problema, no un detalle del problema

La formulación canónica es de Bengt Holmström y conviene leerla sin adaptar. El riesgo moral, escribe, aparece «when individuals engage in risk sharing under conditions such that their privately taken actions affect the probability distribution of the outcome». La causa está en la información: «The source of this moral hazard or incentive problem is an asymmetry of information among individuals that results because individual actions cannot be observed and hence contracted upon». El remedio obvio es vigilar —«A natural remedy to the problem is to invest resources into monitoring of actions and use this information in the contract»— y tropieza inmediatamente con la frase que gobierna todo lo que sigue: «Generally, however, full observation of actions is either impossible or prohibitively costly».

Un agente de software no tiene intereses propios que ocultar, y por eso la analogía con el empleado deshonesto sería mala. Lo que se conserva no es el conflicto de incentivos sino la estructura de información: las acciones del ejecutor no son observables sin coste, quien delegó paga ese coste íntegro, y el resultado que sí observa es una señal ruidosa de lo que ocurrió. Que el agente no mienta a propósito sólo cambia de qué hay que protegerse: ya no de un incentivo desalineado sino de un modo de fallo particular —el modelo contesta algo arbitrario y plausible en lugar de detenerse— y de la tentación, muy humana, de no comprobarlo.

Holmström añade después el criterio que debería gobernar el diseño de cualquier compuerta, y que es el resultado principal de su artículo. Precisa primero qué es una señal que vale algo: «A signal y is said to be valuable if both the principal and the agent can be made strictly better off with a contract of the form s(x,y) than they are with a contract of the form s(x)». Y luego explica cuándo no vale nada: cuando el resultado ya es estadístico suficiente, es decir, cuando «x carries all the relevant information about a, and y adds nothing to the power of inference». La proposición 3 lo cierra en cinco palabras: «a signal is valuable if and only if it is informative».

Traducido a compuertas, esto da un criterio de admisión falsable. Una compuerta vale lo que aporte sobre lo que el agente está haciendo más allá de lo que el resultado revelará por sí solo. La que se dispara donde la persona no puede aprender nada que no fuera a saber igualmente no es supervisión: es coste, y como el presupuesto de atención es finito, se paga con las compuertas que sí informaban. ALLAN no tiene hoy ningún criterio de este tipo: cualquier capacidad concedida puede llevar compuerta, y nada distingue la que informa de la que sólo interrumpe.

Verificar cuesta más que aceptar, y eso decide el comportamiento

La versión empírica moderna del mismo argumento está en Vasconcelos y otros. Su tesis es que la sobre-dependencia no es un defecto cognitivo inevitable sino una elección: «our paper argues that people strategically choose whether or not to engage with an AI explanation». La formalizan como lo que es, un cálculo: «we formalize this strategic choice in a cost-benefit framework, where the costs and benefits of engaging with the task are weighed against the costs and benefits of relying on the AI». Y su conclusión sobre por qué tantas explicaciones no sirven de nada es la frase operativa para cualquier interfaz de aprobación: «some of the null effects found in literature could be due in part to the explanation not sufficiently reducing the costs of verifying the AI's prediction».

Bainbridge había registrado el caso peor cuarenta años antes: «Ephrath (1980) has reported a study in which system performance was worse with computer aiding, because the operator made the decisions anyway, and checking the computer added to his workload». Cuando comprobar cuesta más que decidir, el humano decide y además paga la comprobación: hay un punto en el que añadir supervisión empeora el sistema.

De ahí la regla que ALLAN adoptó en su documento de visión: «verificar debe costar menos que aceptar» (docs/producto/mi-trabajo-design.md:27). El código no la cumple.

Por qué no se arregla con formación

La objeción natural es que esto se corrige entrenando a la persona. No se corrige, y hay literatura específica que lo dice.

Parasuraman y Riley separaron dos modos de fallo simétricos. Del primero: «Misuse refers to over reliance on automation, which can result in failures of monitoring or decision biases». Del segundo: «Disuse, or the neglect or underutilization of automation, is commonly caused by alarms that activate falsely». Y la mecánica del abandono la explican por la estadística, no por el carácter: «This often occurs because the base rate of the condition to be detected is not considered in setting the trade-off between false alarms and omissions». Una cola que avisa de más entrena a la persona a no leerla; una que avisa de menos la deja sin argumentos para intervenir. Las dos fallas son la misma vista desde extremos opuestos, y ninguna es un defecto del usuario.

Los errores del primer modo también los tipifican: «Automation bias may result in omission errors, in which the operator fails to notice a problem or take an action because the automated aid fails to inform the operator», mientras que «Commission errors occur when operators follow an automated directive that is inappropriate». La distinción importa porque una compuerta sólo protege contra el segundo tipo. Contra el primero —el trabajo que se degrada sin que nadie levante la mano— no puede nada por definición: no hay llamada que interceptar. Y advierten de que la pericia no inmuniza: «It is not only untrained operators who show these tendencies».

La revisión de Parasuraman y Manzey cierra la salida fácil. Sobre la complacencia: «Automation complacency is found in both naive and expert participants and cannot be overcome with simple practice». Sobre el sesgo: «Automation bias occurs in both naive and expert participants, cannot be prevented by training or instructions, and can affect decision making in individuals as well as in teams».

Esto es lo incómodo del asunto. Si la complacencia no se corrige con práctica ni con instrucciones, todo texto de interfaz que pida atención —«revise cuidadosamente antes de aprobar»— es decorativo por construcción. Queda sólo el diseño: cambiar los costes relativos de las opciones, no exhortar a quien elige.

Buçinca, Malaya y Gajos midieron precisamente eso, y midieron también el precio de hacerlo. Su punto de partida coincide con el de Vasconcelos: «people rarely engage analytically with each individual AI recommendation and explanation, and instead develop general heuristics about whether and when to follow the AI suggestions». Su resultado: «The results demonstrate that cognitive forcing significantly reduced overreliance compared to the simple explainable AI approaches». Y el peaje, dicho sin rodeos: «However, there was a trade-off: people assigned the least favorable subjective ratings to the designs that reduced the overreliance the most». La fricción correcta es impopular. Un equipo que optimice satisfacción declarada la eliminará y no sabrá que lo ha hecho.

Y un tercer hallazgo suyo, que rara vez se cita y aquí es determinante: «on average, cognitive forcing interventions benefited participants higher in Need for Cognition more». La fricción ayuda sobre todo a quien ya estaba dispuesto a pensar. La medida más eficaz que conocemos contra la sobre-dependencia funciona peor con quien más la necesita.

Dónde poner la compuerta, y por qué más no es mejor

La escala de referencia para graduar esto sigue siendo la de Sheridan y Verplank. No se pudo recuperar el informe original de 1978; se citó en su lugar una reproducción publicada que la atribuye e imprime la tabla —«An initial scale of levels of automation was proposed by Sheridan & Verplanck (1978)»—. Aviso de esta revisión: esa reproducción tampoco se ha podido reabrir (la URL de hfes-europe devuelve ahora HTML del sitio, no el PDF), de modo que las filas de la tabla que siguen son cita de segunda mano no verificada, y ninguna afirmación posterior de este ensayo debería apoyarse en su redacción exacta. Los tres niveles centrales definen el problema entero:

La distancia entre 5 y 6 parece de implementación y es de gobierno. En el nivel 5 el silencio del humano detiene la acción; en el 6 la autoriza. Un temporizador que aprueba por defecto convierte la compuerta en un trámite: el estado de reposo del sistema pasa a ser «adelante».

ALLAN está en el nivel 5, y no por declaración sino por construcción. Cuando una aprobación caduca sin decisión, el barrido la marca expirada y termina la ejecución en fallo: store.CompleteRun(ctx, run.ID, agents.RunStatusFailed, …) con el motivo "approval expired: no operator decision within the approval timeout" (Platform Server/internal/app/human_request_expiry.go:92,110). No existe ninguna ruta que convierta el silencio en consentimiento. Es una propiedad falsable: si alguien añadiera un camino de auto-aprobación, este párrafo dejaría de ser cierto y el sistema habría cambiado de nivel sin que nadie lo decidiera.

Que el nivel esté bien elegido no dice nada sobre cuántas compuertas caben. Bainbridge enuncia el límite por el lado de la atención: «We know from many "vigilance" studies (Mackworth, 1950) that it is impossible for even a highly motivated human being to maintain effective visual attention towards a source of information on which very little happens, for more than about half an hour». Y su conclusión sobre el caso límite es directa: «If the computer is being used to make the decisions because human judgement and intuitive reasoning are not adequate in this context, then which of the decisions is to be accepted? The human monitor has been given an impossible task».

La forma de esa curva —poca intervención rinde mal, demasiada también— aparece medida en contextos cercanos. Walker y otros, controlando enjambres de robots, informan que «there is indeed a need for some human influence; however, after a certain point, further influence causes performance degradation». Y en conducción parcialmente automatizada, McWilliams y Ward describen el lado izquierdo de la curva y lo nombran: «A state of cognitive underload is especially common during continuous, monotonous, and low demand driving scenarios», con la relación explícitamente en forma de U —«This can be visualized by thinking of an inverted U similar to the Yerkes-Dodson curve»—. Que la U invertida esté establecida para vigilancia y conducción no la establece para el número de compuertas de una plataforma de agentes: eso es analogía razonada, no resultado medido. ALLAN no ha medido su propia curva y no tiene hoy con qué medirla.

Queda entonces una sola formulación defendible del objetivo, y es la de Lee y See: la confianza no se maximiza, se calibra, porque «trust guides reliance when complexity and unanticipated situations make a complete understanding of the automation impractical». El objetivo no es que la persona apruebe menos ni que apruebe más, sino que su tasa de aprobación siga a la fiabilidad real del agente. Ninguna de las métricas que ALLAN publica hoy permite saber si eso ocurre.

Qué hace ALLAN hoy

El motor trata las compuertas como límites, no como peticiones. El comentario de cabecera lo enuncia: «A gate honoured only by a cooperative model is not governance — it is a request, and the person who declared it was told they had a checkpoint» (Platform Server/internal/agents/consultation.go:17-23).

La aplicación es real. La intercepción ocurre en el runtime de herramientas antes de la política de plataforma, y ese orden es deliberado: permite que el contrato diga «puedes enviar correo, pero enséñamelo antes» incluso donde la plataforma no regula el envío (Platform Server/internal/agents/tool_runtime.go:250-262). La comprobación de si una compuerta ya fue franqueada se resuelve contra el histórico durable de aprobaciones y falla cerrada: si el almacén no responde, la llamada no procede, porque «Treating a storage error as "probably approved" would let an outage widen the authority a person granted» (consultation.go:186-190).

Sobre el contenido de la decisión el motor también hace lo correcto en dos sitios. El asunto de la aprobación es la frase de negocio que escribió la persona, literal y sin tocar: esa única asignación «is the difference between a card reading "aprobar email.send" and one reading "aprobar el envío del informe trimestral a Dirección"» (consultation.go:603-608, aplicado en :631). Y la herramienta con la que el agente plantea la consulta pide el material de la decisión: el argumento debe explicar «Qué vas a hacer y por qué, para que la persona pueda decidir sin tener que reconstruirlo. Sin esto la decisión es a ciegas» (consultation.go:544-545).

Ahí aparece la primera grieta, y está en el propio motor. Tres líneas más abajo, el esquema declara "required": []string{"consultation_point_id"} (consultation.go:548): el argumento que el comentario describe como la diferencia entre decidir y decidir a ciegas es opcional. Un modelo que invoque la compuerta sin escribirlo produce una tarjeta válida y vacía.

La asimetría que invierte la regla

Suponiendo que el argumento exista, hay que seguirlo hasta la pantalla. En la cola de autorizaciones se renderiza así:

<pre className="max-h-40 overflow-auto rounded-lg bg-muted p-3 text-xs text-foreground">
  {JSON.stringify(approval.payload, null, 2)}
</pre>

(Platform UI/components/approvals/action-approval-modal.tsx:69-76). El texto que el motor pidió en prosa se entrega como volcado JSON bajo el rótulo «Argumentos», junto a gate_id, gate_kind y work_id, que a la persona no le dicen nada. La clave agent_argument que el motor escribe (consultation.go:626) no se lee por su nombre en ningún punto de la interfaz: buscar el literal en todo Platform UI no devuelve ninguna aparición.

En la tarjeta de «Mi trabajo» la asimetría es medible. Aprobar es un botón (Platform UI/components/work/attention-card.tsx:272-282). Denegar exige abrir un formulario (:267), escribir un motivo no vacío —la condición es literalmente disabled={!denialReason.trim()} (:251)— y confirmar en un segundo botón (:246-256). Rechazar cuesta estrictamente más que aceptar, y la única salida barata es la que no requiere haber mirado nada.

La revisión de resultados repite el patrón. «Aceptar resultado» es un clic habilitado sin haber abierto ninguna evidencia (Platform UI/components/work/result-review-dialog.tsx:226), mientras que «Solicitar cambios» abre un Textarea obligatorio y necesita un segundo clic (:205, :220). La evidencia —supuestos, checklist, procedencia— vive plegada en un <details> y se muestra como JSON.stringify(values, null, 2) (:32-43). El documento de visión pedía lo contrario: «En lo irreversible: "Aprobar" se habilita al abrir evidencia» (docs/producto/mi-trabajo-design.md:488).

Contra el marco de Vasconcelos, esto es el diseño al revés: el coste de comprometerse con la tarea sube —JSON, plegado, formulario obligatorio— y el de confiar en el agente baja a un clic. No hace falta suponer nada sobre el usuario para predecir el resultado.

Y hay una asimetría más entre las dos superficies. La tarjeta de «Mi trabajo» resuelve la aprobación en línea sin mostrar el payload en ningún momento, porque WorkAttentionItem ni siquiera lo transporta (Platform UI/types/work.ts:60-93), mientras que el modal de /dashboard/action-approvals sí lo muestra, aunque sea mal. La ruta más cómoda enseña menos.

Lo que el sistema garantiza, enunciado de forma falsable

Estas afirmaciones se pueden refutar leyendo los ficheros citados. El silencio nunca autoriza: una aprobación no resuelta caduca hacia una ejecución fallida (human_request_expiry.go:92,110). Una denegación no se vuelve a preguntar dentro del mismo encargo: se devuelve al agente como resultado de herramienta y no como error, para que replanifique (consultation.go:239-241, 269-291). Una compuerta no bloqueante nunca detiene una llamada (internal/workcontract/contract.go:354-355). Y una compuerta que no puede dispararse porque ningún conector instalado provee su capacidad se reporta en vez de romper el encargo, porque «a checkpoint that silently cannot fire is exactly the decorative governance invariant I5 exists to catch» (Platform Server/internal/app/capabilities.go:37-39).

Y una que no se garantiza: nada asegura que la persona que aprueba haya visto la evidencia, ni que la evidencia exista. No hay función de forzado cognitivo en ninguna de las tres superficies de decisión.

Lo que está roto o sin terminar

on_budget_threshold no existe como límite. El enum declara que «each value has a distinct enforcement point in this engine. A kind nothing enforces would be decorative governance, which the design forbids outright (invariant I5)» (internal/workcontract/contract.go:94-97), y describe el tipo como algo que «fires at a percentage of the encargo's ceiling» (:107). Un comentario posterior afirma que «the engine fires it from the budget checkpoint» (:483-484) y el plan lo prometió con esas palabras: «se engancha al checkpoint que ya existe» (docs/producto/encargos-implementation-plan.md:906). El símbolo aparece sólo en su declaración, en esos comentarios y en un test del propio paquete; ThresholdPct no se lee en ningún punto del motor. Que el invariante no lo atrape es estructural: el test de I5 recorre los campos de Authority por reflexión y ConsultationPoints declara tres puntos de aplicación (internal/app/work_authority_invariant_test.go:40-55), de modo que una clase de compuerta sin aplicación pasa dentro de un campo que sí la tiene. El mecanismo que detecta gobierno decorativo tiene la granularidad equivocada para este caso.

Las métricas de compuerta cuentan lecturas, no estados. GateCleared y GateDenied se incrementan dentro de gateSatisfiedIn, que se invoca en cada llamada guardada y en cada reanudación (consultation.go:202,205). El comentario lo justifica —se cuenta «where the decision is READ rather than where it is made» porque es el único sitio que ve todos los caminos (:198-201)—, pero la consecuencia es que una compuerta franqueada una vez y consultada quince veces suma quince. El paquete se escribió contra esta clase de error —«A limit nobody can observe is indistinguishable from a limit that is not there» (internal/workmetrics/workmetrics.go:6-7)— y el contador acaba midiendo tráfico donde el diseño quería medir estado.

El Observatorio mide la velocidad, no el acierto. Publica mediana hasta decisión, tasa de denegación, mediana de revisión y tasa de versiones que pidieron cambios (Platforma UI Backend/platforma_ui_backend/services/work_projection.py:2088-2130). La tasa de reversión de autonomía y el coste por encargo devuelven "available": False con su motivo declarado (:2131-2141). No hay ninguna métrica de exactitud de la decisión humana, pese a que el documento de visión pedía tres por su nombre —«% aprobaciones revertidas, rachas de aprobación en <10 seg (¿sello de goma?), compuertas que jamás rechazan» (docs/producto/mi-trabajo-design.md:568)— y fijaba la metodología: «medir exactitud real de decisiones humanas, no solo velocidad o satisfacción» (:571). La consecuencia hay que decirla: de las cuatro cifras publicadas, la mediana hasta decisión es exactamente la que un sello de goma optimiza. Un equipo que se marque como objetivo bajarla estará premiando el comportamiento que la interfaz ya facilita.

La «capacidad» que muestra la home no es capacidad de atención. WorkCapacitySummary contiene unidades de trabajo concedidas, consumidas, reservadas y disponibles (Platform UI/types/work.ts:169-177). El primer principio del documento de visión —presupuestar la atención humana con control de admisión— no está implementado. Se mide el presupuesto de cómputo y se le llama capacidad.

La tarjeta no cierra la decisión. WorkAttentionItem lleva título, resumen, motivo de prioridad, origen y genealogía (Platform UI/types/work.ts:60-93). No lleva reversibilidad, ni coste estimado de atender, ni proyección de qué ocurre si nadie interviene, ni incertidumbre del agente en primera persona. Y las salidas son dos —type WorkDecisionAction = "approve" | "deny" (:198)— donde el diseño pedía cuatro: aprobar, corregir, devolver y rechazar (docs/producto/mi-trabajo-design.md:477). Una compuerta con dos salidas y sin contexto transfiere responsabilidad mejor de lo que la controla.

La cola de decisiones no tiene pulso, y las superficies de consumo sí. La cola de autorizaciones carga una vez al montar y sólo vuelve a cargar después de que la persona decida: no hay sondeo, ni SSE, ni refresco temporizado (Platform UI/components/approvals/action-approval-queue.tsx:40-42). «Mi trabajo» sí mantiene un flujo vivo sobre /v1/me/work/stream (Platform UI/hooks/use-work-overview.ts:198-206), y la bandeja, la barra lateral y el medidor de capacidad sondean con temporizador (components/layout/capacity-meter.tsx:54, hooks/use-sidebar-conversations.ts:186). El reparto es el peor posible: la pantalla que dice cuánto ha gastado se refresca sola; la que contiene las decisiones pendientes, no.

El artículo 14, que es más difícil de lo que parece

El Reglamento (UE) 2024/1689 no pide un humano que apruebe. Pide un sistema diseñado para poder ser supervisado: «High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use» (art. 14.1). Y gradúa la exigencia: «The oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system […]» (art. 14.3).

De las cinco capacidades del apartado 4, tres son razonablemente construibles: interpretar correctamente la salida (14.4.c), poder «decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output» (14.4.d) y poder «intervene in the operation of the high-risk AI system or interrupt the system through a "stop" button or a similar procedure that allows the system to come to a halt in a safe state» (14.4.e). Las otras dos son duras. La primera es 14.4.a: entender capacidades y límites hasta poder detectar «anomalies, dysfunctions and unexpected performance», que es lo que Bainbridge declaró tarea imposible cuando la máquina decide mejor que quien la vigila.

La segunda es la que hace que este ensayo exista. El apartado 14.4.b exige capacitar a la persona «to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)». Pero Parasuraman y Manzey establecieron que el sesgo de automatización «cannot be prevented by training or instructions». Un requisito legal de mantenerse consciente de un sesgo que la evidencia dice que no se previene con instrucciones sólo puede satisfacerse por diseño: cambiando los costes relativos de aprobar y de comprobar, no advirtiendo a quien decide. Un aviso en la tarjeta cumpliría la letra y no la función.

Ben Green documentó adónde lleva confundir las dos cosas. Tras revisar cuarenta y una políticas: «First, evidence suggests that people are unable to perform the desired oversight functions. Second, as a result of the first flaw, human oversight policies legitimize government uses of faulty and controversial algorithms without addressing the fundamental issues with these tools». El efecto neto es que «human oversight policies provide a false sense of security in adopting algorithms and enable vendors and agencies to shirk accountability for algorithmic harms». Su propuesta es institucional: justificar antes y revisar en agregado después. Es, traducido a producto, el Observatorio que ALLAN diseñó y no construyó.

Una precisión de alcance: el artículo 14 obliga a los sistemas de alto riesgo, y ALLAN es una plataforma de propósito general; que un despliegue concreto caiga en esa categoría depende del uso que le dé el responsable. Eso no altera el argumento técnico. Lo que el artículo 14 describe hay que construirlo de todos modos para que delegar signifique algo; el calendario sólo dice cuándo será exigible.

Dónde deja esto a ALLAN

El motor construyó la parte difícil. Las compuertas son límites reales aplicados antes que la política, fallan cerradas, no se dejan franquear por silencio y llevan como asunto la frase que escribió una persona. El invariante que exige que cada término de autoridad tenga un punto de aplicación existe como test y no como disciplina, aunque su granularidad deje pasar una clase entera de compuerta.

La parte que falta no es la aplicación sino la economía. El sistema puede detener; todavía no puede abaratar la comprobación por debajo del coste de aceptar, ni exigir que el argumento exista antes de abrir la tarjeta, ni medir si quien aprueba está decidiendo o firmando, ni saber cuántas compuertas caben en un día antes de que la marginal empiece a restar. Las cuatro carencias son la misma: nadie ha modelado la atención como el recurso escaso que es. Mientras siga así, el sistema producirá aprobaciones —muchas, rápidas y baratas— y no habrá forma de distinguir cuáles fueron decisiones.

Referencias

• Holmström, B. (1979). Moral Hazard and Observability. The Bell Journal of Economics 10(1), 74-91. https://people.duke.edu/~qc2/BA532/1979 Rand Holmstrom.pdf — p. 74: «It has long been recognized that a problem of moral hazard may arise when individuals engage in risk sharing under conditions such that their privately taken actions affect the probability distribution of the outcome»; p. 74: «The source of this moral hazard or incentive problem is an asymmetry of information among individuals that results because individual actions cannot be observed and hence contracted upon»; p. 74: «A natural remedy to the problem is to invest resources into monitoring of actions and use this information in the contract»; p. 74: «Generally, however, full observation of actions is either impossible or prohibitively costly»; p. 83: «A signal y is said to be valuable if both the principal and the agent can be made strictly better off with a contract of the form s(x,y) than they are with a contract of the form s(x)»; p. 84: «x carries all the relevant information about a, and y adds nothing to the power of inference»; p. 84, Proposición 3: «a signal is valuable if and only if it is informative». (El PDF es un facsímil escaneado de JSTOR; las frases se leyeron de las páginas 2, 11 y 12 del fichero, correspondientes a las páginas 74, 83 y 84 del artículo.) NO RE-VERIFICADA en esta revisión de citas: el fichero se descargó de nuevo (1,9 MB, 19 páginas) y no contiene ninguna capa de texto —la extracción devuelve cadena vacía en todas sus páginas—, de modo que estas siete frases no han podido cotejarse contra la fuente en esta pasada. Proceden de la redacción anterior del artículo. Quien quiera apoyarse en ellas debe leer el facsímil a ojo o recuperar una copia con texto.

• Parasuraman, R. y Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors 39(2), 230-253. https://andy-blog.oss-cn-beijing.aliyuncs.com/blog/2021-08-02-parasurman-humans-and-automation-use-misuse-disuse-abuse.pdf — resumen, p. 230: «Misuse refers to over reliance on automation, which can result in failures of monitoring or decision biases»; p. 230: «Disuse, or the neglect or underutilization of automation, is commonly caused by alarms that activate falsely. This often occurs because the base rate of the condition to be detected is not considered in setting the trade-off between false alarms and omissions»; p. 239: «Automation bias may result in omission errors, in which the operator fails to notice a problem or take an action because the automated aid fails to inform the operator»; p. 239: «Commission errors occur when operators follow an automated directive that is inappropriate»; p. 239: «It is not only untrained operators who show these tendencies». Procedencia, corregida en esta revisión: el PDF de esa URL es un facsímil de ProQuest sin capa de texto (24 páginas, ninguna extraíble), así que las tres frases de la p. 239 no se han podido cotejar en esta pasada y proceden de la redacción anterior. Las dos del resumen sí se re-verificaron, contra la página del editor (https://journals.sagepub.com/doi/10.1518/001872097778543886), que imprime «over reliance» en dos palabras; una versión anterior de este artículo transcribía «overreliance», y se ha corregido aquí y en el cuerpo.

• Parasuraman, R. y Manzey, D. H. (2010). Complacency and bias in human use of automation: an attentional integration. Human Factors 52(3), 381-410. doi:10.1177/0018720810376055. https://pubmed.ncbi.nlm.nih.gov/21077562/ — resumen, Results: «Automation complacency occurs under conditions of multiple-task load, when manual tasks compete with the automated task for the operator's attention. Automation complacency is found in both naive and expert participants and cannot be overcome with simple practice. Automation bias results in making both omission and commission errors when decision aids are imperfect. Automation bias occurs in both naive and expert participants, cannot be prevented by training or instructions, and can affect decision making in individuals as well as in teams».

• Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. https://ckrybus.com/static/papers/Bainbridge_1983_Automatica.pdf — p. 776: «We know from many "vigilance" studies (Mackworth, 1950) that it is impossible for even a highly motivated human being to maintain effective visual attention towards a source of information on which very little happens, for more than about half an hour»; p. 776: «A more serious irony is that the automatic control system has been put in because it can do the job better than the operator, but yet the operator is being asked to monitor that it is working effectively»; p. 776: «If the computer is being used to make the decisions because human judgement and intuitive reasoning are not adequate in this context, then which of the decisions is to be accepted? The human monitor has been given an impossible task»; p. 776: «One can therefore only expect the operator to monitor the computer's decisions at some meta-level, to decide whether the computer's decisions are "acceptable"»; p. 777: «Ephrath (1980) has reported a study in which system performance was worse with computer aiding, because the operator made the decisions anyway, and checking the computer added to his workload».

• Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T., Bernstein, M. S. y Krishna, R. (2023). Explanations Can Reduce Overreliance on AI Systems During Decision-Making. CSCW 2023, arXiv:2212.06823. http://export.arxiv.org/api/query?id_list=2212.06823 — resumen: «our paper argues that people strategically choose whether or not to engage with an AI explanation, demonstrating empirically that there are scenarios where AI explanations reduce overreliance»; «we formalize this strategic choice in a cost-benefit framework, where the costs and benefits of engaging with the task are weighed against the costs and benefits of relying on the AI»; «Our results suggest that some of the null effects found in literature could be due in part to the explanation not sufficiently reducing the costs of verifying the AI's prediction».

• Buçinca, Z., Malaya, M. B. y Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proc. ACM Hum.-Comput. Interact. 5, CSCW1, art. 188. https://www.eecs.harvard.edu/~kgajos/papers/2021/bucinca21trust.pdf — resumen, p. 1: «we posit that people rarely engage analytically with each individual AI recommendation and explanation, and instead develop general heuristics about whether and when to follow the AI suggestions»; «The results demonstrate that cognitive forcing significantly reduced overreliance compared to the simple explainable AI approaches»; «However, there was a trade-off: people assigned the least favorable subjective ratings to the designs that reduced the overreliance the most»; «Our results show that, on average, cognitive forcing interventions benefited participants higher in Need for Cognition more».

• Lee, J. D. y See, K. A. (2004). Trust in automation: designing for appropriate reliance. Human Factors 46(1), 50-80. doi:10.1518/hfes.46.1.50_30392. https://pubmed.ncbi.nlm.nih.gov/15151155/ — resumen: «Automation is often problematic because people fail to rely upon it appropriately»; «In particular, trust guides reliance when complexity and unanticipated situations make a complete understanding of the automation impractical».

• Save, L. y Feuerberg, B. (2012). Designing Human-Automation Interaction: a new level of Automation Taxonomy. En Human Factors: a view from an integrative perspective, HFES Europe Chapter Conference, Toulouse, 43-55. https://www.hfes-europe.org/wp-content/uploads/2014/06/Save.pdf — p. 44: «An initial scale of levels of automation was proposed by Sheridan & Verplanck (1978) representing a continuum of levels between low automation, in which the human performs the task manually, and full automation in which the computer is fully autonomous (cf. Table 1)»; p. 44, Tabla 1, «Levels of automation of Decision and Action Selection (Sheridan & Verplanck, 1978)»: nivel 4 «Suggests one alternative, and»; nivel 5 «Executes that suggestion if the human approves, or»; nivel 6 «Allows the human a restricted veto time before automatic execution»; nivel 10 «The computer decides everything, acts autonomously, ignores the human». El informe original de Sheridan y Verplank (MIT, 1978) no se pudo recuperar en esta sesión: se cita esta reproducción y se advierte del salto de fuente. Nótese que esta fuente escribe «Verplanck», grafía que difiere de la habitual «Verplank». NO RE-VERIFICADA en esta revisión de citas: la URL de hfes-europe ya no devuelve el PDF sino una página HTML del sitio, de modo que ni la frase de la p. 44 ni las filas de la Tabla 1 han podido cotejarse en esta pasada. Son, por tanto, cita de segunda mano sobre una fuente que en este momento no se puede abrir; la escala de Sheridan y Verplank sigue sin verificación primaria.

• Walker, P., Nunnally, S., Lewis, M., Chakraborty, N. y Sycara, K. (2013). Levels of Automation for Human Influence of Robot Swarms. Proc. HFES Annual Meeting. https://publications.ri.cmu.edu/storage/publications/pub_files/2014/9/walkerHFES2013loa-final-CR.pdf — resumen: «We investigate what environmental conditions are conducive to different amounts of human influence, and at what point further human intervention has a detrimental effect on the swarm's performance. The results show that for complex environments containing numerous obstacles and small passageways, there is indeed a need for some human influence; however, after a certain point, further influence causes performance degradation».

• McWilliams, T. y Ward, N. (2021). Underload on the Road: Measuring Vigilance Decrements During Partially Automated Driving. Frontiers in Psychology 12, 631364. https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2021.631364/full — «the vigilance decrement, where people are less likely to detect and properly respond to an infrequent target stimulus»; «A state of cognitive underload is especially common during continuous, monotonous, and low demand driving scenarios»; «This can be visualized by thinking of an inverted U similar to the Yerkes-Dodson curve».

• Green, B. (2022). The Flaws of Policies Requiring Human Oversight of Government Algorithms. Computer Law & Security Review 45; arXiv:2109.05067. https://arxiv.org/abs/2109.05067 — resumen: «First, evidence suggests that people are unable to perform the desired oversight functions. Second, as a result of the first flaw, human oversight policies legitimize government uses of faulty and controversial algorithms without addressing the fundamental issues with these tools»; «Thus, rather than protect against the potential harms of algorithmic decision-making in government, human oversight policies provide a false sense of security in adopting algorithms and enable vendors and agencies to shirk accountability for algorithmic harms».

• Parlamento Europeo y Consejo (2024). Reglamento (UE) 2024/1689, artículo 14 (Supervisión humana). https://artificialintelligenceact.eu/article/14/ — 14.1: «High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use»; 14.3: «The oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system […]» (la frase continúa «and shall be ensured through either one or both of the following types of measures»; la elisión, antes sin marcar, queda ahora señalada); 14.4.a: «to properly understand the relevant capacities and limitations of the high-risk AI system and be able to duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance»; 14.4.b: «to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)»; 14.4.c: «to correctly interpret the high-risk AI system's output, taking into account, for example, the interpretation tools and methods available»; 14.4.d: «to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system»; 14.4.e: «to intervene in the operation of the high-risk AI system or interrupt the system through a "stop" button or a similar procedure that allows the system to come to a halt in a safe state».