Casi todo lo que se escribe sobre inteligencia artificial y ciberseguridad es una de dos cosas: que los atacantes ahora usan IA, o que la IA va a defenderte. Las dos son verdad a medias y ninguna sirve para decidir nada. Lo que sí ha cambiado, y es concreto, es que las empresas están conectando modelos a sus datos y a sus herramientas, y eso crea una superficie de ataque que hace tres años no existía.
Conviene empezar quitando ruido, porque aquí es donde más lo hay.
La IA generativa no ha inventado ataques nuevos. Lo que ha hecho es bajar el coste del engaño hasta casi cero, y eso sí tiene consecuencias prácticas:
Lo que no ha cambiado es por dónde se entra: una credencial válida, un sistema sin actualizar y alguien que hace clic. Quien te venda que la IA ha cambiado la naturaleza del ataque te está vendiendo un producto.
Esta es la parte que importa y la que casi nadie mira. En cuanto una empresa conecta un asistente a su documentación, a su base de datos o a sus herramientas, ha construido un sistema que:
Eso es exactamente la descripción de algo que hay que probar antes de exponerlo. Y tiene una propiedad incómoda que ningún sistema anterior tenía: para un modelo de lenguaje, los datos y las instrucciones son lo mismo. No hay una frontera técnica que separe "esto es contenido que debes resumir" de "esto es una orden que debes obedecer". Toda la seguridad de estos sistemas sale de ahí.
El marco de referencia que ordena estos riesgos es el OWASP Top 10 para aplicaciones LLM, que es al mundo de los modelos lo que el Top 10 clásico es a la web.
La inyección de prompts es lo que sale en todos los titulares, casi siempre en su versión aburrida: un usuario escribe en el chat "ignora tus instrucciones" y el modelo hace algo que no debía. Eso es el jailbreak, y como problema de empresa es menor, porque el usuario se está engañando a sí mismo dentro de su propia sesión.
La que importa es la indirecta. Aquí la instrucción no la escribe el usuario: viene dentro de un contenido que el sistema procesa por su cuenta. Un correo que el asistente resume. Una página que consulta. Un documento que alguien de fuera subió a la carpeta compartida. Un ticket de soporte que abre un cliente.
El contenido lleva escondida una instrucción, el modelo la lee como si viniera de su dueño, y actúa. La víctima no ha hecho nada, no ha hecho clic en nada y no se entera. Es la diferencia entre alguien que engaña a su propio asistente y alguien que engaña al asistente de otro.
De ahí sale también la fuga del prompt de sistema, que suele ser el primer paso: conocer las instrucciones y las herramientas del asistente para saber qué se le puede pedir.
Una inyección de prompts, por sí sola, hace que un modelo escriba algo raro. Molesto y poco más.
Se convierte en un incidente cuando el modelo tiene manos. Y ahí es donde están hoy las empresas: asistentes conectados por MCP u otros mecanismos a correo, a repositorios, a bases de datos, a la herramienta de tickets o a la pasarela de pagos.
Los fallos que encontramos casi nunca están en el modelo. Están en el diseño de alrededor:
La conclusión práctica: trata a tu asistente como a un usuario que puede ser engañado, no como a un componente de confianza. Permisos mínimos, credenciales propias, confirmación para lo que tiene efecto, y registro de lo que hace.
La forma habitual de que un asistente conozca tu empresa es RAG: se indexa documentación y el modelo consulta ese índice al responder. Es lo correcto y trae dos problemas concretos.
El primero es de permisos. Al indexar una carpeta se suele indexar todo lo que hay, y los permisos del documento original rara vez viajan con el fragmento indexado. El resultado es un buscador que contesta a cualquiera sobre documentos que no cualquiera podía abrir. Se descubre el día que alguien pregunta por las nóminas.
El segundo es que el índice es una superficie de entrada. Si un tercero puede meter contenido en algo que se indexa, ha metido texto que el modelo tratará como contexto de confianza. Ahí se juntan la inyección indirecta y el envenenamiento de datos.
Y luego está lo que pasa sin permiso de nadie: el shadow AI. Gente pegando contratos, código o datos de clientes en herramientas que la empresa no ha aprobado ni revisado. Prohibirlo por circular no funciona nunca. Lo que funciona es dar una alternativa aprobada que sirva, y entonces la prohibición se sostiene sola.
El reglamento europeo de inteligencia artificial ordena los sistemas por nivel de riesgo y pone obligaciones distintas según dónde caiga cada uno. Lo que conviene saber sin entrar en plazos ni artículos, que eso lo mira un asesor con tu caso delante:
Un pentest de IA no consiste en intentar que el modelo diga una barbaridad. Eso es una demostración, no un hallazgo. Lo que se prueba es el sistema alrededor del modelo:
Cuando lo que se quiere es evaluar el comportamiento del modelo en sí, y no el sistema, eso es LLM red teaming, que es un ejercicio distinto y complementario.
El proyecto entero, fase a fase, está escrito en cómo funciona un pentest de IA. Si esto es lo primero que miras, conviene leer antes qué es el pentesting, y para un alcance concreto, contacto.
Qué es el ciclo de vida de desarrollo seguro, qué se hace en cada fase, qué aportan SAST, DAST y SCA, y por dónde empezar si hoy no tenéis nada montado.
Qué es un pentest, qué fases tiene, qué recibes al final, cuánto dura y en qué se diferencia de un análisis de vulnerabilidades.
Cómo funciona el 2FA, qué métodos son fuertes y cuáles no, por qué el SMS ya no basta y cómo lo esquiva el phishing actual.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
