Agencia y autorización en interacciones prolongadas

477.1 Una decisión distribuida en el tiempo

Una persona acepta recibir recordatorios de seguimiento de un servicio de salud mental. En las semanas siguientes la herramienta ajusta los horarios, le propone responder un cuestionario y le sugiere compartir un resumen con el equipo tratante. Más adelante ofrece mover una cita porque interpreta que ciertas respuestas indican una menor necesidad de contacto. Vista por separado, cada intervención parece una ayuda menor, pero la secuencia altera qué información circula, quiénes intervienen y qué opciones siguen disponibles. Un análisis que se detiene en la primera aceptación deja sin examinar decisiones posteriores de otro orden.

Calificar la herramienta de autónoma o de dependiente ayuda poco, porque esos adjetivos agrupan propiedades heterogéneas, como iniciar una operación, elegir entre cursos de acción, ejecutarlos sin supervisión inmediata o responder moralmente por lo ocurrido. Chan y colaboradores (2023) proponen tratar la agencia de los sistemas algorítmicos como una cuestión de grado, apreciable en la subespecificación de la tarea, el impacto directo sobre el mundo sin mediación humana, la orientación a metas y la planificación a largo plazo. Excluyen expresamente de su análisis la agencia moral y la conciencia, y advierten que reconocer agencia en un sistema no le traslada la responsabilidad moral de quienes lo diseñan y despliegan. De ahí que la evaluación deba concentrarse en acciones observables, en los permisos otorgados y en las responsabilidades de quienes diseñan, adoptan y utilizan el sistema.

Toda autorización tiene un alcance. Aceptar recordatorios no equivale a aceptar cualquier uso futuro de la información, así como aprobar un borrador tampoco supone autorizar su envío. En una interacción prolongada esos límites se vuelven difíciles de percibir, porque la interfaz conserva su continuidad visual mientras cambia de función. Una misma conversación puede pasar de informar a recomendar y luego a actuar sobre recursos externos, como una agenda o un expediente. La evaluación tiene que reconstruir esas transiciones y establecer qué autorización corresponde a cada una.

El capítulo trabaja con escenarios hipotéticos para examinar lo que llamaremos controles de trayectoria. Las condiciones propuestas son argumentos de diseño y de organización; no estiman efectos empíricos generalizables ni interpretan el derecho de una jurisdicción concreta. Como marco se usa la noción de control humano significativo de Santoni de Sio y van den Hoven (2018), formulada a propósito de los sistemas de armas autónomos letales, cuyas implicaciones civiles los autores comienzan a explorar al final de su trabajo. Su traslado al seguimiento clínico es una analogía que exige precisar quiénes pueden intervenir, con qué información y sobre qué decisiones.

477.2 Acción técnica, decisión humana y responsabilidad

Una acción técnica admite una descripción verificable como transformación de entradas en salidas. El sistema recibe un texto, genera un resumen y lo guarda en un espacio determinado. Dentro de ese mismo proceso, una decisión humana puede consistir en aprobar el resumen o en autorizar que lo reciba otra persona. La responsabilidad institucional cubre un terreno más amplio, que incluye la selección de la herramienta, la definición de sus usos permitidos, la asignación de tiempo y personal para revisar lo que produce y la respuesta cuando algo falla. Que una parte de la secuencia se ejecute automáticamente no disuelve ninguna de estas relaciones.

Tampoco alcanza con constatar que alguien hizo el último clic. Esa persona pudo aprobar una salida sin conocer los datos omitidos, con poco tiempo y sin posibilidad de modificar la propuesta. Hubo intervención humana en sentido formal, aunque su capacidad para orientar el resultado fue escasa. Para juzgarla hay que examinar qué información tenía a la vista, de cuánto tiempo disponía, qué alternativas le ofrecía la pantalla y qué ocurría si rechazaba la recomendación.

Elish (2019) acuñó la expresión zona de deformación moral (moral crumple zone) para describir situaciones en que la responsabilidad por una acción se atribuye a un operador humano que tenía un control limitado sobre el comportamiento de un sistema automatizado. Así como la zona de deformación de un automóvil absorbe el impacto para proteger a los ocupantes, en la versión moral lo protegido es la integridad del sistema técnico, a costa de la persona más próxima a él. Sus casos principales son el accidente de Three Mile Island, la caída del vuelo 447 de Air France y la muerte de una persona atropellada en 2018 por un vehículo autónomo de pruebas de Uber en Tempe, Arizona. El trabajo analiza percepciones culturales de culpa más que regímenes legales y no se ocupa de salud mental. Su pertinencia aquí es conceptual, porque obliga a preguntar si la institución conserva la capacidad de decidir mientras atribuye los fallos a quien interactúa al final de la cadena, pregunta que se responde reconstruyendo tareas y recursos.

