Adenda de consentimiento para el piloto de captura privada¶

Estado: BORRADOR BLOQUEANTE — no aprobado para uso real Contexto técnico: eppa-private-fixture-pilot-v1 Versión propuesta: private-capture-consent-v1 Fecha de revisión legal: pendiente

Esta adenda documenta la información mínima que debe revisar y aprobar el responsable legal/privacidad. No reemplaza asesoramiento legal, consentimiento clínico ni las obligaciones institucionales aplicables.

Propósito acotado¶

La captura se usa una sola vez para validar el recorrido EPPA de cuatro vistas, la ubicación de marcadores y la comparación técnica con el flujo acordado. No autoriza atención clínica, diagnóstico, entrenamiento de modelos, publicación, marketing, identificación biométrica ni reutilización general.

La creación de un fixture derivado persistente es un propósito separado. Si el resultado todavía permite identificar a la persona, se trata con las mismas restricciones que la imagen original y no se conserva sin una aprobación específica adicional.

Texto informativo mínimo a aprobar¶

Antes de capturar, la persona debe recibir en lenguaje claro:

quién es el responsable y cómo contactarlo;
qué cuatro fotografías se tomarán y para qué prueba concreta;
que el fondo reglado y los marcadores corporales pueden hacer identificable la imagen aunque no se muestre nombre;
que el acceso está limitado a operadores designados del piloto;
dónde se aloja el bucket y qué proveedores/subencargados intervienen;
que el original se cifra, no se incluye en backups y se elimina al cerrar la sesión o, como máximo, dentro de 24 horas;
que el lifecycle de storage es una defensa adicional y no la garantía primaria de borrado;
qué metadatos/auditoría mínimos quedan después del purge y por cuánto tiempo;
cómo retirar el consentimiento y solicitar acceso o eliminación;
qué ocurre con un resultado derivado y cómo se verifica su anonimización;
riesgos residuales, canal de incidente y ausencia de beneficio clínico.

Registro exigido¶

No se abre una sesión si falta cualquiera de estos campos:

organización y sujeto pseudónimo interno;
operador autenticado y grant vigente;
consent_record_id del último consentimiento granted para eppa-private-fixture-pilot-v1;
versión y hash del texto aprobado;
fecha/hora, método y referencia a la evidencia; la evidencia no se embebe en la imagen, el objeto ni los logs;
propósitos aceptados individualmente;
expiración efectiva y deadline de purge;
ubicación/proveedor de storage aprobados;
responsable de responder una revocación.

Una cabecera opcional del cliente no prueba consentimiento. El servidor valida el registro vigente, organización, contexto y ausencia de una revocación antes de crear la sesión y antes de cada transición sensible.

Procedimiento operativo¶

Antes de la sesión¶

Verificar identidad del operador, allowlist temporal y rol.
Mostrar el texto aprobado y responder preguntas.
Registrar aceptación o detenerse; nunca preseleccionar consentimiento.
Confirmar que no se capturan documentos, pantallas, terceros ni datos fuera de las cuatro vistas.

Durante la sesión¶

Usar sólo el host piloto protegido.
Identificar la sesión por UUID; no usar nombre, DNI, email ni historia clínica en filename, object key, etiquetas o notas.
No descargar, hacer screenshot, compartir URL ni copiar la imagen a chat, email, Drive, Git o LFS.
Ante error de autorización, consentimiento, cifrado o storage, fallar cerrado y solicitar purge; no degradar a almacenamiento local.

Cierre normal¶

Revisar el candidato derivado sólo dentro del entorno protegido.
Registrar aprobación/rechazo sin copiar la imagen.
Solicitar purge inmediato de originales y temporales.
Verificar ausencia de objetos/versiones/multipart antes de marcar la sesión deleted.
Entregar confirmación operativa de borrado por el canal acordado.

Revocación¶

Registrar withdrawn en el mismo contexto.
Bloquear inmediatamente upload, lectura, finalización y aprobación.
Encolar purge prioritario de originales, temporales y candidato.
Escalar si la ausencia no se verifica dentro de 15 minutos.
Evaluar por separado los metadatos/auditoría que deban conservarse por una obligación válida; documentar fundamento y plazo.

Incidente¶

Se considera incidente: enlace público, objeto en backup, log con contenido o clave sensible, acceso cross-org, pérdida de KEK, purge vencido, descarga local o uso fuera del propósito. Deshabilitar el feature flag, revocar credenciales, preservar sólo evidencia técnica sanitizada y activar el proceso institucional de notificación. No copiar la imagen para investigar.

Matriz de aprobación¶

Todos los campos deben contener nombre, fecha y referencia de evidencia antes de cambiar este documento a aprobado:

Control	Responsable	Estado	Evidencia
Texto y base legal aplicable	Legal/privacidad	PENDIENTE	—
Propósito clínico/técnico	Responsable clínico	PENDIENTE	—
Ubicación, proveedor y subencargados	Privacidad/infra	PENDIENTE	—
TTL, purge y no-backup	Custodio de datos	PENDIENTE	—
Controles de acceso y respuesta a incidentes	Seguridad/infra	PENDIENTE	—
Tratamiento del fixture derivado	Legal + responsable clínico	PENDIENTE	—
Prueba sintética completa	QA independiente	PENDIENTE	—
Autorización excepcional de una captura real	Dueño del piloto	PENDIENTE	—

Mientras exista un PENDIENTE, no hay autorización para una imagen real ni para un despliegue accesible a participantes.