1. Proposito
Esta politica define como [Nombre de la organizacion] detecta, clasifica, contiene y se recupera de incidentes especificos de IA. Los planes estandar de respuesta a incidentes de TI no cubren los modos de fallo de IA como la deriva del modelo, las alucinaciones, los incidentes de sesgo, la inyeccion de prompts o el envenenamiento de datos. Esta politica cubre esa brecha.
2. Alcance
Esta politica se aplica a:
- Todos los sistemas de IA en produccion (internos y orientados al cliente).
- Todos los incidentes de seguridad, seguridad fisica y fallos de rendimiento relacionados con IA.
- Todos los empleados que detecten, reporten o respondan a incidentes de IA.
- Incidentes que involucren tanto sistemas de IA desarrollados internamente como de terceros.
3. Categorias de incidentes de IA
| Categoria | Descripcion | Ejemplos |
|---|---|---|
| Seguridad fisica | El resultado de IA causa o podria causar dano a personas | Consejo medico peligroso, recomendacion de seguridad incorrecta, contenido danino para menores |
| Sesgo | La IA produce resultados discriminatorios entre grupos protegidos | Tasas de rechazo dispares en contratacion, puntuacion crediticia sesgada, moderacion de contenido injusta |
| Seguridad | Ataque adversario o acceso no autorizado a sistemas de IA | Inyeccion de prompts, jailbreak, extraccion de modelos, exfiltracion de datos a traves de IA, envenenamiento de datos de entrenamiento |
| Privacidad | La IA expone datos personales o confidenciales | Memorizacion de PII por el modelo, fuga de datos confidenciales por prompt, intercambio no autorizado de datos a traves de IA |
| Rendimiento | La calidad de la IA se degrada por debajo de los umbrales aceptables | Caida de exactitud, aumento de alucinaciones, pico de latencia, deriva del modelo mas alla de la tolerancia |
| Cumplimiento | La IA opera fuera de los limites regulatorios | Divulgaciones de transparencia faltantes, decisiones automatizadas no autorizadas, brechas de documentacion descubiertas |
4. Clasificacion de severidad
| Severidad | Criterios | Tiempo de respuesta |
|---|---|---|
| Critico (P1) | Dano activo a personas, violacion de datos o notificacion regulatoria requerida | Respuesta inmediata, contencion dentro de 1 hora |
| Alto (P2) | Riesgo significativo de dano, sesgo significativo detectado o violacion de seguridad contenida pero no resuelta | Respuesta dentro de 4 horas, contencion dentro de 24 horas |
| Medio (P3) | Degradacion del rendimiento, sesgo no critico o brecha de cumplimiento identificada | Respuesta dentro de 24 horas, resolucion dentro de 5 dias habiles |
| Bajo (P4) | Problema de calidad menor, hallazgo informativo o problema estetico | Registrado y atendido en la proxima revision programada |
5. Proceso de respuesta
Texto de marcador de posición. Complete con el lenguaje de su organización para 5. Proceso de respuesta.
Fase 1: Deteccion y reporte
- Los incidentes pueden detectarse mediante alertas de monitoreo, reportes de usuarios, hallazgos de auditoria o notificaciones de terceros.
- Cualquier empleado que sospeche un incidente de IA debe reportarlo inmediatamente al Responsable de gobernanza de IA o al equipo de seguridad.
- El reporte debe incluir: nombre del sistema, descripcion del incidente, estimacion de severidad y cualquier accion inmediata tomada.
Fase 2: Triaje
- El Responsable de gobernanza de IA (o Seguridad para incidentes de seguridad) asigna la severidad y ensambla el equipo de respuesta.
- La composicion del equipo de respuesta depende de la categoria: Titular del modelo (siempre), Seguridad (para seguridad/privacidad), Juridico (para cumplimiento/regulatorio), Titular de datos (para incidentes de datos).
- Para P1 y P2: el sistema de IA puede suspenderse pendiente de investigacion. La decision de suspender la toma el Responsable de gobernanza de IA o el lider del equipo de seguridad.
Fase 3: Contencion
- Detener el dano inmediato: suspender el sistema, bloquear el vector de ataque, revertir a una version anterior del modelo o restringir el acceso.
- Preservar la evidencia: registros, estado del modelo, muestras de entrada/salida, datos de monitoreo.
- Notificar a las partes afectadas si es necesario (ver seccion 6).
Fase 4: Investigacion
- Identificar la causa raiz: ¿fue un problema del modelo, de datos, de infraestructura o una accion adversaria?
- Determinar el alcance: ¿cuantos usuarios/decisiones/resultados se vieron afectados? ¿En que periodo de tiempo?
- Evaluar las implicaciones regulatorias: ¿esto desencadena obligaciones de notificacion?
Fase 5: Correccion
- Corregir la causa raiz (reentrenar, parchear, actualizar barreras de proteccion, corregir el pipeline de datos).
- Validar la correccion mediante pruebas antes de restablecer el servicio en produccion.
- Actualizar el monitoreo para detectar la recurrencia.
Fase 6: Revision posincidente
- Realizar una revision posincidente sin culpables dentro de los 10 dias habiles posteriores a la resolucion.
- Documentar: cronologia, causa raiz, impacto, acciones de respuesta, lecciones aprendidas, medidas preventivas.
- Presentar los hallazgos al Comite de gobernanza de IA para incidentes P1 y P2.
- Actualizar politicas, procedimientos o controles basandose en las lecciones aprendidas.
6. Obligaciones de notificacion
| Desencadenante | Notificacion requerida | Plazo |
|---|---|---|
| Violacion de datos personales (RGPD Art. 33) | Autoridad de control | Dentro de las 72 horas de haber tomado conocimiento |
| Alto riesgo para los derechos de las personas (RGPD Art. 34) | Personas afectadas | Sin demora indebida |
| Incidente grave de IA (Reglamento Europeo de IA Art. 73) | Autoridad de vigilancia del mercado | Dentro de los 15 dias de haber tomado conocimiento |
| Incidente de IA del proveedor | Interno: Responsable de gobernanza de IA + Juridico | Dentro de las 24 horas de la notificacion del proveedor |
7. Roles y responsabilidades
| Rol | Responsabilidades de respuesta a incidentes |
|---|---|
| Responsable de gobernanza de IA | Clasifica los incidentes, ensambla el equipo de respuesta, coordina la investigacion, gestiona las comunicaciones. |
| Titular del modelo | Proporciona el contexto del sistema, ejecuta la contencion (suspension/reversion), lidera la investigacion tecnica. |
| Seguridad | Lidera la respuesta a incidentes de seguridad, preserva la evidencia, realiza el analisis forense. |
| Juridico | Evalua las obligaciones de notificacion, redacta las comunicaciones con reguladores, asesora sobre responsabilidad. |
| Comunicaciones | Gestiona las comunicaciones externas si se requiere divulgacion publica. |
8. Alineacion regulatoria
- Reglamento Europeo de IA: Articulo 73 (notificacion de incidentes graves), Articulo 20 (acciones correctivas).
- RGPD: Articulos 33-34 (notificacion de violaciones).
- ISO/IEC 42001: Clausula 10.2 (no conformidad y accion correctiva).
- NIST AI RMF: Funcion MANAGE (MG-4: respuesta a incidentes).
- Marco de IR de IA de CoSAI: Guias de deteccion, triaje, contencion y recuperacion.
9. Revision
Esta politica se revisa anualmente, despues de cada incidente P1 y cuando surjan nuevas categorias de incidentes por orientacion regulatoria o experiencia del sector.
Control documental
| Campo | Valor |
|---|---|
| Titular de la politica | [Responsable de gobernanza de IA / CISO] |
| Aprobado por | [Comite de gobernanza de IA] |
| Fecha de vigencia | [Fecha] |
| Proxima fecha de revision | [Fecha + 12 meses] |
| Version | 1.0 |
| Clasificacion | Interna |