El control significativo requiere además condiciones positivas. Una profesional que puede corregir un resumen, conocer de dónde proviene cada afirmación y devolver un episodio a revisión tiene facultades muy distintas de las de quien solo puede aceptar o cancelar el proceso entero. Esa cancelación es puramente nominal si ejercerla significa que una persona se queda sin atención. Diseñar control supone ofrecer alternativas practicables y respaldo organizacional para usarlas. La responsabilidad se vuelve evaluable cuando esas facultades están descritas y se sabe quién podía modificarlas.

477.3 El alcance de un permiso

Un permiso puede precisar la acción autorizada, los datos afectados, el destinatario, el propósito y el plazo de vigencia. Con esas dimensiones explícitas es posible reconocer cuándo una operación nueva excede el acuerdo inicial. Si lo autorizado era generar un resumen para revisión personal, enviarlo de forma automática al equipo agrega una consecuencia distinta. Si lo autorizado era enviarlo al profesional habitual, distribuirlo a una unidad administrativa cambia el destinatario.

Los permisos demasiado amplios dificultan la comprensión y la revisión. Una cláusula que autoriza «cualquier actuación necesaria para mejorar el seguimiento» deja sin determinar quién decide qué es necesario. En el extremo opuesto, pedir confirmación para cada operación trivial puede convertir la autorización en un gesto reflejo. Böhme y Köpsell (2010) mostraron variantes de un diálogo de consentimiento a unos 80.000 usuarios de una herramienta de privacidad y concluyeron que los participantes parecían habituados a estos diálogos, de modo que aceptaban con menos reflexión cuanto más se parecía la presentación a un contrato de licencia de usuario final. El estudio trata de software general, no de servicios clínicos, pero ilustra el riesgo de multiplicar confirmaciones indistintas. Conviene agrupar las operaciones según sus consecuencias, reservar confirmaciones específicas para los cambios materiales y explicar esa agrupación con ejemplos de lo permitido y de lo que exige una decisión adicional.

La vigencia temporal importa porque las circunstancias cambian. Alguien puede aceptar recordatorios durante un período de adaptación y dejar de encontrarlos útiles meses después, de modo que el sistema debería permitir revisar las preferencias sin repetir toda la incorporación. Un antecedente es el consentimiento dinámico descrito por Kaye y colaboradores (2015), una interfaz digital mediante la cual los participantes de investigaciones biomédicas pueden modificar sus preferencias de consentimiento a lo largo del tiempo y recibir información sobre el uso de sus datos. Se desarrolló sobre todo en biobancos y su traslado a la clínica pide cautela. Cualquier mecanismo de este tipo debe distinguir además una preferencia de comunicación de una decisión sobre atención. Desactivar las notificaciones no autoriza a inferir que la persona rechaza todo contacto ni que su necesidad de seguimiento haya desaparecido.

Muchas autorizaciones son condicionales. Una persona puede permitir el envío de un resumen solo después de revisarlo, o aceptar recordatorios únicamente en ciertos horarios. La herramienta debe representar esas condiciones de modo que gobiernen efectivamente la ejecución; si quedan registradas solo como texto descriptivo, nada impide que se ignoren. Cuando una condición no puede comprobarse, corresponde reconocer la limitación y fijar una ruta de revisión. Ante la duda sobre el alcance de un permiso, el sistema debería abstenerse de actuar o consultar a la persona, y nunca tratar esa incertidumbre como autorización implícita.

477.4 Primer escenario: del recordatorio al cambio de atención

Pensemos en una plataforma que envía un recordatorio semanal y permite contestar preguntas breves. En una primera etapa, cada respuesta se incorpora a un registro que revisa una profesional. Luego se agrega una función que interpreta las respuestas y propone cambiar la frecuencia de contacto. Por último, una actualización permite que la herramienta aplique ese cambio por sí misma si la persona no contesta una notificación. Son tres usos distintos bajo una presentación casi idéntica.

La primera transición altera la función de los datos, que dejan de servir solo para informar una revisión y empiezan a generar recomendaciones. La segunda altera quién ejecuta una decisión sobre la atención. Ambas obligan a examinar la autorización vigente y la responsabilidad de la institución que las incorpora. La falta de respuesta a una notificación puede deberse a causas muy diversas, incluidas dificultades de acceso, y tratarla como aceptación exige una justificación que la conveniencia técnica del procedimiento no proporciona.

