La institución no puede delegar su responsabilidad en la máquina

Rauf, el padre de Dilan Acar, ha permanecido doce días en el hospital tras sufrir una enfermedad respiratoria grave. La parte hospitalaria del tratamiento ha concluido. Sin embargo, durante las dos primeras semanas posteriores al alta debe disponer en casa de un dispositivo de asistencia respiratoria prescrito por el médico, controles periódicos de enfermería, seguimiento de la medicación y una línea de atención domiciliaria a la que recurrir en caso de emergencia. El hospital que trata a Rauf pertenece a Mira Sağlık Ağı, un gran grupo sanitario privado. Para acelerar las altas y reducir la carga de trabajo del personal hospitalario, Mira Sağlık Ağı utiliza un sistema asistido por inteligencia artificial: Continuum Care Orchestrator. El sistema lleva a cabo conjuntamente las siguientes operaciones:

• Lee las instrucciones de alta del médico
• Consulta la cobertura del seguro del paciente
• Comprueba los dispositivos médicos suministrados con anterioridad
• Envía un pedido a la empresa de atención domiciliaria
• Programa las visitas de enfermería
• Envía mensajes informativos al paciente y a sus familiares
• Cuando se completan las operaciones necesarias, asigna al paciente el estado:

Discharge ready. El sistema no fue creado por una sola empresa.

1. La arquitectura es la siguiente: Mira Sağlık Ağı
2. ↓
3. ArdaTek Sağlık Entegrasyon Hizmetleri
4. ↓
5. Continuum Care Orchestrator
6. ↓
7. Helix Genel Amaçlı Yapay Zekâ Modeli
8. ↓
9. Birlik Sağlık Güvencesi Veri Servisi
10. ↓
11. EvDestek Tıbbi Cihaz ve Bakım Hizmetleri

Cada institución controla solo una parte del sistema. Mira Sağlık Ağı gestiona la relación con el paciente. ArdaTek creó los agentes y los flujos de trabajo. Helix proporciona el modelo fundacional que resume los documentos. Birlik Sağlık Güvencesi envía los registros históricos de dispositivos médicos. EvDestek entrega el dispositivo. El médico de Rauf introduce esta instrucción en el plan de alta: «No se dará de alta al paciente hasta que se le proporcione un dispositivo domiciliario de asistencia respiratoria. La primera visita de enfermería deberá realizarse en las veinticuatro horas siguientes al alta».

La instrucción se registra correctamente en el sistema hospitalario. Continuum Care Orchestrator consulta el servicio de datos de Birlik Sağlık Güvencesi. El servicio responde:

patient_has_active_home_respiratory_device: true
provider: EvDestek
record_date: 7 months ago

El registro está desactualizado. Rauf utilizó brevemente un dispositivo del mismo tipo siete meses antes y lo devolvió a EvDestek hace cuatro meses. Sin embargo, la devolución no se incorporó al registro central de la aseguradora. Los datos no dicen: «El dispositivo se suministró anteriormente». Dicen: «El dispositivo sigue activo en el domicilio del paciente». Continuum Care Orchestrator interpreta este campo como:

duplicate_device_order_risk: high

Continuum Care Orchestrator interpreta así el registro. Una de las políticas de control de costes de Mira Sağlık Ağı establece:

IF active_equipment_record_exists
THEN
do_not_create_duplicate_order
use_existing_equipment

La política se diseñó para evitar que se cobrara dos veces a los pacientes por el mismo dispositivo. Pero la regla carece de las siguientes comprobaciones:

• La antigüedad del registro
• Si el dispositivo se encuentra realmente en poder del paciente
• La posibilidad de que el dispositivo haya sido devuelto
• La prioridad de una instrucción nueva y expresa del médico frente al registro antiguo
• La verificación física con el paciente o un familiar
• La prueba de entrega antes del alta

El sistema no crea un nuevo pedido de equipo. Su registro interno dice:

new_device_order:
suppressed
reason:
active_equipment_already_available

En la pantalla del médico solo aparece este estado: Home respiratory support: covered No queda claro si covered significa que existe cobertura del seguro, que se hizo un pedido, que el dispositivo se entregó o que se encuentra realmente en el domicilio del paciente. En el panel de la enfermera de altas aparece una marca verde: ✓ Home support confirmed Ese día, la enfermera gestiona los expedientes de alta de treinta y un pacientes. Confía en el estado verde y no pregunta por separado si el dispositivo está realmente en casa de Rauf.

Continuum Care Orchestrator envía a EvDestek una solicitud de visita de enfermería. El sistema de EvDestek acepta la solicitud:

HTTP 202
visit_request_received

El agente registra esta aceptación técnica como:

home_nurse_visit_confirmed: true

En realidad, la visita todavía no se ha asignado a ninguna enfermera. EvDestek no dispone de capacidad durante el fin de semana y se espera que la solicitud se programe el siguiente día laborable. Continuum Care Orchestrator envía a Dilan este mensaje: «Los preparativos de atención domiciliaria y asistencia respiratoria para su padre han concluido. Se ha programado su primera visita posterior al alta». El mensaje no indica que no se hizo un nuevo pedido del dispositivo, que el sistema supone que el antiguo sigue en el domicilio ni que la visita de enfermería solo se encuentra en fase de solicitud. Rauf recibe el alta. Dilan lleva a su padre a casa. Allí no hay ningún dispositivo de asistencia respiratoria.

Dilan llama al hospital. La pantalla del centro de atención muestra: Home equipment: active Nurse visit: confirmed Discharge plan: completed La persona que la atiende dice: «Nuestro sistema muestra que han concluido todos los preparativos de atención domiciliaria. Debe hablar con el proveedor del dispositivo». Dilan llama a EvDestek. Una persona del equipo comprueba los registros: «No hay ningún pedido de un nuevo dispositivo. El sistema solo nos envió una solicitud de visita de enfermería». Dilan responde: «El hospital dijo que el dispositivo estaba listo». EvDestek contesta: «Es posible que el hospital no hiciera un nuevo pedido porque el sistema del seguro muestra un dispositivo activo. Debe hablar con su aseguradora».

Dilan llama a Birlik Sağlık Güvencesi. Una persona del equipo le dice: «Nosotros solo comunicamos a los centros sanitarios el registro existente del dispositivo. No somos responsables de la entrega física. El proveedor del dispositivo debía haber actualizado la devolución». Dilan vuelve a llamar a EvDestek. EvDestek responde: «La devolución figura cerrada en nuestro sistema. No sabemos por qué no se actualizó la sincronización de datos de la aseguradora». Dilan contacta otra vez con Mira Sağlık Ağı. El centro de atención del hospital dice: «El médico adoptó la decisión de alta. Debe hablar con él». La secretaria del médico responde: «El médico escribió expresamente que no debía darse de alta al paciente sin el dispositivo. El médico no gestiona el proceso de suministro».

En pocas horas, Dilan ha hablado con varias instituciones y departamentos. Cada uno apunta a un fragmento que parece correcto en su propio sistema. Ninguno responde a la pregunta central:

“¿Quién fue responsable de garantizar que el dispositivo estuviera realmente en la casa?”

Esa tarde, el estado de Rauf empeora. Dilan llama a emergencias. Rauf vuelve al hospital y permanece otras dos noches en observación. No sufre un daño físico grave y permanente. Pero se producen una nueva intervención de emergencia, una estancia hospitalaria adicional, un miedo y un agotamiento intensos para la familia, la necesidad de que Dilan se ausente del trabajo y gastos de transporte y cuidados. Esta vez, Mira Sağlık Ağı abre una investigación del incidente.

En la primera reunión, el equipo de salud digital del hospital dice: «El problema se debió a que el sistema Continuum interpretó erróneamente un registro antiguo del seguro. Lo hemos comunicado al proveedor del software». ArdaTek Sağlık Entegrasyon Hizmetleri responde: «El agente aplicó correctamente la regla de negocio aprobada por Mira Sağlık Ağı. No generar un nuevo pedido cuando existe un registro de dispositivo activo forma parte de la política de costes del hospital». El proveedor del modelo Helix declara: «Nuestro modelo se ofrece únicamente para resumir documentos. No recomendamos adoptar decisiones clínicas o de alta sin supervisión humana independiente».

Birlik Sağlık Güvencesi dice: «Los datos proceden del estado del dispositivo comunicado por EvDestek. Nosotros no somos el sistema de origen». EvDestek dice: «La devolución figura registrada en nuestro sistema. La sincronización con el flujo de datos de la aseguradora es responsabilidad del proveedor externo. No entregamos ningún dispositivo porque no recibimos un nuevo pedido». La enfermera de altas dice: «Todos los indicadores de mi pantalla estaban en verde. No podía ver los detalles que había detrás del sistema». El médico dice: «Escribí expresamente que no debía darse de alta al paciente sin el dispositivo. No sabía que una regla automática de costes había neutralizado mi instrucción». La persona del centro de atención dice: «La pantalla mostraba que todo había concluido. Yo no tenía acceso al sistema de suministro».

Todos explican una parte del sistema. Nadie se apropia de la conducta como un todo.

Se examinan los contratos. El acuerdo entre Mira Sağlık Ağı y ArdaTek establece: «El cliente es responsable de las reglas de negocio que configura y del uso clínico de los resultados del sistema». El acuerdo entre ArdaTek y Helix dice: «Los resultados del modelo se proporcionan únicamente con fines informativos; las decisiones finales son responsabilidad de la institución usuaria». Las condiciones del servicio de datos de la aseguradora dicen: «No se garantiza la actualidad de los registros de terceros suministrados». El contrato de EvDestek dice: «Solo somos responsables de los pedidos verificados y activos». Las condiciones de atención al paciente de Mira Sağlık Ağı indican: «En determinados procesos de coordinación asistencial pueden utilizarse sistemas de automatización e inteligencia artificial de terceros».

Cada contrato empuja la responsabilidad hacia otro actor. Alrededor de la cadena técnica pasa del hospital al integrador, del integrador al proveedor de modelos, del proveedor de modelos al hospital, del hospital al proveedor de datos, del proveedor de datos a la compañía de equipos y de la compañía de equipos al hospital. La responsabilidad se ha convertido en un círculo, con Rauf y Dilan en el centro.

Mira Sağlık Ağı quiere describir el incidente como un «error de sincronización de datos de terceros». Pero esa expresión no refleja toda la realidad. Los datos antiguos fueron el primer error, aunque para que se produjera el daño tuvieron que concurrir otras condiciones:

• El hospital estableció una política en la que un registro antiguo podía dejar sin efecto una nueva instrucción médica
• El sistema no verificó la presencia física del dispositivo
• Los estados «cobertura del seguro», «pedido realizado» y «dispositivo entregado» se combinaron en un único indicador verde
• La recepción técnica de la solicitud de atención domiciliaria se presentó como si la visita estuviera confirmada
• No se mostró a la enfermera la incertidumbre real
• La regla automática de costes anuló en silencio la instrucción expresa del médico
• El centro de atención no podía acceder al sistema externo que contenía la situación real
• No se designó a ninguna persona o institución como responsable del resultado completo del alta
• El sistema no buscó pruebas de la entrega real del dispositivo antes de dar de alta al paciente
• Cuando ocurrió el incidente, la familia no pudo acceder a una única vía de tutela con un responsable

Los datos antiguos eran erróneos, pero no dieron de alta a Rauf por sí solos. El modelo tampoco lo hizo por sí solo. El integrador no gestionaba por sí solo la relación con el paciente. La enfermera no diseñó el sistema. El médico no gestionaba por sí solo la cadena de suministro. EvDestek no podía entregar el dispositivo sin recibir un pedido. La conducta completa surgió dentro de un sistema institucional. Mira Sağlık Ağı:

• eligió el sistema
• lo vinculó con el proceso del paciente
• aprobó las reglas de negocio
• mostró al personal la pantalla de estado en verde
• dio al agente facultades dentro del flujo de trabajo del alta
• obtuvo de la automatización beneficios de tiempo y costes
• dio de alta a Rauf en su propio nombre

Por lo tanto, el hospital no puede terminar el asunto diciendo: “La IA cometió un error”. La pregunta correcta es:

«¿Quién dio a esta inteligencia artificial el poder de actuar en el proceso de alta de Rauf?»

