OWASP actualiza su guía de seguridad para IA

OWASP volvió a mover la barra de la seguridad para IA justo cuando muchas empresas están pasando de pilotos a despliegues reales. Y eso importa más de lo que parece, porque el problema ya no es solo “usar un LLM”, sino conectar modelos con datos internos, herramientas, APIs, flujos de aprobación y agentes que toman acciones por su cuenta.

Si trabajas en producto, seguridad o arquitectura, el cambio te afecta de forma directa. Los riesgos que antes se veían como “casos raros” ahora aparecen en tareas cotidianas: un prompt malicioso que intenta sacar información, un agente que ejecuta una acción no prevista, una integración que expone datos sensibles o una política de acceso que quedó demasiado amplia. OWASP está actualizando sus marcos para cubrir ese escenario con más precisión, y vale la pena revisar qué trae, qué no trae y cómo aterrizarlo en equipos de LatAm.

Qué está actualizando OWASP y por qué te debería importar

OWASP GenAI Security Project nació para ordenar el caos alrededor de la seguridad en aplicaciones con IA generativa. Su trabajo más conocido ha sido ayudar a equipos a identificar riesgos y a convertirlos en controles concretos, algo parecido a lo que hizo OWASP en su momento con aplicaciones web, solo que ahora el foco está en modelos, prompts, contextos, herramientas y cadenas de ejecución más complejas.

La actualización que está empujando el proyecto apunta a ampliar esos marcos para cubrir mejor LLM y agentes, en un momento en que la adopción empresarial ya no se limita a chatbots internos. Hoy ves IA en buscadores corporativos, asistentes para soporte, copilots de desarrollo, automatización de procesos y agentes que llaman APIs, leen documentos y toman decisiones operativas. Ese salto cambia el perfil de riesgo porque ya no basta con proteger la entrada y la salida del modelo.

OWASP también viene alineando su trabajo con lo que se ve en el mercado y en la investigación aplicada. La documentación del proyecto y sus listas de riesgos sirven como referencia práctica para equipos que necesitan priorizar. Si quieres revisar la fuente oficial, puedes empezar por el sitio del proyecto: OWASP GenAI Security Project y, para contexto más amplio, la guía de OWASP Top 10 for Large Language Model Applications.

De chatbots a sistemas con agencia

El cambio clave es este: un chatbot responde, pero un agente actúa. Cuando un sistema puede leer correo, consultar una base de datos, abrir un ticket o disparar una transacción, el riesgo ya no se parece solo a una fuga de prompt. Se parece más a un problema de permisos, validación de contexto, auditoría y límites de ejecución.

Eso obliga a pensar en la seguridad como una cadena. Tienes el modelo, el prompt, el contexto recuperado, las herramientas conectadas, la identidad del usuario, la política de acceso y el registro de lo que ocurrió. Si cualquiera de esas piezas falla, el incidente ya no es hipotético.

En LatAm esto pega fuerte porque muchas empresas están adoptando IA encima de infraestructuras híbridas, con SaaS, APIs de terceros y datos repartidos entre CRM, ERP, data warehouses y repositorios internos. No siempre hay un inventario claro de qué datos toca cada flujo. Y sin inventario, no hay forma real de aplicar controles finos.

Riesgos nuevos o más visibles en LLM y agentes

OWASP viene insistiendo en que los riesgos de IA no son una sola categoría. Hay amenazas sobre la confidencialidad, la integridad, la disponibilidad y la gobernanza. En LLM y agentes, algunas de las más relevantes son más fáciles de entender cuando las bajas a un caso real.

Por ejemplo, prompt injection. Un usuario o un documento recuperado puede incluir instrucciones para desviar al modelo. Si tu asistente resume tickets de soporte y uno de esos tickets trae instrucciones escondidas para revelar datos o cambiar el comportamiento, el modelo puede obedecer si no separaste bien instrucciones, contexto y contenido no confiable.

También está el data leakage. Muchas empresas conectan el modelo a documentos internos y luego descubren que el sistema responde con fragmentos de contratos, datos personales o información financiera que no debería exponer. No siempre es un fallo del modelo; muchas veces es un fallo de diseño de permisos, filtrado y clasificación.