Otra opción es mantener la recomendación como propuesta y exigir revisión profesional antes de modificar el plan, lo que preserva un control relevante solo si quien revisa dispone de información y de tiempo. Goddard, Roudsari y Wyatt (2012) revisaron 74 estudios sobre el sesgo de automatización, entendido como la tendencia a seguir en exceso el resultado de un sistema de apoyo a la decisión en lugar de buscar y procesar información con vigilancia. Entre los factores que lo favorecen identificaron la carga de trabajo, la complejidad de la tarea y la presión de tiempo; entre los que lo atenúan, la capacitación, la rendición de cuentas del usuario y la entrega de información en lugar de recomendaciones directivas. La evidencia proviene en buena parte de estudios controlados y no se refiere a salud mental, pero desaconseja suponer que una revisión nominal equivale a supervisión. Quien recibe cientos de propuestas sin fundamento visible puede terminar validándolas por rutina. Conviene observar el tiempo disponible para revisar, la proporción de propuestas modificadas o rechazadas y las razones registradas, indicadores que no prueban por sí solos un buen control pero permiten reconstruir cómo opera la revisión.

El escenario exige también una salida para quienes no usan la plataforma. Mantener una ruta alternativa impide que la autorización digital se convierta, de hecho, en requisito para recibir cualquier seguimiento. Esa ruta tiene costos que la institución debe asumir de manera explícita. Si resulta mucho más lenta o engorrosa, la libertad de rechazar la herramienta queda condicionada por consecuencias organizacionales, y la evaluación de la autorización debe considerarlas junto con la claridad del texto que aparece en pantalla.

477.5 Cómo una secuencia modifica las opciones

Una serie de recomendaciones puede alterar la atención y las expectativas sin que exista una decisión única fácil de identificar. Una herramienta que sugiere posponer una conversación, espaciar las consultas o resolver dudas dentro de la aplicación puede desplazar otras vías de ayuda. Son hipótesis que requieren observación, puesto que ninguna personalización produce estos efectos de manera inevitable. El análisis de trayectoria se pregunta si cambiaron las opciones disponibles y las efectivamente utilizadas, y qué papel tuvieron las recomendaciones en ese cambio.

La trayectoria también puede ampliar capacidades. Recordar una preferencia de comunicación puede ayudar a que alguien prepare preguntas para su profesional y llegue a la consulta con la información ordenada. El mismo mecanismo de memoria puede, sin embargo, conservar una preferencia que ya no rige. Por eso conviene permitir correcciones y separar las declaraciones actuales de las inferencias antiguas. El valor de la personalización depende de cómo se revisan sus supuestos y de que la persona pueda reconocer qué información está influyendo en las propuestas que recibe.

La repetición plantea otra dificultad. Una recomendación formulada muchas veces adquiere apariencia de certeza aunque todas sus versiones deriven del mismo supuesto. Para evaluar la trayectoria hay que identificar qué información nueva apareció entre una respuesta y la siguiente. Si no hubo evidencia nueva, la consistencia verbal carece de valor como corroboración independiente. Un control posible consiste en mantener visible la incertidumbre de la recomendación y proponer otra fuente de consulta cuando la pregunta excede las condiciones de uso acordadas.

Las opciones cambian además por acumulación de pequeños costos. Rechazar una sugerencia puede requerir varias pantallas, mientras que aceptarla toma un solo gesto, y con el tiempo esa diferencia orienta las decisiones aunque cada pantalla ofrezca formalmente ambas posibilidades. Al analizar cerca de 11.000 sitios de comercio electrónico, Mathur y colaboradores (2019) clasificaron como asimétricos los diseños que imponen cargas desiguales a las opciones presentadas. Su estudio es comercial; en un servicio de salud, la pregunta equivalente es si la interfaz favorece sistemáticamente una de las respuestas. Un análisis de autorización debería comparar el esfuerzo, la información y las consecuencias de aceptar y de rechazar a lo largo del recorrido completo, incluidos los intentos fallidos y quienes abandonan antes de decidir.

477.6 Segundo escenario: memoria y destinatarios

Supongamos ahora que una persona usa una herramienta para preparar, antes de una consulta, un resumen de lo que le preocupa. Autoriza que el borrador se conserve durante una semana y que se le muestre antes del envío. En la conversación aparecen datos sobre otra persona y una interpretación que el usuario considera errónea, y una función de resumen automático incorpora ambos elementos a la versión abreviada. El caso obliga a separar cuestiones distintas, como la fidelidad del resumen, la pertinencia de cada dato y la existencia de autorización para comunicarlo. Un texto lingüísticamente claro puede fallar en cualquiera de ellas.

