TL; DR
Actualmente, todos los consejos de administración preguntan sobre el riesgo de la IA, y la mayoría de los equipos de seguridad responden con adjetivos en lugar de cifras. Los marcos de gobernanza indican qué gobernar, pero no qué cuantificar. Todas estas métricas de riesgo de IA provienen del mismo origen: el código que su organización ya implementa.
- Una estrategia de IA basada en agentes tiene tres capas, y solo una de ellas es el modelo. Lo que escribe el agente, a qué está conectado y qué información recibe. La mayoría de los programas miden lo primero e ignoran los otros dos.
- El radio de explosión no está incluido en el modelo. Se encuentra en el archivo de habilidades, la configuración de MCP, el ámbito de la herramienta y las credenciales con las que se ejecuta el agente. Una evaluación de modelo limpia y un agente con privilegios excesivos coexisten sin problemas.
- Nueve indicadores de riesgo de la IA, cada uno de ellos un número en lugar de un adjetivo. Activos de IA no aprobados, rutas de inyección rápidas que llegan a un sumidero de herramientas, Secretos en
.mcp/servers.json, dependencias añadidas por el agente marcadas antes de que existiera una firma. - Si no puede alcanzar esa cifra este trimestre, el problema no reside en la métrica. El inventario es. Empiece con tres recuentos, no con un programa.
¿Qué implica realmente el riesgo de la IA cuando eres tú quien distribuye el software?
Pregúntale a diez personas qué significa el riesgo de la IA y obtendrás diez respuestas. Sesgo del modelo. Alucinaciones. Fugas de datos. Riesgos regulatorios. Pérdida de empleos. Todos son reales, todos merecen atención, y ninguno de ellos puede ser resuelto por un equipo de seguridad un martes por la tarde.
Existe una versión más específica de la pregunta que un equipo de seguridad sí puede asumir: ¿Qué inteligencia artificial se ejecuta dentro del software que desarrollamos, qué puede alcanzar y qué sucede cuando alguien la manipula? Esa versión tiene una respuesta, y la respuesta reside en sus repositorios y pipelineen lugar de en un documento de política.
Esta es la versión del riesgo de IA de la que trata esta publicación. No porque las cuestiones de gobernanza no importen, sino porque las cuestiones de gobernanza no se pueden responder hasta que se responda esta. Un marco le pide que haga un inventario de sus sistemas de IA. No le dice que el inventario está en un .mcp/servers.json archivo que nadie ha abierto desde que fue committed
¿Por qué la mayoría de los programas de evaluación de riesgos de la IA miden lo incorrecto?
Existen tres patrones de fracaso, y la mayoría de las organizaciones presentan al menos dos de ellos.
- Medir la adopción en lugar de la exposición. «El 72 % de nuestros desarrolladores utiliza herramientas de IA» es una métrica de productividad con un distintivo de seguridad. No dice nada sobre el alcance de esas herramientas.
- Medir el modelo en lugar del sistema. Realizar pruebas de penetración en un punto final permite determinar si se puede persuadir a un modelo para que diga algo que no debería. Sin embargo, no explica qué sucede después, ya que el alcance del impacto reside en el ámbito de la herramienta, las credenciales con las que se ejecuta el agente y los archivos de configuración que definen ambos. Una evaluación de modelo impecable y un agente con privilegios excesivos coexisten sin problemas.
- Medir lo que es fácil de contar. Número de políticas de IA publicadas. Número de empleados que completaron la formación en IA. Estas cifras aumentan de forma constante y no guardan correlación con nada.
El Marco de gestión de riesgos de IA del NIST Es explícito que la medición es una de sus cuatro funciones principales, junto con gobernar, mapear y administrar. El marco está deliberadamente basado en resultados en lugar de ser prescriptivo, lo cual es correcto para un standard y poco útil un martes. Todavía tienes que decidir qué contar.
¿Qué métricas de riesgo de la IA realmente aportan información útil?
Nueve indicadores. Cada uno es un número, cada uno cambia cuando cambia tu exposición y cada uno se puede generar mediante código en lugar de mediante una encuesta.
| Métrico | Por qué importa | De dónde proviene el número |
|---|---|---|
| 01Total de activos de IA descubiertos y variación desde el mes pasado. | No se puede informar sobre el riesgo de la IA si nunca se ha cuantificado. La tendencia importa más que la cantidad absoluta. | Descubrimiento continuo de modelos, marcos de trabajo, conjuntos de datos, puntos finales de inferencia, agentes, servidores MCP, habilidades y herramientas de codificación de IA |
| 02Activos de IA no aprobados como porcentaje del total | Esta es su tasa de IA en la sombra. Es la métrica de riesgo de IA más citada por un consejo de administración. | El estado de aprobación se registra por activo según su póliza. |
| 03Activos de IA sin propietario identificado | Un activo que nadie posee es un activo que nadie arreglará. Generalmente es el número más feo del conjunto. | La propiedad se registra en relación con el activo. |
| 04Rutas de inyección rápidas que llegan a un sumidero de herramientas | La entrada de datos no confiable que llega a la solicitud del sistema solo importa si hay algo peligroso en el otro extremo. | Detección de riesgos de IA mapeada a la Los 10 mejores candidatos para el Máster en Derecho de OWASP |
| 05Servidores MCP en uso y cuántos contienen resultados. | La configuración de MCP es donde el agente recibe sus órdenes. También es donde se acumulan las credenciales. | La configuración del servidor MCP se analizó como un artefacto de seguridad. |
| 06Secretos encontrados en archivos de configuración de IA | Una investigación realizada en 2026 encontró más de 24,000 Secretos en archivos de configuración de MCP en GitHub público, con más de 2,000 aún válidos. | Detección de secretos en todo el código, configuraciones, contenedores y pipelines |
| 07Dependencias añadidas por el agente marcadas antes de que existiera una firma pública. | Los agentes extraen paquetes rápidamente, y el nombre que inventó tu modelo es una superficie de ataque cultivable. | Alerta temprana de malwaredetección de evidencia seguida de validación por IA |
| 08Porcentaje de hallazgos de IA que son accesibles y se encuentran en código en desarrollo activo. | Separa el trabajo pendiente que nunca podrás completar del trabajo que cambia tu exposición. | El embudo de priorización de IA |
| 09Porcentaje de artículos escritos por agentes pull requests fusionado con una aprobación humana | La métrica de gobernanza que un regulador solicitará, y la que nadie monitorea. | Pull request de clientes y puertas de aprobación |
Si solo toma una, tome la métrica 02. La proporción de activos de IA no aprobados con respecto al total de activos de IA es el número que sobrevive a la traducción de un equipo de seguridad a una auditoría. commitcamiseta, y se mueve cuando realmente haces algo.
¿Qué debe abarcar una estrategia de IA basada en agentes?
Tres capas. El error que casi todo el mundo comete es empezar por la primera y parar ahí.
- Primera capa: lo que escribe el agente. El código generado automáticamente presenta las mismas vulnerabilidades que el código escrito por humanos, y estudios que se remontan a 2022 han demostrado sistemáticamente que una parte sustancial de los programas generados por IA contienen fallos de seguridad. Esta capa es la más conocida, razón por la cual acapara toda la atención.
- Capa dos: a qué está conectado el agente. Archivos de habilidades, archivos de reglas, configuraciones del servidor MCP, ámbitos de herramientas, la credencial con la que se ejecuta el agente. Esta es la capa que determina hasta dónde llega un ataque exitoso, y es invisible para cualquier sistema que pruebe el modelo a través de su punto final. ATLAS DE MITRE cataloga este terreno directamente: el caso de éxito de Rules File Backdoor, AML.CS0041, describe caracteres de ancho cero en un archivo de reglas que convierten la documentación en instrucciones que un agente obedece silenciosamente. Un revisor que lee el pull request no ve nada.
- Tercera capa: lo que el agente recopila. Dependencias, modelos, conjuntos de datos, herramientas externas. 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, lo que produjo más de 205 000 nombres ficticios únicos. Los atacantes ya no necesitan comprometer a un mantenedor. Simplemente registran el nombre que inventó tu agente y esperan.
Una estrategia de IA con agentes que cubre solo la capa uno produce un informe limpio y un perfil de riesgo de IA sin cambios. Los 10 mejores candidatos para el Máster en Derecho de OWASP refleja esto en su propia estructura: la agencia excesiva se sitúa en la cima de la lista precisEs posible que se deba a que es un problema de cableado, no un problema del modelo.
¿Cómo se implementa esto sin ralentizar a los agentes?
El instinto nos lleva a restringirlo todo. Esto fracasa porque el objetivo principal del agente es el rendimiento, y un control que reduce el rendimiento a la mitad se elimina en menos de un trimestre.
Tres principios de implementación que se mantienen vigentes:
- Medir continuamente, seleccionar selectivamente. Las nueve métricas de riesgo de IA se pueden recopilar en cada escaneo sin bloquear nada. Reserve los controles estrictos para el pequeño conjunto donde el fallo es irrecuperable: una dependencia maliciosa, un Secreto activo, un modelo no aprobado que maneja datos regulados.
- Coloca la seguridad donde ya está el agente. Un agente conectado a través de MCP llama a la plataforma de seguridad mientras genera y analiza el código que acaba de escribir, e itera sobre las correcciones hasta que el código cumpla con los umbrales establecidos. No hay intervención humana en esta etapa, ni es necesario instalar nada donde se ejecuta el agente. Este es el único punto de intervención que se adapta al rendimiento del agente, en lugar de depender de él.
- Mantén al humano en el pull request. Todo lo que llega al código de producción debe ser aprobado por una persona. Esto no es prudencia, sino la postura de diseño que la Ley de IA de la UE promueve, y es mucho más económico implementarlo ahora que adaptarlo posteriormente bajo la presión de una auditoría. Además, se trata de la métrica 09, razón por la cual vale la pena monitorizarla desde el primer día.
La fila que suele quedar sin asignar en la mayoría de las organizaciones es la segunda. Los archivos de configuración se encuentran entre la seguridad de las aplicaciones, que los trata como infraestructura, y la ingeniería de plataformas, que los trata como documentación. Es precisamente en ese vacío donde se producen los ataques más interesantes.
¿Cómo empezar a medir el riesgo de la IA este trimestre?
No desarrolles el programa completo. Genera tres datos. Cuenta tus recursos de IA. Cuenta cuántos de ellos no fueron aprobados. Cuenta cuántos Secretos se encuentran en archivos de configuración de IA. Estos tres datos caben en una diapositiva; son todos defendibles y resultarán peores de lo que espera quien los solicitó.
Luego, seleccionen el problema más grave y soluciónenlo antes de la próxima reunión de la junta directiva. Ese es un programa de gestión de riesgos de IA que funciona. Todo lo demás es secundario.
Las organizaciones que tendrán dificultades con el riesgo de la IA en 2027 no son las que actuaron con rapidez, sino las que dedicaron 2026 a redactar políticas de IA sin realizar ningún análisis. Una política sin métricas de riesgo es solo un documento. Las métricas de riesgo de la IA son las que la convierten en un control.
Consulta tus propias cifras. Conecta un repositorio y Xygeni te devuelve tu inventario de IA, los activos no aprobados, los riesgos mapeados a los marcos que utilizan tus auditores y una lista de materiales de IA (AI-BOM) que puedes exportar. Empieza gratis or RESERVAR UNA DEMOSTRACIÓN.
Preguntas Frecuentes
¿Cuál es la diferencia entre riesgo e seguridad en la IA?
La seguridad de la IA se centra principalmente en el comportamiento del modelo: si actúa según lo previsto, si sus resultados son perjudiciales y si puede ser manipulado para que actúe de forma indebida. El riesgo de la IA, en el contexto de la seguridad, se refiere al alcance que un sistema de IA comprometido o con mal funcionamiento puede tener dentro del entorno. Ambos aspectos se superponen, pero son responsabilidad de equipos diferentes y se miden con instrumentos distintos. Un equipo de seguridad puede actuar sobre el segundo aspecto desde hoy mismo.
¿Cuántas métricas de riesgo de IA deberíamos presentar al consejo de administración?
De tres a cinco. Un consejo no puede tomar decisiones con nueve cifras, y una presentación con nueve suele ocultar la que realmente importa. Informe el número total de activos de IA, el porcentaje no aprobado y una métrica de exposición, como los hallazgos de IA disponibles en desarrollo activo. Guarde el resto para la revisión operativa.
¿Necesitamos una lista de materiales basada en IA si aún no existe ninguna normativa que la exija?
Actualmente, ninguna normativa exige una lista de materiales para IA (AI-BOM), razón por la cual generarla es económico ahora y costoso en el futuro. Hoy existen dos formatos legibles por máquina, y un auditor aceptará cualquiera de ellos. El valor no reside en el cumplimiento normativo, sino en que la generación del archivo obliga a disponer del inventario, y de este inventario dependen todas las métricas de riesgo de la IA.
Nuestros desarrolladores utilizan herramientas de IA que nunca aprobamos. ¿Por dónde empezamos?
Antes de actuar, implementa medidas de control. Anunciar una política contra herramientas invisibles fomenta su uso clandestino y reduce la visibilidad necesaria. Primero, realiza un análisis inicial, publica la cifra internamente sin atribución y úsala para elaborar una lista de herramientas aprobadas que refleje las necesidades reales de los usuarios. La aplicación de la normativa resulta mucho más efectiva cuando se basa en la evidencia que cuando se anticipa a ella.
