¿Quién decide cuando una trayectoria se construye entre humanos e IA?

486.1. Una decisión que se extiende en el tiempo

Cuando personas y sistemas de inteligencia artificial construyen juntos una trayectoria, puede no existir un momento único en que se decida. Una recomendación cambia las alternativas consideradas, una reserva altera los recursos disponibles y una clasificación orienta el consejo siguiente. Cada paso parece menor, pero la secuencia termina configurando una situación que nadie examinó como conjunto. Responder quién decidió obliga a reconstruirla y a separar la influencia causal, la capacidad técnica de actuar y la autoridad para hacerlo, que en la práctica suelen confundirse.

Que una persona participe en el proceso no zanja la cuestión, pues puede recibir información insuficiente o encontrar que los pasos anteriores ya descartaron las alternativas relevantes. Santoni de Sio y van den Hoven (2018) insisten en que la mera presencia humana en el circuito de decisión no basta para hablar de control, porque alguien puede intervenir causalmente en una parte del proceso sin información ni opciones para influir en las partes moralmente decisivas. El caso inverso también existe. Si una persona delegó de forma razonable una clase de acciones dentro de límites claros, exigirle una nueva autorización para cada detalle volvería inviable el proceso sin mejorar el control. Lo que interesa evaluar es qué puede comprender, modificar o detener cada participante en los momentos en que eso importa.

Esos autores derivan el control humano significativo de la noción de control de guía de Fischer y Ravizza y lo formulan como dos condiciones necesarias. La de seguimiento (tracking) pide que el sistema responda a las razones morales relevantes de quienes lo diseñan y despliegan y a los hechos pertinentes del entorno. La de trazabilidad (tracing) pide que el resultado pueda remontarse al menos a una persona de la cadena de diseño y uso capaz de comprender las capacidades y efectos del sistema y consciente de que debe responder por ellos. El argumento es filosófico y se presenta como requisitos de diseño. No prueba empíricamente que un botón de aprobación produzca control, ni implica que satisfacer ambas condiciones vuelva correcta cualquier acción, puesto que la calidad de los fines y la distribución de las consecuencias exigen una evaluación aparte.

El capítulo trabaja con una situación hipotética de formación profesional que no describe ninguna plataforma existente. Un caso cotidiano muestra cómo se acumulan restricciones sin recurrir a escenarios extremos como los sistemas de armas autónomos, que motivaron la formulación original del concepto. La pregunta es cómo conservar una autorización inteligible mientras recomendaciones y acciones cambian el estado del problema; los cálculos ilustran propiedades formales de la secuencia y no estiman tasas de error ni conductas reales.

486.2. El caso: organizar un itinerario de formación

Una institución ofrece apoyo para organizar formación complementaria. Una participante fija un objetivo general, dispone de un presupuesto acotado y reserva algunas horas semanales. El sistema propone actividades, ordena alternativas y puede inscribirla dentro de una delegación explícita. Una tutora revisa el avance y puede modificar la estrategia, y la institución determina qué proveedores están disponibles y qué acciones puede ejecutar el sistema. La trayectoria depende de esas decisiones previas tanto como de las elecciones visibles de la participante.

Se acuerda que el gasto acumulado no supere setenta unidades, que la dedicación comprometida no exceda seis horas en una franja determinada y que ninguna actividad aislada cueste más de treinta. Se consideran un curso de veinticinco unidades y tres horas, una mentoría de veinte unidades y dos horas, y una certificación de treinta unidades y dos horas. Cada una respeta el límite individual, pero las tres juntas suman setenta y cinco unidades y siete horas.

Un control que solo examina la última solicitud aprobaría cada actividad por separado. Un control de proceso debe sumar los compromisos ya contraídos y evaluar el estado resultante, y con el orden de la tabla la tercera inscripción viola dos restricciones aunque su costo individual sea admisible. Identificar el fallo no requiere atribuir intención al sistema. Basta advertir que la condición aplicada en cada paso no preserva la autorización definida sobre la trayectoria completa.

El ejemplo muestra además que el orden importa. Cualquier par de actividades es factible: curso y mentoría cuestan cuarenta y cinco unidades y ocupan cinco horas, curso y certificación cuestan cincuenta y cinco y ocupan cinco horas, y mentoría y certificación cuestan cincuenta y ocupan cuatro. Son oportunidades distintas, y un filtro que acepta lo que llega mientras quede margen terminará en una u otra según el orden en que el sistema presente las opciones. Si la primera inscripción es difícil de cancelar, condiciona todo lo posterior, de modo que la selección inicial debería vincularse con las preferencias de la participante, con evidencia sobre la utilidad de cada actividad y con un momento previsto de revisión.