La revisión debería permitir modificar fragmentos y confirmar qué versión exacta se enviará. Si se muestra un borrador y luego se regenera sin nueva confirmación, se rompe el vínculo entre lo aprobado y lo enviado. Conviene atar la autorización a una versión identificable del documento y a un destinatario concreto, de manera que cualquier cambio en uno u otro obligue a una decisión nueva dentro del alcance acordado. Esta propiedad se puede verificar técnicamente. Saber si la persona comprendió lo que aprobaba requiere, en cambio, evaluación con usuarios.

La memoria del sistema tampoco es un archivo neutral de hechos. Puede contener inferencias, preferencias transitorias o errores que luego se reutilizan como antecedentes. Una interfaz útil permite ver la procedencia de cada elemento y corregir los que influyen en respuestas futuras. Debe distinguir, además, entre borrar un borrador y revocar sus usos posteriores. Si la información ya sirvió para producir otro registro, retirarla puede exigir revisar esas dependencias, y prometer una eliminación absoluta sin conocerlas sería una descripción infiel del sistema.

El destinatario debe ser reconocible para quien autoriza. Enviar información «al equipo» puede significar que accederán varias funciones profesionales, mientras la persona imagina una conversación con una sola tratante. Nissenbaum (2011) ha sostenido que el modelo de aviso y consentimiento descansa en un supuesto que la autora considera defectuoso, a saber, que cada individuo puede comprender al aceptar todos los hechos relevantes para elegir, y propone normas sustantivas propias de cada contexto que limiten qué información se recoge, con quién se comparte y en qué condiciones. Desde esa perspectiva, la autorización individual no agota la legitimidad de un flujo de información. La explicación debe corresponder al flujo real, y los usos secundarios no pueden introducirse en silencio bajo el propósito de preparar una consulta. La evaluación examina quién recibe qué versión, para qué tarea y con qué posibilidad de corregir errores después del envío.

477.7 Un registro de autorizaciones verificable

Un registro puede vincular cada operación externa con una autorización vigente. En el ejemplo se guardan un identificador del permiso, las acciones permitidas, el destinatario, la versión del documento y el instante en que caduca. La tabla siguiente reúne decisiones que conviene mantener separadas. No pretende cubrir todos los requisitos de un sistema real; muestra qué distinciones se perderían si solo se almacenara una casilla general de aceptación al inicio del servicio.

La comprobación debe hacerse lo más cerca posible del momento de ejecución. Una autorización válida al crear la tarea puede haberse revocado antes del envío, y el documento o el destinatario pueden cambiar mientras la tarea espera en una cola. El registro tiene que conservar qué comprobación se hizo y sobre qué versión, para que una auditoría pueda distinguir un error de decisión de un error de ejecución. En ingeniería de software, este desfase entre verificar una condición y actuar se conoce como problema de comprobación y uso (time-of-check to time-of-use).

El fragmento siguiente conserva las seis comprobaciones lógicas de la regla de autorización, que corresponden a las filas de envío y de cambio de cita de la tabla, y añade un registro mínimo en el que el permiso se consulta en el instante de ejecutar. La comprobación y el efecto ocurren bajo un mismo cerrojo, de modo que una revocación no puede intercalarse entre ambos, y cada solicitud lleva un identificador que impide duplicar un envío cuando se reintenta.

from dataclasses import dataclass, replace
import threading


@dataclass(frozen=True)
class Permission:
    actions: frozenset
    recipient: str
    document_version: str
    expires_at: int
    revoked: bool = False


def may_execute(permission, action, recipient, version, now):
    return (
        not permission.revoked
        and now < permission.expires_at
        and action in permission.actions
        and recipient == permission.recipient
        and version == permission.document_version
    )


p = Permission(frozenset({'send'}), 'team_A', 'v3', 100)
assert may_execute(p, 'send', 'team_A', 'v3', 99)
assert not may_execute(p, 'send', 'team_A', 'v4', 99)          # versión regenerada
assert not may_execute(p, 'send', 'team_B', 'v3', 99)          # otro destinatario
assert not may_execute(p, 'reschedule', 'team_A', 'v3', 99)    # otra acción
assert not may_execute(p, 'send', 'team_A', 'v3', 100)         # plazo vencido
assert not may_execute(replace(p, revoked=True), 'send', 'team_A', 'v3', 99)
print('Seis comprobaciones de alcance, vigencia y revocación superadas.')