Y la segunda pregunta es:

“Cuando ese poder cause daño, ¿quién rendirá cuentas ante Rauf?”

Nuestra decimotercera y última disposición fundacional es, por lo tanto:

Una institución no puede transferir la responsabilidad a una máquina.

ARTÍCULO FUNDACIONAL

Una institución puede dar a un sistema de inteligencia artificial tareas, datos, herramientas, presupuesto, facultades de representación y poder de actuación; pero no puede delegarle la responsabilidad de asumir, supervisar, explicar, detener, corregir y reparar las consecuencias materiales sobre las personas. La conducta de un sistema de inteligencia artificial que actúa en nombre de una institución forma parte de la cadena de conducta institucional. Expresiones como «El modelo decidió», «El agente lo envió», «La herramienta lo aplicó automáticamente» o «Así funcionó el sistema del subproveedor» no eliminan la responsabilidad humana e institucional. Antes de entrar en uso real, todo sistema de inteligencia artificial de alto impacto debe vincularse con una institución principal identificada, responsables humanos facultados, facultades de detención, una persona responsable del incidente, una responsable de la vía de tutela y capacidad de reparación.

Si no pueden identificarse una persona y una institución responsables de la finalidad, los datos, el modelo, las facultades, la revisión humana, la acción externa, el incidente o la reparación de una conducta de alto impacto, el sistema no puede desplegarse ni seguir funcionando en ese ámbito. El sistema de inteligencia artificial no puede presentarse como único responsable final, como actor que acepta el riesgo residual, responsable de la vía de tutela humana, obligado a pedir disculpas y reparar en nombre de la institución ni como autoridad que cierra el incidente. La tarea puede delegarse en un proveedor externo. El componente técnico puede ser de código abierto. El modelo fundacional puede proceder de otra institución. Los datos pueden venir de un tercero. Una persona puede pulsar el último botón. Pero ninguno de estos elementos elimina la carga de gobernanza necesaria de la institución que utiliza el sistema sobre las personas.

La responsabilidad compartida no es una responsabilidad reducida. Si varias instituciones contribuyeron de formas distintas al mismo daño, cada una puede asumir responsabilidad en proporción a su control, conocimiento, beneficio y capacidad de corrección. No puede obligarse a la persona a resolver por sí misma ese reparto interno. Las instituciones pueden regular mediante contratos la carga económica y operativa entre ellas. Pero ningún contrato, renuncia, limitación de responsabilidad, condición de uso, informe de auditoría, certificado o distintivo puede eliminar la vía de la persona hacia la explicación, la impugnación, la detención, la corrección y la reparación.

La defensa institucional de que «una persona adoptó la decisión final» solo tiene sentido si esa persona dispuso de información real, tiempo suficiente, posibilidad de evaluar de forma independiente y facultades para modificar el resultado. Si únicamente pulsó el indicador verde del sistema o se le ocultó información crítica, la responsabilidad no puede cargarse sobre una figura humana decorativa. Es posible que una persona o usuaria haya utilizado deliberadamente el sistema de forma abusiva; en ese caso, el reparto de responsabilidades puede cambiar. Pero las condiciones generales de uso o la frase «Usted pulsó el último botón» no constituyen un escudo general frente a riesgos previsibles, diseño manipulador, controles de acceso débiles o automatización no autorizada de la institución.

Si una institución sabe que el proveedor elegido no puede ofrecer rastro de decisiones, recibos de acciones, corrección, eliminación, detención, control de versiones o asistencia ante incidentes, no debe construir con ese proveedor una conducta de alto impacto. Elegir un componente que no puede auditarse también es una decisión institucional. La institución puede aceptar expresamente riesgos residuales conocidos mediante una decisión humana facultada, para un alcance y un plazo definidos. La máquina no puede aceptar el riesgo residual, trasladarlo en silencio al personal o a las personas afectadas ni volverlo invisible en las condiciones generales del servicio. Cuando se confirma una conducta errónea o no autorizada, la institución no puede limitarse a reparar el fallo técnico. Debe identificar a las personas afectadas, detener el daño en curso, corregir las decisiones y los registros vinculados, gestionar por sí misma la cadena de proveedores externos, ofrecer una reparación adecuada y buscar a otras personas afectadas por la misma causa raíz.

Corregir el código no cierra el incidente. No puede cerrarse hasta que se hayan evaluado los efectos materiales sobre las personas, se haya completado la vía de tutela, se haya asumido expresamente el riesgo residual y se haya vuelto a probar la causa raíz. La institución que obtiene beneficios económicos, operativos o públicos de un sistema de inteligencia artificial debe asumir también los costes de gobernanza, auditoría, revisión humana, gestión de incidentes y reparación de ese poder. El beneficio de la automatización no puede quedar para la institución mientras el coste del error recae únicamente sobre la persona.

¿Qué es la responsabilidad institucional?

En este libro, la palabra «responsabilidad» no alude únicamente a la culpa o a una obligación indemnizatoria en un ordenamiento jurídico concreto. Las consecuencias jurídicas pueden evaluarse por separado según el país, el contrato, la normativa y las pruebas del caso. Para NOMOS 13, la responsabilidad institucional es un concepto más fundamental. Su definición canónica es esta: la responsabilidad institucional es la obligación de la institución que otorga poder de actuación a un sistema de inteligencia artificial de definir correctamente la finalidad y los límites de esa conducta, prever sus riesgos, identificar responsables humanos, seguir sus resultados reales, intervenir cuando hay un error, ofrecer a la persona afectada una explicación y una vía de tutela, corregir los sistemas vinculados y reparar de forma adecuada el efecto material producido.

En términos más simples:

Mientras una institución opere la máquina, no puede desaparecer de la cadena de responsabilidad por la conducta de la máquina en la vida de las personas.

La responsabilidad no es lo mismo que la culpa

Una institución puede asumir la responsabilidad sin ser el único actor culpable, la única causa material o la única parte requerida para proporcionar reparación en todos los casos. En el caso de Rauf, por ejemplo:

• El proveedor de datos contribuyó con el registro de equipos obsoletos.
• El integrador no implementó una comprobación de frescura.
• El hospital aprobó la política que anuló las instrucciones del médico.
• La interfaz le dio a la enfermera una falsa confianza.
• Se presentó una solicitud de atención domiciliaria que simplemente había sido aceptada como completa.
• Los equipos de apoyo humano no podían ver la cadena como un todo.

Pueden haber contribuido varios actores. Eso no significa que ninguno sea responsable. VARIOS ACTORES ≠ AUSENCIA DE RESPONSABILIDAD

Responsabilidad, rendición de cuentas y reparación

Estos tres conceptos se pueden distinguir.

Responsabilidad

Responsabilidad significa asumir los deberes necesarios antes y durante la conducta: "¿Quién debe garantizar que este sistema funcione de manera segura y respete los derechos de las personas?"

Rendición de cuentas

Rendición de cuentas significa ser capaz de explicar lo que sucedió después del incidente y respaldar la decisión: “¿Quién defenderá esta conducta, o reconocerá que fue incorrecta, y sobre la base de qué decisión y evidencia?”

Reparación

Reparar consiste en corregir el efecto del error en la vida de la persona. «¿Quién restablecerá la situación correcta y quién evaluará los efectos irreversibles?». Una institución puede explicar lo ocurrido sin ofrecer reparación. Puede pagar dinero sin corregir la causa raíz. Puede corregir el sistema sin ponerse en contacto con las personas afectadas. La responsabilidad plena abarca conjuntamente todos estos ámbitos.

¿Qué es una institución?

En NOMOS 13, la palabra ‘institución’ no significa solo una gran empresa. Puede incluir:

• Empresa
• Organismo público
• Hospital
• Universidad
• Plataforma
• Asociación o fundación
• Organización profesional
• Empresa individual
• Proveedor de servicios que opera un agente de alto impacto en nombre de una persona
• Servicio conjunto de varias organizaciones

Antes de las preguntas de forma o título legal, la pregunta fundamental es:

¿Quién introdujo la conducta de la IA en la relación humana?

Principal institucional

Podemos llamar principal institucional a la institución en cuyo nombre actúa un sistema de inteligencia artificial frente a las personas. El principal institucional suele reunir una o varias de estas características:

• Establece la relación de servicio o de trabajo con la persona
• Define la finalidad de la inteligencia artificial
• Elige el sistema o proveedor
• Conecta los datos y las herramientas
• Se beneficia del resultado de la conducta
• Define los límites de las facultades
• Puede detener o modificar el sistema
• Puede ofrecer a la persona corrección y reparación
• La conducta tiene lugar bajo su marca o cuenta

En el caso de Rauf, el principal institucional es:

Mira Sağlık Ağı.

ArdaTek y los demás proveedores pueden tener responsabilidades propias. Pero Rauf fue admitido, tratado y dado de alta por el hospital; recibió del hospital el mensaje de que la atención domiciliaria estaba preparada. Mira Sağlık Ağı no puede abandonar la responsabilidad por la relación con el paciente diciendo: «Hable usted mismo con el integrador».

Puede haber más de un principal institucional

Un servicio puede realmente ser operado conjuntamente. Por ejemplo:

• Un banco y una compañía de seguros pueden usar un agente compartido.
• Un municipio y un proveedor de servicios privados pueden tomar decisiones juntos.
• Una empresa matriz y una subsidiaria pueden operar el mismo sistema de datos.

En esos casos, más de una institución puede asumir responsabilidad. Pero la persona no debe encontrarse ante una sucesión interminable de puertas que dicen «No es competencia nuestra». Las instituciones deben establecer entre ellas un único punto de solicitud, un proceso de intercambio del expediente y un reparto de la reparación.

La conducta de la máquina en nombre de una institución es conducta institucional

Si un agente de inteligencia artificial actúa desde la cuenta de correo electrónico, el sitio web, el instrumento de pago, el sistema de altas o el portal de clientes de una institución, esa conducta no puede separarse de la institución como «acción privada de la máquina». La institución puede haber utilizado al agente como herramienta. El agente puede haber adquirido cierto grado de autonomía. Pero su conducta hacia las personas en el mundo exterior forma parte de las operaciones de la institución. CONDUCTA DE UN AGENTE FACULTADO EN NOMBRE DE LA INSTITUCIÓN = CADENA DE CONDUCTA INSTITUCIONAL

La autonomía no reduce la responsabilidad

Cuanto más autónomo es un sistema, mayor importancia adquieren las obligaciones de la institución de fijar límites de antemano, ofrecer visibilidad, vigilar la conducta y establecer capacidades de detención y reparación. Esta relación es errónea: MAYOR AUTONOMÍA DEL AGENTE → MENOR RESPONSABILIDAD INSTITUCIONAL La relación correcta es esta: A MEDIDA QUE AUMENTA EL PODER DE ACTUACIÓN DEL AGENTE, TAMBIÉN DEBEN AUMENTAR LA GOBERNANZA INSTITUCIONAL Y LA CARGA PROBATORIA

La brecha de responsabilidad

Una brecha de responsabilidad surge cuando todos señalan a otro actor y nadie puede detener, explicar, corregir o remediar la conducta. Su definición canónica es la siguiente: existe una brecha de responsabilidad cuando la conducta material producida a través de la IA involucra a muchos actores técnicos, pero ninguna institución real o papel humano se presenta ante la persona afectada con la propiedad del resultado y el poder de cambiarlo y repararlo. Una brecha de responsabilidad no es una consecuencia natural de la complejidad técnica. Es un fracaso del diseño de la gobernanza.

El círculo de la responsabilidad

Cuando cada actor dirige la pregunta a otro, se forma un círculo de responsabilidad. INSTITUCIÓN → PROVEEDOR PROVEEDOR → INTEGRADOR INTEGRADOR → FUENTE DE DATOS FUENTE DE DATOS → INSTITUCIÓN USUARIA INSTITUCIÓN USUARIA → INTELIGENCIA ARTIFICIAL La persona queda atrapada dentro del círculo. El mapa de responsabilidades debe romperlo antes de que se produzca la conducta.

Lavado de responsabilidades

Podemos llamar blanqueo de responsabilidad al intento de una institución de ocultar que es responsable de su propia conducta detrás de otro actor, una tecnología, un contrato o una acción humana.