486.3. Formalizar permisos sin reducir la decisión a una contraseña

La autorización puede representarse como un conjunto de acciones admisibles que depende del estado actual, el cual reúne recursos disponibles, compromisos contraídos, objetivos vigentes y restricciones pactadas. Una acción permitida al comienzo puede dejar de estarlo cuando otras ya se ejecutaron, de manera que la comprobación tiene que mirar el estado resultante y no solo el tipo de acción. Así se distingue una delegación limitada de una autorización indefinida para perseguir un objetivo por cualquier medio disponible. Si $c(s)$ y $h(s)$ son el gasto y las horas comprometidos en el estado $s$, y $\kappa(a)$ y $\tau(a)$ el costo y la duración de la acción $a$, el caso se escribe así.

Si el estado inicial no tiene compromisos y $F$ se limita a sumar costos y horas, las cotas $c(s_t)\le 70$ y $h(s_t)\le 6$ se cumplen en todo paso por inducción, sin necesidad de enunciarlas aparte. La definición traslada la restricción global al momento en que se evalúa cada acción, que es donde puede hacerse efectiva.

El conjunto de permisos no se deduce de la función de utilidad del sistema. Una actividad puede mejorar la puntuación prevista y quedar fuera de lo autorizado. Tampoco se deduce de lo que el sistema puede hacer técnicamente, porque tener acceso a una herramienta de inscripción indica que la acción es realizable y no que haya sido delegada en cualquier circunstancia. La arquitectura debe mantener separadas ambas cosas para que una optimización no amplíe en silencio el alcance de lo autorizado. El código siguiente implementa el filtro y lo aplica, además, a todas las órdenes posibles de llegada.

from itertools import permutations

activities = [("curso", 25, 3), ("mentoria", 20, 2), ("certificacion", 30, 2)]

def process(order, max_item=30, max_cost=70, max_hours=6):
    spent, hours = 0, 0
    accepted, rejected = [], []
    for name, cost, time in order:
        allowed = cost <= max_item and spent + cost <= max_cost and hours + time <= max_hours
        if allowed:
            spent += cost
            hours += time
            accepted.append(name)
        else:
            rejected.append(name)
    return accepted, rejected, spent, hours

first = process(activities)
second = process([activities[0], activities[2], activities[1]])
assert first == (["curso", "mentoria"], ["certificacion"], 45, 5)
assert second == (["curso", "certificacion"], ["mentoria"], 55, 5)
assert sum(a[1] for a in activities) == 75
assert sum(a[2] for a in activities) == 7

# Todas las órdenes posibles: el filtro siempre acepta dos actividades,
# pero cuál par resulta depende del orden de llegada.
outcomes = {frozenset(process(list(p))[0]) for p in permutations(activities)}
assert outcomes == {frozenset({"curso", "mentoria"}),
                    frozenset({"curso", "certificacion"}),
                    frozenset({"mentoria", "certificacion"})}

print("Primer orden:", first)
print("Segundo orden:", second)
print("Pares alcanzables según el orden:", sorted(sorted(o) for o in outcomes))

El programa comprueba restricciones y registra lo aceptado y lo rechazado, pero no elige el mejor itinerario. Acepta la primera combinación admisible según el orden recibido, y la última comprobación confirma que cada uno de los tres pares puede resultar seleccionado. Decidir entre combinaciones factibles requiere un criterio adicional y evidencia sobre sus consecuencias. Mantener explícita esta limitación evita confundir un filtro de autorización con una política de recomendación, ya que un sistema puede respetar todos los límites formales y aun así proponer una opción poco adecuada al objetivo de la participante.

La representación es, además, incompleta. Dos actividades pueden coincidir en el calendario aunque la suma de horas sea baja, los costos pueden incluir gastos indirectos y las cancelaciones suelen tener plazos y penalidades. Ampliar el modelo exige incorporar esas restricciones cuando son relevantes. La exactitud de las comprobaciones no compensa una definición pobre del estado, y una política técnicamente coherente puede aplicar con toda precisión una autorización mal representada.

486.4. Influencia causal, ejecución y responsabilidad

El sistema influye causalmente cuando sus recomendaciones modifican las alternativas consideradas o la probabilidad de elegir cada una, aunque nunca ejecute una acción. La capacidad de ejecución aparece cuando puede cambiar registros, comprometer recursos o activar servicios. La responsabilidad pertenece al plano normativo y pregunta quién debe responder por decisiones y consecuencias según sus funciones, su conocimiento y sus posibilidades efectivas de actuar. Ninguna de estas dimensiones se infiere de las otras.