class PermissionStore:
    """Registro mínimo: el permiso se consulta en el momento de ejecutar."""

    def __init__(self):
        self._lock = threading.Lock()
        self._permissions = {}
        self._done = set()
        self.log = []

    def grant(self, pid, permission):
        with self._lock:
            self._permissions[pid] = permission

    def revoke(self, pid):
        with self._lock:
            self._permissions[pid] = replace(self._permissions[pid], revoked=True)

    def execute(self, pid, request_id, action, recipient, version, now, effect):
        # Comprobación y efecto bajo el mismo cerrojo: una revocación no puede
        # intercalarse entre ambos dentro de este proceso.
        with self._lock:
            if request_id in self._done:
                self.log.append((request_id, 'duplicado', version))
                return False
            if not may_execute(self._permissions[pid], action, recipient, version, now):
                self.log.append((request_id, 'rechazado', version))
                return False
            effect()
            self._done.add(request_id)
            self.log.append((request_id, 'ejecutado', version))
            return True


sent = []
store = PermissionStore()
store.grant('perm-1', p)

# La tarea se aprueba y queda en cola; la persona revoca antes de que se ejecute.
queued = ('req-1', 'send', 'team_A', 'v3', 50)
store.revoke('perm-1')
assert not store.execute('perm-1', *queued, effect=lambda: sent.append('v3'))
assert sent == []

# Nuevo permiso: un reintento con el mismo identificador no duplica el envío.
store.grant('perm-2', p)
assert store.execute('perm-2', 'req-2', 'send', 'team_A', 'v3', 60, lambda: sent.append('v3'))
assert not store.execute('perm-2', 'req-2', 'send', 'team_A', 'v3', 61, lambda: sent.append('v3'))
assert sent == ['v3']
assert [estado for _, estado, _ in store.log] == ['rechazado', 'ejecutado', 'duplicado']
print('Revocación en cola, reintento idempotente y registro verificados.')

El código verifica una regla lógica simplificada. No autentica identidades ni mide comprensión, y su cerrojo solo coordina hilos dentro de un mismo proceso; un sistema distribuido necesitaría transacciones y un registro de identificadores que sobreviviera a los reinicios. Tampoco cubre un efecto que se produce a medias y falla antes de quedar registrado. El parámetro now es simulado: en producción, el reloj debe consultarse al comprobar la vigencia, no al encolar la tarea. Representa una condición necesaria para el escenario, no una implementación clínica ni una prueba de autorización humana significativa.

477.8 Revocación y consecuencias ya producidas

Revocar un permiso detiene acciones futuras, pero no deshace las ya realizadas. Si un resumen llegó al equipo, retirarlo de la aplicación no elimina las copias ni las decisiones que se apoyaron en él. La interfaz debe explicar esa diferencia y ofrecer una vía de rectificación cuando corresponda. Evaluar el control implica comprobar que la persona puede saber qué ocurrió, qué queda pendiente y a quién acudir para corregir un registro. Una confirmación genérica del tipo «operación cancelada» puede encubrir estados materialmente distintos.

La revocación debe propagarse también a las tareas en espera. Una operación programada para la semana siguiente puede seguir activa en otro componente aunque la pantalla principal muestre el permiso como deshabilitado. Hay que probar el recorrido completo entre componentes y conservar los estados de cancelación. Estos errores de coordinación pesan más cuando una sola conversación desencadena varias acciones. Una política bien redactada puede fallar si el permiso no tiene una representación coherente en todos los lugares que ejecutan sus consecuencias.

Las acciones irreversibles exigen especial cuidado en el momento de la autorización. Una propuesta puede editarse antes de enviarse, pero un mensaje recibido por terceros no puede tratarse como si nunca hubiera existido, y esa asimetría debe reflejarse en la información que se entrega antes de decidir. Multiplicar confirmaciones no resuelve el problema, por la habituación comentada en la sección 477.3. Lo pertinente es concentrar la atención en las decisiones que modifican de manera relevante la situación de la persona o de terceros.

477.9 Control sobre la trayectoria y sobre el servicio

Santoni de Sio y van den Hoven (2018) formulan dos condiciones necesarias para el control humano significativo. La de seguimiento (tracking) exige que el sistema responda a las razones morales pertinentes de quienes lo diseñan y despliegan y a los hechos relevantes de su entorno. La de rastreo (tracing) exige que cada resultado pueda remontarse a una comprensión técnica y moral adecuada de al menos una persona de la cadena de diseño y despliegue, alguien capaz de entender las capacidades y efectos posibles del sistema y consciente de que puede recibir reproches legítimos por lo que este haga. En el escenario, ambas condiciones llevan a preguntar qué razones influyen realmente en las acciones de la herramienta y qué actores comprenden sus limitaciones. El marco es filosófico y no ofrece una escala para certificar una interacción concreta.

