Responsabilidad, supervisión y agentes

Cuando un sistema produce un daño, la tentación es buscar el punto donde «decidió la IA».

Ese punto puede no existir.

El resultado emerge de una cadena: diseño, datos, selección de modelo, configuración, recuperación, instrucciones, permisos, uso, supervisión, decisión y ejecución. Cada paso puede ser razonable aisladamente y el conjunto resultar incoherente.

La responsabilidad jurídica necesita atribuir sin fingir simplicidad.

Explicación causal y atribución normativa

Saber qué causó técnicamente un resultado no decide quién responde.

La causalidad pregunta qué condiciones produjeron el efecto. La atribución normativa pregunta quién tenía un deber, qué riesgo debía controlar, qué conducta era exigible y qué consecuencia se anuda a su incumplimiento.

Un proveedor puede haber originado un defecto. Un integrador puede no detectarlo. La organización puede utilizar el sistema fuera de alcance. Un profesional puede validar sin revisión suficiente. Una autoridad puede haber diseñado incentivos incompatibles con el control.

La explicación completa puede ser distribuida.

La responsabilidad también puede serlo, sin quedar disuelta.

El agente no recibe personalidad por ejecutar

Un agente puede planificar y usar herramientas con autonomía operativa. Puede crear archivos, enviar mensajes, modificar registros o iniciar transacciones.

Esa capacidad no le confiere por sí misma personalidad, mandato o patrimonio.

El lenguaje de agencia técnica debe distinguirse de la agencia jurídica. La organización sigue necesitando responder:

quién habilitó la función;
con qué alcance;
en nombre de quién actúa el sistema;
qué actos puede perfeccionar;
qué confirmación se exige;
cómo se identifica frente a terceros;
y cómo se impugna o revierte.

Decir «lo hizo el agente» describe un mecanismo.

No cierra la atribución.

Autonomía por consecuencias

La autonomía no debería medirse solo por número de pasos sin intervención humana.

Importa:

amplitud de herramientas;
sensibilidad de datos;
posibilidad de afectar a terceros;
reversibilidad;
velocidad;
volumen;
capacidad de replicación;
y dificultad de detectar el error.

Un sistema que redacta cien borradores puede trabajar durante horas y tener poca autonomía material. Uno que cambia una instrucción de pago en un solo paso puede tener un radio enorme.

Gobernar agentes es gobernar consecuencias posibles.

Supervisión efectiva

La supervisión humana fracasa cuando se diseña como presencia nominal.

No es efectiva si quien revisa:

recibe más salidas de las que puede examinar;
desconoce fuentes;
no ve incertidumbre ni alternativas;
carece de tiempo;
teme contrariar el sistema o a la dirección;
no puede detener;
o sabe que su corrección será ignorada.

Una revisión efectiva exige competencia, información, independencia, tiempo y autoridad.

También una interfaz que dirija la atención hacia la diferencia relevante. Pedir que una persona relea indiscriminadamente todo lo generado destruye la ventaja y favorece la automatización complaciente.

Umbrales de actuación

La autoridad puede distribuirse por efecto:

Autonomía reversible

El sistema prepara, clasifica, organiza o simula dentro de un entorno sin efecto externo material.

Acción condicionada

Puede actuar cuando se cumplen reglas observables y existe posibilidad clara de reversión.

Confirmación humana

Requiere aprobación explícita antes de comunicar, comprometer, presentar, pagar, borrar, revelar o alterar derechos.

Doble control

Actos de especial sensibilidad exigen dos funciones o personas independientes.

Prohibición

Determinadas decisiones o datos quedan fuera, aunque técnicamente sean accesibles.

El umbral no debe fijarse una sola vez. Puede bajar ante incidentes, cambios de modelo, nueva jurisdicción o pérdida de observabilidad.

Delegación y no delegación

Delegar una función no elimina el deber de elegir y vigilar cuando ese deber existe.

Pero tampoco es riguroso afirmar que toda salida debe ser rehecha por completo por una persona. Si la supervisión exige repetir el trabajo, no se ha diseñado una división funcional.

La arquitectura debe determinar qué aporta cada parte:

el sistema recupera y compara;
una prueba automatizada verifica formatos o citas;
un profesional evalúa pertinencia y estrategia;
otra autoridad aprueba el acto;
un registro conserva el recorrido.

La responsabilidad se sostiene mediante especialización trazable, no mediante ficción de autosuficiencia humana.

Defecto, servicio y conducta

Un daño relacionado con IA puede activar regímenes distintos: responsabilidad contractual, extracontractual, profesional, de producto, laboral, administrativa o sectorial.

La Directiva europea de responsabilidad por productos defectuosos de 2024 incluye software dentro de su marco y moderniza reglas de prueba y divulgación para productos complejos; su aplicación concreta depende de transposición, fechas y hechos.[^23]