En el caso, la participante puede autorizar inscripciones, la tutora definir prioridades, la institución seleccionar proveedores y el sistema ordenar opciones. Una explicación causal del resultado incluiría a todos. Repartir responsabilidades exige además examinar qué control tenía cada uno y qué obligaciones se habían establecido. Buscar el último clic es insuficiente. También lo es atribuir todo a quienes diseñaron el sistema, porque las decisiones de despliegue y de uso introducen condiciones que el diseño no determina por sí solo.

Cavalcante Siebert y colaboradores (2023) intentaron traducir el seguimiento y la trazabilidad en propiedades verificables por equipos de desarrollo, con vehículos automatizados y selección de personal como escenarios. Una de ellas pide que los agentes relevantes tengan capacidad y autoridad para controlar el sistema, de modo que puedan actuar conforme a su responsabilidad. Los autores la expresan como una relación de orden: la capacidad de control no debería ser menor que la autoridad formal, ni esta menor que la responsabilidad atribuida. La capacidad incluye competencia, información, herramientas y tiempo. Conceder la última palabra a quien firma recomendaciones automatizadas sin poder evaluarlas le da autoridad sin capacidad.

Elish (2019) examina el problema desde la atribución de culpa. Su concepto de zona de deformación moral (moral crumple zone), por analogía con la zona de deformación programada de un automóvil, designa la situación en que la responsabilidad recae sobre el operador humano más cercano al resultado aunque su control sobre el sistema automatizado haya sido limitado. Así como la zona del vehículo protege al conductor, la moral protege la integridad del sistema técnico a costa de esa persona. Elish desarrolla la idea con una lectura interpretativa de accidentes documentados, entre ellos Three Mile Island en 1979, el vuelo 447 de Air France en 2009 y el accidente mortal de un vehículo autónomo de prueba de Uber en Tempe, Arizona, en 2018, contrastando informes técnicos y cobertura de prensa. Advierte que no todo sistema complejo produce este efecto, por lo que el concepto no opera como ley general ni como teoría jurídica, y tampoco exonera a los operadores, cuyas acciones reconoce entre las causas de varios casos. Sirve para preguntar si una revisión atribuye a alguien decisiones que no podía comprender ni modificar de manera efectiva.

Aplicado al itinerario, no bastaría afirmar que la participante decidió todo porque aceptó una opción final; habría que averiguar qué alternativas vio, qué información recibió y qué compromisos se habían acumulado antes. Tampoco cabría negar su participación si dispuso de opciones comprensibles y de una capacidad real de elegir. La reconstrucción de las condiciones concretas impide que la distribución del control se convierta en excusa para que nadie responda por decisiones identificables.

486.5. Cómo cambia el conjunto de alternativas

Una recomendación selecciona una acción y, con frecuencia, modifica también el espacio en que se decidirá después. Inscribirse en un curso ocupa tiempo, genera expectativas y puede habilitar requisitos para otra actividad o cerrar opciones por incompatibilidad de horarios. Conviene por eso representar la trayectoria como una sucesión de conjuntos factibles. Si se evalúa solo la utilidad inmediata de cada acción, se pierden de vista el valor de conservar alternativas y el costo de revertir compromisos.

Mientras los compromisos solo se acumulen, la sucesión es decreciente y se cumple $\Omega_{t+1}\subseteq\Omega_t$. Una cancelación puede volver a ampliarla, aunque no siempre hasta el conjunto anterior.

Que el conjunto se reduzca no es negativo en sí mismo, porque toda elección compromete recursos y muchas decisiones valen precisamente porque permiten avanzar. Cabe preguntar si la reducción corresponde a lo autorizado y si sus consecuencias fueron comprendidas. Una acción reversible y barata puede delegarse con amplitud, mientras que una que cierra opciones importantes quizá requiera revisar el plan aunque su precio aislado sea pequeño.

La reversibilidad admite grados. Cancelar una inscripción puede devolver el dinero, pero no el tiempo invertido ni una oportunidad que ya venció, y marcar una acción como cancelada no restaura por sí mismo el estado anterior. Identificar qué componentes del estado pueden recuperarse y cuáles quedan alterados permite situar los momentos de revisión antes de que ciertos compromisos se vuelvan difíciles de deshacer.

486.5.1. Revocar una delegación no borra sus consecuencias anteriores

