¿Ya tienes un presupuesto para seguridad de IA? ¿Y ahora qué?

Conclusiones clave

• Los presupuestos para seguridad de IA deben dejar atrás el gasto en herramientas aisladas y convertirse en una inversión unificada en visibilidad, gobernanza y control durante todo el ciclo de vida de la IA.

• Las organizaciones deben presupuestar dos frentes conectados: proteger el desarrollo agéntico, donde los agentes de IA generan código, usan herramientas y ejecutan flujos de trabajo, y proteger las aplicaciones agénticas, donde los agentes interactúan con usuarios, datos, API y sistemas de producción.

• Un presupuesto sólido para seguridad de IA debe incluir fondos específicos para el descubrimiento de IA, la evaluación de riesgos de agentes y modelos, la aplicación de políticas, las pruebas adversariales, la protección en tiempo de ejecución y las pruebas de gobernanza.

• La gobernanza y el cumplimiento deben tratarse como una partida presupuestaria propia, no quedar ocultos dentro del gasto en herramientas ni relegarse al área de GRC. Los equipos necesitan descubrimiento continuo, políticas aplicables, informes de riesgos y registros de auditoría que demuestren que los sistemas de IA se gestionan de forma responsable.

• Comprar herramientas aisladas de seguridad de IA puede aumentar los costos y la complejidad sin ofrecer un control unificado. Un enfoque de plataforma ayuda a los equipos de seguridad a conectar la visibilidad de la IA, la inteligencia sobre riesgos, la aplicación de políticas y las evidencias en desarrollo y producción.

La mayoría de las organizaciones destinan su presupuesto de seguridad de IA a la capa equivocada. El impulso inicial es comprar herramientas de visibilidad para inventariar los modelos, mapear las API y lanzar un panel.

Pero la visibilidad por sí sola no detendrá al agente de programación que acaba de incorporar un servidor MCP comprometido. Tampoco detendrá al agente en producción que está a punto de enviar un registro de un cliente a un lugar al que no debería llegar. Ni impedirá que un flujo de trabajo autónomo encadene cinco acciones permitidas por separado para producir un resultado peligroso.

La visibilidad sin aplicación de políticas no es gobernanza. Las organizaciones que adoptan agentes de IA ahora deben proteger dos frentes distintos, pero conectados:

1. Los agentes que desarrollan software

2. Los agentes que operan dentro de aplicaciones en producción

El problema presupuestario que los líderes de seguridad deben resolver ahora no es si pueden detectar los riesgos de IA después de que ocurran, sino si pueden gobernar los agentes durante todo su ciclo de vida: desde cómo se crean hasta cómo se comportan en producción. Para ello, hay que proteger ambos frentes: trasladar la seguridad hacia las primeras etapas para proteger el código generado por IA y la cadena de suministro de agentes mientras se desarrolla el software, y ofrecer visibilidad y gobernanza sobre los agentes y las aplicaciones que se ejecutan en producción.

Frente 1: Proteger a los agentes que desarrollan software

En el desarrollo agéntico, los agentes de IA ahora incorporan dependencias, invocan servidores MCP, ejecutan scripts, encadenan acciones entre entornos y generan código listo para producción con una revisión humana mínima. Esto crea tres superficies de riesgo que la seguridad de aplicaciones tradicional no se diseñó para controlar: lo que usan los agentes, lo que hacen y lo que generan.

1. Lo que usan los agentes: servidores MCP, habilidades y herramientas externas

Los agentes de programación con IA no parten de cero. Para completar tareas, incorporan continuamente servidores MCP, API externas, habilidades reutilizables, componentes de código abierto, complementos y herramientas de terceros; cualquiera de estos elementos puede ser vulnerable, malicioso o estar mal configurado.

Estos componentes se seleccionan e invocan en tiempo de ejecución, sin aprobación previa, lo que significa que pueden introducirse herramientas externas no confiables en tu flujo de trabajo al instante. Si una herramienta de seguridad solo analiza el artefacto final, no detecta el momento en que el riesgo entró en el flujo de trabajo: cuando el agente seleccionó y usó una entrada no confiable.

La investigación de Snyk ya identificó capacidades maliciosas de agentes en ecosistemas compartidos, servidores MCP vulnerables y fallas críticas en infraestructuras de agentes de uso extendido. CVE-2025-6514, por ejemplo, expuso mcp-remote a la ejecución remota completa de código.

2. Lo que hacen los agentes: ejecución de herramientas, scripts y acceso a sistemas

Los agentes no solo sugieren: ejecutan acciones de forma autónoma y a velocidad de máquina. Una vez que reciben un objetivo, pueden ejecutar comandos, modificar archivos, interactuar con la infraestructura, consultar sistemas, llamar a API y encadenar flujos de trabajo entre entornos, a menudo con permisos amplios, supervisión limitada y sin aprobación humana.

El incidente de Replit hizo tangible este tipo de falla: un agente de IA ignoró instrucciones explícitas de «congelar», eliminó una base de datos de producción e inventó miles de registros falsos para ocultar lo que había hecho.

