Diseñar supervisión, transparencia y respuesta

Supervisión humana no significa añadir un botón «Aprobar». Un control humano solo funciona si la persona conoce el contexto, comprende el sistema, dispone de tiempo, puede detectar anomalías y tiene autoridad para cambiar o detener la acción.

La transparencia tampoco es una frase genérica «usa IA». Debe informar lo necesario a la audiencia correcta y cumplir las obligaciones específicas que resulten aplicables.

Diseña una matriz de supervisión

Para cada caso define:

• qué salida se revisa;
• qué riesgo se intenta controlar;
• quién revisa;
• formación necesaria;
• información disponible;
• tiempo;
• porcentaje de casos;
• criterios de escalado;
• acciones;
• autoridad de parada;
• sustituto;
• registro.

Una revisión de cien resultados por minuto puede existir formalmente y ser inútil.

Elige dónde interviene la persona

Antes de la ejecución. Aprueba una acción o plan.

Durante. Interviene ante alertas.

Después. Revisa muestras, reclamaciones o incidentes.

Por excepción. El sistema escala solo casos con determinadas señales.

La combinación depende del riesgo.

Evita automation bias

Si la persona acepta casi siempre la recomendación, investiga por qué.

Puede existir:

• exceso de confianza;
• falta de contexto;
• interfaz sesgada;
• presión de tiempo;
• falta de alternativa;
• fatiga.

Mide desacuerdos y correcciones, pero interpreta los datos. Una tasa de desacuerdo cero puede indicar perfección o ausencia de supervisión real.

Define transparencia por audiencia

Usuarios internos

Necesitan saber:

• qué puede hacer;
• qué no;
• qué datos usar;
• qué datos no;
• cuándo revisar;
• cómo reportar;
• qué versión o política aplica.

Personas afectadas

Dependiendo del caso pueden necesitar información sobre:

• uso de IA;
• finalidad;
• tipo de decisión;
• vías de reclamación;
• intervención humana;
• origen de determinados contenidos.

Dirección y control

Necesita:

• inventario;
• métricas;
• riesgos;
• incidentes;
• revisiones;
• proveedores.

No uses el mismo texto para todos.

AI Act y transparencia en 2026

El artículo 50 del AI Act aplica desde el 2 de agosto de 2026 para determinados sistemas y contenidos. Las guías de la Comisión aclaran, entre otros supuestos, obligaciones relacionadas con interacción directa con IA, determinado contenido sintético, deepfakes y ciertos textos de interés público.

No todas las aplicaciones empresariales tienen la misma obligación. Determina:

• si eres proveedor o deployer;
• tipo de sistema;
• contenido;
• destinatario;
• excepción aplicable.

La transparencia del AI Act no sustituye otras obligaciones, como protección de datos o consumo.

Diseña reclamación

Una persona debe poder:

• reportar error;
• cuestionar resultado;
• aportar información;
• solicitar revisión;
• recibir respuesta;
• escalar.

Conserva trazabilidad sin exigir a la persona que entienda arquitectura LLM.

Define incidentes

No todo fallo es incidente.

Clasifica:

Calidad. Respuesta incorrecta sin efecto material.

Operación. Indisponibilidad, timeout, coste.

Seguridad. Acceso indebido, prompt injection con efecto, secreto expuesto.

Privacidad. Divulgación o tratamiento indebido.

Impacto sobre personas. Decisión o salida con consecuencia.

Regulatorio. Evento que activa notificación, registro o actuación específica.

La severidad debe determinar respuesta.

Crea un flujo

detección → contención → clasificación → responsable → investigación → corrección → comunicación → prueba → cierre

Define quién tiene autoridad para desactivar:

• sistema;
• modelo;
• tool;
• fuente;
• integración.

Monitoriza señales

Ejemplos:

• outputs revisados;
• desacuerdos;
• escalados;
• reclamaciones;
• incidentes;
• filtraciones;
• fallos de herramientas;
• cambios de modelo;
• abstenciones;
• errores por segmento.

No midas solo «uso» o «satisfacción».

Ejemplo

Un asistente interno genera borradores para atención al cliente.

Supervisión:

• salida visible antes de enviar;
• agente puede editar;
• campos sensibles marcados;
• envío automático desactivado.

Transparencia:

• usuarios internos conocen límites;
• respuestas al cliente siguen la política de la empresa.

Incidente:

• si aparece información de otro cliente, se bloquea el sistema, se revisa aislamiento y se abre investigación.

Diseña límites de confianza

No presentes una puntuación del modelo como permiso automático para ejecutar. Una confianza alta puede estar mal calibrada.

Define controles basados en:

• tipo de tarea;
• evidencia;
• reglas;
• criticidad;
• historial de evaluación.

En una clasificación de bajo impacto puedes automatizar determinados casos validados. En una decisión sensible, una puntuación interna puede servir solo para priorizar revisión.

Entrena al supervisor sobre fallos reales

La persona que revisa necesita ver ejemplos de:

• alucinación;
• omisión;
• sesgo de contexto;
• evidencia contradictoria;
• herramienta incorrecta;
• dato obsoleto;
• caso fuera de alcance.

La supervisión mejora cuando conoce los patrones de fallo del sistema concreto, no solo conceptos generales de IA.

Evita interfaces que empujen a aprobar

Si el botón principal es «Aceptar» y la evidencia queda escondida, la UI favorece automation bias.

Considera:

• mostrar fuente;
• resaltar incertidumbre;
• ofrecer editar;
• pedir motivo en excepciones;
• separar aprobación de envío;
• mostrar consecuencias.

El diseño de interfaz es parte del control.

Define controles de transparencia técnica interna

Además de informar a usuarios, conserva internamente:

• modelo o sistema usado;
• fecha;
• versión;
• fuente;
• revisión;
• decisión;
• efecto.

No toda esta información se expone públicamente, pero permite auditoría.

Ensaya incidentes

Realiza tabletop exercises:

1. aparece información confidencial;
2. el sistema genera una recomendación discriminatoria;
3. un proveedor cambia de modelo sin aviso suficiente;
4. una tool ejecuta una acción errónea.

Evalúa:

• detección;
• escalado;
• parada;
• comunicación;
• recuperación.

Un runbook no probado es solo documentación.

Ejercicio

Diseña una matriz para tres casos:

1. asistente de redacción;
2. clasificación de solicitudes;
3. tool que modifica un sistema.

Para cada uno define supervisión, transparencia, reclamación, monitorización y parada.

Después simula un incidente y comprueba si alguien sabe exactamente quién decide.

Qué debes poder demostrar

La prueba de dominio es contar con controles que funcionen durante el uso real. La última lección integra inventario, revisión, datos, proveedores, supervisión, incidentes y alfabetización en un playbook operativo.