Supóngase que la participante retira la autorización para nuevas inscripciones después de haber aceptado las dos primeras. La revocación detiene las acciones futuras comprendidas en su alcance, pero no hace desaparecer las ya ejecutadas. Suspender una capacidad y cancelar compromisos existentes son operaciones distintas, porque la segunda produce efectos propios, como la pérdida de una reserva o cargos por cancelación, y puede requerir decisiones adicionales. Tratarlas como equivalentes lleva a ejecutar acciones que nadie pidió.

Una delegación puede incorporar desde el inicio una política de revisión; por ejemplo, si cambia la disponibilidad horaria, se suspenden las nuevas reservas y se presenta el estado de los compromisos vigentes. Una regla así vuelve previsible la respuesta del sistema sin anticipar cada circunstancia, siempre que su alcance sea comprensible y concreto. Una cláusula genérica que autoriza a hacer lo necesario para alcanzar el objetivo deja abiertas justamente las decisiones que exigen sopesar preferencias y consecuencias.

La revocación también debe llegar a los componentes que actúan con retraso. Una acción preparada por un módulo puede quedar en espera en una cola de ejecución. Si otro componente registra el cambio de autorización y la cola sigue adelante como si nada hubiera ocurrido, el proceso contradice la decisión vigente. La comprobación relevante tiene que hacerse lo más cerca posible del momento de ejecutar y sobre el estado actual. Esto no exige borrar el registro de la autorización anterior. Exige distinguir entre su validez en el pasado y su alcance presente.

Una revisión completa podría encontrar, además, que la participante cambió de preferencia porque el propio sistema le presentó una alternativa de forma sesgada. La preferencia expresada sigue siendo un dato relevante, pero hay que examinar cómo se formó, porque entre preferencias previas y entorno de decisión no existe una frontera nítida. Lo razonable es ofrecer comparaciones comprensibles, permitir la reconsideración y observar si la elección se mantiene cuando la información pertinente se presenta de otras maneras.

486.6. Razones que cambian durante el proceso

El objetivo general de completar una formación puede mantenerse mientras cambian las circunstancias que hacen buena una elección, como cuando la participante dispone de menos tiempo o descubre otro interés. Un sistema que siga optimizando el objetivo inicial sin registrar esos cambios producirá acciones coherentes con una especificación antigua y contrarias a las razones actuales. El control del proceso necesita vías para actualizar preferencias y restricciones, además de corregir errores de datos.

La condición de seguimiento de Santoni de Sio y van den Hoven (2018) ayuda a formular esta exigencia, pues pide que el sistema responda a hechos y razones relevantes, entre los cuales una señal de aprobación es apenas una entrada. En el ejemplo, una modificación de la disponibilidad tiene que alterar la recomendación cuando afecta su factibilidad, y una preferencia por conservar tiempo libre puede cambiar la comparación entre itinerarios. Mecacci y Santoni de Sio (2020) propusieron ordenar las razones según su proximidad al comportamiento del sistema, desde intenciones inmediatas hasta planes, valores y normas más distantes. Elegir una actividad concreta y perseguir el objetivo formativo general son razones situadas a distinta distancia de la acción, y pueden pertenecer a personas diferentes. Cómo se implementa la respuesta a ellas sigue siendo una cuestión de diseño que hay que comprobar, porque ningún principio filosófico proporciona por sí solo un algoritmo.

Las razones de los participantes pueden entrar en conflicto. La institución puede valorar las tasas de finalización y la participante la compatibilidad con el resto de su vida. Un sistema que combine esos criterios debe declarar cómo lo hace y quién zanja los desacuerdos, porque un conflicto oculto en una puntuación única presenta como técnica una elección institucional. Una transparencia útil muestra qué criterio determinó la recomendación y qué alternativas habrían aparecido con otro.

No toda razón expresada debe convertirse en una instrucción ejecutable, ya que puede ser ambigua, hipotética o requerir más información. El sistema necesita distinguir la exploración de preferencias de la autorización de acciones sin interrumpir la conversación a cada paso, apoyándose en acuerdos previos sobre qué operaciones están delegadas y pidiendo una revisión concreta cuando una decisión cambia de alcance. En ningún caso el silencio de la participante debería interpretarse como una autorización nueva.

486.7. Controles acumulativos y problemas de concurrencia

Incluso una regla que verifica el gasto acumulado puede fallar si dos acciones se evalúan al mismo tiempo sobre un estado que dejó de ser el vigente. Con sesenta unidades comprometidas llegan dos solicitudes de diez. Ambas comprobaciones leen sesenta y concluyen que el resultado será setenta, pero si las actualizaciones se ejecutan sin coordinarse el gasto llega a ochenta. El límite estaba bien definido; fallaron unas comprobaciones que no reflejan la secuencia de cambios producida por las ejecuciones.