Este tipo de incidente no ocurre porque un analizador no haya detectado una función vulnerable. Ocurre porque el comportamiento dinámico y de varios pasos del agente no se gobernó en el momento de actuar. El desarrollo agéntico requiere controles dentro del ciclo de ejecución, lo suficientemente cerca como para evaluar el contexto, los permisos y el riesgo antes de que se complete una acción insegura.

3. Lo que generan los agentes: código y dependencias

Los agentes también generan código y dependencias más rápido de lo que una revisión humana puede validar. Ese resultado puede incluir vulnerabilidades, dependencias inseguras, secretos codificados directamente o configuraciones incorrectas.

El problema del desarrollo agéntico es que la IA produce código continuamente, a velocidad de máquina y, a menudo, fuera de los procesos de revisión en los que confían las organizaciones. Para cuando se ejecuta el análisis posterior a la confirmación, el código vulnerable puede estar ya en el repositorio. En algunos flujos de trabajo, incluso puede haberse empaquetado, implementado o reutilizado por otro agente.

Proteger el código generado significa validarlo en el momento de su creación, antes de que llegue al repositorio o forme parte de un flujo de trabajo agéntico más amplio. En el desarrollo agéntico, si no proteges lo que generan los agentes desde el momento de su creación, estarás persiguiendo el riesgo después de que ya se haya introducido.

Frente 2: Proteger a los agentes que operan dentro de aplicaciones en producción

El segundo frente es producción. La mayoría de las organizaciones ya tienen agentes que operan dentro de aplicaciones, como agentes de soporte que atienden solicitudes de clientes, agentes de flujos de trabajo que acceden a sistemas internos, procesos autónomos que llaman a API y aplicaciones nativas de IA que recuperan datos, toman decisiones y actúan sin intervención humana.

La pregunta es si sabes qué hacen tus agentes y si puedes detenerlos cuando hacen algo indebido. Una vez que están activos, la gobernanza falla en tres dimensiones: descubrimiento, evaluación de riesgos y cumplimiento.

1. Descubrimiento: no puedes gobernar los agentes que no ves

Los equipos de seguridad necesitan una visión en tiempo real de dónde se ejecutan los agentes de IA, qué modelos usan, qué herramientas invocan, a qué datos acceden y qué flujos de trabajo ejecutan.

La mayoría de las organizaciones no tienen una visión completa. La IA en la sombra agrava el problema, ya que los empleados y equipos crean herramientas personalizadas de IA generativa, incorporan agentes a los flujos de trabajo y conectan sistemas de IA con datos internos sin una revisión formal de seguridad. Por eso, la falta de inventario no se limita a tener documentación incompleta de los sistemas conocidos: también implica desconocer los agentes que operan fuera de los canales establecidos.

Si no sabes qué agentes existen, no puedes aplicarles políticas, evaluar sus riesgos, demostrar el cumplimiento ni asignar responsabilidades cuando algo sale mal. El inventario es la base de la gobernanza, pero no es el objetivo final.

2. Evaluación de riesgos: las reglas deben aplicarse donde actúan los agentes

Muchas organizaciones ya tienen políticas de gobernanza de IA. El problema es que la mayoría está en documentos, hojas de cálculo o procesos de revisión que los agentes nunca encuentran. Esta «gobernanza sobre el papel» crea una peligrosa falsa sensación de seguridad.

Por ejemplo, una política que dice «los agentes no pueden exponer datos de clientes a servicios externos» solo importa si se aplica cuando el agente intenta hacerlo. De lo contrario, la organización tiene gobernanza en el papel y comportamientos sin control en producción.

Las aplicaciones agénticas necesitan que las políticas se apliquen en la capa de ejecución, donde las reglas evalúan qué intenta hacer el agente, qué datos utiliza, qué herramientas invoca y si la acción cruza un límite definido. Así, si un agente manipulado intenta enviar datos de clientes a un punto de conexión externo, la acción se puede bloquear o modificar antes de que se complete.

3. Cumplimiento: debes demostrar qué pasó, por qué y con qué autoridad

Cuando un agente provoca un problema comercial, los equipos de seguridad necesitan más que registros. Necesitan un registro justificable de lo ocurrido: qué hizo el agente, a qué datos accedió, qué herramienta invocó, qué política se aplicó, si la acción se permitió o se bloqueó y quién era responsable del flujo de trabajo.

El caso de Air Canada demostró que se puede responsabilizar a las organizaciones por lo que un chatbot de IA les dice a los clientes. El incidente de inyección de instrucciones de Chevrolet mostró lo fácil que es manipular una IA de cara al público para que produzca resultados con consecuencias comerciales. Los flujos tóxicos muestran cómo los agentes pueden encadenar herramientas, datos y API de formas que ninguna acción aislada revelaría por sí sola.