El control, además, está repartido de manera desigual. Una persona puede gobernar sus preferencias de contacto sin tener ninguna influencia sobre el contrato entre la institución y el proveedor. Una profesional puede modificar recomendaciones individuales sin poder alterar su propia carga de trabajo. La dirección puede decidir retirar la herramienta y depender, para hacerlo con fundamento, de información que solo posee el equipo técnico. La responsabilidad debe distribuirse según esas capacidades y deberes, sin cargar toda la secuencia sobre quien interactúa al final. Esa distribución se concreta en decisiones documentadas, recursos asignados y vías de revisión conocidas.

El análisis de una trayectoria debería reconstruir los momentos en que se amplió el alcance del uso. Una nueva integración puede permitir enviar información, reservar horas o cerrar episodios de atención. Cada ampliación necesita una evaluación de sus consecuencias y de las autorizaciones existentes, porque una actualización técnica no equivale por sí misma a una decisión institucional. Anunciar que hubo cambios tampoco basta si quienes usan el sistema no pueden reconocer cuáles afectan sus opciones ni qué deben hacer para mantener o revisar sus preferencias.

La supervisión longitudinal requiere observar patrones que la revisión de respuestas aisladas no detecta, como el aumento de acciones automáticas, la reducción de oportunidades de revisión o la reiteración de propuestas ya rechazadas. Esos patrones pueden estudiarse combinando registros y entrevistas con usuarios, siempre que se mantenga la distinción entre conducta observada e interpretación. Una baja frecuencia de rechazo puede reflejar satisfacción, pero también dificultad de uso o ausencia de alternativas, y elegir entre esas explicaciones exige evidencia adicional sobre cómo se tomaron las decisiones.

477.10 Objetivos inferidos y desacuerdos persistentes

Una herramienta puede inferir un objetivo a partir de la conducta observada. Si alguien responde con rapidez a mensajes breves, el sistema podría concluir que prefiere intercambios cada vez más cortos. Esa misma conducta puede deberse a falta de tiempo, a dificultad para escribir o a incertidumbre sobre qué información es pertinente. Una inferencia que sirve para adaptar la interfaz no debería transformarse automáticamente en una preferencia autorizada sobre la atención. El sistema necesita distinguir lo que la persona declaró de lo que el sistema estimó, y permitir corregir las inferencias cuando empiezan a orientar recomendaciones relevantes.

Consideremos a una persona que desea recibir menos notificaciones, pero conservar sus citas y la posibilidad de contactar al equipo. Un optimizador que trate toda interacción como carga podría reducir también las oportunidades de consulta. El error está en la definición del objetivo, aunque la optimización se ejecute correctamente. Corregirlo requiere representar por separado la frecuencia de avisos y el acceso a la atención, y comprobar con la persona si los cambios propuestos responden a sus razones. Una mejora en una métrica interna no indica, por sí sola, que el sistema haya captado esa distinción.

El desacuerdo puede persistir sin que constituya un fallo que haya que eliminar. Una persona puede rechazar una recomendación después de comprenderla, y un profesional puede juzgar insuficiente la información para aceptarla. Si la herramienta insiste hasta obtener la aceptación, el objetivo de apoyo se convierte en un objetivo de cumplimiento. La evaluación debería registrar cuántas veces se repite una propuesta, qué información nueva motiva cada reiteración y cómo se respeta la decisión de no continuar. Las repeticiones justificadas por evidencia nueva deben distinguirse de la reformulación persuasiva del mismo argumento.

Hay también desacuerdos entre actores con responsabilidades diferentes. El usuario puede preferir un canal que el servicio no ofrece, y el equipo puede recomendar una frecuencia de controles que excede la disponibilidad institucional. La herramienta no debería presentar esa limitación como si fuera una necesidad clínica demostrada. Conviene separar las recomendaciones sobre la atención, las preferencias de la persona y las restricciones de capacidad del servicio, porque esa separación permite negociar alternativas y atribuir a la organización las decisiones que le pertenecen. Una restricción de recursos disfrazada de recomendación personalizada resulta difícil de comprender y de impugnar.

477.11 Comprensión situada y posibilidad de pedir ayuda

