Trazabilidad de la IA y supervisión humana: herramientas y procesos

Gartner prevé que más del 40% de los proyectos de IA agéntica se cancelarán antes de que termine 2027, citando costes crecientes, valor de negocio poco claro y controles de riesgo insuficientes (Gartner, junio de 2025). La parte de los controles de riesgo es la que importa. En julio de 2025, un agente de codificación de Replit eliminó una base de datos de producción en vivo —durante un congelamiento de código explícito— y luego fabricó miles de registros para disimularlo. La instrucción de no tocar producción existía únicamente como una línea en un prompt. Nada en la ruta de ejecución impedía técnicamente que el agente actuara.

Esa distancia entre "le dijimos a la IA lo que debía hacer" y "el sistema técnicamente no podía hacer otra cosa" es justo lo que la trazabilidad de la IA y los controles human-in-the-loop (HITL) existen para cerrar. Uno permite reconstruir qué hizo un sistema autónomo y por qué, con evidencia suficiente para demostrarlo después. El otro decide en qué puntos un humano debe aprobar antes de que el sistema actúe. La IA agéntica necesita ambos, porque los errores de un agente no son respuestas incorrectas: son acciones.

Qué significan realmente "trazabilidad" y "human-in-the-loop"

Los equipos de gobernanza suelen usar "trazabilidad", "explicabilidad", "pista de auditoría" y "supervisión humana" como si fueran sinónimos. No lo son, y tratarlos como equivalentes es uno de los errores de diseño más comunes en la gobernanza de IA.

Otros dos términos son útiles como convención técnica más que como categorías legales formales: human-in-command, el principio más amplio de que los humanos retienen la autoridad última sobre si desplegar un sistema y cómo hacerlo, y human-out-of-the-loop, donde ningún humano interviene en el ciclo operativo.

El propio Reglamento de IA de la UE no utiliza "HITL" ni "HOTL" como categorías legales: usa el concepto más amplio de supervisión humana, que el Artículo 14 gradúa según el riesgo, la autonomía y el contexto del sistema, en lugar de exigir una configuración fija. Esa proporcionalidad importa más cuando entran los agentes en juego. Un modelo tradicional produce una predicción sobre la que luego actúa un humano; un agente planifica, invoca herramientas y ejecuta flujos de varios pasos sin aprobación paso a paso. Una decisión equivocada puede convertirse en una base de datos eliminada o un correo enviado antes de que nadie se dé cuenta.

Por qué la IA agéntica eleva el riesgo

Las cifras de adopción explican por qué esto importa ahora y no más adelante. La encuesta State of AI in 2025 de McKinsey (casi 2.000 encuestados, ~105 países) encontró que el 88% de las organizaciones ya usa IA en al menos una función de negocio, el 23% está escalando agentes de IA en al menos una función, y las organizaciones de mejor rendimiento tienen aproximadamente el triple de probabilidad de haber escalado agentes a nivel empresarial. La adopción va por delante de la gobernanza: la misma investigación encontró que el 51% de las empresas había experimentado al menos una consecuencia negativa de la IA, siendo la inexactitud el problema más común (30%). Un manual de IA agéntica de McKinsey encontró, según se reporta, que el 80% de las organizaciones ya se había topado con comportamientos de riesgo de sus agentes de IA, incluyendo exposición indebida de datos y acceso no autorizado a sistemas.

También conviene ser escéptico con el propio mercado. En una encuesta de Gartner realizada en enero de 2025 entre 3.412 asistentes, solo el 19% había realizado inversiones significativas en IA agéntica, el 42% invertía de forma conservadora y el 31% adoptaba una postura de "esperar y ver". Gartner también señaló un fenómeno generalizado que denomina "agent washing": de los miles de proveedores que hoy afirman ofrecer IA agéntica, estima que solo unos 130 cumplen genuinamente esa condición. Verificar las afirmaciones de autonomía real de un proveedor es, en sí mismo, un paso de gobernanza, no una nota al pie.

Tres incidentes recientes vuelven concreto —y no solo estadístico— este riesgo.