Riesgos que más aparecen en la práctica

OWASP suele organizar estos problemas alrededor de patrones repetibles. En una implementación real, los que más te conviene vigilar son:

1. Prompt injection directa e indirecta.
2. Exposición de datos sensibles por contexto amplio o mal filtrado.
3. Excessive agency, cuando el agente puede hacer demasiado sin confirmación humana.
4. Tool misuse, es decir, uso indebido de herramientas conectadas.
5. Supply chain risk en modelos, prompts, plugins y dependencias.
6. Logging insuficiente, que deja sin trazabilidad lo que el sistema hizo.

La parte más delicada es que varios de estos riesgos se combinan. Un agente con acceso a una API interna, un prompt vulnerable y logs pobres puede convertirse en una vía de exfiltración difícil de detectar. No necesitas una falla sofisticada para tener un incidente serio.

Aquí una tabla simple para aterrizar el problema:

En la práctica, este tipo de tabla ayuda a priorizar. No necesitas resolver todo al mismo tiempo, pero sí identificar qué puede romper más rápido tu operación.

Qué mitigaciones propone OWASP y cómo se aterrizan

La parte útil de OWASP no es solo el inventario de riesgos, sino la idea de convertirlos en controles. Si lo llevas a un equipo de producto y seguridad, el objetivo no es “hacer IA segura” como concepto abstracto, sino definir una serie de barreras concretas antes de poner un sistema en producción.

La primera capa es el diseño. Antes de conectar un modelo a herramientas o datos internos, define qué puede hacer, qué no puede hacer y bajo qué condiciones. Si el caso de uso es resumir documentos, no le des capacidad para escribir en sistemas productivos. Si debe abrir tickets, limita campos, estados y destinos permitidos.

La segunda capa es la validación. Todo lo que entra al modelo y todo lo que sale del modelo debe pasar por controles. Eso incluye sanitizar entradas, limitar contexto, revisar salidas y bloquear acciones peligrosas. No basta con confiar en que el modelo “se portará bien”.

Controles que sí puedes implementar

Una buena forma de empezar es con una lista de controles mínimos:

• Separar instrucciones del sistema, instrucciones del usuario y contenido recuperado.
• Aplicar control de acceso por usuario y por rol antes de inyectar contexto.
• Limitar herramientas con allowlists y parámetros estrictos.
• Exigir confirmación humana para acciones de alto impacto.
• Registrar prompts, respuestas, herramientas usadas y decisión final.
• Redactar o tokenizar datos sensibles antes de enviarlos al modelo.
• Evaluar el sistema con pruebas de prompt injection y abuso de herramientas.

Si quieres un referente técnico para pruebas y evaluación, OWASP mantiene recursos y listas que puedes revisar desde su proyecto de GenAI. También te conviene mirar la documentación de tu proveedor de modelo, porque los controles reales dependen mucho de la plataforma. Por ejemplo, si usas Azure OpenAI, Anthropic o Google Cloud, cada uno documenta límites, seguridad y observabilidad de forma distinta.

A nivel operativo, el truco está en no dejar la seguridad para el final. Si ya tienes un asistente en producción, agrega controles por capas. Si todavía estás en diseño, mejor. Ahí puedes evitar que la arquitectura nazca con permisos demasiado amplios o con un RAG que trae documentos sin clasificación.

Cómo usar estas guías en equipos de producto y seguridad en LatAm

En LatAm, el problema no suele ser la falta de interés. Lo que falta muchas veces es tiempo, inventario y coordinación entre equipos. Producto quiere sacar una funcionalidad rápido, seguridad quiere visibilidad, y data o infraestructura termina resolviendo la integración sin un marco común. OWASP ayuda precisamente a poner un idioma compartido.

Para equipos de producto, la guía sirve como checklist de diseño. Si estás lanzando un asistente para clientes, pregúntate qué datos ve, qué herramientas usa y qué acciones puede ejecutar. Si la respuesta no cabe en una página, probablemente el alcance ya está demasiado abierto.