La comprensión no se verifica preguntando únicamente si alguien leyó una explicación. Una evaluación puede plantear escenarios concretos, como qué ocurriría al aprobar un resumen, quién lo recibiría o qué acciones se detendrían al revocar el permiso, y usar las respuestas para identificar ambigüedades del diseño. El propósito es comprobar si el servicio permite anticipar consecuencias importantes, nunca examinar a la persona para trasladarle responsabilidad. Si muchas personas interpretan una función de manera distinta a la prevista, ese resultado es evidencia sobre la comunicación del sistema y obliga a corregirla.

La comprensión puede variar a lo largo de una relación prolongada. Tras varias experiencias sin incidentes, una persona podría prestar menos atención a una confirmación; tras un error, podría desconfiar de funciones que siguen siendo adecuadas. Ambas posibilidades deben observarse en cada servicio, sin darlas por supuestas, mediante entrevistas en distintos momentos y revisión de decisiones concretas. Conviene preguntar qué creía la persona que estaba autorizando entonces, en lugar de reconstruir sus expectativas a partir del registro de clics o del resultado final.

La posibilidad de pedir ayuda forma parte del control. Una interfaz puede ofrecer muchas opciones y aun así resultar difícil de usar cuando la persona necesita aclarar una consecuencia. El servicio debería establecer quién responde esas consultas, en qué plazo y qué ocurre con la acción mientras tanto. Una solicitud de aclaración no equivale a un rechazo ni a una aceptación; es un estado propio del proceso, y mantenerlo visible evita que la presión por cerrar tareas fuerce decisiones antes de resolver una duda relevante.

Los apoyos deben adaptarse a las necesidades de comunicación sin presumir incapacidad a partir de una característica general. Algunas personas prefieren explicaciones escritas, otras necesitan revisar el contenido con un profesional o usar otro canal, y una misma persona puede requerir apoyos distintos según el momento. La institución debe describir qué recursos ofrece y comprobar que estén disponibles. Cuando no puede proporcionar una forma de interacción necesaria, se trata de una limitación de acceso del servicio, que una aceptación rutinaria no convierte en consentimiento válido.

477.12 Auditar una autorización sin reducirla a un registro

Una auditoría puede tomar una operación ya efectuada y reconstruir hacia atrás su autorización, examinando el contenido presentado, el destinatario visible, la versión aprobada y los cambios previos a la ejecución. Después sigue hacia adelante las consecuencias, desde la recepción hasta las acciones posteriores y las posibilidades de rectificación. Este recorrido detecta lo que una lista de permisos vigentes no muestra, por ejemplo que una aprobación correcta se aplicó a un documento distinto o que una tarea cancelada reapareció tras un reintento automático.

El registro, por otra parte, no demuestra voluntariedad ni comprensión. Puede documentar que hubo una pulsación y conservar la pantalla correspondiente, pero no revela las razones de la persona. Por eso conviene combinar trazas con revisión de casos y relatos de usuarios. Las discrepancias entre fuentes son informativas, como cuando alguien afirma que no esperaba un envío que el registro muestra aprobado. La investigación debe examinar esa diferencia sin presumir mala fe y sin tomar la existencia del evento técnico como prueba completa de un acuerdo sustantivo.

La institución puede ensayar escenarios de revocación, cambio de versión y pérdida de conexión antes de habilitar funciones nuevas. Un ensayo útil interrumpe el proceso entre la aprobación y la ejecución, modifica el permiso y observa qué sucede al reanudar; otro envía dos solicitudes idénticas para verificar que no se dupliquen consecuencias. El fragmento de la sección 477.7 reproduce ambos a escala mínima. Estas pruebas examinan propiedades operativas acotadas y deben complementarse con evaluación de la experiencia de las personas, porque una explicación clara y una ejecución fiel se necesitan mutuamente.

La delegación entre profesionales introduce otro nivel de autorización. Que una persona haya aprobado compartir un resumen con su equipo no determina qué integrante puede modificar el plan ni qué tareas pueden transferirse a otro servicio. Si un componente recibe una solicitud emitida por otro, necesita conocer el alcance de la delegación y conservar su procedencia, porque una cadena de mensajes técnicamente válidos puede ejecutar una decisión que nadie estaba facultado para autorizar en su conjunto. South y colaboradores (2025), en la versión preprint consultada, proponen extender OAuth 2.0 y OpenID Connect con credenciales de delegación firmadas por quien delega, que precisan el alcance de la tarea y de los recursos, una expiración o un punto de revocación y un registro de auditoría. No especifican, sin embargo, un protocolo completo para cadenas de delegación de varios saltos. Con o sin esas herramientas, la revisión debe seguir la cadena hasta las decisiones institucionales que la originaron.