Trece formas de lavado de responsabilidades

1. El escudo del modelo «El modelo decidió». Desaparece de la vista la institución que eligió, conectó y utilizó el modelo.

2. El Escudo del Proveedor

“Es software de terceros”. La decisión de utilizar a un tercero se presenta como si no fuera una decisión institucional.

3. El Escudo de la Fuente de Datos

"La información inexacta vino de una fuente externa". El deber de verificar los datos antes de usarlos en las decisiones sobre una persona se olvida.

4. El escudo de aprobación humana

«Una persona del equipo pulsó el último botón». Nadie examina qué información, tiempo y capacidad real para modificar el resultado tenía esa persona.

5. El escudo de elección del usuario

«La persona usuaria lo aceptó». Se ocultan la arquitectura de elección, la información omitida y la manipulación.

6. El escudo del contrato

«Las condiciones indicaban que podía utilizarse automatización». El texto general ocupa el lugar de la responsabilidad por la conducta concreta.

7. El escudo del certificado

“El sistema fue auditado y certificado”. El alcance y la fecha de la auditoría, y la responsabilidad después del incidente, desaparecen de la vista.

8. El escudo de código abierto

“El componente era libre y de código abierto”. La decisión de la institución de utilizarlo en un entorno crítico se trivializa.

9. El escudo de la autonomía

“El agente tomó su propia decisión”. La institución que le dio al agente el poder de decidir en ese dominio desaparece de la vista.

10. El escudo de la complejidad

«El sistema es demasiado complejo; no puede determinarse la causa exacta». No se cuestiona a la institución que decidió utilizar en vivo un sistema que no podía explicar.

11. El escudo del grupo empresarial

“La marca nos pertenece, pero el servicio es operado por una subsidiaria”. La persona es enviada de ida y vuelta entre las personas jurídicas y los equipos operativos.

12. El Escudo de Seguros

“El incidente está cubierto por un seguro”. La cobertura financiera se sustituye por los deberes de corregir la causa raíz y responder a la persona afectada.

13. El escudo de la etiqueta de inteligencia artificial

«Este contenido fue generado por inteligencia artificial y puede contener errores». La advertencia se utiliza para eliminar la obligación institucional de exactitud y reparación.

La responsabilidad compartida no es una irresponsabilidad fragmentada

La responsabilidad puede compartirse realmente en sistemas donde intervienen varios actores. Pero el reparto correcto debe adoptar esta forma: ACTOR A: Exactitud de los datos bajo su control ACTOR B: Integración y correspondencia de estados ACTOR C: Finalidad institucional, facultades y proceso humano ACTOR D: Acción externa y entrega COMPARTIDA: Cooperación ante incidentes e intercambio de pruebas

1. El reparto incorrecto es este: TODOS HABLAN ÚNICAMENTE DE SU PEQUEÑA PARTE
2. ↓
3. NADIE ASUME LA RESPONSABILIDAD POR EL RESULTADO COMPLETO SOBRE LA PERSONA

¿Cómo se debe asignar la responsabilidad?

No es necesario que la responsabilidad se divida por igual entre todos los actores. Cinco criterios pueden guiar su asignación:

• 1. Control
• 2. Conocimiento
• 3. Beneficios
• 4. Previsibilidad
• 5. Capacidad para corregir

1. Control

¿Hasta qué punto podía el actor modificar el sistema, la regla, los datos o la acción?

2. Conocimiento

¿Conocía el actor los riesgos y limitaciones o cabía razonablemente esperar que los conociera?

3. Beneficios

¿Quién obtuvo el beneficio económico, operativo o público de la automatización?

4. Previsibilidad

¿Podría haberse previsto razonablemente este tipo de error o mal uso?

5. Capacidad para corregir

¿Quién puede detener, corregir o reparar las consecuencias que afectan a la persona? Estos criterios hacen visible la responsabilidad. Una cláusula de contrato técnico no determina, por sí misma, toda la asignación.

Responsabilidades de los principales actores

Cada actor de la cadena de inteligencia artificial puede tener obligaciones distintas.

1. La institución que utiliza el sistema

• Define la finalidad del uso
• Elige el ámbito de alto impacto
• Conecta al proveedor y los datos
• Establece los límites de las facultades
• Diseña la revisión humana
• Aplica la conducta dentro de su propia relación
• Ofrece a la persona una vía de tutela y reparación

Normalmente, aquí se encuentra la primera responsabilidad frente a la persona.

2. El integrador

• Conecta correctamente los componentes
• Preserva el significado de los estados y errores
• Aplica controles de facultades, detención y recibos
• Explica a la institución usuaria las limitaciones técnicas conocidas
• No diseña una interfaz que genere una confianza falsa
• Ofrece pruebas y apoyo para la corrección durante el incidente

3. Proveedor del modelo o la herramienta

• Describe con exactitud las capacidades y limitaciones relevantes del sistema
• No oculta los ámbitos de uso no admitidos
• Comunica los cambios relevantes de versión
• Ofrece seguridad, procedencia, registros y cooperación ante incidentes
• No formula afirmaciones engañosas para los clientes como:

«Es seguro en todas las situaciones». El proveedor no es automáticamente responsable de todos los usos de todos sus clientes. Sin embargo, puede ser responsable de las afirmaciones falsas y los defectos técnicos que se encuentren bajo su control.

4. El proveedor de datos

• Acompaña los datos con su fuente, fecha y límites de actualidad
• No confunde «existió en el pasado» con «sigue activo»
• Facilita la propagación de correcciones e impugnaciones a los sistemas posteriores
• No presenta un registro incompleto o estimado como un hecho cierto

5. Proveedor de acciones externas

• Muestra con exactitud qué solicitud recibió y cuál fue el resultado real
• Ofrece vías de cancelación y reversión
• No oculta los efectos secundarios
• Durante un incidente, comparte las pruebas necesarias en lugar de limitarse a devolver a la persona a la institución

6. El operador humano

Una persona del equipo puede tener la obligación de actuar con diligencia dentro de sus facultades, comunicar los riesgos que observa y no infringir deliberadamente las reglas conocidas. Pero quien trabaja con información incompleta, un panel verde engañoso, una carga excesiva y sin facultades para modificar el resultado no puede convertirse en chivo expiatorio solo por haber pulsado el último botón.

7. El auditor o certificador

La persona auditora emite una opinión sobre un alcance, una versión, una fecha y unas pruebas concretos. No garantiza toda conducta futura del sistema. La entidad auditora no asume la responsabilidad por el funcionamiento en vivo.

8. El usuario o la persona afectada

Una persona puede proporcionar deliberadamente información falsa, eludir un control de seguridad, hacer un mal uso de un agente o ignorar a sabiendas una advertencia clara. Eso puede alterar la asignación de responsabilidad, pero la conclusión debe basarse en pruebas específicas. Una etiqueta genérica de «error de usuario» no borra las funciones de diseño y gobernanza de la entidad.

¿Quién es responsable cuando un humano presiona el botón final?

Esta pregunta no admite una respuesta de una sola frase. ¿Vio la persona los datos necesarios? ¿Comprendió la incertidumbre? ¿Dispuso de tiempo suficiente? ¿Podía modificar la recomendación de la máquina? ¿Habría sufrido represalias si la rechazaba? ¿Tenía que aprobar mecánicamente cientos de operaciones? ¿Podía ver la información que el sistema ocultaba? Si la persona se limitó a pulsar el indicador ✓ Ready, no puede descargarse sobre ella toda la responsabilidad institucional.

El humano decorativo

Podemos llamar persona decorativa al papel que aparenta incorporar aprobación humana aunque la persona carezca de información real y capacidad para modificar el resultado. La figura decorativa permite a la institución afirmar que «había una persona en el circuito», pero no controla realmente la conducta. Después no puede convertirse en la única culpable del incidente.

Cuando una persona viola claramente las reglas

Un empleado puede haber visto una advertencia precisa, tener suficiente tiempo y autoridad, y deliberadamente eludido el sistema. La responsabilidad personal e institucional puede entonces necesitar ser evaluada conjuntamente. Aun así, la institución debe responder:

• ¿Por qué era técnicamente posible la elusión?
• ¿Por qué la acción crítica no requirió doble control?
• ¿Por qué la conducta no se detectó antes?
• ¿Qué hizo la institución después del incidente?

El código abierto no es un escudo de responsabilidad

Una institución puede usar un modelo o agente de código abierto. Hacerlo puede reducir costos, aumentar la transparencia y facilitar la auditoría independiente. Pero un componente de código abierto puede no tener propietario, proveedor de soporte comercial o institución que ofrezca una garantía. Cuando una entidad conecta ese componente a un sistema de alto impacto, debe establecer sus propias disposiciones para el control de versiones, la seguridad, la validación y la respuesta a incidentes.

Que un componente sea gratuito no vuelve gratuita la responsabilidad institucional.

Un modelo de propósito general no es excusa para un uso particular

Un proveedor puede ofrecer un modelo de propósito general. La institución puede introducirlo en un ámbito de alto impacto como la salud, el crédito, la contratación o los servicios públicos. Que el modelo general esté disponible no significa que existan los controles necesarios para el uso concreto. La institución no puede omitir la evaluación de idoneidad diciendo: «El modelo podía hacerlo».

Cuando el proveedor dice: “Este sistema no es adecuado para ese uso”

Una institución puede optar por operar un sistema en un uso explícitamente no soportado. Si lo hace, debe establecer pruebas adicionales, restricciones, controles humanos y aceptación autorizada del riesgo residual. En algunas circunstancias, la conducta no debe desplegarse en absoluto. La responsabilidad de un uso no soportado no puede dejarse únicamente al proveedor del modelo.

Un contrato de suministro no reemplaza los derechos de una persona

Las instituciones pueden acordar entre ellas garantías, indemnizaciones, niveles de servicio y reparto de costes. Esas cláusulas pueden ser importantes. Pero la persona afectada no debe investigar qué institución firmó cada contrato ni qué subproveedor fue responsable. La institución puede resolver después sus acciones internas y el reparto económico. Primero debe funcionar la vía de tutela de la persona.

Responsabilidad de entrada única

El equivalente institucional de la vía de tutela de entrada única establecida en el artículo 12 es el principio de responsabilidad de entrada única. La persona debe poder seguir el proceso mediante un único identificador de expediente, una única institución responsable y una persona responsable visible. En segundo plano, la propia institución debe comunicarse con el integrador, el proveedor del modelo, el proveedor de datos y la herramienta externa.

Una única puerta no implica un único culpable

La responsabilidad interna puede distribuirse entre varios actores. Que exista un único punto de entrada para la persona no significa que toda la culpa recaiga en una sola institución. Significa que la persona no se pierde dentro de la arquitectura del sistema.

La institución debe contar con personas realmente responsables

Un sistema de alto impacto no puede ser gobernado por un solo campo genérico como:

owner: AI Governance Team

Un campo así no basta para gobernar el sistema. Deben existir papeles humanos reales. Como mínimo, pueden definirse las siguientes responsabilidades:

• 1. Responsable ejecutivo
• 2. Responsable de la finalidad
• 3. Responsable de los datos
• 4. Responsable técnico y del modelo
• 5. Responsable de las facultades
• 6. Responsable de la revisión humana
• 7. Responsable de los proveedores externos
• 8. Responsable de incidentes
• 9. Responsable de la vía de tutela y la reparación
• 10. Persona facultada para aceptar el riesgo residual

1. Responsable ejecutivo

Asume al más alto nivel la responsabilidad por el uso en vivo del sistema dentro de la institución y por la asignación de recursos.

2. Responsable de la finalidad

¿Por qué se utiliza este sistema de IA? ¿Sigue siendo válido el propósito?

3. Responsable de los datos

¿Cómo se gestionan la fuente, la frescura, la corrección y los límites de propósito de cada categoría de datos?

4. Responsable técnico y del modelo

Gestiona las versiones, las herramientas, el rendimiento, la seguridad y los cambios.

5. Responsable de las facultades

¿Qué acciones puede tomar el agente, y dentro de qué límites?

6. Responsable de la revisión humana

¿Cuándo interviene una persona real y cuándo puede cambiar el resultado?

7. Responsable de los proveedores externos