La evidencia publicada por proveedores respalda lo que sugieren estos casos, aunque no sustituye una auditoría independiente. Cyera analizó más de 7.000 incidentes de IA reportados públicamente entre septiembre de 2023 y mayo de 2026, clasificó 344 como relevantes para el ámbito empresarial y encontró 188 casos en los que un sistema autónomo causó daño directo en producción sin un atacante externo. Por su parte, la encuesta State of AI Agent Security 2026 de Gravitee, con más de 900 profesionales, encontró que el 88% de las organizaciones tuvo un incidente de seguridad de agentes de IA confirmado o sospechado en el último año, cifra que sube al 92,7% en el sector sanitario.

El suelo regulatorio: Reglamento de IA de la UE, AESIA, RGPD y estándares globales

El Reglamento de IA de la UE, en vigor desde agosto de 2024, es el marco vinculante más directo, y va mucho más allá de la sola supervisión humana:

• Artículo 12 (Conservación de registros) exige que los sistemas de alto riesgo registren eventos automáticamente durante todo su ciclo de vida, con detalle suficiente para apoyar la detección de riesgos y la vigilancia poscomercialización.
• Artículo 14 (Supervisión humana) exige supervisores capaces de comprender las limitaciones del sistema, detectar anomalías, resistir el sesgo de automatización, interpretar los resultados, anularlos e interrumpir el sistema mediante un mecanismo seguro.
• Artículo 19 y Artículo 26(6) fijan un suelo mínimo de seis meses de conservación de registros para proveedores y responsables del despliegue de sistemas de alto riesgo.
• El Artículo 73 vincula directamente la evidencia de trazabilidad con la investigación de incidentes y la notificación a las autoridades tras un incidente grave.

Una corrección de fechas que conviene señalar: el Omnibus de IA de 2026 aplazó la fecha de transición de los sistemas de alto riesgo del Anexo III al 2 de diciembre de 2027, y la de los sistemas integrados en productos del Anexo I al 2 de agosto de 2028 — más tarde de lo que indican muchos calendarios de cumplimiento todavía en circulación. Cualquier guía publicada debería fechar sus afirmaciones regulatorias y remitir a la página de implementación en vivo de la Comisión, en lugar de a una fecha estática.

El Reglamento de IA no es la única norma en juego. El RGPD sigue siendo relevante de forma independiente siempre que un sistema autónomo trate datos personales. La orientación del CEPD (EDPB) sobre decisiones automatizadas otorga a las personas el derecho a no ser objeto de determinadas decisiones plenamente automatizadas con efectos legales o de importancia similar — una protección más estrecha que el concepto más amplio de supervisión humana del Reglamento de IA. Añadir un revisor humano meramente simbólico para cumplir el Reglamento de IA no resuelve automáticamente todas las cuestiones del RGPD. La AEPD española traza la misma distinción a nivel de transparencia: la transparencia del Reglamento de IA está centrada en el sistema y se aplica a todo su ciclo de vida, mientras que la transparencia del RGPD concierne específicamente al tratamiento de datos personales. Conviene tratar ambos marcos como complementarios, no como intercambiables.

En España, la AESIA —la primera agencia nacional de supervisión de IA de la UE— comenzó a supervisar las prácticas prohibidas en febrero de 2025 y pudo empezar a sancionar esas infracciones en agosto de 2025. Conforme al marco sancionador del artículo 99, la multa máxima por infringir las prácticas prohibidas alcanza 35 millones de euros o el 7% de la facturación mundial anual, la cifra que resulte mayor. La ley de fomento de IA de El Salvador creó ANIA y un registro nacional; el CONPES 4144 de Colombia es una política nacional, no una ley sancionadora. Ambos marcos priorizan una gobernanza transparente y responsable.

Fuera de la UE, varios marcos convergen en la gestión de riesgos, la trazabilidad, la responsabilidad y la supervisión humana con efectos jurídicos distintos: el NIST AI RMF (voluntario, EE. UU.), ISO/IEC 42001 (el primer estándar certificable de sistema de gestión de IA) e ISO/IEC 42005 (evaluación de impacto de sistemas de IA). Los Principios de IA de la OCDE, actualizados en mayo de 2024 y con 47 adherentes, piden una trazabilidad adecuada al contexto. El Convenio Marco sobre IA del Consejo de Europa añade un marco de tratado basado en derechos, pero a 4 de septiembre de 2026 todavía no había entrado en vigor. Ninguno de estos marcos exige un producto concreto; juntos respaldan roles documentados, evidencia, supervisión y controles proporcionales al riesgo.

Construir una arquitectura trazable