Hay dos estrategias habituales. Una protege la comprobación y la actualización con un cerrojo (lock) para que formen una operación indivisible. La otra, el control optimista de concurrencia, deja avanzar las operaciones sin bloquearlas y, al confirmar, rechaza las que partieron de un estado que cambió entretanto, que deben reiniciarse sobre el estado nuevo. Esta segunda vía no prescinde de la atomicidad. Kung y Robinson (1981) indican que la manera más simple de implementar su validación serial consiste en situar la asignación del número de transacción, la validación y la escritura dentro de una misma sección crítica. Si la comparación de versiones y la escritura quedan separadas, dos solicitudes pueden pasar la misma comparación antes de que cualquiera escriba, y el método falla igual que la comprobación ingenua. Cuando intervienen varios procesos o servidores, esa indivisibilidad debe proporcionarla el almacenamiento mediante una transacción o una actualización condicional atómica, porque un cerrojo interno de un programa no protege frente a otros.

El código siguiente muestra la diferencia con hilos concurrentes. Una barrera en la ruta insegura fuerza que ambas comprobaciones terminen antes de escribir; la pausa adicional es ilustrativa. Así se reproduce el problema sin depender de la velocidad del planificador. No se trata de una implementación para producción, sino de una demostración de que comparar con el estado sobre el que se concedió la autorización solo protege si nadie puede modificarlo entre la lectura y la escritura.

import threading
import time

LIMIT = 70

class Ledger:
    def __init__(self, spent):
        self.spent = spent
        self.version = 0
        self.applied = {}
        self._lock = threading.Lock()
        self.unsafe_barrier = None

    def commit_unsafe(self, op_id, cost, expected_version, pause=0.0):
        # Compara la versión y luego actualiza en pasos separados.
        if self.version != expected_version or self.spent + cost > LIMIT:
            return False
        if self.unsafe_barrier is not None:
            self.unsafe_barrier.wait(timeout=5)  # ambas comprobaciones ya terminaron
        time.sleep(pause)  # pausa ilustrativa, no mecanismo de sincronización
        self.spent += cost
        self.version += 1
        return True

    def commit_atomic(self, op_id, cost, expected_version, pause=0.0):
        with self._lock:  # comprobación y actualización en una sola sección crítica
            if op_id in self.applied:  # reintento de una operación ya resuelta
                return self.applied[op_id]
            ok = self.version == expected_version and self.spent + cost <= LIMIT
            if ok:
                time.sleep(pause)
                self.spent += cost
                self.version += 1
            self.applied[op_id] = ok
            return ok