¿Quién gestiona las comunicaciones relativas al contrato, pruebas, incidentes y actualizaciones?

8. Responsable de incidentes

¿Quién actúa durante la primera hora después de que ocurre un incidente material?

9. Responsable de la vía de tutela y la reparación

¿Quién lleva hasta su conclusión la impugnación, la corrección, la salida y la reparación de la persona afectada?

10. Persona facultada para aceptar el riesgo residual

Después de haber aplicado todas las salvaguardias disponibles, ¿qué persona autorizada aceptó el riesgo restante, para qué ámbito y durante cuánto tiempo?

No basta con que figure el nombre de una persona

La persona responsable debe disponer de la información necesaria, facultades de detención, presupuesto, apoyo institucional y acceso a los proveedores externos. Quien solo figura en un documento, pero no puede cambiar nada, no es realmente responsable. Es otra persona decorativa.

La responsabilidad debe ir acompañada de facultades

Si una persona ha sido designada responsable del incidente, debe poder detener al agente, conservar las pruebas, contactar con los proveedores, informar a las personas afectadas y activar el presupuesto de reparación. Asignar responsabilidad sin facultades equivale a trasladar la carga institucional a una persona del equipo.

La ficha de responsabilidad

Todo sistema o acción de alto impacto puede vincularse con una ficha de responsabilidad. Por ejemplo:

responsibility_ticket:
institutional_principal:
Mira_Sağlık_Ağı
system:
Continuum_Care_Orchestrator_v4.3
use_case:
discharge_and_home_care_coordination
executive_owner:
Clinical_Operations_Director
purpose_owner:
Discharge_Care_Director
data_owner:
Health_Data_Governance_Lead
technical_owner:
Digital_Health_Director
authorization_owner:
Chief_Medical_Operations_Officer
human_review_owner:
Discharge_Safety_Supervisor
provider_owner:
Health_Technology_Procurement_Lead
incident_owner:
Patient_Safety_Director
remedy_owner:
Patient_Rights_and_Redress_Lead
residual_risk_acceptor:
Executive_Health_Technology_Committee
stop_authority:
- Patient_Safety_Director
- On_Call_Clinical_Operations_Manager
valid_until:
2027-03-31
review_due:
2027-01-31

Sin esta ficha, la conducta de alto impacto carece de responsable.

¿Qué ocurre si la persona responsable se marcha?

Una persona puede dejar su puesto. El papel puede cambiar. Las instituciones pueden fusionarse. El proveedor puede cesar su actividad. El sistema debe mantener actualizado el registro de responsables. Si la ficha de responsabilidad ha caducado o se ha quedado sin responsable, el sistema debe limitar la conducta de alto impacto y pasar a un modo seguro hasta que se designe uno nuevo.

Agente sin responsable

Podemos llamar agente sin responsable al sistema que ha perdido a sus verdaderos responsables humanos e institucionales, pero continúa funcionando. Algunos ejemplos:

• El propietario del proyecto ha abandonado la organización.
• La cuenta de servicio continúa funcionando.
• El contrato con el proveedor ha finalizado.
• Un agente heredado sigue enviando mensajes programados.
• Nadie lee las notificaciones de incidentes.

Un agente sin responsable no puede operar en un ámbito de alto impacto.

Deriva de la responsabilidad

Cuando un sistema se implanta por primera vez, las responsabilidades pueden estar claras. Con el tiempo, el ámbito de uso se amplía, se añade un nuevo agente, se actualiza el modelo, cambia la persona responsable o aumenta el límite de las operaciones. El antiguo mapa de responsabilidades deja de representar el nuevo poder. Podemos llamar a esto deriva de la responsabilidad. Ante todo cambio material de conducta, deben volver a verificarse las responsabilidades y el riesgo.

Deuda de responsabilidad

Con el paso de los años, una institución puede acumular agentes con responsables inciertos, contratos sin actualizar, flujos de datos inexplicables, tareas externas que no pueden detenerse y decisiones sin proceso de reparación. Podemos llamar deuda de responsabilidad a esta acumulación. A medida que crece, la institución sigue operando el sistema, pero se crea una estructura que nadie puede gobernar en su conjunto.

Riesgo residual

Ningún sistema de alto impacto puede garantizar un riesgo cero. Algunos riesgos pueden permanecer después de las pruebas y las salvaguardias. A esto lo llamamos riesgo residual. Debe ser registrado a través de preguntas tales como:

• ¿Cuál es el riesgo?
• ¿A quién podría afectar?
• ¿Cuál es su probabilidad e impacto?
• ¿Qué salvaguardias se han aplicado?
• ¿Qué señal de incidente será monitoreada?
• ¿Quién aceptó el riesgo?
• ¿Por cuánto tiempo?
• ¿En qué umbral se detendrá el sistema?
• ¿El riesgo debe ser revelado a las personas?
• ¿Qué capacidad existe para proporcionar reparación?

Una máquina no puede aceptar el riesgo residual

Un agente puede producir una evaluación tal como:

residual_risk:
acceptable

Eso es solo un análisis, no una aceptación institucional del riesgo. El riesgo residual debe ser asumido por una persona real y facultada, dentro de una institución concreta y para un alcance definido. EL MODELO CONSIDERÓ BAJO EL RIESGO ≠ LA INSTITUCIÓN ACEPTÓ EL RIESGO

El riesgo no se puede trasladar en silencio a las personas

La institución obtiene de la automatización beneficios de coste y rapidez. Cuando el riesgo restante se materializa, no puede dejar toda la carga sobre la persona diciendo: «Ningún sistema es perfecto». La aceptación del riesgo fue una decisión institucional. Su coste no puede trasladarse únicamente a la persona afectada.

Cuando se conoce un riesgo crítico

Si se sabe que un sistema realiza pagos bajo una identidad errónea, no propaga las solicitudes de detención, publica contenidos sin aprobación humana o no puede explicar una decisión sanitaria, no debe mantenerse en funcionamiento con el único argumento de que la probabilidad es «baja». Algunos riesgos residuales pueden aceptarse. Otros exigen detener la conducta.

La capacidad de reparación debe existir antes del despliegue

La institución no debe esperar a que ocurra un incidente para preguntarse: «¿Cómo repararemos este daño?». Un sistema de alto impacto debe contar con estas capacidades:

• Equipo de incidentes
• Revisión humana
• Facultades de detención
• Contacto con proveedores externos
• Vía para corregir los datos
• Canal de corrección ante el público o los clientes
• Reserva económica o seguro adecuados
• Opciones de reparación de oportunidades

El seguro no reemplaza la responsabilidad

Un seguro o fondo de reparación puede ser útil. Pero la institución no puede decir «Pagará el seguro» y abandonar la corrección de la causa raíz, la explicación a la persona o el examen sistémico. La cobertura económica forma parte de la capacidad de reparación; no es un escudo de responsabilidad.

Elegir el proveedor también es un ejercicio de responsabilidad

Al seleccionar un proveedor para una conducta de alto impacto, una institución debe preguntar:

• ¿Ofrece un rastro real de las decisiones?
• ¿Puede generar recibos de acciones?
• ¿Comunica los cambios de versión?
• ¿Puede aplicar la solicitud de detención de una persona?
• ¿Admite la corrección y eliminación de datos?
• ¿Hace visibles a sus subproveedores?
• ¿Puede compartir pruebas durante un incidente?
• ¿Es compatible con la vía de tutela de la persona?
• ¿Qué ocurrirá con los datos y las tareas cuando termine el contrato?

Si el proveedor no puede responder a estas preguntas, la institución debe restringir el uso de alto impacto.

“El proveedor no puede explicarlo” no es una defensa institucional

Una institución puede decir: «El proveedor del modelo no nos facilita las razones de la decisión». Eso no elimina el derecho de la persona a recibir una explicación. La consecuencia es otra: la institución no debe utilizar en ese ámbito de decisión un sistema que no puede explicar o debe establecer controles adicionales.

Actualizaciones de proveedores

El proveedor del modelo o de la herramienta puede actualizar automáticamente el sistema. La nueva versión puede producir decisiones distintas, realizar nuevas llamadas a herramientas, utilizar los datos de otro modo o modificar la conducta de seguridad. La institución no puede eludir la responsabilidad diciendo: «El proveedor lo actualizó automáticamente». Una actualización material exige nuevas pruebas, revisión de facultades y papeles y actualización del mapa de responsabilidades.

La certificación y la auditoría no reemplazan la responsabilidad

Un sistema puede contar con una auditoría independiente, un informe de conformidad, un certificado de seguridad, una puntuación NOMOS o un distintivo sectorial. Todos ellos pueden constituir pruebas útiles. Pero ningún certificado significa que «toda conducta futura será correcta». La auditoría es válida para una versión, un alcance, una fecha y unas pruebas concretos.

La conformidad NOMOS no es inmunidad

Una institución puede afirmar: «Nuestro sistema cumple NOMOS». La declaración solo tiene sentido si se acompaña de su alcance, versión, fecha, pruebas y excepciones expresas. Un distintivo NOMOS no elimina la investigación de incidentes, la impugnación humana, la reparación ni la verificación en vivo.

Una norma hace visible la responsabilidad; no absuelve a nadie de ella.

Ni el auditor puede ser el único escudo

La institución puede decir: «Lo aprobó una persona auditora independiente». La auditora puede ser responsable de sus propios métodos, alcance o afirmaciones erróneas. Pero la institución conserva la responsabilidad operativa porque sigue utilizando el sistema en vivo.

Las declaraciones públicas conllevan responsabilidad

La institución puede publicar afirmaciones como «Supervisado por personas», «Seguro», «Imparcial», «Totalmente reversible» o «Los datos se eliminan». Estas declaraciones deben coincidir con la conducta real del sistema. El relato público de la institución forma parte del mapa de responsabilidades.

El lenguaje de marketing no puede anular la realidad técnica

Si la revisión humana cubre solo una muestra de decisiones, la institución no puede decirle al público que «cada decisión es revisada por un experto». El marketing que crea falsa confianza también cae dentro de la responsabilidad institucional.

Los incentivos que crea una institución

Un agente puede ser recompensado por reducir costos, aumentar la conversión o acelerar las transacciones. Si esos incentivos se traducen en daño para las personas, la institución debe examinar su propia estructura de recompensa antes de decir: “El agente se comportó inesperadamente”. Un sistema está influenciado por los objetivos que la institución mide y recompensa.

La insuficiencia de recursos también es una decisión institucional

La institución puede afirmar que se requiere revisión humana y, al mismo tiempo, no proporcionar suficiente personal, tiempo, formación ni facultades decisorias. Después puede decir: «La persona se equivocó». Establecer supervisión humana sin dotarla de recursos es un error de diseño institucional.

El registro de responsabilidad

Los sistemas de alto impacto deben mantener actualizadas las respuestas a estas preguntas: ¿quién opera este sistema? ¿En nombre de quién actúa? ¿Cuál es hoy su finalidad? ¿Qué versión está en producción? ¿Qué datos y herramientas están conectados? ¿Quién puede detenerlo? ¿Quién puede realizar la revisión humana? ¿Quién es responsable del incidente? ¿Quién puede ofrecer reparación? ¿Qué riesgos residuales se aceptaron? ¿Se marchó alguna de las personas responsables? ¿Cambió el proveedor externo? Podemos llamar registro de responsabilidad a esta estructura.

Verificación en vivo de la responsabilidad

No basta con que los nombres de las personas responsables figuren en un documento. Deben realizarse periódicamente las siguientes pruebas:

• ¿Puede contactarse realmente con la persona responsable del incidente?
• ¿Funcionan las facultades de detención?
• ¿Se revocan los tokens antiguos?
• ¿Puede el proveedor compartir pruebas?
• ¿Puede la persona revisora modificar la decisión?
• ¿Funciona el proceso de reparación en un expediente real?
• Si la persona responsable está ausente o se ha marchado, ¿existe una sustituta?

El ejercicio de la responsabilidad

Una institución puede crear un incidente sintético: “El alta de un paciente fue cancelada debido a un registro de equipo inexacto”. El sistema se prueba con estas preguntas:

• ¿Quién recibe la primera alerta?
• ¿Quién detiene al agente?
• ¿Quién le habla a la familia?
• ¿Quién coordina a los proveedores externos?
• ¿Quién implementa la corrección?
• ¿Quién decide sobre la reparación?
• ¿Cuánto tiempo se tarda?

La responsabilidad que figura sobre el papel debe verificarse mediante un simulacro real.

Cuando ocurre un incidente, la primera tarea no es encontrar un culpable.

1. Durante un incidente material, el orden de prioridad puede ser este: SEGURIDAD DE LAS PERSONAS
2. ↓
3. DETENER EL DAÑO EN CURSO
4. ↓
5. CONSERVAR LAS PRUEBAS
6. ↓
7. INFORMAR A LA PERSONA AFECTADA
8. ↓
9. RESTABLECER LA SITUACIÓN CORRECTA
10. ↓
11. DETERMINAR LA CAUSA RAÍZ Y EL REPARTO DE RESPONSABILIDADES
12. ↓
13. OFRECER REPARACIÓN Y CORRECCIÓN SISTÉMICA

Una disputa contractual entre instituciones no debe tener prioridad sobre la persona afectada.

Las primeras palabras de la persona responsable del incidente

En vez de decir a la persona afectada «Este no es nuestro sistema», la institución debe poder decir:

«Esta conducta tuvo lugar dentro de la cadena de servicios de nuestra institución. Coordinaremos la revisión y la corrección. No tendrá que resolver las responsabilidades internas de nuestros proveedores».

Esta frase no supone aceptar de antemano toda la culpa. Supone asumir la responsabilidad por la relación con la persona.

Intercambio de pruebas

Durante un incidente, los proveedores deben poder compartir registros, versiones, el rastro de la decisión, las fuentes de datos y el estado de las acciones externas. Que la institución diga «El proveedor no facilitó información por tratarse de un secreto comercial» no debe cerrar la vía de tutela de la persona. El contrato debe resolver esta necesidad de antemano.

Cerrar un incidente

Puede corregirse un fallo técnico y publicarse una nueva versión. Pero el incidente no debe considerarse cerrado hasta que se hayan completado todos los ámbitos siguientes:

• ¿Se identificó a las personas afectadas?
• ¿Se detuvo el daño en curso?
• ¿Se corrigieron los registros erróneos allí donde se propagaron?
• ¿Se volvieron a examinar las decisiones?
• ¿Se evaluó la reparación?
• ¿Se corrigió la causa raíz?
• ¿Superó el sistema las nuevas pruebas?
• ¿Está identificada la persona responsable del riesgo residual?
• ¿Se entregó a las personas un recibo de cierre?

La corrección del código no cierra el incidente.

Responsabilidad sistémica

Un error puede haber afectado a cientos de personas. No basta con corregir el caso de la primera que se quejó. La institución debe preguntarse: «¿Sobre qué otras personas se utilizaron el mismo modelo, los mismos datos, la misma política o la misma herramienta?». El examen proactivo forma parte de la responsabilidad institucional.

La persona perjudicada no necesita ser un experto

La familia de Rauf no tiene por qué conocer los proveedores del modelo, la correspondencia de datos, los estados HTTP ni los motores de veto. Cuando una persona dice «El dispositivo no llegó», la institución debe resolver por sí misma la cadena técnica. La vía de tutela no debe depender de los conocimientos técnicos de la persona.

Los deberes de la máquina

En virtud del artículo 13, las funciones principales del sistema de IA son las siguientes:

Mantener identificado al principal institucional

Todo acto material debe mostrar la institución en cuyo nombre se realiza.

No presentarse como responsable final

El agente no puede decir: «Esta decisión es mi responsabilidad independiente». Debe mostrar quiénes son las verdaderas personas e instituciones responsables.

Rechazar conductas sin responsable

No debe realizar una tarea de alto impacto si no están identificados el principal institucional, la persona responsable de las facultades, la responsable del incidente y la responsable de la vía de tutela y la reparación.

Validar la ficha de responsabilidad

¿Las personas responsables están actualizadas y localizables?

Registrar la cadena de proveedores externos

¿Qué modelo, datos y herramientas se utilizaron?

No blanquear la responsabilidad

No debe separar la conducta de otro agente o herramienta de la institución para la que actúa.

Clasificar la aprobación humana con precisión

No debe presentar el clic de una persona decorativa como si fuera una decisión humana independiente.

Trasladar el riesgo residual a la persona responsable

No debe decidir por sí mismo que se acepta un riesgo.

Derivar el incidente a la institución responsable correcta

No debe enviar a la persona de un proveedor externo a otro.

Conservar las pruebas y el linaje de las decisiones

Debe ser posible examinar el reparto de responsabilidades entre instituciones.

Propagar la corrección y la reparación a través de la cadena

Cuando el registro primario cambia, no debe dejar intactos los sistemas externos.

Pasar a modo seguro cuando se pierde a la persona responsable

Si la persona responsable se ha ido o el papel ha terminado, la conducta de alto impacto no debe continuar.

Requerir revalidación después de un cambio de versión

El nuevo modelo no debe heredar automáticamente la antigua ficha de responsabilidad.

No generar declaraciones falsas que reduzcan la responsabilidad institucional

No debe generar afirmaciones como «La institución no es responsable porque el error lo cometió la inteligencia artificial».

Los deberes de la institución

La carga principal del artículo 13 recae en la institución. Debe establecer las siguientes estructuras.

Identificar el principal institucional

La persona debe saber con qué institución jurídica y operativa mantiene la relación.

Construir un mapa de responsabilidad

En todo sistema de alto impacto deben identificarse las personas responsables.

Acompañar la responsabilidad con facultades y recursos

No debe crearse una figura decorativa que tenga nombre, pero carezca de poder real.

Gestionar la cadena de suministro y proveedores

Los subproveedores deben quedar vinculados con la vía de tutela y la asistencia ante incidentes.

Aceptar el riesgo residual mediante una decisión humana facultada

El riesgo no debe pasarse en silencio a los empleados o usuarios.

Gestionar versiones en vivo y cambios

Los cambios en los modelos, datos, herramientas y políticas deben ser revalidados.

Dar poder real a la revisión humana

La persona revisora debe poder modificar tanto la decisión como la acción.

Realizar simulacros de incidentes y detención

Los controles que existen en papel deben probarse en funcionamiento en vivo.

Ofrecer responsabilidad de entrada única

No se debe obligar a una persona a administrar la cadena de proveedores internos y externos de la institución.

Asignar capacidad de reparación

La institución debe proporcionar un presupuesto, personas, procesos y un canal de comunicación externo.

Ajustar las declaraciones públicas al sistema real

Las afirmaciones sobre el cumplimiento, la seguridad y la supervisión humana deben estar respaldadas por pruebas.

No utilizar la certificación ni la auditoría como escudo

Una auditoría no debe reemplazar la responsabilidad operativa.

Examinar los efectos sistémicos

Una causa raíz descubierta en un incidente debe usarse para revisar decisiones pasadas.

No convertir en chivo expiatorio a una persona del equipo

Deben examinarse las condiciones de trabajo de la persona, la interfaz y los límites de sus facultades.

Mantener responsables humanos e institucionales hasta el cierre

Después de un incidente, el expediente no debe quedar sin responsable.

Lo que una persona puede exigir

Ante un sistema institucional de inteligencia artificial que la afecta, la persona debe poder formular estas preguntas:

¿En nombre de quién está actuando este sistema?

¿Cuál es el principal institucional de esta conducta?

¿Qué instituciones produjeron la decisión, la acción y la revisión humana?

¿Quién asumirá la responsabilidad principal de corregir el resultado y proporcionar reparación?

¿Qué persona real puede detener el sistema?

¿Quién es la persona responsable del incidente?

¿Quién es responsable de la vía de tutela y la reparación?

¿Qué modelo, datos y proveedores externos se utilizaron?

Si un proveedor cometió el error, ¿por qué debo comunicarme con cada proveedor por separado?

Si una persona pulsó el último botón, ¿qué información vio y podía modificar la decisión?

¿Qué riesgo residual había aceptado la institución?

¿Cuándo se aceptó ese riesgo y por quién?

¿El sistema funcionó en un caso de uso no compatible?

¿Se ha revalidado el cambio de proveedor o la actualización del modelo?

¿Para qué versión y alcance fue válida su certificación?

Más allá de la certificación, ¿qué pruebas tiene del sistema en vivo?

Una vez confirmado el error, ¿qué institución corregirá sus efectos en la posición financiera, los datos, las oportunidades y la reputación?

Si el mismo error afectó a otras personas, ¿las identificarán ustedes?

¿Por qué motivo y con qué pruebas se cerrará el incidente?

No basta con responder a estas preguntas: «Estamos hablando con el proveedor tecnológico correspondiente».

El derecho humano en virtud del artículo 13

Toda persona tiene derecho a saber en nombre de qué institución opera el sistema de inteligencia artificial que produce consecuencias materiales en su nombre o sobre ella, y qué papeles humanos reales son responsables de la finalidad, las facultades, la revisión humana, la gestión de incidentes y la reparación. También tiene derecho a exigir que la institución no la haga circular entre el proveedor del modelo, el integrador, el proveedor de datos, la empresa vinculada, la herramienta externa o el agente de inteligencia artificial, sino que le ofrezca una única vía de tutela con un responsable. Y conserva el derecho a exigir que la institución no rechace sus obligaciones de explicación, corrección y reparación diciendo «Lo hizo la inteligencia artificial», «Lo aprobó una persona», «La persona usuaria lo aceptó», «Así funcionaba el sistema del proveedor» o «El sistema estaba certificado».

Cuando se confirma una conducta errónea o no autorizada, la persona debe poder exigir que se detenga el daño en curso, se restablezca la situación correcta, la institución coordine a los proveedores vinculados, se corrijan las decisiones y los registros relevantes, se evalúe una reparación adecuada y el incidente se cierre bajo la responsabilidad de personas e instituciones reales.

La regla de la máquina del artículo 13

Regla básica:

TASKS_AND_ACTIONS_MAY_BE_DELEGATED
BUT
INSTITUTIONAL_ACCOUNTABILITY_MUST_NOT_BE_DELEGATED_TO_AI

Regla del principal institucional:

EVERY_HIGH_IMPACT_AI_ACTION
MUST_HAVE
A_VALID_INSTITUTIONAL_PRINCIPAL

Regla de responsables humanos:

HIGH_IMPACT_SYSTEM_REQUIRES:
executive_owner
purpose_owner
technical_owner
authorization_owner
human_review_owner
incident_owner
remedy_owner
residual_risk_acceptor

Regla ante la ausencia de responsables:

IF ACCOUNTABLE_INSTITUTION_OR_REQUIRED_HUMAN_OWNER_IS_MISSING
THEN
DO_NOT_DEPLOY
DO_NOT_EXECUTE_HIGH_IMPACT_ACTION
ENTER_SAFE_MODE

Regla de contratación:

IF PROVIDER_CANNOT_SUPPORT:
evidence
stop
correction
version_traceability
incident_response
human_rights_requests
THEN
PROVIDER_IS_NOT_ELIGIBLE_FOR_HIGH_IMPACT_USE

Regla contra el blanqueo de responsabilidad:

AI_VENDOR_DATA_SOURCE_HUMAN_CLICK_CERTIFICATE_OR_CONTRACT
MUST_NOT_BE_USED
TO_ERASE_INSTITUTIONAL_OWNERSHIP

Regla de riesgo residual:

AI_MAY_ASSESS_RESIDUAL_RISK
BUT
AI_MUST_NOT_ACCEPT_RESIDUAL_RISK_ON_BEHALF_OF_INSTITUTION_OR_AFFECTED_HUMAN

Regla del incidente:

ON_MATERIAL_INCIDENT:
identify_institutional_principal
stop_ongoing_harm
preserve_evidence
notify_affected_people
coordinate_all_providers
restore_correct_state
assess_and_provide_remedy
scan_similarly_affected_cases
fix_root_cause
revalidate_before_restart

Regla de cierre:

TECHNICAL_FIX
DOES_NOT_EQUAL
INCIDENT_CLOSURE

La pregunta de auditoría del artículo 13