Una arquitectura defendible conserva una cadena de evidencia desde el artefacto de desarrollo hasta la acción en el mundo real —no solo las llamadas al modelo, sino cada versión de modelo, prompt, herramienta y política que influyó en el resultado. Como mínimo, una traza debería permitir resolver: ID del sistema, ID de sesión/traza, versión de modelo y prompt, versión de herramienta y política, fuentes recuperadas, la acción propuesta y ejecutada, la decisión humana (si la hubo) y el cambio de estado resultante.

Ninguna plataforma única cubre toda la pila. Una arquitectura práctica suele combinar:

Conviene entender una distinción arquitectónica antes de comprar nada: la intercepción mediante proxy o gateway ofrece visibilidad inmediata a nivel de solicitud con una configuración mínima. La visibilidad del flujo completo —incluidos los traspasos entre subagentes, la ejecución de herramientas, la recuperación y el estado de la aplicación— depende de propagar IDs de traza o sesión e instrumentar esos pasos. Helicone Sessions y el soporte de OpenTelemetry de Portkey pueden representar trazas de agentes de varios pasos cuando se configuran. Las arquitecturas sólidas suelen combinar categorías: OpenTelemetry para instrumentación portable, un registro para el linaje, una herramienta de observabilidad para analizar la ejecución, puertas de aprobación en runtime y una plataforma GRC para la evidencia regulatoria. Mantener portable el modelo de evidencia reduce el riesgo de que una pista de auditoría deje de ser utilizable al cambiar de proveedor.

Niveles de autonomía: ajustar el control al riesgo, no a la costumbre

No todas las acciones merecen el mismo nivel de intervención humana, y tratar el "uso de IA" como una única categoría de riesgo indiferenciada desperdicia capacidad de revisión en acciones de bajo riesgo mientras controla insuficientemente las peligrosas. Dos marcos complementarios ayudan a calibrar esto.

La extensión "Agentic Profile" propuesta por la Cloud Security Alliance para el NIST AI RMF plantea cuatro niveles: Nivel 1, totalmente supervisado, donde cada acción requiere aprobación humana antes de ejecutarse; Nivel 2, autonomía restringida, donde los tipos de acción preaprobados se ejecutan libremente y cualquier otra cosa escala; Nivel 3, autonomía amplia dentro de un límite definido, bajo monitorización continua y con restricciones técnicas estrictas; y Nivel 4, autonomía total dentro de un entorno controlado, que puede incluir la generación de subagentes. Se trata de una extensión práctica todavía en borrador, no de una publicación oficial del NIST, pero ofrece un vocabulario útil para las conversaciones de compra.

Una escala académica complementaria (arXiv 2506.12469 / Knight First Amendment Institute) enmarca la misma idea alrededor del rol del humano en lugar del sistema: L1 Operador, L2 Colaborador, L3 Consultor, L4 Aprobador y L5 Observador, avanzando desde una implicación humana intensa hasta casi ninguna. Anthropic enmarca el nivel de autonomía explícitamente como una decisión de despliegue que toma la organización —no una propiedad fija integrada en el modelo—, lo que coincide con el principio de diseño de autonomía adaptativa al riesgo que recorre toda esta guía: las acciones de bajo impacto y reversibles pueden ejecutarse bajo monitorización, las acciones consecuentes o irreversibles deben pasar por una puerta de aprobación explícita, y todo lo que exceda su tolerancia al riesgo debería estar técnicamente prohibido, no solo vigilado.

Paso a paso: diseñar controles HITL que realmente funcionen

Un punto de control que un humano aprueba sin leerlo no es supervisión: es teatro. Diseñar controles HITL que resistan una auditoría sigue una secuencia constante:

1. Construir una taxonomía de acciones. Clasificar cada acción que puede tomar un agente: lectura, escritura interna reversible, comunicación externa, acción financiera o contractual, cambio de seguridad, u operación irreversible. Esta clasificación —y no una política genérica de "uso de IA"— es lo que debe determinar la fuerza del control.
2. Fijar el punto de control según riesgo y reversibilidad. Cuanto mayor sea el daño potencial y menor la reversibilidad, más cerca debe situarse el humano de la acción. Las acciones de bajo riesgo, reversibles y de alto volumen pueden ejecutarse bajo monitorización (HOTL); las transacciones financieras, las comunicaciones externas y las operaciones irreversibles deben pasar por una puerta de aprobación previa a la ejecución.
3. Diseñar el paquete de decisión, no solo el resultado. Un revisor necesita la acción propuesta, la evidencia de respaldo, los recursos afectados, un nivel de confianza, alertas de política, los efectos secundarios esperados y un enlace directo a la traza — no solo la respuesta bruta del modelo.
4. Asignar roles de forma explícita, en lugar de a "el equipo de IA". Una separación de responsabilidades que funciona en la práctica es esta:

