Buenas prácticas de seguridad de LLM para equipos

Las buenas prácticas de seguridad de LLM se reducen a tratar el modelo como un componente no fiable y no determinista de tu arquitectura: valida todo lo que entra, filtra todo lo que sale y nunca des al modelo acceso directo a datos sensibles o acciones privilegiadas sin un punto de control humano o de política. Los controles más eficaces hoy son el filtrado de entradas y salidas, el acceso a herramientas con mínimo privilegio, las defensas contra la inyección de prompts y la gobernanza de datos para evitar la divulgación de información sensible, todo ello directamente asociado al OWASP Top 10 for LLM Applications. A continuación tienes un desglose priorizado y accionable.

Empieza por el OWASP Top 10 for LLM Applications

No inventes tu propia taxonomía de amenazas. El OWASP Top 10 for LLM Applications v1.1 te da un marco compartido y citable que cubre los riesgos de mayor impacto. Dos merecen atención inmediata:

• LLM01: Prompt Injection: los atacantes elaboran entradas que anulan las instrucciones de sistema, ya sea directamente o mediante contenido envenenado que el modelo recupera (inyección indirecta).
• LLM06: Sensitive Information Disclosure: según el OWASP Top 10 for LLM Applications v1.1, los modelos pueden memorizar y reproducir datos de entrenamiento, incluida PII, credenciales y código propietario. Es tanto un problema de gobernanza de datos como del modelo.

El PDF completo del OWASP Top 10 LLM está disponible gratis y merece la pena contrastarlo con cada función LLM que publiques. Úsalo como lista de comprobación de carencias antes del lanzamiento, no después de un incidente.

Cómo proteger los modelos LLM: los controles básicos

«¿Qué LLM es el más seguro?» es la pregunta equivocada: ningún modelo es seguro por defecto, y las mayores carencias están en cómo lo conectas, no en qué proveedor eliges. Prioriza estos controles en orden:

• Validación de entradas y refuerzo de los prompts. Separa estructuralmente las instrucciones de sistema de la entrada del usuario (usa los roles system/user dedicados de la API), y rechaza o sanea las entradas con patrones de inyección. Nunca concatenes texto no fiable directamente en un prompt de sistema.
• Filtrado de salidas. Analiza las respuestas en busca de secretos, PII e incumplimientos de política antes de que lleguen al usuario o a los sistemas posteriores. Es tu última línea de defensa frente a LLM06.
• Acceso a herramientas y datos con mínimo privilegio. Si el modelo puede llamar a funciones o consultar bases de datos, acota esos permisos al máximo. Un modelo que solo puede leer el registro de un cliente no puede filtrar la tabla entera.
• Gobernanza de datos para el entrenamiento y RAG. No hagas fine-tuning con PII o credenciales sin redactar, porque el modelo puede memorizarlas y reproducirlas. Para la generación aumentada por recuperación, aplica controles de acceso al almacén vectorial para que los usuarios solo recuperen los documentos que están autorizados a ver.
• Limitación de frecuencia y monitorización de abusos. Limita las peticiones por usuario para frenar la extracción del modelo y los ataques de «denial-of-wallet», y registra prompts y respuestas para la detección y el análisis forense.

Proteger la capa de agentes: MCP y llamadas a herramientas

A medida que los LLM pasan del chat a los agentes autónomos, la superficie de ataque se desplaza a los conectores. Las buenas prácticas de seguridad de MCP (Model Context Protocol) importan porque un servidor de herramientas comprometido o malicioso puede suministrar contexto envenenado (inyección indirecta de prompts) o exfiltrar datos mediante llamadas a herramientas. Aplica estas:

• Autentica y autoriza cada servidor MCP: trata cada conector como una frontera de confianza distinta, no como una extensión implícita de tu aplicación.
• Humano en el circuito para las acciones de alto impacto, como enviar correos, ejecutar código o hacer pagos. Exige confirmación antes de los pasos irreversibles.
• Valida las salidas de las herramientas antes de que vuelvan a entrar en el contexto del modelo, ya que el contenido recuperado es un vector principal de inyección indirecta.
• Registra todas las invocaciones de herramientas junto con el prompt que las desencadenó para poder reconstruir qué hizo el agente y por qué.

No olvides los fundamentos de seguridad de APIs

Una función LLM sigue siendo una API, y las principales prácticas de seguridad de APIs se aplican directamente: autenticación fuerte (OAuth 2.0, tokens de corta duración), autorización en cada endpoint, limitación de frecuencia, validación de entradas, TLS en todas partes, gestión de secretos fuera del código, registro de peticiones/respuestas, validación de esquemas, aplicación de cuotas y desactivar los mensajes de error detallados que filtran trazas de pila. El OWASP API Security Top 10 encaja de forma natural con la lista de LLM: la autorización rota a nivel de objeto (BOLA) es igual de peligrosa cuando el «objeto» es un documento que recupera tu pipeline RAG.

La conclusión práctica: la seguridad de la IA y de los LLM funciona por capas. Ningún control es suficiente por sí solo. El refuerzo de los prompts reduce la inyección, el filtrado de salidas detecta las fugas, el mínimo privilegio limita el radio de impacto y los controles de API protegen las tuberías. Despliégalos juntos y vuelve a probar tras cada cambio de modelo o de prompt, porque estos sistemas no son deterministas y el prompt seguro de ayer puede comportarse de otra forma mañana.

¿Quieres ver dónde está tu aplicación LLM frente a estos riesgos? El LLM Security Scanner gratuito de PlayCISO prueba tu despliegue en busca de inyección de prompts, fugas de datos y carencias del OWASP LLM Top 10 en minutos.

Preguntas frecuentes

¿Por qué empezar la seguridad de LLM con el OWASP Top 10 for LLM Applications?

No inventes tu propia taxonomía de amenazas. El OWASP Top 10 for LLM Applications v1.1 te da un marco compartido y citable que cubre los riesgos de mayor impacto. Dos merecen atención inmediata: LLM01: Prompt Injection: los atacantes elaboran entradas que anulan las instrucciones de sistema, ya sea directamente o mediante contenido envenenado que el modelo recupera (inyección indirecta).

¿Cómo se protegen los modelos LLM?

«¿Qué LLM es el más seguro?» es la pregunta equivocada: ningún modelo es seguro por defecto, y las mayores carencias están en cómo lo conectas, no en qué proveedor eliges. Prioriza estos controles en orden: Validación de entradas y refuerzo de los prompts.

¿Cómo se protege la capa de agentes, incluidos MCP y las llamadas a herramientas?

A medida que los LLM pasan del chat a los agentes autónomos, la superficie de ataque se desplaza a los conectores. Las buenas prácticas de seguridad de MCP (Model Context Protocol) importan porque un servidor de herramientas comprometido o malicioso puede suministrar contexto envenenado (inyección indirecta de prompts) o exfiltrar datos mediante llamadas a herramientas.

¿Por qué siguen importando los fundamentos de seguridad de APIs en los LLM?

Una función LLM sigue siendo una API, y las principales prácticas de seguridad de APIs se aplican directamente: autenticación fuerte (OAuth 2.0, tokens de corta duración), autorización en cada endpoint, limitación de frecuencia, validación de entradas, TLS en todas partes, gestión de secretos fuera del código, registro de peticiones/respuestas, validación de esquemas, aplicación de cuotas y desactivar los mensajes de error detallados que filtran trazas de pila.