El OWASP Top 10 para aplicaciones con modelos de lenguaje es una lista útil y un mal punto de partida. Útil, porque ordena con nombres compartidos riesgos que hasta hace poco cada equipo describía a su manera. Mal punto de partida, porque se lee como diez ítems independientes, y la reacción natural de un comité es pedir diez controles independientes. Ese es el camino más caro y el menos efectivo.
En la práctica, esos riesgos responden a cuatro preguntas de arquitectura, y cada pregunta tiene un control dominante. Si respondes bien las cuatro, buena parte de la lista queda cubierta como consecuencia; si respondes mal una, no hay filtro que compense. El estándar se revisa de forma periódica y los nombres cambian entre versiones: lo que sigue vale con independencia de la numeración vigente.
Familia 1: el sistema no distingue una orden de un dato
Aquí caen la inyección de prompts en sus dos formas y el manejo inseguro de las salidas. Comparten una causa: en un modelo de lenguaje, las instrucciones y los datos viajan por el mismo canal, y el modelo decide qué obedecer con el mismo mecanismo con el que redacta. El extremo de salida tiene el problema simétrico: lo que el modelo devuelve suele insertarse en un HTML, en una consulta o en un comando, y ahí se comporta como código.
El control que corresponde no es un filtro, es una frontera de confianza declarada en las dos direcciones. Todo lo que entra al contexto desde una fuente que no controlas —web, correo, adjuntos, resultados de herramientas— se marca como no confiable y se trata como dato inerte. Todo lo que sale del modelo se valida y se escapa antes de tocar otro sistema, con el mismo rigor con que tratarías un parámetro de un formulario público. Los clasificadores de entrada ayudan, pero como capa adicional, nunca como el control principal.
Familia 2: el sistema puede hacer más de lo que necesita
Agencia excesiva, integraciones y herramientas mal diseñadas, y el consumo sin límites de recursos pertenecen a esta familia. La pregunta común es qué ocurre cuando el modelo, engañado o simplemente equivocado, decide actuar. Un asistente que solo escribe texto tiene un techo de daño bajo; uno que puede enviar correos o ejecutar código hereda el de esas herramientas.
El control es el mínimo privilegio por tarea, con aprobación humana en lo irreversible. En concreto: identidad propia para cada agente en lugar de credenciales heredadas del usuario; permisos acotados a la función específica y no al rol completo; validación de los parámetros que el modelo pasa a cada herramienta; y una lista corta de acciones —enviar, publicar, pagar, borrar, cambiar permisos— que exigen confirmación explícita fuera del canal conversacional. Los límites de tasa y de gasto pertenecen aquí, porque un agente en bucle es un incidente de disponibilidad y de costo.
La pregunta que ordena la lista completa no es cómo evitar que el modelo se equivoque, sino qué alcanza a hacer cuando se equivoca.
Familia 3: el sistema entrega más de lo que debería
Divulgación de información sensible, filtración del prompt de sistema y extracción del modelo comparten la forma: el atacante no rompe nada, solo consulta. Los tres casos más frecuentes son un motor de recuperación que devuelve documentos que el usuario no tendría derecho a ver, un prompt de sistema que contiene reglas de negocio o claves y que se recupera con insistencia moderada, y un modelo ajustado que reproduce fragmentos memorizados de su material de entrenamiento.
El control es que la autorización se aplique en la recuperación, no en la respuesta. La búsqueda debe filtrar por los permisos del usuario que pregunta antes de construir el contexto; pedirle al modelo que se abstenga de mencionar lo que no corresponde es una instrucción, no un control de acceso. Lo desarrollamos en detalle en nuestro artículo sobre RAG con control de acceso. A eso se suma la higiene de no colocar secretos en el prompt de sistema y de minimizar qué datos entran al ajuste fino, porque lo que no está en el modelo no se puede extraer de él.
Familia 4: el sistema hereda lo que no controla
Cadena de suministro, envenenamiento de datos y de modelos, y las debilidades propias de los vectores y embeddings forman la última familia. Lo que tienen en común es el momento: el daño se introduce antes de que el sistema esté en producción, en artefactos que llegan de fuera. Un conjunto de pesos descargado de un repositorio público, un conjunto de datos de ajuste compilado sin curaduría, un índice vectorial al que varios procesos escriben sin registro de quién puso qué.
El control es la procedencia verificable. Para cada artefacto que alimenta el sistema —modelo, conjunto de datos, corpus indexado— debe existir constancia de su origen, de quién autorizó su incorporación y de qué versión exacta está en uso, con integridad verificable. No es glamoroso y es el único que permite responder la pregunta que aparece tras un incidente: qué entró, cuándo y por orden de quién.
Los dos que no encajan
Quedan fuera del agrupamiento la desinformación y la dependencia excesiva en las salidas del modelo, y es honesto decirlo. No son fallas de arquitectura, son fallas de proceso: el sistema funciona como fue construido y el problema está en cómo se usa lo que produce. Se atienden en otro plano —identificar el contenido generado, exigir verificación de fuentes en decisiones con consecuencia, definir dónde no se admite una respuesta automática.
Usada así, la lista deja de ser una checklist de cumplimiento y se convierte en cuatro preguntas que puedes hacerle a cualquier despliegue: qué texto no confiable llega al contexto y qué se hace con lo que sale; qué puede ejecutar el sistema por su cuenta; qué puede obtener alguien que solo consulta; y de dónde vienen los artefactos que lo componen. Si el equipo responde las cuatro con evidencia, el estándar está cubierto en lo que importa. Si responde con documentos de política, todavía no.