La gobernanza y el cumplimiento deben ser una partida específica del presupuesto de seguridad de IA, no algo oculto dentro del gasto en herramientas ni tratado como una tarea posterior de GRC. A medida que los agentes de IA se extienden por los flujos de trabajo de desarrollo y las aplicaciones de producción, las organizaciones necesitan demostrar qué sistemas de IA existen, qué políticas se les aplican y si esas políticas se hacen cumplir. Sin esa base, el costo de la gobernanza aparece más adelante en forma de auditorías fallidas, acuerdos empresariales estancados, investigaciones posteriores a incidentes o consultorías urgentes para reconstruir un registro de auditoría que debería haber existido desde el principio.

Por qué no funciona comprar dos herramientas desconectadas

El riesgo de IA no se limita ordenadamente a una sola capa. Un modelo, un marco de trabajo de agentes o un servidor MCP puede incorporarse en el código, implementarse mediante un pipeline, ser invocado por una aplicación y luego ser usado por un agente para actuar en producción. Si cada etapa se rige por una herramienta distinta, los equipos de seguridad deben unir vistas parciales del mismo sistema.

El riesgo de IA no se limita ordenadamente a una sola capa. Un modelo, un marco de trabajo de agentes o un servidor MCP puede incorporarse en el código, implementarse mediante un pipeline, ser invocado por una aplicación y luego ser usado por un agente para actuar en producción. Si cada etapa se rige por una herramienta distinta, los equipos de seguridad deben unir vistas parciales del mismo sistema.

Las herramientas fragmentadas generan un control fragmentado. Esto provoca:

• Políticas inconsistentes entre desarrollo y tiempo de ejecución

• Inventarios duplicados que no coinciden

• Puntos ciegos entre la compilación y la implementación

• Registros de auditoría separados que solo cuentan una parte de la historia

• Falta de claridad sobre quién es responsable cuando ocurre un incidente relacionado con agentes

También genera costos fragmentados, ya que cada herramienta especializada implica su propia licencia, trabajo de integración, pipeline de datos, panel y relación con el proveedor. Los equipos suelen duplicar esfuerzos en capacidades de descubrimiento, análisis de riesgos y aplicación de políticas que se superponen, y aun así quedan brechas entre ellas. Para cuando se integran varias herramientas, el costo y la complejidad totales pueden superar el valor de una plataforma unificada, sin ofrecer un control unificado.

En seguridad de IA, la consolidación va más allá de una decisión presupuestaria. Es un requisito de gobernanza. Los equipos de seguridad necesitan una visión conectada de dónde existe la IA, qué riesgos introduce, cómo se comporta y qué políticas se aplican durante todo su ciclo de vida. Sin esa conexión, las organizaciones pueden gastar más y seguir careciendo de la visibilidad, la rendición de cuentas y el control necesarios para ampliar la adopción de IA de forma segura.

Snyk protege ambos frentes de la seguridad agéntica desde una sola plataforma

La plataforma de seguridad de IA de Snyk protege ambos frentes del ciclo de vida de los agentes desde una sola plataforma. Para el desarrollo agéntico, Snyk ayuda a gobernar lo que usan los agentes, lo que hacen y lo que generan: desde servidores MCP y habilidades hasta la ejecución y el código generado por IA. Para las aplicaciones agénticas en producción, Snyk ofrece un registro central de los riesgos de IA relacionados con agentes, modelos, herramientas, datos y flujos de trabajo mediante Evo AI-SPM, y convierte los objetivos de gobernanza en políticas aplicables.

El resultado es una sola capa de control para la seguridad de los agentes: descubrimiento compartido, políticas comunes, aplicación en tiempo real y auditabilidad en desarrollo y producción.

En conjunto, esto crea un modelo unificado para la seguridad de los agentes:

• Un sistema único de registro para los riesgos de la IA y los agentes

• Un modelo único de políticas para desarrollo y producción

• Una capa única de aplicación para comportamientos inseguros de los agentes

• Un registro de auditoría único para la gobernanza y la rendición de cuentas

La pregunta que debes responder antes de cerrar el presupuesto

Si tienes un presupuesto para seguridad de la IA y un equipo directivo que espera resultados, la pregunta clave es simple: ¿Puedes aplicar una política de seguridad a un agente —durante el desarrollo y en producción— antes de que complete una acción insegura?

Si la respuesta es no, no tienes seguridad para agentes ni estás preparado adecuadamente para que el próximo agente elimine una base de datos de producción, alucine una política que haga responsable a tu empresa, filtre datos confidenciales o combine herramientas aprobadas para crear un flujo de trabajo inseguro. Las organizaciones que tengan éxito con la IA no serán las que frenen su adopción. Serán las que integren un control continuo en la forma en que los agentes desarrollan software y operan en producción.

El presupuesto está aprobado y la amenaza es real. El siguiente paso es asegurarte de que tu programa de seguridad de la IA pueda actuar antes de que una acción insegura se convierta en un incidente empresarial. ¿Quieres una guía práctica para implementar una gobernanza continua y exigible? Descarga hoy la Executive Guide to Operationalizing & Enforcing AI Governance.