“Las cerraduras hacen que la gente honrada siga siendo honrada. La gobernanza es el papeleo que demuestra que pusiste bien las cerraduras.”
Modela las amenazas de tu sistema de IA a propósito
Antes de los marcos, la práctica fundamental: siéntate y razona sobre tu sistema concreto. ¿Cuáles son los activos (datos, capacidades, reputación)? ¿Quién podría atacarlo y por qué? ¿Dónde están las fronteras de confianza? ¿Qué es lo peor que podría hacer un modelo comprometido? Los métodos clásicos de modelado de amenazas como STRIDE se adaptan con facilidad a la IA: solo estás añadiendo los modos de fallo del modelo a la lista.
El resultado es una lista priorizada de riesgos ligados a tu arquitectura, que te dice dónde invertir las defensas del capítulo anterior. Una lista de comprobación genérica te dice lo que es posible; un modelo de amenazas te dice lo que importa aquí. Haz el modelo de amenazas.
Los marcos que vale la pena conocer
No necesitas memorizar las normas, pero deberías conocer el mapa, porque los clientes y los auditores se referirán a ellas:
- NIST AI Risk Management Framework: un marco estadounidense voluntario para identificar y gestionar los riesgos de la IA a lo largo del ciclo de vida de un sistema. Un punto de referencia común; en Europa, el Reglamento de IA y las directrices de la AEPD son la referencia.
- OWASP Top 10 para aplicaciones LLM: la lista del profesional de las vulnerabilidades LLM más críticas; corresponde directamente a los capítulos 2 a 5.
- MITRE ATLAS: una base de conocimiento de las tácticas adversarias reales contra los sistemas de IA, modelada sobre el marco ATT&CK.
- SOC 2: no específico de la IA, pero el informe de confianza que piden las grandes empresas europeas; tus funcionalidades de IA entran en su alcance.
- Normas sectoriales y regionales: RGPD, el Reglamento de IA, y normas de sanidad y banca; CCPA/CPRA y HIPAA si tocas el mercado estadounidense.
Garantía: demostrárselo a otra persona
La garantía es la prueba de que tu seguridad existe y funciona. Para un comprador de empresa, «confía en nosotros» no es una respuesta; necesita verlo. Eso significa políticas (reglas escritas sobre cómo se construye y se usa la IA), controles documentados (lo que haces y por qué), pistas de auditoría (los registros y trazas del capítulo 6, que sirven de prueba), y un historial de pruebas (tus hallazgos de equipo rojo y sus correcciones).
Aquí es donde el posicionamiento de SDEN se encuentra con el trabajo técnico: el cumplimiento con SOC 2 y el RGPD no es una sobrecarga burocrática atornillada al final. Es el resultado natural de haber hecho bien el trabajo de ingeniería y de haberlo documentado. Un sistema construido con los controles de este curso produce las pruebas casi como subproducto. Un sistema que no lo hizo no puede fingirlas.
La gobernanza como proceso vivo
La gobernanza fracasa cuando es un documento escrito una vez y archivado. Los sistemas de IA cambian cada semana (nuevos prompts, nuevos modelos, nuevas herramientas, nuevos datos), y cada cambio puede modificar el panorama de riesgos. La gobernanza tiene que ser un proceso que siga el ritmo: un paso de revisión de cambios que pregunte «¿esto afecta a nuestros riesgos o controles?», una reevaluación periódica, y una responsabilidad clara para que la seguridad no sea tarea de todos y, por tanto, de nadie.
- Responsabilidad: una persona o un equipo nombrado como responsable de la seguridad de la IA, no un difuso «a todos nos importa».
- Revisión de cambios: los cambios de modelo, prompt, herramienta y datos pasan por una comprobación ligera de riesgos, no solo por una evaluación de calidad.
- Reevaluación periódica: el modelo de amenazas y los controles se revisan según un calendario, no solo después de un incidente.
- Respuesta a incidentes: un plan ensayado para cuando algo se cuela, incluido quién decide retirar la funcionalidad.
- Gestión de proveedores: las decisiones de confianza sobre los proveedores y las herramientas del capítulo 5, seguidas y revisadas.
Por dónde seguir a partir de aquí
Ahora tienes el arco completo: la nueva superficie de ataque, las amenazas que residen en ella, las defensas en capas, y la gobernanza que las demuestra y las sostiene. El hilo conductor es simple: no puedes confiar en el modelo, así que lo restringes, lo vigilas y lo documentas. Combina esto con el curso de Construir con IA para la parte de ingeniería, y el trabajo de seguridad de SDEN es exactamente esta disciplina aplicada a sistemas reales bajo obligaciones reales.
Una línea por cada uno
- Modela las amenazas de tu sistema concreto (STRIDE más los modos de fallo de los LLM); una lista genérica dice lo que es posible, un modelo de amenazas dice lo que importa aquí.
- Conoce el mapa de marcos (NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS, SOC 2) como estructura compartida, no como sustituto de los controles reales.
- La garantía consiste en demostrarlo con políticas, controles documentados, pistas de auditoría y un historial de pruebas: el subproducto natural de una ingeniería bien hecha.
- La gobernanza debe ser un proceso vivo: responsabilidad clara, revisión de cambios, reevaluación periódica y un plan de incidentes ensayado.