No todo output erróneo es un producto defectuoso. No todo sistema se agota en un servicio. No toda pérdida nace de defecto técnico. La calificación exige reconstruir objeto, control, actualización, expectativa legítima de seguridad, uso y causalidad.

La inteligencia simbiótica añade una dificultad: el valor y el riesgo pueden residir en la configuración conjunta. El contrato y el gobierno deben hacer visible quién mantiene esa configuración y bajo qué estándar.

Logs que permitan comprender

Registrar todo no garantiza explicabilidad.

Un log útil conserva eventos necesarios para reconstruir:

versión de componentes;
fuente y contexto habilitados;
instrucción relevante;
herramientas utilizadas;
salida material;
pruebas realizadas;
intervención humana;
autorización;
acción;
y resultado.

Debe evitar, a la vez, registrar indiscriminadamente secretos y datos que aumentan el daño potencial.

La trazabilidad es selectiva. Se diseña desde preguntas de responsabilidad e investigación de incidentes.

Reparación

Un sistema responsable no se limita a impedir daño. Debe poder reconocerlo y responder.

La reparación puede exigir:

detener;
preservar evidencia;
revertir;
notificar;
corregir datos o decisiones;
ofrecer revisión humana;
compensar;
explicar;
y modificar la arquitectura para evitar repetición.

Cuando un tercero recibe un efecto, necesita un canal inteligible para cuestionarlo. La organización no puede esconderse detrás de complejidad técnica ni obligar al afectado a demostrar el funcionamiento interno al que no tiene acceso.

Responsabilidad sin ego

Los incidentes activan defensa institucional. El proveedor culpa al uso, el usuario al modelo, el equipo a los datos y la dirección a una excepción imprevisible.

La investigación queda capturada por identidades que necesitan no ser causa.

Una respuesta sin ego no elimina garantías ni derecho de defensa. Separa aprendizaje causal de atribución sancionadora lo suficiente para comprender el sistema, sin convertir esa separación en impunidad.

La pregunta inicial no es «¿quién pierde?».

Es «¿qué relación permitió el efecto y cómo impedimos que continúe?».

Después el Derecho realiza los cortes que correspondan.

Árbol de reconstrucción del incidente

Ante un efecto adverso conviene evitar la pregunta prematura «¿falló el modelo?». La reconstrucción puede recorrer seis capas.

1. Efecto

Qué ocurrió, a quién, cuándo y con qué alcance. Separar daño, riesgo, incumplimiento e insatisfacción.

2. Acto material

Qué comunicación, decisión, clasificación, pago, borrado, acceso o recomendación produjo la alteración.

3. Cadena operativa

Qué pasos precedieron al acto, qué herramientas se usaron y dónde pudo haberse detenido.

4. Información y modelo

Qué entradas, fuentes, versiones, instrucciones y salidas intervinieron; qué incertidumbre era visible.

5. Organización

Qué roles, incentivos, volumen, formación, supervisión y excepciones condicionaron el uso.

6. Gobierno y relación externa

Qué proveedor, contrato, norma, evaluación y cambio definían el control disponible.

El árbol permite que un error de output se revele como fallo de fuente, interfaz, autoridad o carga. También puede mostrar que el modelo produjo una salida contraria a controles razonables.

Preservar evidencia sin congelar el daño

La respuesta debe equilibrar dos necesidades:

conservar materiales suficientes para investigar y defender derechos;
detener el procesamiento o acceso que prolonga el efecto.

No siempre conviene apagar todo el sistema. Puede aislarse una función, revocar una herramienta, bloquear un conjunto de datos o volver a operación manual. La decisión debe registrar por qué el alcance es suficiente.

La preservación incluye versiones de modelo y configuración cuando sean accesibles, logs pertinentes, fuentes, autorizaciones y comunicaciones. No justifica copiar indiscriminadamente datos sensibles «por si acaso».

Autoridad de suspensión

Un control solo existe si alguien puede activarlo sin sufrir una barrera imposible.

La organización debe saber:

quién puede suspender;
qué señales bastan;
qué funciones se detienen;
quién recibe aviso;
cómo se mantiene una alternativa;
qué autoridad permite reanudar;
y qué evidencia se exige.

Si únicamente la dirección que patrocinó el proyecto puede detenerlo, un conflicto reputacional puede retrasar la contención. Si cualquiera puede apagarlo todo sin graduación, el control será evitado.

Derecho a impugnar la forma

Quien recibe un efecto debería poder cuestionar no solo el dato final, sino la configuración que lo produjo cuando resulte relevante.

Puede alegar que:

faltaba información;
la finalidad era otra;
el sistema no debía intervenir;
la supervisión fue nominal;
el criterio discriminaba;
o la reparación propuesta no alcanza.

La organización necesita un canal que traduzca esa impugnación a revisión de caso y, cuando proceda, de arquitectura.

Una corrección individual que no examina la regla puede repetir el daño. Una reforma general que ignora el caso puede negar reparación.

La responsabilidad conecta ambos niveles.