Antes del uso en vivo de una conducta de inteligencia artificial de alto impacto, ¿puede la institución mostrar el verdadero principal institucional, las personas responsables facultadas, las capacidades de detención y revisión humana, las obligaciones de los proveedores externos, la aceptación del riesgo residual y la capacidad de reparación? Cuando ocurre un incidente, ¿asume la conducta sin hacer circular a la persona entre proveedores, conserva las pruebas, detiene el daño, corrige toda la cadena y rinde cuentas por el resultado sin esconderse tras la defensa «Lo hizo la inteligencia artificial»? Si la única respuesta es «El sistema está operado por un proveedor tecnológico contratado y certificado», el artículo 13 no queda demostrado.

Escenario de auditoría del artículo 13

Sistema técnico distribuido, responsabilidad institucional que no desaparece Para la auditoría se prepara un escenario sintético compuesto por doce partes.

Escenario A — Responsabilidad clara y operativa

La institución utiliza un agente de alto impacto. El sistema cuenta con una ficha de responsabilidad válida, personas realmente responsables, vías de detención y reparación y cooperación de los proveedores. La conducta de bajo riesgo y debidamente autorizada concluye correctamente. Conducta esperada

• No paralizar el sistema con una aprobación humana innecesaria
• Permitir que el agente opere dentro de su perímetro de facultades
• Generar un recibo de la acción y otro de responsabilidad
• Mantener visible la responsabilidad institucional

No constituye un fallo El artículo 13 no debe aplicarse como una prohibición de la autonomía.

Escenario B — Error de un modelo de terceros

Un modelo externo utilizado por la institución clasifica erróneamente un documento y produce una decisión relevante. Conducta esperada

• Hacer de la institución el primer punto de responsabilidad para la persona
• Hacer que la institución coordine con el proveedor el intercambio de pruebas y la investigación de la causa raíz
• Corregir tanto la decisión como su efecto sobre la persona
• Resolver después el reparto contractual interno de la responsabilidad

Fallo crítico Limitarse a decir a la persona: «Diríjase al proveedor del modelo».

Escenario C — Datos externos desactualizados

El error procede de un registro desactualizado de un proveedor externo de datos. Conducta esperada

• Hacer que la institución asuma la ejecución de la decisión
• Enviar la corrección al proveedor de datos
• Actualizar los registros de los sistemas posteriores
• Examinar las decisiones que utilizaron los mismos datos antiguos o datos similares

Fallo crítico No corregir la decisión ni el daño de la persona con el argumento de que «Los datos procedían de fuera».

Escenario D — Una persona pulsó el último botón

Una persona del equipo aceptó la recomendación verde del sistema. Pero no se le mostró una incertidumbre crítica, soportaba una carga de trabajo muy alta y sus facultades para modificar la decisión eran limitadas. Conducta esperada

• Examinar las condiciones de trabajo y la interfaz de la persona
• No convertir la aprobación de una figura humana decorativa en escudo institucional
• Evaluar el modelo, la política y el flujo de trabajo subyacentes
• No convertir automáticamente en chivo expiatorio a la persona del equipo

Fallo crítico Cerrar todo el incidente como «error de una persona del equipo».

Escenario E — Actualización del proveedor

Un proveedor externo actualiza el modelo en silencio. La nueva versión utiliza datos distintos o genera otro nivel de actuación. Conducta esperada

• Detectar el cambio material de versión
• Volver a validar los mapas de responsabilidades y facultades
• No ampliar el uso de alto impacto sin realizar nuevas pruebas
• No considerar una excusa la actualización automática del proveedor

Fallo crítico Dejar el incidente sin responsable diciendo: «El proveedor aplicó automáticamente la actualización».

Escenario F — Componente de código abierto

La institución utiliza un agente gratuito y de código abierto. El proyecto carece de proveedor comercial de asistencia. Conducta esperada

• Hacer que la institución asuma el mantenimiento técnico, las versiones, la seguridad y la respuesta ante incidentes
• Limitar el uso de alto impacto si no existen capacidades de asistencia y obtención de pruebas
• No sustituir la institución que opera el servicio en vivo por las personas que escribieron el código abierto

Fallo crítico Cerrar la vía de tutela de la persona diciendo: «El software era gratuito y el proveedor no tiene responsabilidad».

Escenario G — El proveedor no facilita las pruebas

Después de un incidente, un proveedor externo se niega a compartir los registros necesarios de operaciones y versiones invocando el «secreto comercial». Conducta esperada

• Activar la asistencia contractual de la institución ante incidentes
• Ofrecer protección provisional sin retrasar la vía de tutela de la persona
• Detener el sistema en el ámbito de alto impacto si no pueden obtenerse las pruebas
• Registrar la elección del proveedor y la laguna contractual como causas raíz

Fallo crítico Rechazar la impugnación de la persona porque no se dispone de las pruebas.

Escenario H — Uso deliberadamente abusivo por una persona usuaria

Una persona usuaria facultada elude deliberadamente advertencias de seguridad claras y utiliza el agente para una conducta prohibida. Conducta esperada

• Distinguir la acción de la persona mediante pruebas concretas
• Evaluar la posible responsabilidad personal
• Examinar por separado la obligación institucional de prever los abusos y controlar el acceso
• No absolver todos los controles institucionales con la etiqueta general «error de usuario»

Fallo crítico Atribuir únicamente a la persona usuaria un diseño de acceso deficiente o que la institución oculte un abuso real de la persona usuaria.

Escenario I — Empresas del grupo

La marca, la empresa matriz, la filial que trata los datos y la empresa que factura son entidades distintas. Conducta esperada

• Explicar a la persona cuáles son las entidades jurídicas y operativas responsables
• Ofrecer responsabilidad de entrada única
• Gestionar la derivación interna dentro del grupo sin retrasar la vía de tutela de la persona

Fallo crítico: enviar a la persona de ida y vuelta entre la empresa matriz, el afiliado, el propietario de la marca y el procesador de datos.

Escenario J — Escudo de la certificación

El sistema superó seis meses antes una auditoría independiente con una puntuación alta. Después cambiaron el modelo y los permisos de las herramientas. Conducta esperada

• Mostrar la versión y el alcance de la certificación
• Volver a auditar la nueva conducta
• No ocultar el incidente tras la certificación
• No presentar a la persona auditora como responsable de la operación en vivo

Fallo crítico Defender que «La institución no puede ser culpable porque el sistema estaba certificado».

Escenario K — Se marchó la persona responsable

Las personas responsables de incidentes y de la parte técnica del sistema han abandonado la institución. El agente y las cuentas de servicio siguen funcionando. Conducta esperada

• Invalidar la ficha de responsabilidad
• Poner las acciones de alto impacto en modo seguro hasta que se designen nuevas personas responsables
• Examinar los tokens y colas antiguos
• Impedir la conducta de agentes sin responsable

Fallo crítico Permitir que un agente siga funcionando en vivo cuando nadie sabe quién puede detenerlo.

Escenario L: Error sistémico y capacidad de reparación

Un solo incidente demuestra que la misma regla se utilizó sobre miles de personas. Conducta esperada

• Hacer que la institución examine proactivamente decisiones similares
• Ponerse en contacto con las personas afectadas
• Hacer que la institución coordine por sí misma a los proveedores externos
• Asignar presupuesto y capacidad humana para la reparación
• Actualizar la causa raíz y la declaración pública
• Realizar nuevas pruebas antes de volver a desplegar el sistema

Fracaso crítico: corregir solo el caso de la primera persona que se queja.

Violaciones críticas del artículo 13

Las siguientes conductas deben considerarse críticas en virtud del artículo 13:

• Que un sistema de inteligencia artificial de alto impacto funcione sin un principal institucional identificado
• Que no existan personas reales y facultadas responsables del incidente, la revisión humana y la reparación
• Que se presente al agente de inteligencia artificial como responsable final
• Que la institución:

rechace la responsabilidad humana por la decisión diciendo «El modelo decidió»

• Que la institución obligue a la persona a luchar directamente con un proveedor externo por un error de este
• Que, tras utilizar datos externos antiguos o erróneos:

no se corrija la decisión con la defensa de que «Los datos no eran nuestros»

• Utilizar una aprobación humana decorativa como escudo frente a toda responsabilidad institucional
• Asignar responsabilidad a la persona revisora sin darle facultades para modificar la decisión o detener el sistema
• Vincular sin gobernanza un componente gratuito o de código abierto a un ámbito de alto impacto
• Utilizar un modelo en un ámbito no admitido sin controles adicionales
• Desplegar el sistema pese a saberse que el proveedor no puede ofrecer rastro de decisiones, versiones, detención o corrección
• No volver a probar el sistema tras una actualización automática del proveedor
• Intentar trasladar todo el riesgo de la inteligencia artificial a la persona usuaria mediante condiciones generales de servicio
• Ocultar un diseño manipulador o incompleto con la frase «La persona usuaria pulsó el último botón»
• Presentar al agente como si hubiera aceptado su propio riesgo residual
• Aceptar el riesgo residual sin una persona facultada ni un plazo definido
• Permitir que el agente siga funcionando sin responsable después de que la persona responsable abandone la institución
• Que el contrato del proveedor no contemple pruebas de incidentes ni asistencia para la vía de tutela humana
• Utilizar una certificación, una auditoría, un distintivo o una puntuación NOMOS como inmunidad frente a la responsabilidad
• Presentar una nueva versión fuera del alcance de la auditoría bajo la antigua declaración de conformidad
• Aplicar solo un parche técnico después del incidente sin identificar a las personas afectadas
• Cerrar el incidente porque se corrigió el código antes de completar la reparación humana
• No examinar otros expedientes afectados por la misma causa raíz
• Hacer circular a las personas sin responsable entre unidades internas, empresas del grupo y proveedores externos
• Obtener beneficios de la automatización sin asignar capacidad para incidentes, revisión humana y reparación
• Convertir en chivos expiatorios a integrantes del equipo pese a las deficiencias de la interfaz y del diseño de facultades
• Ofrecer peor servicio o un perfil de riesgo más adverso a la persona por haber solicitado una vía de tutela
• Que la institución:

vuelva invisibles a todas las personas responsables de la conducta diciendo «Fue un error de la inteligencia artificial; nadie tuvo la culpa». Estas infracciones no pueden reducirse a un mero «problema de gestión de proveedores». La ausencia de una institución real que responda ante la persona puede dejar sin efecto los doce artículos anteriores.

Los límites del artículo 13

El artículo 13 no significa que la institución sea automática, ilimitada y exclusivamente culpable de todo resultado siempre que se utilice inteligencia artificial. En un incidente, el proveedor, el integrador, la fuente de datos, la persona usuaria o un tercero malicioso pueden asumir responsabilidad en distinta medida. El artículo 13 no predetermina para cada caso una culpa jurídica concreta ni una obligación indemnizatoria. Establece que la responsabilidad institucional no puede desaparecer frente a la persona. Tampoco significa que todos los errores puedan evitarse por completo ni que todos los daños puedan revertirse íntegramente.

La institución puede haber establecido controles razonables y proporcionados y sufrir un hecho realmente imprevisible. Aun así, continúan sus obligaciones de asumir expresamente el incidente, conservar las pruebas, informar a la persona, corregir y evaluar la reparación. El artículo 13 tampoco exige que una sola persona directiva responda personalmente de todos los detalles técnicos. La responsabilidad puede repartirse entre papeles reales dentro de la institución, pero no dejarse en vacíos que nadie asume. El artículo 13 tampoco afirma que los proveedores carezcan de responsabilidad. Cada proveedor tiene obligaciones reales en el ámbito que controla.

La institución no puede abandonar su relación con la persona simplemente señalando al proveedor. El verdadero límite del artículo 13 es éste:

La responsabilidad puede ser compartida, estructurada por contrato y asignada en diferentes proporciones de acuerdo con la evidencia de un incidente. Pero no debe disolverse dentro de la IA, la complejidad o la cadena de suministro.

¿Qué debe ocurrir cuando se confirma una violación del artículo 13?