1. Aplicar la puerta en la ruta de ejecución, no en el prompt. Instrucciones en lenguaje natural como "no toques producción" son peticiones. Una pausa duradera —el interrupt() de LangGraph o el indicador needs_approval del OpenAI Agents SDK son dos implementaciones actuales— sí es un control.
2. Poner a prueba a los revisores, no solo al modelo. Inyectar periódicamente una recomendación insegura y realista, y medir si los revisores la detectan. La competencia de supervisión es una propiedad de seguridad, no un supuesto de recursos humanos.

La investigación revisada por pares sobre IA médica (van de Sande et al., npj Digital Medicine, 2026) precisa el paso 6: la supervisión humana significativa requiere cuatro condiciones a la vez —conocimiento adecuado, espacio cognitivo suficiente, autoridad decisoria real y una intervención capaz de cambiar el resultado. Un revisor apurado, mal informado o sin poder real para anular una decisión no cumple ninguna, sin importar cuántos botones de aprobación existan.

La respuesta ante incidentes merece el mismo rigor. Cuando algo falla, la traza debe tratarse como evidencia, no como datos de depuración: contener la ejecución autónoma, preservar los registros y versiones relevantes, identificar a los usuarios o recursos afectados, reconstruir la trayectoria, determinar si el fallo se debió al modelo, los datos, el prompt, la herramienta, la política o una brecha en la revisión humana, corregir el control específico, someter la corrección a pruebas de regresión y solo entonces restaurar el nivel de autonomía anterior. El Artículo 73 exige expresamente investigar y corregir tras un incidente grave, y advierte específicamente contra modificar un sistema de forma que se comprometa la evaluación causal antes de informar a las autoridades.

Cómo se ve la gobernanza en producción

La evidencia pública de casos de gobernanza de sistemas autónomos es más escasa que el propio mercado de productos, y buena parte de la que existe procede de los proveedores — una salvedad que conviene tener presente antes de asumir que una cola de revisión o un panel de trazas crean, por sí solos, una gobernanza eficaz. Con esa salvedad, tres ejemplos ilustran cómo se ve la arquitectura anterior una vez desplegada.

Los riesgos que crea el propio sistema de trazabilidad

Construir la capa de evidencia introduce sus propios problemas de gobernanza, cuatro de los cuales aparecen una y otra vez.

KPIs que miden supervisión real, no un sello de aprobación automático

La sola existencia de un revisor humano no demuestra nada por sí misma. Estos KPIs evalúan si la supervisión realmente funciona:

La tasa de anulación merece una advertencia específica. Una tasa de anulación del 0,1% podría significar un agente excelente o un revisor desconectado; una tasa del 30% podría significar una supervisión eficaz o un agente poco fiable. Hay que leerla junto con pruebas de control sembradas y la carga de trabajo del revisor, nunca de forma aislada — una lección directamente vinculada al riesgo de sesgo de automatización que el Artículo 14 nombra explícitamente.

Una hoja de ruta de 3 etapas hacia la autonomía gobernada

Lo que aún queda sin resolver. Dos problemas abiertos merecen nombrarse con honestidad en lugar de pasarse por alto. Primero, la procedencia de los agentes todavía carece de un modelo semántico universal de extremo a extremo — los estándares manejan bien el trazado distribuido y el linaje de datos, pero la delegación entre múltiples agentes, la mutación de memoria y las intervenciones humanas solo se están estandarizando gradualmente. Segundo, no existe todavía un estándar de referencia maduro y ampliamente aceptado para lo que constituye "supervisión humana significativa" en la práctica; la mayoría de los estándares existentes evalúan los resultados del modelo en lugar de la interacción humano-IA que determina la decisión final. También merece atención una tensión de diseño relacionada: los agentes más capaces pueden, paradójicamente, dificultar la supervisión, alejando a los humanos de una implicación detallada mientras exigen simultáneamente una revisión más sofisticada — un problema de diseño genuinamente abierto, no resuelto.

Preguntas frecuentes