Un incidente con un agente de IA comprime el ciclo de respuesta normal. El sistema puede proponer otra llamada de herramienta, actualizar una credencial o iniciar otra ejecución mientras el equipo aún está abriendo un puente. Este manual le brinda al comandante del incidente un camino ordenado: contener la capacidad activa, preservar el registro, restaurar una liberación conocida, conciliar los efectos secundarios y tomar la decisión de informar a partir de hechos verificados. Relaciona la evidencia con el artículo 73 de la Ley de IA de la UE sin asumir que cada agente o incidente cae dentro de esa disposición. Sólo información operativa general; Un abogado calificado debe confirmar el alcance legal, los plazos y las notificaciones.
Abrir un incidente y poner en marcha los relojes.
El [Perfil de IA generativa del NIST] (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) recomienda una propiedad definida, ensayos periódicos, mejoras retrospectivas y alineación con las leyes de notificación de infracciones, privacidad y otras leyes para los planes de incidentes de IA generativa de terceros. NIST SP 800-61 Revisión 3 integra la respuesta a incidentes en la preparación, detección, respuesta y recuperación.
Declare un registro de incidente antes de que los socorristas realicen cambios paralelos. Registre el tiempo de primera detección, el tiempo de concientización, el sistema afectado y la liberación, el comportamiento observado, los efectos secundarios conocidos, las personas afectadas, los entornos, las identidades de los agentes y humanos y la fuente de cada hecho. Mantenga las afirmaciones, hipótesis y decisiones como campos separados.
Asigne cuatro roles con nombre. El comandante del incidente es dueño de la secuencia y la contención. El propietario del sistema opera el agente y los servicios posteriores. El líder de pruebas conserva los registros y el cronograma de acción. El propietario legal decide el alcance de la notificación y coordina con los equipos de abogados, privacidad, seguridad y sectores.
- Propietario de gravedad: establece el nivel de impacto actual y el momento de la próxima revisión
- Fecha límite de contención: establece el último tiempo aceptable para que cada actuador de interruptor de apagado reconozca
- Propietario de la evidencia: fuente de registros, tiempo de recolección, estado de integridad y custodia de cada artefacto
- Propietario del informe: registra cada régimen posible, activación legal, autoridad, reloj y decisión.
Preservar evidencia volátil antes de cambios amplios
Capture el estado volátil a medida que comienza la contención: identificadores de ejecución activa, trabajos en cola, solicitudes de decisión abiertas, identidad de proceso y carga de trabajo, versión actual, versión de modelo y solicitud, versión de política, identificadores de credenciales, conexiones de red, libro de llamadas de herramientas e ID de solicitudes posteriores. Sellar el horario de recogida y la identidad del recolector.
Para un incidente grave cubierto, [el artículo 73(6) de la Ley de IA de la UE] (https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) exige que el proveedor investigue, evalúe el riesgo y tome medidas correctivas. También requiere que el proveedor informe a las autoridades competentes antes de cambiar el sistema de IA de una manera que pueda afectar una evaluación posterior de las causas del incidente. El abogado debe decidir cuándo se aplica esa condición. El manual debe hacer explícito el punto de control de preservación de evidencia para que la contención y la preservación regulatoria puedan avanzar juntas.
Copie los registros relevantes en un almacén controlado por incidentes con protección de retención. Conserve los registros sin procesar y cree líneas de tiempo derivadas por separado. Los hash y las firmas pueden mostrar si los archivos recopilados cambiaron después de la captura; no pueden probar que una fuente omitida nunca existió, por lo que el manifiesto de recopilación debe enumerar las fuentes esperadas y las fuentes faltantes.
contener la capacidad
Invoque la arquitectura de interruptor de apagado del agente de IA en el alcance más estrecho que contenga el comportamiento observado. Amplíe al agente, versión, inquilino o entorno a medida que cambien los hechos.
La contención finaliza cuando cada actuador requerido reconoce o el comandante del incidente registra un sustituto manual. Un estado verde del servicio de flujo de trabajo no puede establecer contención para tokens, trabajos posteriores en cola o un trabajador que se ejecuta fuera de ese servicio.
| Objetivo | Acción | Hecho requerido para la contención |
|---|---|---|
| Carreras activas y cerradas. | Enviar cancelación, cerrar solicitudes de decisión pendientes y negar intentos de reanudación posteriores | Estado terminal y último efecto secundario comprometido para cada ejecución |
| Ruta política | Instale un bloque con alcance de incidente en cada herramienta y puerta de salida. | Versión de política, primera acción denegada y comportamiento de cierre fallido |
| Identidad del agente | Deshabilite la identidad, revoque tokens, impida la actualización y rote los secretos expuestos | Ventana de acceso residual y resultado para cada clase de credencial |
| Carga de trabajo | Terminar o poner en cuarentena el proceso y restringir la salida | Inventario de carga de trabajo y reconocimiento de aislamiento |
| Colas y trabajos posteriores | Cancelar trabajos pendientes y enumerar solicitudes que ya se han comprometido | Estado terminal o compensador por cada solicitud aceptada |
| Acceso a datos | Congele las rutas de escritura afectadas y conserve las instantáneas cuando esté autorizado | Almacenamientos cubiertos, tiempo de captura y escrituras observadas después de la declaración |
Revertir el sistema y conciliar los efectos.
Elija el punto de recuperación de la evidencia. Registre la última versión en buen estado, el paquete de políticas, el modelo y la versión del mensaje, el manifiesto de la herramienta, la configuración del conector y la generación de secretos. Verificar su procedencia antes de la promoción.
Una reversión de la versión restaura la configuración y los bytes implementados anteriormente. No puede recuperar un correo electrónico, deshacer una transferencia completa, restaurar un registro externo eliminado ni retirar datos ya divulgados. Abra un elemento de compensación específico del sistema para cada efecto comprometido y asigne un propietario y una fecha límite.
Aumente la recuperación con credenciales nuevas y una lista de permitidos específica del incidente. Ejecute un control controlado con la denegación de incidentes aún activa para las versiones anteriores afectadas. Libere un tráfico más amplio solo después de que el canario produzca las decisiones políticas, los efectos secundarios y la evidencia esperados.
- Versión: restaurar el artefacto anterior verificado y conservar el artefacto fallido para su análisis
- Política: restaurar la política anterior verificada mientras se mantiene la denegación en el ámbito del incidente con mayor prioridad
- Identidad: emita credenciales nuevas con una nueva generación y el alcance mínimo requerido
- Estado: restaurar a partir de una instantánea autorizada solo después de que la pista de evidencia registre su procedencia e impacto.
- Efectos externos: compensar, notificar o corregir manualmente cada acción comprometida a través del sistema propietario
- Monitoreo: aumentar el muestreo y las alertas para la versión recuperada y definir el umbral de salida
Construir el registro de evidencia del incidente
El registro debe permitir que un revisor independiente reconstruya el evento sin leer una transcripción del chat ni pedir a los encuestados que lo recuerden. Conserve la secuencia del evento de origen y adjunte las decisiones como registros separados y firmados.
En KLA Control Plane, Lineage Explorer reconstruye la ejecución del agente, Audit Trail mantiene la gobernanza y las acciones del operador, y Evidence Room empaqueta registros seleccionados como Sealed Evidence Bundle. Estas rutas se implementan en el entorno de desarrollo de KLA, que es el único entorno que KLA ejecuta actualmente. El paquete aún necesita un manifiesto de recopilación que nombre las fuentes esperadas, las fuentes faltantes y el alcance elegido por el propietario de la evidencia.
| grupo de evidencia | Campos obligatorios | Pregunta respondida |
|---|---|---|
| Detección | Señal, umbral, fuente, primer tiempo observado, primera clasificación, decisión de concientización | ¿Cómo y cuándo supo la organización? |
| Ejecución | Ejecutar, agente, lanzamiento, modelo, solicitud, llamadas a herramientas, argumentos, resultados, efectos secundarios | ¿Qué capacidad actuó y qué cambió? |
| Gobernancia | Versiones de políticas, decisiones, solicitudes de decisiones, aprobadores, roles, hashes de argumentos | ¿Qué controles evaluaron cada acción consecuente? |
| Contención | Comando, alcance, actor, reconocimientos, efecto secundario final, exposición restante | ¿Cuándo se detuvo la capacidad? |
| Recuperación | Procedencia buena conocida, reversión, canario, identidad nueva, elementos de compensación | ¿Cómo se restableció el funcionamiento seguro? |
| Informes | Regímenes aplicables, análisis de factores desencadenantes, evaluación causal, decisión del abogado, presentaciones | ¿Por qué, cuándo y dónde se informó del incidente? |
Relación de los hechos con el artículo 73 de la Ley de IA de la UE
El [texto oficial de la Ley de IA de la UE] (https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) limita el artículo 73 a los proveedores de sistemas de IA de alto riesgo comercializados en el mercado de la Unión. El artículo 3, apartado 49, define un incidente grave como un incidente o mal funcionamiento que directa o indirectamente provoca la muerte o un daño grave para la salud, una alteración grave e irreversible de infraestructuras críticas, una infracción de las obligaciones del Derecho de la Unión que protegen los derechos fundamentales o un daño grave a la propiedad o al medio ambiente.
El Ómnibus Digital sobre IA, Reglamento (UE) 2026/1744, entró en vigor el 27 de julio de 2026. Cambió las fechas de aplicación de los requisitos de alto riesgo del Capítulo III al 2 de diciembre de 2027 para los sistemas del Anexo III y al 2 de agosto de 2028 para los sistemas del Anexo I. Los plazos de presentación de informes del Artículo 73 permanecen sin cambios. La interacción entre la clasificación del sistema, la función del proveedor o implementador, la ley del sector, las fechas de transición y el artículo 73 requiere una decisión legal específica para cada caso.
Registre esa decisión con los hechos disponibles en ese momento. Un evento de seguridad fuera del alcance del Artículo 73 puede requerir acción bajo otro régimen.
| Disposición | norma estatutaria | Registro del libro de jugadas |
|---|---|---|
| Artículo 73, apartado 1 | Un proveedor de un sistema de IA de alto riesgo comercializado en el mercado de la Unión notifica un incidente grave a las autoridades de vigilancia del mercado de los Estados miembros donde ocurrió | Clasificación del sistema, identidad del proveedor, colocación en el mercado, Estados miembros, autoridades |
| Artículo 73, apartado 2 | Informar inmediatamente después de establecer un vínculo causal o una probabilidad razonable de que exista, con un límite máximo de 15 días después de tener conocimiento | Tiempo de concientización, versiones de evaluación causal, tiempo de reporte, motivo del tiempo transcurrido |
| Artículo 73, apartado 3 | Una infracción generalizada o una alteración grave e irreversible de una infraestructura crítica tiene un límite máximo de dos días después de su conocimiento. | Categoría de impacto, alcance geográfico, tiempo de concientización, plazo de dos días |
| Artículo 73, apartado 4 | Una muerte se notifica inmediatamente después de que se establece o sospecha la causa, con un límite máximo de 10 días después del conocimiento. | Daño conocido, tiempo de sospecha, evidencia causal, plazo de diez días |
| Artículo 73, apartado 5 | Un informe inicial incompleto puede ir seguido de un informe completo cuando sea necesario para puntualidad. | Envío inicial, lagunas conocidas, propietario de la actualización, destino del informe completo |
| Artículo 73, apartado 6 | El proveedor investiga, evalúa el riesgo, toma medidas correctivas, coopera e informa a las autoridades antes de un cambio que pueda afectar la evaluación de la causa posterior. | Plan de investigación, estado de conservación, acciones correctivas, contacto con la autoridad antes del cambio material. |
| Artículo 26, apartado 5 | Un implementador que identifica un incidente grave informa inmediatamente primero al proveedor, luego al importador o distribuidor y a las autoridades de vigilancia del mercado pertinentes. | Análisis de roles, intentos de contacto, orden de notificación, ruta de proveedor inalcanzable |
Utilice una secuencia operativa de 24 horas
Establecer el ritmo de respuesta interna dentro de los límites legales de presentación de informes para que la revisión legal reciba hechos verificados mientras la evidencia aún esté disponible.
| tiempo transcurrido | Objetivo principal | Evidencia de salida |
|---|---|---|
| 0 a 15 minutos | Declarar incidente, asignar roles, establecer alcance de denegación, invocar desconexión automática | ID de incidente, tiempo de conocimiento, comando, estado del actuador |
| 15 a 60 minutos | Preservar el estado volátil, revocar la identidad, aislar la carga de trabajo y abarcar el trabajo posterior | Manifiesto de recopilación, resultado de la credencial, efecto secundario final conocido |
| 1 a 4 horas | Seleccione un buen estado conocido, revertir, abrir elementos de compensación, ejecutar canary controlado | Procedencia de recuperación, resultado canario, registro de compensación. |
| 4 a 8 horas | Reconstruir el evento y clasificar el daño, el papel, la geografía y los posibles regímenes. | Cronograma versionado, evaluación de impacto, lista de cuestiones legales |
| 8 a 24 horas | Aprobar notificaciones, emitir la primera actualización de estado, definir plan de seguimiento e investigación | Informe de decisión, presentaciones, actualización de las partes interesadas, próximo momento de revisión |
Ensayar los huecos que aparecen bajo presión.
NIST AI RMF Administre 4 llamadas para planes de respuesta, recuperación y comunicación documentados y monitoreados. El [plan de seguimiento poscomercialización] (/blog/post-market-monitoring-plan-ai-agents) debería proporcionar los umbrales, la propiedad y las fuentes de evidencia que abren este manual.
Ejecute ejercicios para una ejecución activa, una espera de aprobación, una credencial robada, un efecto secundario externo comprometido, una fuente de registro faltante, un proveedor inaccesible y un exportador de evidencia no disponible. Registre el tiempo de contención, el efecto secundario final posterior al comando, los reconocimientos faltantes, la integridad de la evidencia, el tiempo de recuperación y el tiempo de decisión de presentación de informes.
Utilice la Guía de autonomía responsable para confirmar que las autoridades de supervisión ordinaria y de emergencia hayan nombrado propietarios. Revise el [tutorial del incidente de Hugging Face] (/blog/hugging-face-ai-agent-breach-pre-execution-controls) para ver un ejemplo público de acción a velocidad de máquina, recolección de credenciales, movimiento lateral y reconstrucción de más de 17 000 eventos registrados.
Preguntas frecuentes
¿Cuál es la primera acción en un incidente con un agente de IA?
Declare un incidente, asigne el comandante del incidente, el propietario del sistema, el líder de pruebas y el propietario legal, registre el tiempo de conocimiento y establezca el alcance afectado para denegar. Invoque los actuadores de interrupción mientras se preserva la ejecución volátil, la identidad, la política y el estado posterior.
¿Cómo contenemos a un agente de IA deshonesto?
Cancele ejecuciones activas y cerradas, deniegue llamadas a nuevas herramientas en un punto de cumplimiento externo, deshabilite la identidad del agente, revoque y rote credenciales, aísle la carga de trabajo, cancele el trabajo en cola y en sentido descendente, y mantenga el incidente abierto hasta que todos los actuadores requeridos lo reconozcan.
¿Qué significa la reversión para un incidente con un agente de IA?
Restaure la versión, la política, el modelo, el mensaje, el manifiesto de herramienta y la configuración del conector anteriores verificados con credenciales nuevas. Realice un seguimiento de cada efecto secundario externo comprometido a través de un procedimiento de compensación, corrección o notificación específico del sistema.
¿Cuándo exige un informe el artículo 73 de la Ley de IA de la UE?
El artículo 73 se dirige a los proveedores de sistemas de IA de alto riesgo comercializados en el mercado de la Unión cuando se produce un incidente grave en virtud del artículo 3, apartado 49. El plazo y la autoridad para la presentación de informes dependen de la evaluación causal, el tipo de incidente, el Estado miembro, la función, la superposición de sectores y las fechas de aplicación actuales. Un abogado calificado debe confirmar la obligación específica del caso.
¿Cuáles son los plazos de presentación de informes del artículo 73?
El artículo 73 establece la notificación inmediata después de que se establezca un vínculo causal o una probabilidad razonable, con un límite máximo de 15 días después de tener conocimiento. Una infracción generalizada o una alteración grave e irreversible de una infraestructura crítica tiene un límite máximo de dos días. Una muerte tiene un límite de diez días y un desencadenante inmediato cuando se establece o se sospecha la causalidad. Se permite un informe inicial incompleto cuando sea necesario por razones de puntualidad.
¿Qué evidencia debe contener un registro de incidente de un agente de IA?
Mantenga los tiempos de detección y concientización, identificadores de ejecución y lanzamiento, versiones de modelos y solicitudes, llamadas de herramientas, argumentos, decisiones de políticas, aprobaciones, efectos secundarios, comandos y reconocimientos de contención, cambios de credenciales, registros preservados, procedencia de reversión, resultados de compensación, análisis legales e informes.
Conclusiones clave
Un libro de jugadas de incidentes sólido establece el control antes de que el equipo intente explicar el evento. Detenga la capacidad, preserve el estado, restaure una versión verificada, concilie todos los efectos comprometidos y tome la decisión de informar a partir de un registro de evidencia versionado. Conecte el manual con el monitoreo posterior a la comercialización y ensaye hasta que el tiempo de contención, la integridad de la evidencia y el estado de recuperación sean hechos medidos.