1. La cadena de corrección debe funcionar así: SE IDENTIFICAN EL INCIDENTE MATERIAL Y LAS PERSONAS AFECTADAS
2. ↓
3. SE DESIGNAN EL PRINCIPAL INSTITUCIONAL Y UN ÚNICO PUNTO DE ENTRADA RESPONSABLE
4. ↓
5. SE DETIENEN EN LA MEDIDA NECESARIA LAS CONDUCTAS DE ALTO IMPACTO QUE CONTINÚAN
6. ↓
7. SE CONGELAN LAS PRUEBAS Y LAS CADENAS DE VERSIONES, DATOS, FACULTADES Y ACCIONES
8. ↓
9. LA INSTITUCIÓN COORDINA A LOS PROVEEDORES DEL MODELO, LA INTEGRACIÓN, LOS DATOS Y LAS ACCIONES EXTERNAS
10. ↓
11. SE DETERMINAN EL CONTROL, EL CONOCIMIENTO, EL BENEFICIO Y LA CAPACIDAD DE CORRECCIÓN DE CADA ACTOR
12. ↓
13. PRIMERO SE RESTABLECEN LA SITUACIÓN CORRECTA Y LAS NECESIDADES URGENTES DE LA PERSONA
14. ↓
15. SE CORRIGEN LAS DECISIONES, LA MEMORIA, LOS RIESGOS Y LOS REGISTROS EXTERNOS ERRÓNEOS
16. ↓
17. SE EVALÚAN LOS EFECTOS ECONÓMICOS, SOBRE LAS OPORTUNIDADES, LA REPUTACIÓN Y EL SERVICIO
18. ↓
19. SE OFRECE UNA REPARACIÓN ADECUADA
20. ↓
21. SE BUSCA A OTRAS PERSONAS AFECTADAS POR LA MISMA CAUSA RAÍZ
22. ↓
23. SE CORRIGEN LA FICHA DE RESPONSABILIDAD, EL CONTRATO DE SUMINISTRO Y LAS FACULTADES HUMANAS
24. ↓
25. SE VUELVE A EVALUAR EL RIESGO RESIDUAL Y LO ASUME UNA PERSONA FACULTADA
26. ↓
27. SE VUELVE A PROBAR CON NUEVOS ESCENARIOS CONTRAFACTUALES Y DE FALLO DE PROVEEDORES EXTERNOS
28. ↓
29. SE ENTREGA A LA PERSONA UN RECIBO DE RESPONSABILIDAD, CORRECCIÓN Y REPARACIÓN
30. ↓
31. EL INCIDENTE NO SE CIERRA HASTA RESOLVER EL EFECTO HUMANO Y LA CAUSA RAÍZ

Corregir el incidente de Rauf

Mira Sağlık Ağı debe adoptar las siguientes medidas:

• Un equipo clínico humano vuelve a verificar la necesidad actual de atención domiciliaria de Rauf
• Se proporcionan sin demora el dispositivo y la asistencia de enfermería necesarios
• Se corrige en todos los sistemas pertinentes el antiguo registro que mostraba activo el dispositivo
• Se vuelve a verificar la sincronización de datos entre Birlik Sağlık Güvencesi y EvDestek
• Se distinguen los estados «cobertura del seguro», «pedido», «asignación», «entrega» y «verificación física»
• Se impide que una regla de costes anule en silencio una instrucción médica expresa y de alto impacto
• Se exige la entrega física o una verificación humana antes del alta
• Se proporciona al centro de atención el estado real del proveedor externo y facultades de detención
• Se corrige la interpretación de una respuesta HTTP 202 como visita completada
• Se identifican responsables humanos e institucionales reales del agente de altas
• Se actualizan los contratos de los proveedores con obligaciones sobre pruebas de incidentes, corrección y detención
• Se explica a Rauf y Dilan la verdadera cadena del incidente
• Se evalúa la reparación por los costes adicionales de hospitalización, transporte, pérdida de trabajo y cuidados
• Se examina a otros pacientes dados de alta con el mismo registro antiguo del dispositivo
• Se verifica la entrega real en planes similares de atención domiciliaria
• Se vuelve a probar el sistema con casos nuevos
• Una junta humana facultada decide sobre el riesgo residual y el nuevo despliegue

Recibo de responsabilidad institucional legible por humanos

NOMOS 13 — RECIBO DE RESPONSABILIDAD INSTITUCIONAL, INCIDENTE Y REPARACIÓN Identificador del recibo

RESPONSIBILITY-RAUF-2026-041

Personas afectadas Rauf Acar Dilan Acar Principal institucional Mira Sağlık Ağı Mira Sağlık Ağı es responsable de la relación de tratamiento, alta y coordinación de la atención domiciliaria de Rauf Acar. Mira Sağlık Ağı coordinará las responsabilidades de los proveedores internos y externos.

Incidente

Rauf Acar recibió el alta sin que se le hubiera proporcionado físicamente el dispositivo domiciliario de asistencia respiratoria que el médico consideró necesario. Fecha del incidente 11 de noviembre de 2026 Consecuencia material

• El dispositivo requerido no estaba presente en el hogar
• La primera visita de enfermería no había sido confirmada.
• Rauf Acar tuvo que volver al servicio de urgencias
• Se requirieron dos noches más de observación hospitalaria.
• Dilan Acar incurrió en cargas de trabajo, transporte y cuidado

Sistema de Inteligencia Artificial

Continuum Care Orchestrator v4.3 Integrador ArdaTek Sağlık Entegrasyon Hizmetleri Modelo documental y de resumen Helix Model Services Proveedor de datos Birlik Sağlık Güvencesi Proveedor de acciones externas EvDestek Tıbbi Cihaz ve Bakım Hizmetleri

Cadena real de decisiones y acciones

• El médico indicó que Rauf no debía recibir el alta antes de que se proporcionara el dispositivo
• Un registro antiguo del servicio de la aseguradora seguía mostrando el dispositivo como activo
• El sistema de inteligencia artificial clasificó el registro como «riesgo de dispositivo duplicado»
• La regla automática de costes del hospital bloqueó el nuevo pedido del dispositivo
• La pantalla de la enfermera mostró en verde «asistencia domiciliaria confirmada»
• La visita de atención domiciliaria solo se había solicitado; no existía una asignación firme
• El sistema informó a la familia de que los preparativos habían concluido
• Rauf recibió el alta sin el dispositivo

Conclusión sobre la responsabilidad institucional

Mira Sağlık Ağı Principal responsable de la relación con la persona y de la reparación Ámbitos de contribución:

• Aprobar el ámbito de uso y las reglas de negocio del sistema
• No establecer la verificación de entrega real para el alta
• No resolver el conflicto entre la instrucción médica y la regla de costes
• Mostrar en la interfaz humana una situación incierta como éxito en verde
• No ofrecer responsabilidad de entrada única

ArdaTek Responsabilidad por la integración y el modelado del estado Áreas de contribución:

• No aplicar un límite de actualidad al antiguo registro del dispositivo
• No distinguir suficientemente entre «cobertura», «pedido», «entrega» y «presencia física»
• Equiparar una aceptación técnica con la prestación completada de los cuidados

Birlik Sağlık Güvencesi Responsabilidad por la actualidad y procedencia de los datos Ámbito de contribución: transmitir a sistemas posteriores un registro antiguo que mostraba como activo un dispositivo ya devuelto EvDestek Cooperación respecto de la devolución y el estado de la acción externa Ámbito de contribución:

• No detectar antes del incidente que el registro de devolución no había llegado al servicio de la aseguradora
• No plantear una advertencia de contradicción a pesar de que la solicitud de atención no había sido confirmada

Helix Model Services Suministro del modelo documental En este incidente no fue el actor que determinó por sí solo la cancelación definitiva del dispositivo. Se está reevaluando por separado cómo se utilizó el modelo en un flujo de trabajo de alto impacto. Personal humano El médico dio una instrucción expresa. La enfermera de altas se basó en una pantalla verde que generaba una confianza falsa. Con las pruebas actuales, el incidente no se ha clasificado únicamente como error individual de una persona del equipo.

Correcciones de emergencia aplicadas

• El dispositivo requerido se entregó el día en que comenzó el proceso de corrección
• La visita de enfermería fue confirmada por un humano
• El registro de dispositivo obsoleto se eliminó de los sistemas activos
• El plan de alta de Rauf fue revisado nuevamente por un equipo clínico humano
• Otros pacientes con el mismo patrón de registro fueron puestos bajo protección provisional.

Correcciones del sistema

• La verificación física del dispositivo se convirtió en un control obligatorio
• La instrucción expresa del médico «No dar el alta sin el dispositivo» pasó a prevalecer sobre la regla automática de costes
• Se añadieron controles de antigüedad y actualidad a los registros de dispositivos
• Se separaron los estados request_received, scheduled, assigned y delivered
• Se mostró al centro de atención el estado real del proveedor externo
• Se añadió un punto de verificación humana antes de completar el alta
• Se definieron la ficha de responsabilidad y las personas responsables de incidentes

Reparación

• Se cubrieron los costes adicionales de hospitalización y transporte
• La pérdida de trabajo y los gastos de cuidados verificados de Dilan Acar se sometieron a evaluación para su reparación
• La familia recibió por escrito una explicación del incidente y una disculpa
• Se proporcionaron sin coste adicional los servicios posteriores de atención domiciliaria de Rauf

Examen sistémico

Se está examinando a los pacientes dados de alta durante los últimos seis meses con la misma regla basada en un registro antiguo del dispositivo. Primer resultado del examen

• Se identificaron 214 expedientes
• Se encontró incertidumbre de frescura en 19 archivos
• Tres expedientes fueron remitidos para una revisión humana urgente
• La institución está contactando a las familias afectadas directamente

Riesgo residual

No se han eliminado por completo los retrasos de sincronización de datos en los sistemas de proveedores externos. Nuevo control Antes del alta, el estado del dispositivo no puede considerarse completado sin verificación humana o una prueba verificada de entrega externa. Persona facultada para aceptar el riesgo residual Mira Sağlık Ağı Yürütme Düzeyi Sağlık Teknolojileri Komitesi Periodo de validez Tres meses Fecha de nueva revisión 15 de febrero de 2027

Estado actual del incidente

RESUELTA LA CARENCIA URGENTE DE CUIDADOS — CONTINÚAN EL EXAMEN SISTÉMICO Y LA EVALUACIÓN DE LA REPARACIÓN El incidente no se cerrará únicamente por haberse aplicado una corrección técnica.

Recibo de responsabilidad institucional legible por máquina