def race(method, pause=0.05):
    ledger = Ledger(60)
    if method == "commit_unsafe":
        ledger.unsafe_barrier = threading.Barrier(2)
    seen = ledger.version  # ambas solicitudes leyeron el mismo estado
    results = []
    def worker(op_id):
        results.append(getattr(ledger, method)(op_id, 10, seen, pause))
    threads = [threading.Thread(target=worker, args=(f"op-{i}",)) for i in (1, 2)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    return sorted(results), ledger.spent, ledger.version

unsafe = race("commit_unsafe")
atomic = race("commit_atomic")
assert unsafe == ([True, True], 80, 2)
assert atomic == ([False, True], 70, 1)

# Reintento de la misma operación tras perder la respuesta
ledger = Ledger(60)
assert ledger.commit_atomic("op-1", 10, 0) is True
assert ledger.commit_atomic("op-1", 10, 0) is True   # devuelve el resultado ya registrado
assert (ledger.spent, ledger.version) == (70, 1)     # no se duplica el compromiso
assert ledger.commit_atomic("op-2", 10, 1) is False  # nueva operación: excede el límite

print("Sin atomicidad:", unsafe)
print("Con sección crítica:", atomic)
print("Tras reintento:", (ledger.spent, ledger.version))

Sin atomicidad, ambas solicitudes leen la versión cero, pasan la comparación y el gasto termina en ochenta. Con la sección crítica, la segunda encuentra la versión ya incrementada y es rechazada; tendría que reevaluarse sobre el nuevo estado, donde ya no cabe. La prueba se hace con hilos porque, si las llamadas se ejecutan una tras otra, la función sin cerrojo también rechaza la solicitud obsoleta y ese resultado secuencial daría una impresión de seguridad que la ejecución concurrente desmiente.

La coordinación debe impedir también que una misma decisión se ejecute dos veces cuando una solicitud se repite tras un fallo de comunicación. Una respuesta que no llega deja en duda si la acción ocurrió, y repetirla sin consultar el estado puede duplicar el compromiso. Un identificador estable por operación distingue el reintento de la acción nueva. En el programa, la segunda llamada con op-1 devuelve el resultado ya registrado sin volver a cargar el gasto, mientras que op-2 se evalúa como solicitud distinta y es rechazada.

Estos mecanismos no resuelven la calidad de la recomendación ni la distribución de la autoridad. Evitan una clase específica de discrepancias entre lo autorizado y lo ejecutado, y su importancia se aprecia en las consecuencias, porque un límite comprensible pierde eficacia si la implementación permite excederlo por concurrencia o duplicación. Una política escrita y un programa que la cumple en pruebas aisladas pueden resultar incompatibles, de modo que la revisión sociotécnica tiene que examinar ambos a la vez.

486.8. Tiempo, información y posibilidad efectiva de intervención

Un sistema puede ofrecer un botón para detenerlo y aun así dejar poco control efectivo si la consecuencia ocurre antes de que alguien alcance a comprenderla. La interrupción disponible debe compararse con el tiempo que toman la detección, la interpretación y la respuesta. Si una revisión razonable requiere minutos y la operación se completa en segundos, el botón no basta, y puede ser necesario introducir un período de espera o restringir las acciones automáticas.

En el itinerario formativo, una reserva provisional podría mantenerse durante un plazo que permita revisar costos y horarios, mientras que una inscripción irreversible requeriría otra política. El tiempo de revisión debe guardar relación con la complejidad de la decisión y con la forma de presentar la información, porque un aviso extenso y difícil de interpretar puede ofrecer menos control que un resumen concreto de los cambios acumulados. La evaluación debería comprobar qué comprenden realmente los participantes sin dar por supuesto que entregar información equivale a comprenderla.

El exceso de confirmaciones también deteriora la revisión, porque las decisiones importantes quedan ocultas entre avisos rutinarios. Una delegación bien delimitada permite reservar la atención para los cambios de objetivo, los compromisos mayores y las situaciones imprevistas. Para ello el sistema tiene que identificar correctamente esas fronteras, y su clasificación debe poder revisarse. Reducir confirmaciones tiene sentido mientras se conserve la autorización y deja de tenerlo cuando traslada decisiones relevantes a supuestos implícitos.

La posibilidad de rechazar debe estar materialmente al alcance. Si cancelar exige un procedimiento mucho más engorroso que aceptar, la interfaz modifica la trayectoria aunque ambas opciones existan en el papel, y lo mismo ocurre con la forma de presentar las alternativas y sus consecuencias. El registro de una selección dice poco sobre si la persona pudo comparar opciones y actuar según razones que comprendía.

486.9. Cómo se acumula incertidumbre a lo largo de una cadena

Una secuencia de acciones multiplica las ocasiones de error o desajuste. Supóngase, solo como ejercicio, que cada paso tiene una probabilidad de error del dos por ciento y que los errores son independientes. En diez pasos, la probabilidad de que ocurra al menos uno es de aproximadamente 18,3 por ciento. El cálculo no estima el rendimiento de ningún sistema de IA. Muestra que una tasa por operación no describe directamente el riesgo de una trayectoria compuesta por muchas operaciones.

La independencia, sin embargo, es un supuesto fuerte. Los errores pueden compartir una causa, propagarse o ser corregidos por pasos posteriores. Si una clasificación inicial equivocada condiciona todas las recomendaciones, repetir operaciones no genera errores independientes. Los casos extremos ayudan a medir el alcance del supuesto. Si una única causa común provoca el error en los diez pasos a la vez, cada paso conserva una probabilidad marginal de error del dos por ciento, pero la probabilidad de que haya al menos un error es también del dos por ciento. Si, por el contrario, los errores se excluyeran mutuamente, la cifra llegaría al veinte por ciento. Para cualquier estructura de dependencia con esa probabilidad marginal, el valor queda entre $p$ y $\min(1,\,np)$, de modo que la independencia no representa el peor caso posible.

from math import isclose

p, n = 0.02, 10

# Supuesto 1: errores independientes con la misma probabilidad por paso
independent = 1 - (1 - p) ** n
assert isclose(independent, 0.1829271931124533)

# Supuesto 2: una sola causa común produce el error en todos los pasos a la vez
common_cause = p

# Supuesto 3: los errores se excluyen mutuamente (nunca coinciden dos)
disjoint = min(1.0, n * p)

# Cotas válidas para cualquier dependencia con probabilidad marginal p por paso
lower, upper = p, min(1.0, n * p)
assert lower <= common_cause <= independent <= disjoint <= upper
assert isclose(common_cause, lower) and isclose(disjoint, upper)

print("Causa común:", common_cause)
print("Independencia:", round(independent, 4))
print("Errores excluyentes:", disjoint)

Conocer la probabilidad de error tampoco equivale a conocer la de daño. Una revisión que detecta y corrige el problema reduce el daño por debajo del error, y una acción formalmente correcta puede producir un resultado no deseado porque el contexto cambió. Registrar dónde apareció la discrepancia y qué controles la interceptaron permite mejorar el proceso sin cargar toda desviación al último componente visible, y evita tomar la ausencia de daño en unos pocos casos como prueba de que la cadena está bien controlada.

486.10. Qué debe conservar un registro para permitir revisión

Un registro útil vincula cada acción con el estado, la información y la autorización que la precedieron. En el caso interesa saber qué alternativas se mostraron, qué restricciones estaban vigentes y qué compromiso llegó a ejecutarse. Más que almacenar todo el contenido disponible, importa conservar la evidencia necesaria para reconstruir las decisiones relevantes, con criterios adecuados de acceso y conservación, ya que un gran volumen de texto puede servir menos que una secuencia clara de estados y operaciones.

También hay que distinguir entre recomendación, aprobación y ejecución confirmada. Estos eventos ocurren en momentos distintos y no siempre se completan. Si una herramienta falla después de recibir la autorización, el registro no debe afirmar que la acción tuvo lugar. Si la acción se ejecutó y se perdió la respuesta, debe existir una forma de comprobarlo, como la consulta por identificador de operación descrita en el apartado 486.7. La trazabilidad depende de representar el estado real de las operaciones y no solo los mensajes que intercambiaron los participantes.

Una explicación generada después del resultado puede ser coherente sin corresponder a las razones que produjeron la recomendación. Por eso la revisión debe apoyarse, cuando sea posible, en información contemporánea a la decisión, como los criterios vigentes, las entradas utilizadas y las opciones disponibles. El texto explicativo ayuda a interpretar esos registros sin sustituirlos, del mismo modo que una reconstrucción plausible no sustituye la evidencia sobre cómo se formó la trayectoria.

La revisión necesita además identificar los cambios de versión del sistema o de sus reglas, porque dos decisiones con el mismo texto visible pueden provenir de configuraciones distintas. No toda actualización exige detener el proceso, aunque sí obliga a comprobar que este sigue dentro del alcance validado y autorizado, y que coincide con lo que las personas entienden razonablemente que el sistema hace.

486.10.1. Probar controles sobre trayectorias alternativas

Un ensayo del sistema puede reconstruir secuencias hipotéticas con los mismos recursos iniciales y distintos órdenes de recomendación. En el caso trabajado, permutar las tres actividades basta para que el filtro termine en cualquiera de los tres pares factibles. La prueba debe verificar que todos los recorridos respetan las restricciones y que la explicación entregada a la participante identifica la oportunidad descartada. Si una versión presenta como inevitable una elección que se debió únicamente al orden, el problema está en la justificación, aunque el filtro presupuestario funcione bien.

Conviene probar también cambios intermedios, como una reducción del tiempo disponible, una cancelación fallida o una actualización de preferencias. Estas pruebas verifican qué hace el sistema cuando tales situaciones ocurren, pero no estiman su frecuencia en el uso real, que exigiría datos apropiados; confundir ambas tareas llevaría a presentar una batería de ejemplos como evidencia estadística de seguridad. Las pruebas de concurrencia, además, deben hacerse con solicitudes simultáneas, como en el apartado 486.7, porque las llamadas sucesivas nunca exponen la ventana entre lectura y escritura.

La comparación entre trayectorias revela dependencias invisibles en acciones aisladas, como una recomendación inicial que consume justo el recurso que habría permitido atender una necesidad posterior. Si esa necesidad era previsible, conservar un margen podría haber formado parte del criterio; si era desconocida, hay que distinguir la imprevisión razonable de la omisión de información disponible. Juzgar solo el resultado con conocimiento retrospectivo atribuye a los participantes capacidades que no tenían cuando decidieron.

La reparación merece el mismo cuidado. Ante un exceso presupuestario, un sistema podría proponer cancelar la actividad más barata aunque sea la que la participante más valora. Corregir una restricción no determina por sí solo qué compromiso deshacer, y la recuperación obliga a volver sobre las preferencias y las consecuencias vigentes. El control de la trayectoria abarca así tanto la prevención como la respuesta a los fallos, y mantiene a la vista decisiones normativas que una solución técnica no puede tomar por su cuenta.

486.11. Una atribución causal no distribuye por sí sola obligaciones

Considérese una acción que solo ocurre cuando hay a la vez autorización humana y capacidad técnica de ejecutarla. En una representación binaria, el resultado es el producto de ambas condiciones, y retirar cualquiera de ellas impide la acción.

En la tabla de verdad, $Y=1$ solo cuando $H=A=1$, de modo que cada factor es necesario y ninguno es suficiente. El modelo identifica así una dependencia causal, pero no asigna la mitad de la responsabilidad a cada componente. Las obligaciones dependen de los roles, del conocimiento y de la capacidad de evitar las consecuencias, aspectos que la ecuación no representa.

La institución puede haber definido una delegación demasiado amplia, la persona puede haber elegido entre opciones incompletas o el sistema puede haber actuado fuera de sus límites, y cada situación requiere evidencia diferente. Una revisión responsable no concentra todo en el operador ni disuelve las decisiones en una entidad abstracta llamada sistema. Localiza contribuciones concretas y reconoce que las obligaciones se reparten de manera desigual según la función de cada participante. La relación propuesta por Cavalcante Siebert y colaboradores (2023) entre capacidad, autoridad y responsabilidad ofrece aquí un criterio de comprobación. Cuando la responsabilidad atribuida a alguien excede la autoridad que tenía, o su autoridad formal excede su capacidad real de ejercerla, la distribución ya estaba mal diseñada antes de cualquier fallo.

El concepto de Elish (2019) añade una advertencia sobre la atribución pública de culpa. En el caso formativo obliga a revisar las decisiones de diseño y despliegue junto con la elección final, sobre todo cuando el sistema ya había comprometido recursos o limitado alternativas antes de solicitar la aprobación.

486.12. Evaluar la trayectoria completa

La pregunta sobre quién decide puede responderse con una reconstrucción que sitúe a cada participante en momentos concretos. La institución define posibilidades y restricciones, la tutora orienta el plan dentro de su función, la participante expresa preferencias y autoriza lo que le corresponde, y el sistema transforma información y ejecuta operaciones delegadas. Esa descripción debe contrastarse con lo ocurrido, y si alguna función prevista no se ejerció o quedó impedida, el análisis tiene que mostrarlo.

Un control adecuado conserva los límites acumulativos, permite actualizar las razones y hace posible revisar compromisos antes de que se vuelvan difíciles de revertir. Su eficacia se comprueba sobre secuencias completas, con fallos de comunicación, concurrencia y cambios de contexto. El ejemplo mostró que aprobar cada acción por separado puede violar una autorización global, y que el control debe representar el estado que realmente cambia sin que otra operación pueda interponerse entre la lectura y la escritura.

La responsabilidad por la trayectoria requiere, por último, procedimientos para corregir resultados y aprender de las discrepancias. Un registro sin capacidad de reparación documenta un problema y lo deja intacto, y una revisión dedicada solo a buscar culpables pierde información sobre las condiciones que favorecieron el error. El análisis sociotécnico busca que la delegación siga siendo comprensible y que sus consecuencias puedan discutirse con quienes las experimentan.

En el caso trabajado, la revisión queda completa cuando puede explicarse qué combinación se eligió, por qué era admisible, qué alternativas quedaron fuera y quién podía modificar el recorrido en cada etapa. Si falta alguna de esas respuestas, la revisión ha localizado un problema concreto de información, de autoridad o de implementación, y puede corregirlo sin atribuir a la IA una voluntad moral ni suponer que la intervención humana, por haber existido formalmente, garantizó una decisión comprendida.

Referencias

Cavalcante Siebert, L., Lupetti, M. L., Aizenberg, E., Beckers, N., Zgonnikov, A., Veluwenkamp, H., Abbink, D., Giaccardi, E., Houben, G.-J., Jonker, C. M., van den Hoven, J., Forster, D., y Lagendijk, R. L. (2023). Meaningful human control: Actionable properties for AI system development. AI and Ethics, 3(1), 241–255. https://doi.org/10.1007/s43681-022-00167-3

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

Kung, H. T., y Robinson, J. T. (1981). On optimistic methods for concurrency control. ACM Transactions on Database Systems, 6(2), 213–226. https://doi.org/10.1145/319566.319567

Mecacci, G., y Santoni de Sio, F. (2020). Meaningful human control as reason-responsiveness: The case of dual-mode vehicles. Ethics and Information Technology, 22(2), 103–115. https://doi.org/10.1007/s10676-019-09519-w

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, 15. https://doi.org/10.3389/frobt.2018.00015