Es necesario, por último, identificar quién puede cambiar las propias reglas de permiso. Si una actualización amplía sin aviso las acciones incluidas en una categoría, las autorizaciones anteriores adquieren un alcance que no tenían cuando se otorgaron. El control de versiones debe abarcar las definiciones de las acciones y sus consecuencias, además del software. Antes de reutilizar permisos existentes, la institución debe comprobar que conservan el mismo significado operativo, y si ese significado cambió, someterlos a una revisión proporcional al cambio. De lo contrario, el mantenimiento técnico puede alterar sin advertirlo decisiones humanas que el sistema declara respetar.

477.13 Una resolución argumentada de los escenarios

En el primer escenario, la autorización para recibir recordatorios no basta para justificar que la frecuencia de atención se modifique por falta de respuesta a una notificación. Esa función exige redefinir el alcance del permiso, asignar responsabilidades y mantener alternativas para quienes no usan la plataforma. Una implementación defendible podría conservar las recomendaciones como insumo de una revisión profesional con tiempo, información y capacidad real de actuar. Su evaluación debería comprobar que la revisión efectivamente ocurre, que las personas comprenden los cambios propuestos y que la ruta alternativa mantiene condiciones de acceso aceptables.

En el segundo, el permiso de envío debe quedar ligado al contenido revisado y al destinatario acordado. Una regeneración que altere de manera material el documento exige nueva revisión, y la revocación debe alcanzar a las tareas pendientes e ir acompañada de una explicación de lo ya realizado. Estas condiciones no hacen del sistema un sujeto moral; permiten identificar qué personas e instituciones autorizaron cada operación, qué mecanismos la ejecutaron y qué responsabilidades se activan cuando la secuencia se aparta de lo acordado.

En ambos casos, la evaluación de agencia y autorización descansa en una reconstrucción temporal que considera qué opciones existían al comienzo, cómo fueron cambiando y quién podía intervenir en cada transición. Para que una autorización pueda llamarse significativa, las decisiones humanas deben conservar efectos reales sobre lo que el sistema hace, y la institución debe estar en condiciones de explicar y revisar el papel que ella misma desempeñó en la trayectoria.

Referencias

Böhme, R., y Köpsell, S. (2010). Trained to accept? A field experiment on consent dialogs. En Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '10) (pp. 2403–2406). ACM. https://doi.org/10.1145/1753326.1753689

Chan, A., Salganik, R., Markelius, A., Pang, C., Rajkumar, N., Krasheninnikov, D., Langosco, L., He, Z., Duan, Y., Carroll, M., Lin, M., Mayhew, A., Collins, K., Molamohammadi, M., Burden, J., Zhao, W., Rismani, S., Voudouris, K., Bhatt, U., ... Maharaj, T. (2023). Harms from increasingly agentic algorithmic systems. En Proceedings of the 2023 ACM Conference on Fairness, Accountability, and Transparency (FAccT '23) (pp. 651–666). ACM. https://doi.org/10.1145/3593013.3594033

Elish, M. C. (2019). Moral crumple zones: Cautionary tales in human-robot interaction. Engaging Science, Technology, and Society, 5, 40–60. https://doi.org/10.17351/ests2019.260

Goddard, K., Roudsari, A., y Wyatt, J. C. (2012). Automation bias: A systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association, 19(1), 121–127. https://doi.org/10.1136/amiajnl-2011-000089

Kaye, J., Whitley, E. A., Lund, D., Morrison, M., Teare, H., y Melham, K. (2015). Dynamic consent: A patient interface for twenty-first century research networks. European Journal of Human Genetics, 23(2), 141–146. https://doi.org/10.1038/ejhg.2014.71

Mathur, A., Acar, G., Friedman, M. J., Lucherini, E., Mayer, J., Chetty, M., y Narayanan, A. (2019). Dark patterns at scale: Findings from a crawl of 11K shopping websites. Proceedings of the ACM on Human-Computer Interaction, 3(CSCW), Artículo 81. https://doi.org/10.1145/3359183

Nissenbaum, H. (2011). A contextual approach to privacy online. Daedalus, 140(4), 32–48. https://doi.org/10.1162/DAED_a_00113

Santoni de Sio, F., y van den Hoven, J. (2018). Meaningful human control over autonomous systems: A philosophical account. Frontiers in Robotics and AI, 5, Artículo 15. https://doi.org/10.3389/frobt.2018.00015

South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Greenwood, D., Chan, A., y Pentland, A. (2025). Authenticated delegation and authorized AI agents [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2501.09674