TL; DR
La "gestión de riesgos de la IA" describe dos disciplinas opuestas que comparten un nombre. Gestionar el riesgo que genera la IA no es lo mismo que usar la IA para gestionar el riesgo. La mayoría de las organizaciones hacen una cosa, les venden la otra y no informan adecuadamente sobre ninguna de las dos.
- La gestión de riesgos de la IA genómica es un problema de descubrimiento antes que un problema de gobernanza. No se puede gobernar un patrimonio que nunca se ha contabilizado, y el inventario a menudo reside en un
.mcp/servers.jsonarchivo que nadie ha abierto desde que fue committed - La IA para la gestión de riesgos se gana un lugar en tres puestos de trabajo. Correlación, explicación y volumen. No es buena para tomar decisiones, por eso la IA propone y algo determinista verifica antes de que alguien lo vea.
- Ambas disciplinas convergen en un punto. La IA que implementas para gestionar el riesgo es en sí misma un activo de IA, con un modelo, acceso a herramientas y credenciales. Pertenece a tu propio inventario.
- Empiece por contar, no por redactar políticas. Una póliza redactada antes del descubrimiento describe un patrimonio imaginario. Tres cifras en una diapositiva superan un marco que nadie puede verificar.
¿Por qué ahora la “gestión de riesgos de la IA” significa dos cosas diferentes?
Escribe la frase en cualquier cuadro de búsqueda y obtendrás dos bibliotecas completamente diferentes.
Uno es sobre el riesgo que crea la IAModelos con comportamiento impredecible, agentes con más permisos de los previstos, código generado con fallos a gran escala, reguladores que preguntan qué estás ejecutando. Llamémoslo gestión de riesgos de GenAI.
El otro es sobre La IA como instrumento de la función de riesgoModelos que priorizan alertas, resumen la exposición, elaboran soluciones y explican un hallazgo a alguien que no lee registros de pila. Podríamos llamarlo IA para la gestión de riesgos.
Comparten nombre, partida presupuestaria y, a menudo, diapositiva, pero no son la misma disciplina. Una es defensiva y se pregunta qué podría salir mal. La otra es operativa y se pregunta qué podemos dejar de hacer manualmente. CISQuien los confunde acaba con una política de gobernanza que no reduce la carga de trabajo y un programa de automatización que nadie ha evaluado en cuanto a riesgos.
Nombrar la división no es una cuestión de pedantería. Es la forma más rápida de averiguar cuál de las dos financia realmente su organización.
¿Qué debe abarcar la gestión de riesgos de GenAI?
Tres capas, y solo una de ellas es el modelo.
- Lo que escribe la IA. El código generado contiene las mismas clases de vulnerabilidades que el código escrito por humanos, y llega más rápido de lo que el proceso de revisión puede procesarlo. Esta capa recibe casi toda la atención porque es la más conocida.
- A qué está programada la IA. Archivos de habilidades, archivos de reglas, configuraciones del servidor MCP, ámbitos de herramientas, la credencial con la que se ejecuta un agente. Texto sin formato, commitSe revisa como documentación y define a qué tiene acceso el asistente. Esta capa decide hasta dónde llega un ataque exitoso y es invisible para cualquier sistema que pruebe el modelo a través de su punto final.
- Lo que la IA recopila. Dependencias, modelos, conjuntos de datos, herramientas externas. Los atacantes ya no necesitan comprometer a un mantenedor cuando pueden registrar el nombre del paquete que inventó tu agente. Una investigación presentada en USENIX Security en 2025 generó 2.23 millones de muestras de código en 16 modelos y descubrió que el 19.7 % de los paquetes recomendados no existían, produciendo más de 205 000 nombres ficticios únicos.
Cualquier programa de gestión de riesgos de GenAI que cubra solo la primera capa produce un informe limpio y un perfil de riesgo sin cambios. Los 10 mejores candidatos para el Máster en Derecho de OWASP está estructurado en torno a esta realidad: la agencia excesiva se sitúa cerca de los primeros puestos.cisEs posible que se deba a que es un problema de cableado y no un problema del modelo.
Y las tres capas dependen de algo más básico que cualquiera de ellas. Es necesario saber qué IA se tiene. El descubrimiento no es un paso preliminar para la gestión de riesgos de la IA general, sino la base sobre la que se sustenta todo lo demás, y es donde la mayoría de los programas se estancan silenciosamente.
¿Para qué sirve realmente la IA en la gestión de riesgos?
Dejando a un lado el marketing, la respuesta honesta es concisa pero valiosa. La IA en la gestión de riesgos se gana su lugar en tres puestos de trabajo.
- Correlación. Seis herramientas producen seis versiones del mismo hallazgo con seis niveles de gravedad diferentes. Decidir que se trata del mismo problema, en el mismo componente, con una única causa raíz, es un trabajo de análisis de patrones tedioso que los humanos realizan de forma lenta e inconsistente.
- Explicación. La diferencia entre un hallazgo y una solución suele radicar en la comprensión. Una explicación que detalle la ruta de la vulnerabilidad, el componente afectado y el alcance del problema convierte un ticket que alguien cierra como "no se solucionará" en uno que sí se resuelve.
- Volumen. Cuando un programador genera mil archivos en una semana, la revisión deja de ser un control y se convierte en una cola. Nada humano se ajusta a esa situación, y ninguna contratación la cambia.
La IA para la gestión de riesgos no destaca precisamente por su capacidad de decisión. Un modelo que propone una solución no validada representa un riesgo disfrazado de ventaja. El patrón que sí funciona es el razonamiento de la IA combinado con un análisis determinista: la IA propone una solución, y un sistema no probabilístico la verifica para comprobar su conformidad con las políticas, su vulnerabilidad a la explotación y su impacto en los cambios drásticos antes de que nadie la vea.
Existe una segunda ventaja, menos evidente. La misma inteligencia que prioriza los resultados de tus propios escáneres puede priorizar los de los demás. Si la capa de IA se integra con las herramientas que ya has adquirido, en lugar de reemplazarlas, la IA en la gestión de riesgos se convierte en una adición a tu infraestructura en lugar de un proyecto de migración, lo que suele marcar la diferencia entre un programa que comienza este trimestre y uno que comienza el próximo año.
¿Dónde falla la IA en la gestión de riesgos?
Tres modos de fallo, todos ellos comunes.
- Confianza sin procedencia. Un resumen de riesgos generado por IA se lee perfectamente, pero no cita ninguna fuente. Cuando un auditor pregunta cómo se obtuvo una cifra, «el modelo lo dijo» no es una respuesta válida. Cada resultado en un programa de gestión de riesgos necesita una ruta de seguimiento que lo conecte con un hallazgo, un archivo y una línea de código.
- Automatización sin puerta. La tentación con un agente capaz es dejar que arregle las cosas. Para cualquier cosa que llegue al código de producción, una persona debe aprobarlo en el pull requestEsto no es timidez; es la posición que Ley de IA de la UE te empuja hacia de todos modos, en un cronograma escalonado que ya se ha modificado una vez. Construir el punto de aprobación ahora cuesta un diseño decisión. Modernizarlo bajo auditoría cuesta un cuarto.
- Medir la adopción en lugar de la exposición. “Nuestro equipo utiliza IA para la gestión de riesgos a diario” es una estadística de uso. No dice nada sobre si el riesgo disminuyó.
¿Cómo convergen ambas disciplinas?
Esta es la parte que casi nadie ha incluido todavía en una diapositiva.
La IA que implementas para gestionar el riesgo es en sí misma un activo de IA. Tiene uno o varios modelos. Tiene acceso a herramientas. Lee tu código fuente, tus hallazgos y, a menudo, tu Secretos. Se ejecuta con credenciales. Puede conectarse a un servidor MCP. Si tu inventario de gestión de riesgos de GenAI no lo incluye, tu inventario es incorrecto y la vulnerabilidad reside en el sistema con mayores privilegios que posees.
Eso convierte las dos disciplinas en un solo programa. La IA de seguridad se encuentra en el mismo inventario que la IA que instalaron sus desarrolladores. Tiene un estado de aprobación. Tiene un propietario nombrado. Está delimitada, registrada y controlada en el pull request exactamente igual que cualquier otra cosa con acceso de escritura a tus repositorios.
Las organizaciones que consideran la IA para la gestión de riesgos como una simple adquisición de herramientas, en lugar de una implementación de IA, lo descubrirán durante su primera auditoría, y será una conversación incómoda. Las organizaciones que la abordan de ambas maneras obtienen un único inventario, un único modelo de riesgo y una única respuesta cuando el consejo directivo lo solicita.
¿Cómo es un modelo operativo de gestión de riesgos de IA que funcione correctamente?
Seis funcionalidades, cada una con un propietario identificado y algo que demuestre que está en funcionamiento.
| Capacidad | Lo que cubre | ¿Quién es el dueño? | ¿Qué lo demuestra? |
|---|---|---|---|
| descubrimiento de IA | Modelos, agentes, conjuntos de datos, servidores MCP, herramientas de codificación, incluida su IA de seguridad. | Líder de seguridad de aplicaciones | A inventario en vivo con un estado de aprobación por activo |
| Detección de riesgos mediante IA | Rutas de inyección rápidas, límites de agentes inseguros, habilidades maliciosas y archivos de reglas | Líder de seguridad de aplicaciones | Hallazgos mapeados a marcos reconocidos, con archivo y línea |
| Evaluación de la cadena de suministro | Dependencias que la IA incorpora antes de que exista una firma. | Líder de seguridad de aplicaciones | Veredicto de la proyección por paquete, por semana |
| Triaje asistido por IA | Correlación, explicación y priorización en todas las herramientas. | Operaciones de seguridad | Reducción de los hallazgos que llegan a un desarrollador |
| Puerta humana | Aprobación de todo lo que llegue al código de producción. | Líder de plataforma o DevOps | Porcentaje de artículos escritos por agentes pull requests con un aprobador humano |
| Informes | La postura que va hacia arriba | CISOficina O | Una lista de materiales de IA exportable y tres números sobre los que una junta puede actuar |
La fila que la gente olvida es la primera, segunda cláusula. Tu IA de seguridad pertenece a tu propio inventario.
Como empiezas
No con una póliza. Las pólizas redactadas antes del descubrimiento describen un patrimonio imaginario.
Enumera las IA que se ejecutan en tu software, incluyendo las que implementó tu equipo de seguridad. Publica la cifra internamente sin atribución, ya que mencionar nombres en esta etapa fomenta el uso clandestino y destruye la visibilidad que acabas de obtener. Luego, acuerda una lista aprobada que refleje las necesidades reales de tus equipos y restringe el acceso a los elementos que son irrecuperables en caso de fallos: una dependencia maliciosa, una credencial activa y un modelo no aprobado que interactúa con datos regulados.
Las organizaciones que tendrán dificultades con la gestión de riesgos de la IA en 2027 no son las que actuaron con rapidez, sino las que dedicaron 2026 a redactar políticas de IA sin tener en cuenta los resultados.
Esta es la posición xygeni Se diseñó en torno a: un inventario que abarca la IA que instalaron sus desarrolladores y la IA que introdujo su equipo de seguridad, un modelo de riesgo aplicado a sus hallazgos y a los que producen sus otras herramientas, y una persona que aprueba todo lo que llega al código de producción.
Dos disciplinas, un inventario. Cuanto antes dejen de ser programas separados con propietarios separados, antes empezará a funcionar cualquiera de ellos.
Preguntas Frecuentes
¿La gestión de riesgos de la IA es lo mismo que la gobernanza de la IA?
La gobernanza establece las reglas: quién puede usar qué, bajo qué condiciones y con qué aprobaciones. La gestión de riesgos de la IA es el trabajo operativo de averiguar qué se está ejecutando realmente, medir la exposición que genera y reducirla. La gobernanza sin gestión de riesgos produce una política que nadie puede verificar. La gestión de riesgos sin gobernanza produce conclusiones sobre las que nadie tiene autoridad para actuar. La mayoría de las organizaciones tienen mucho más del primer caso que del segundo.
¿Podemos utilizar la IA para la gestión de riesgos antes de haber resuelto la gestión de riesgos de GenAI?
Sí, y la mayoría de los equipos lo harán, porque la presión operativa es inmediata y la presión de gobernanza es trimestral. La condición es que se inventarien los componentes de la IA de seguridad desde el primer día, en lugar de añadirlos posteriormente. Agregar un activo a un inventario es sencillo. Reconstruir dieciocho meses de acceso no documentado para un auditor no lo es.
¿A qué marco de referencia debería ajustarse un programa de gestión de riesgos de IA?
El Marco de gestión de riesgos de IA del NIST es el vocabulario más ampliamente aceptado, y sus cuatro funciones de gobernar, mapear, medir y administrar le brindan una estructura que una junta reconocerá. Combínelo con el trabajo de OWASP GenAI para la capa técnica, ya que NIST le dice qué resultados buscar y OWASP le dice cómo se ven realmente los ataques. Ninguno de los dos le dirá qué contar, lo cual sigue siendo su decisión.cision.
¿La IA en la gestión de riesgos reduce la plantilla de personal?
No en los equipos que lo usan bien. Cambia en qué invierte el equipo su día. La correlación, el triaje y la explicación del primer borrador se trasladan al modelo, y el tiempo humano se traslada al decisIones que tienen consecuencias: qué se restringe, qué riesgo se acepta y quién lo acepta, y qué hallazgos realmente amenazan la producción. Si su plan de negocio se basa en la reducción de personal, el programa suele evaluarse con criterios erróneos en un plazo de dos trimestres.