Para seguridad, la guía sirve como base de threat modeling. No necesitas inventar un marco desde cero. Puedes tomar los riesgos de OWASP, mapearlos a tus flujos y definir controles por criticidad. Eso te permite hablar con el negocio en términos concretos: qué se bloquea, qué se monitorea y qué requiere aprobación humana.

Un flujo de trabajo práctico para tu equipo

Puedes empezar con este proceso de 6 pasos:

1. Inventaría los casos de uso de IA y clasifícalos por impacto.
2. Identifica qué datos toca cada flujo: públicos, internos, confidenciales o regulados.
3. Lista herramientas y acciones disponibles para cada agente o asistente.
4. Marca acciones críticas que requieran aprobación humana.
5. Define pruebas de abuso: prompt injection, exfiltración y tool misuse.
6. Registra métricas de seguridad y revisa incidentes cada mes.

Ese flujo funciona tanto para una fintech en México como para una empresa de retail en Colombia o una operación regional en Ecuador. La diferencia no está en el principio, sino en el nivel de regulación, el tipo de dato y la madurez del equipo.

Si trabajas con datos personales, también conviene alinear esto con tu marco legal local. En Ecuador, por ejemplo, la Ley Orgánica de Protección de Datos Personales cambia cómo debes pensar el acceso, la minimización y el tratamiento de información. En otros países de la región pasa algo parecido con normas locales y contratos con clientes corporativos. La guía de OWASP no reemplaza eso, pero sí te da una base técnica para no improvisar.

Qué revisar antes de poner un agente en producción

Un agente útil no es el que hace más cosas, sino el que hace menos cosas mal. Antes de lanzarlo, revisa tres preguntas: qué puede ver, qué puede hacer y cómo vas a enterarte si se equivoca. Si no puedes responder esas tres cosas con claridad, todavía no está listo.

También conviene separar ambientes. Un agente que prueba acciones en staging no debería tener las mismas credenciales que uno en producción. Parece obvio, pero en implementaciones rápidas suele pasar que se reutilizan llaves, tokens y permisos “para avanzar”. Ese atajo después cuesta incidentes y horas de auditoría.

Un punto que OWASP empuja con fuerza es la trazabilidad. Si el sistema toma una decisión, necesitas saber qué prompt recibió, qué contexto recuperó, qué herramienta llamó y con qué resultado. Sin eso, no puedes depurar fallos ni responder a un incidente con precisión.

Señales de que tu diseño está demasiado abierto

Hay varias señales prácticas:

• El agente puede leer más documentos de los que necesita.
• La misma credencial sirve para desarrollo, pruebas y producción.
• No existe un límite claro entre sugerir y ejecutar.
• Los logs guardan poco o nada de la conversación.
• Nadie puede explicar qué pasa si el modelo se equivoca en una acción crítica.

Si te reconoces en dos o más de esas señales, no hace falta reescribir todo. Pero sí necesitas frenar y rediseñar el alcance. Muchas fallas de IA en producción no vienen del modelo, sino de una mala definición de permisos y responsabilidad.

Para equipos que ya tienen copilots o agentes internos, una revisión útil es mapear cada herramienta conectada y preguntarte si realmente necesita acceso de escritura. En muchos casos, un sistema que solo lee y propone ya cubre el caso de uso. Darle escritura desde el día uno suele ser innecesario.

Tabla resumen

La lectura práctica es sencilla: OWASP no está diciendo que no uses IA. Está diciendo que la uses con límites claros, trazabilidad y controles que puedas defender frente a negocio, auditoría y clientes. Eso es especialmente útil en LatAm, donde muchas organizaciones quieren avanzar rápido pero todavía están definiendo gobierno de datos y responsabilidades entre equipos.

Si tu empresa ya tiene un piloto de IA, este es un buen momento para revisarlo con ojos de seguridad. Si todavía estás diseñando el producto, mejor todavía: puedes aplicar estas guías antes de que el sistema se vuelva difícil de corregir. Y si trabajas en seguridad, esta actualización te da un lenguaje más concreto para sentarte con producto y decir: este agente sí, pero con estos límites.