“Construye un castillo, no un muro. Los muros caen; las capas te dan tiempo para detectar y reaccionar.”
Defensa en profundidad, porque el modelo te traicionará
No puedes confiar en el modelo. No porque sea malicioso, sino porque sigue instrucciones procedentes de contenido no fiable y no puedes impedirlo de forma fiable. Así que lo envuelves en capas, cada una dando por hecho que la capa de dentro podría fallar: filtra lo que entra, restringe lo que el modelo puede hacer, filtra lo que sale, y vigílalo todo. Ninguna capa se sostiene sola.
Capa 1: controlar las entradas
Antes de que el contenido llegue al modelo, tienes la oportunidad de reducir el riesgo. Valida y restringe las entradas del usuario allí donde el formato lo permita. Analiza el contenido recuperado y el proporcionado por el usuario en busca de patrones de inyección evidentes y de cargas maliciosas conocidas. Elimina o neutraliza el texto oculto (caracteres invisibles, blanco sobre blanco, metadatos sospechosos) en los documentos. Esto atrapa los ataques perezosos y eleva el coste de los demás, pero trátalo como una fricción, nunca como un muro, porque un payload decidido pasa de todos modos.
Capa 2: restringir lo que el modelo puede hacer
Esta es la capa más robusta, y la que se sostiene con independencia de lo ingenioso que sea el ataque. Si el modelo solo puede hacer poco, un modelo comprometido solo puede hacer poco. Todo aquí trata sobre la capacidad, no la detección.
- Mínimo privilegio: cada herramienta y fuente de datos acotada a exactamente lo que la tarea requiere, nada «por si acaso».
- Zonas de confianza separadas: el contenido no fiable y las acciones privilegiadas nunca se encuentran en una sola llamada al modelo sin una puerta (la idea del doble LLM).
- Humano en el bucle: las acciones irreversibles o de alto riesgo requieren aprobación; el modelo propone, una persona dispone.
- Sandbox: la ejecución de herramientas y todo el código generado por el modelo se ejecutan de forma aislada, sin vía hacia el resto de tu sistema.
- Límites de tasa y de presupuesto: topes por usuario para que el abuso no pueda agotar los recursos ni inflar la factura.
Capa 3: verificar las salidas
Antes de que la salida del modelo llegue a un usuario o desencadene una acción, inspecciónala. Valídala frente al esquema que esperas, y rechaza todo lo que esté malformado. Analiza las salidas en busca de secretos filtrados, datos personales u otros datos que no deberían figurar en la respuesta. Para las acciones, confirma que la llamada de herramienta propuesta está dentro del conjunto permitido y con los parámetros correctos. El filtro de salida es tu última oportunidad de interceptar un compromiso que las capas de entrada y de capacidad pasaron por alto.
Capa 4: vigilar y reaccionar
No vas a evitar todos los ataques, así que tienes que poder verlos. Registra cada prompt, recuperación, llamada de herramienta, salida y decisión (las mismas trazas que pedía el capítulo sobre evaluaciones del curso de construcción, que sirven a la vez como pista de auditoría de seguridad). Vigila las anomalías: picos de rechazos, patrones inusuales de llamadas a herramientas, intentos de extraer el prompt de sistema, costes descontrolados. Y ten una vía de respuesta a incidentes: ¿cómo detectas, contienes y respondes cuando (y no si) algo se cuela?
La vigilancia es también cómo aprendes. Cada ataque real que interceptas se convierte en un caso de evaluación adversaria y en una señal de ajuste para tus filtros. La postura de seguridad de un sistema de IA en producción no es un estado que alcanzas; es un bucle que haces girar.
Equipo rojo: atácate a ti mismo primero
No esperes a que un atacante encuentre los fallos. Formar un equipo rojo significa atacar deliberadamente tu propio sistema: probar cada inyección, jailbreak y abuso de capacidad que se te ocurra, antes de salir a producción y de forma continua después. El resultado no es solo una lista de errores; es un conjunto creciente de evaluaciones adversarias que previene las regresiones.
Conviértelo en un bucle, no en un evento puntual. Cada hallazgo obtiene una corrección y una prueba permanente, de modo que el mismo fallo nunca puede reabrirse sin que nadie se dé cuenta. Es exactamente la disciplina de evaluación del curso de construcción, apuntada a la seguridad en lugar de a la calidad, y es la diferencia entre un sistema seguro hoy y uno que sigue seguro a medida que evoluciona.
Una línea por cada uno
- Defiende en profundidad: da por hecho que el modelo seguirá instrucciones hostiles y envuélvelo en capas que atrapen cada una el fallo de la anterior.
- Controla las entradas (fricción), restringe las capacidades (la capa robusta), verifica las salidas (último filtro), y vigílalo todo (ve los ataques).
- La restricción de capacidad supera a la detección: la pregunta es qué puede hacer un modelo comprometido, no si puede ser engañado.
- Forma un equipo rojo de forma continua, convirtiendo cada hallazgo en una corrección más una evaluación adversaria permanente: la seguridad es un bucle, no una casilla que marcar.
Adónde ir ahora