Maetra recomienda que los operadores de servicios esenciales del Reino Unido comprueben si pueden conservar evidencia de un intento fallido de detener a un agente de IA. La nueva ficha informativa del gobierno sobre resiliencia de la IA agéntica, publicada el 3 de noviembre, describe posibles medidas futuras sobre seguridad, notificación, conservación de evidencia y revisiones de incidentes. No establece hoy esas obligaciones específicas para agentes. Para los equipos de cumplimiento, la preparación más útil es un ensayo que conecte una acción observada con la intervención del operador y con la acción que ocurrió después.
El documento oficial indica que el alcance detallado y las definiciones se desarrollarán junto con la industria y las autoridades de supervisión. Se centra en la pérdida de supervisión o de control sobre agentes dentro de redes y sistemas de información. Los equipos deberían seguir la evolución de ese alcance junto con sus mecanismos actuales de gestión de incidentes.
Lo que ha propuesto el gobierno
La ficha informativa plantea cuatro medidas: requisitos técnicos y organizativos de resiliencia, notificación a otras organizaciones afectadas, conservación de información relevante del incidente y facultades ministeriales para encargar revisiones técnicas. La aplicación llegaría tras la sanción real mediante normativa de desarrollo, con consulta y procedimiento de aprobación afirmativa del Parlamento. El documento limita expresamente su ambición a la pérdida de control agéntica, en lugar de establecer un marco integral que abarque todos los daños relacionados con la IA.
Esa distinción afecta al trabajo de cumplimiento. Un registro interno debería identificar la propuesta, el servicio potencialmente afectado y una persona responsable de seguir la evolución. También debería mantener visibles las dudas pendientes sobre aplicabilidad y fechas de implantación. Registrar una propuesta como si fuera una obligación ya implantada crea una falsa sensación de seguridad y puede desviar el trabajo de ingeniería hacia un requisito cuyo alcance todavía se está diseñando.
El análisis de Maetra es que las organizaciones pueden preparar evidencia operativa útil mientras esas cuestiones siguen abiertas. La orientación propuesta sobre conservación de evidencia hace que merezca la pena un ejercicio acotado: demostrar qué ocurrió cuando un operador intentó recuperar el control. El ejercicio descrito a continuación es un método de preparación, no una lista oficial del gobierno ni una conclusión sobre las obligaciones jurídicas de ninguna organización.
Conserve la intervención además de la acción del agente
Un registro que termina en una alerta no puede explicar si la contención funcionó. Una orden enviada para detener un flujo de trabajo tampoco basta por sí sola. Los investigadores deben distinguir entre la solicitud, su acuse de recibo y el comportamiento observable posterior.
Piense en un agente hipotético de gestión de servicios que empieza a modificar registros fuera del servicio que tiene asignado. Un operador pausa el planificador de tareas, pero un proceso que ya estaba en marcha sigue usando un conector. Una entrada de registro que diga «agente en pausa» ocultaría la brecha. Un registro mejor mostraría qué planificador de tareas se pausó, qué proceso siguió activo, qué acceso conservó y cuándo completó su última operación externa.
El propio ejemplo de la ficha informativa incluye información sobre acciones del agente e intentos de controlarlas. Los equipos deberían decidir qué registros fiables pueden producir realmente sus sistemas. Deberían evitar convertir el razonamiento interno especulativo en un requisito previo para reconstruir lo ocurrido. Las solicitudes a herramientas, las decisiones de autorización, las respuestas de conectores y los cambios observados en el sistema pueden respaldar una investigación incluso cuando no se dispone del razonamiento privado de un modelo.
Ensayar un intento de recuperar el control
Seleccione un flujo de trabajo delimitado en un entorno de prueba seguro y acuerde el resultado de contención esperado antes de empezar. Asigne al ejercicio una persona responsable de ingeniería y otra responsable de la evidencia de cumplimiento. La persona responsable de ingeniería establece qué hacen los controles; la responsable de la evidencia comprueba si otra persona revisora puede entender el resultado.
| Evidencia que debe conservarse | Pregunta a la que debe responder |
|---|---|
| Identificadores del flujo de trabajo, del proceso y del conector | ¿Qué partes del sistema todavía podían actuar? |
| Marcas temporales de la alerta y de la intervención | ¿Cuándo supo el operador del problema y cuándo respondió? |
| Solicitud exacta de control y acuse de recibo | ¿Qué se pidió y qué componente lo aceptó? |
| Resultados de las acciones posteriores | ¿Se detuvo la actividad, falló o continuó en otro lugar? |
| Ubicación de conservación y registro de acceso | ¿Quién puede recuperar la evidencia sin alterarla? |
Use una acción de prueba inocua y reversible con un destino conocido. Si un proceso continúa después de una pausa, conserve ese resultado como un hallazgo. No marque el ejercicio como satisfactorio solo porque el panel haya cambiado de estado. Acuerde una corrección, asigne una persona responsable y repita la prueba después del cambio.
La conservación necesita su propia decisión. Conserve la información necesaria para entender el incidente, restrinja el acceso y aplique las normas pertinentes de privacidad y conservación. Copiar cada prompt, archivo y credencial a una carpeta de incidente puede crear una exposición adicional. Remita a los originales protegidos cuando proceda y registre las supresiones deliberadas para que las personas revisoras sepan qué falta.
Mantenga trazables las decisiones sobre partes afectadas
La propuesta también mira más allá de la notificación a clientes hacia otras organizaciones a las que un agente pueda afectar. Como preparación, la persona responsable del servicio puede relacionar los destinos de los conectores con un contacto operativo e identificar quién decidiría si hace falta una notificación. Las obligaciones y umbrales reales de notificación exigen una evaluación conforme a las normas aplicables en ese momento.
Durante el ensayo, compruebe si el equipo puede identificar un sistema externo afectado a partir de sus propios registros. Registre la incertidumbre si un conector compartido oculta el destino o la identidad utilizada. Una lista de contactos solo es útil cuando el equipo puede conectarla con la operación que se está investigando.
Esto se apoya en las cuestiones de titularidad tratadas en el análisis de Maetra sobre evidencia de identidad de agentes según NIST. Aquí la pregunta concreta es si la evidencia sobrevive a un intento de intervención y respalda una revisión posterior. Comply ayuda con la correspondencia entre marcos, la vigilancia regulatoria y la gestión de evidencia; Audit ayuda con un historial verificable. Ninguno sustituye la ingeniería de incidentes ni determina la aplicabilidad jurídica.
Para la próxima revisión de cumplimiento, utilice la cobertura de marcos de Maetra para vincular un control existente con su responsable de evidencia y con el resultado más reciente del ensayo. Mantenga separado el estado de la propuesta del Reino Unido hasta que el proceso de consulta e implantación establezca los requisitos aplicables.
Fuentes
- Gobierno del Reino Unido, Agentic AI resilience measures, 3 de noviembre de 2026. Documento de política principal. El ensayo operativo anterior es análisis de Maetra.