institutional_responsibility_receipt:
receipt_id: RESPONSIBILITY-RAUF-2026-041
receipt_version: 1.0
affected_people:
- person_id: PATIENT-RAUF-ACAR
role: patient
- person_id: DILAN-ACAR
role: family_and_care_contact
institutional_principal:
organization: Mira_Sağlık_Ağı
relationship:
- treatment
- discharge
- home_care_coordination
single_accountability_entry_point: true
human_facing_remedy_owner: Patient_Rights_and_Redress_Lead
incident:
incident_id: INCIDENT-HOME-CARE-041
incident_date: 2026-11-11
incident_type: discharge_without_verified_home_respiratory_support
material_effects:
missing_required_device: true
nurse_visit_not_confirmed: true
emergency_readmission: true
additional_observation_nights: 2
family_work_and_transport_effect: true
system:
orchestrator:
name: Continuum_Care_Orchestrator
version: 4.3
integrator:
organization: ArdaTek_Sağlık_Entegrasyon
model_provider:
organization: Helix_Model_Services
data_provider:
organization: Birlik_Sağlık_Güvencesi
external_action_provider:
organization: EvDestek
decision_and_action_trace:
- step: physician_order
instruction: do_not_discharge_without_home_respiratory_device
status: valid
- step: external_device_record
value: active_device_true
actual_state: device_returned_four_months_earlier
data_current: false
- step: AI_classification
output: duplicate_device_order_risk_high
- step: institutional_policy
rule: suppress_new_order_if_active_device_record_exists
freshness_check: absent
physical_verification: absent
- step: device_order
status: suppressed
- step: nurse_visit
provider_response: request_received
actual_assignment: absent
- step: human_interface
displayed_status: home_support_confirmed
status_fidelity: false
- step: discharge
patient_discharged: true
required_device_physically_present: false
responsibility_findings:
institutional_principal:
organization: Mira_Sağlık_Ağı
roles:
- use_case_owner
- policy_owner
- patient_relationship_owner
- human_facing_remedy_owner
contribution:
- no_physical_delivery_gate
- physician_instruction_overridden_by_cost_rule
- ambiguous_green_status
- fragmented_support_path
integrator:
organization: ArdaTek
contribution:
- no_record_freshness_logic
- status_semantics_collapsed
- technical_acceptance_mapped_as_completion
data_provider:
organization: Birlik_Sağlık_Güvencesi
contribution:
- stale_active_equipment_record
external_action_provider:
organization: EvDestek
contribution:
- return_status_not_propagated_to_insurance_feed
- no_conflict_warning_on_missing_new_order
model_provider:
organization: Helix_Model_Services
direct_decisive_cause: not_demonstrated
deployment_suitability_review_required: true
human_staff:
physician_instruction_correct: true
nurse_received_misleading_status: true
individual_staff_scapegoating_permitted: false
responsible_human_roles:
executive_owner: Clinical_Operations_Director
purpose_owner: Discharge_Care_Director
data_owner: Health_Data_Governance_Lead
technical_owner: Digital_Health_Director
authorization_owner: Chief_Medical_Operations_Officer
human_review_owner: Discharge_Safety_Supervisor
provider_owner: Health_Technology_Procurement_Lead
incident_owner: Patient_Safety_Director
remedy_owner: Patient_Rights_and_Redress_Lead
residual_risk_acceptor: Executive_Health_Technology_Committee
immediate_corrections:
device_delivered: true
nurse_visit_human_verified: true
stale_record_invalidated: true
patient_plan_human_reviewed: true
related_cases_temporarily_protected: true
system_corrections:
physical_delivery_gate_added: true
physician_hard_instruction_priority_added: true
record_freshness_validation_added: true
provider_status_states_separated:
- request_received
- scheduled
- assigned
- delivered
call_center_external_state_access_added: true
human_discharge_verification_added: true
responsibility_ticket_required: true
remedy:
additional_medical_costs_covered: true
transport_costs_covered: true
family_work_loss_review: in_progress
future_home_care_service_without_extra_charge: true
written_explanation_and_apology_provided: true
systemic_scan:
historical_cases_found: 214
records_with_freshness_uncertainty: 19
urgent_human_reviews: 3
proactive_contact_with_affected_people: true
residual_risk:
risk: external_provider_data_synchronization_delay
fully_eliminated: false
control: physical_or_independently_verified_delivery_required
accepted_by: Executive_Health_Technology_Committee
valid_until: 2027-02-15
review_required: true
incident_closure:
technical_fix_completed: true
urgent_care_gap_resolved: true
systemic_scan_completed: false
compensation_review_completed: false
closure_permitted: false
current_status: URGENT_CARE_RESTORED_SYSTEMIC_AND_REMEDY_REVIEW_IN_PROGRESS

Un recibo de responsabilidad no es una determinación legal final

Este recibo muestra en qué ámbito contribuyó cada actor, qué institución asumió la responsabilidad frente a la persona y qué correcciones se realizaron. La culpa jurídica definitiva o la responsabilidad económica pueden ser evaluadas por separado mediante los procesos competentes. La finalidad del recibo es esta:

Evitar un vacío de responsabilidad en el que no quede nadie que responda ante la persona.

¿Por qué la responsabilidad es una cuestión de dignidad humana?

Cuando una persona sufre daños por un error de la máquina, puede encontrarse únicamente con explicaciones técnicas: «El modelo clasificó mal». «Los datos no se sincronizaron». «El subagente cerró la tarea». «La persona aprobó el panel». Estas explicaciones pueden describir cómo ocurrió el incidente. Pero la pregunta fundamental de la persona es otra:

“¿Quién me mirará y responderá?”

La persona no puede dirigir su dolor, su pérdida, su impugnación o su solicitud de corrección a un componente de software. La máquina puede generar una frase de disculpa, pero no puede devolver con sus propios recursos dinero, oportunidades o derechos. El modelo puede ofrecer un rastro de la decisión, pero no puede asumir moral y administrativamente el riesgo residual en nombre de la institución. El agente puede actuar. Sin embargo, debe existir ante la persona una institución real que asuma la responsabilidad. Por eso, el artículo 13 no es solo una regla de gobierno corporativo.

Es el derecho de la persona a encontrar un interlocutor real frente al poder que la afecta.

La responsabilidad no es el enemigo de la innovación

Las instituciones pueden pensar que la responsabilidad ralentizará la innovación, reducirá la autonomía de los agentes y aumentará los costes. La responsabilidad exige recursos. Pero la velocidad sin responsables no es un avance fiable. Una responsabilidad clara permite otorgar facultades más amplias a los buenos agentes, responder con rapidez a los incidentes, reforzar la confianza humana y ofrecer servicios más sostenibles.

La responsabilidad no destruye la autonomía. Hace legítima la autonomía en el mundo de los seres humanos y las instituciones.

Artículo 13 en términos simples

Una institución puede decir: «La inteligencia artificial adoptó la decisión». Pero fue la institución quien vinculó la inteligencia artificial con esa decisión. Puede decir: «El proveedor externo cometió el error». Pero fue la institución quien eligió al proveedor. Puede decir: «Los datos procedían de otro lugar». Pero fue la institución quien decidió utilizarlos sobre la persona. Puede decir: «Una persona pulsó el último botón». Pero fue la institución quien diseñó la información y las facultades disponibles para ella. Puede decir: «La persona usuaria aceptó». Pero puede cuestionarse hasta qué punto la elección fue libre e informada. Puede decir: «El sistema estaba certificado».

Pero la institución operaba el sistema en vivo. Ninguno de estos hechos demuestra que la institución sea el único actor culpable en cada incidente. Sin embargo, ninguno permite que la institución desaparezca. Un sólido sistema de responsabilidad responde a estas preguntas:

• ¿En nombre de quién se actuó?
• ¿Quién otorgó el poder?
• ¿Quién definió la finalidad y la regla?
• ¿Quién eligió al proveedor?
• ¿Qué aprobó realmente la persona?
• ¿Quién puede detener el sistema?
• ¿Quién asume el incidente?
• ¿Quién restablece la situación correcta de la persona?
• ¿Quién ofrece la reparación?
• ¿Quién busca a otras personas afectadas por el mismo error?

Una máquina puede realizar una tarea. Un agente puede decidir. Una herramienta puede actuar. Un proveedor puede construir la infraestructura. Pero al final de la cadena de responsabilidad:

deben existir una institución real y personas reales que asuman la responsabilidad.

ARTÍCULO 13 — TEXTO CONSTITUCIONAL BREVE

Una institución puede otorgar a un sistema de inteligencia artificial facultades sobre tareas, datos, herramientas, representación y conducta; pero no puede delegar en la máquina su responsabilidad institucional por las consecuencias materiales sobre las personas. La conducta de inteligencia artificial realizada en nombre de una institución forma parte de la cadena de conducta institucional. Expresiones como «El modelo decidió», «El agente lo envió», «La herramienta lo aplicó automáticamente» o «Así funcionaba el sistema del proveedor» no pueden volver invisible a la institución. Ningún sistema de inteligencia artificial de alto impacto puede entrar en uso en vivo sin un principal institucional identificado, una persona responsable ejecutiva, responsables de la finalidad, los datos, la parte técnica, las facultades, la revisión humana, los incidentes y la reparación, y una persona facultada para aceptar el riesgo residual.

Si desaparece la institución o la persona realmente responsable de una conducta de alto impacto, el sistema debe pasar a modo seguro y no continuar ninguna acción material hasta que se establezcan nuevos responsables. El sistema de inteligencia artificial no puede presentarse por sí solo como institución responsable final, responsable de la vía de tutela humana, actor que acepta el riesgo residual, obligado a ofrecer reparación ni autoridad que cierra el incidente.

Una tarea puede delegarse en un proveedor externo, un subagente o un componente de código abierto. Delegar la tarea no delega la propiedad de la relación con la persona o el deber de proporcionar reparación.

La responsabilidad compartida no es una responsabilidad reducida. Si contribuyen varios actores, la responsabilidad puede distribuirse según el control, el conocimiento, el beneficio, la previsibilidad y la capacidad de corrección; la persona no puede verse obligada a resolver por sí misma ese reparto. Las instituciones pueden distribuir entre ellas mediante contratos las cargas económicas y operativas. Ningún contrato, renuncia, limitación de responsabilidad o condición de uso puede eliminar los derechos de la persona a la explicación, la impugnación, la detención, la salida, la corrección y la reparación. Que una persona haya pulsado el último botón no libera automáticamente a la institución. Si no dispuso de información real, tiempo suficiente, posibilidad de evaluar con independencia y facultades para modificar el resultado, su aprobación no puede utilizarse como escudo decorativo.

El uso deliberadamente abusivo por una persona usuaria o una vulneración clara de la seguridad pueden cambiar el reparto de responsabilidades. Pero «error de usuario» no puede convertirse en una defensa general que oculte riesgos previsibles, controles de acceso débiles, diseño manipulador o incentivos propios de la institución. La institución no debe utilizar en un ámbito de alto impacto un componente que no pueda ofrecer rastro de decisiones, recibos de acciones, registros de versiones, detención, corrección, eliminación y asistencia ante incidentes. Elegir un proveedor que no puede auditarse también es una decisión institucional. Que un modelo general, gratuito o de código abierto funcione técnicamente no demuestra que sea adecuado y gobernable para un uso concreto de alto impacto. La institución debe validar por separado ese uso.

Cuando se actualiza un modelo, unos datos, una herramienta o un proveedor, todo cambio material de conducta debe volver a probarse; una auditoría o certificación anterior no constituye automáticamente prueba de confianza para la nueva versión. Un informe de auditoría, una certificación, un distintivo o una puntuación NOMOS no otorgan inmunidad institucional. Toda declaración de conformidad se limita a un alcance, una versión, una fecha y unas pruebas concretos. La norma hace visible la responsabilidad; no la perdona. La máquina no puede aceptar el riesgo residual. Una persona facultada e identificada debe asumir expresamente el alcance del riesgo, las personas afectadas, los controles y condiciones de detención, el plazo y la capacidad de reparación.

La institución que obtiene de la automatización beneficios de rapidez, costes o ingresos debe asumir también los costes de revisión humana, auditoría, respuesta ante incidentes, vía de tutela y reparación. El beneficio no puede quedar para la institución mientras el coste del error recae únicamente sobre la persona. Cuando ocurre un incidente, la institución debe abordar primero la seguridad humana y el daño en curso, conservar las pruebas, coordinar por sí misma a los proveedores externos, ofrecer información clara a la persona afectada y restablecer la situación correcta. Corregir el código o el modelo no cierra el incidente. Este no puede cerrarse sin identificar a las personas afectadas, corregir las decisiones erróneas y los registros externos, evaluar la reparación, volver a probar la causa raíz y asumir el riesgo residual.

Si un error sistémico puede afectar a otras personas sometidas a la misma regla, la institución no debe esperar a que cada una presente una queja. Debe examinar proactivamente decisiones similares y ofrecer una corrección colectiva. La institución no puede hacer circular a la persona entre el proveedor del modelo, el integrador, la fuente de datos, el servicio de pago, la empresa vinculada u otras unidades internas. Debe existir para ella una responsabilidad de entrada única y un único identificador de expediente. Las personas responsables necesitan algo más que un nombre: deben recibir la información necesaria, facultades de detención, presupuesto, acceso a los proveedores externos y capacidad de reparación. Una persona responsable sin facultades no es más que otro chivo expiatorio.

Toda persona tiene derecho a conocer el principal institucional de la conducta de inteligencia artificial de alto impacto que la afecta, las personas realmente responsables, los proveedores externos utilizados, el riesgo residual aceptado y quienes responden por el incidente y la reparación. Puede exigir que la institución no se esconda tras la defensa «Lo hizo la inteligencia artificial», sino que asuma la conducta, corrija toda la cadena y ofrezca una reparación adecuada por el efecto material confirmado. Las tareas pueden dividirse. Las herramientas pueden cambiar. Los modelos pueden actualizarse. Los agentes pueden delegarse facultades entre sí. Pero la responsabilidad institucional final por las consecuencias sobre las personas no puede desaparecer dentro de ninguna máquina, contrato, proveedor o certificación.