Por qué la IA es otra clase de objetivo

Tipo: Conceptual · Fase: Orientación

PhiloCorp te pide revisar un asistente que responde consultas sobre una base de conocimiento. Hasta ahí, el encargo parece conocido. Después aparece un detalle: además de responder, el asistente puede pedirle a una herramienta que cambie el estado de un ticket. Una respuesta incorrecta y una acción incorrecta ya tienen consecuencias distintas.

La pregunta que conviene anotar primero en el brief es concreta: ¿qué puede cambiar el sistema si toma una decisión equivocada? El pentest de aplicaciones sigue siendo necesario. A ese trabajo le sumamos la evaluación del comportamiento del modelo y de los controles que limitan sus efectos.

Tres cambios que trae el red teaming de IA

1. El comportamiento también es un activo. Los archivos, las bases y las credenciales siguen importando. Pero ahora también protegés qué información usa el asistente, qué respuesta entrega y qué acción propone. Un embedding o una salida puede revelar información bajo determinadas condiciones; la reconstrucción depende del modelo, los datos y el acceso del evaluador. La Parte 07 distingue esas precondiciones de una exposición confirmada.

2. La persistencia puede vivir en los datos. Una instrucción insertada en una memoria persistente o en un documento recuperable puede volver a influir en sesiones futuras. Reiniciar el contenedor no la elimina si el almacenamiento sobrevive y el sistema vuelve a consumirlo. También hay poisoning del entrenamiento, cuyo efecto depende de cómo se entrenó o ajustó el modelo. No des por sentado que persiste después de cualquier cambio: eso se verifica con una prueba posterior al reinicio, reindexado o despliegue que corresponda.

3. Una decisión puede disparar varias acciones. Los agentes pueden llamar herramientas, abrir tickets y operar otros servicios. El impacto depende de los permisos, del flujo y de los límites de ejecución. En PhiloCorp, por ejemplo, cambiar un ticket podría iniciar otra automatización: el mapa tiene que seguir ese efecto hasta donde llegue el alcance autorizado.

Hay incidentes documentados que muestran por qué vale la pena mirar esta capacidad. Anthropic informó en noviembre de 2025 una campaña de espionaje detectada en septiembre, denominada GTG-1002, y estimó que la IA realizó entre el 80 % y el 90 % de las operaciones tácticas. Es una evaluación publicada por el proveedor, no una medición independiente ni una propiedad de todos los agentes. El caso también muestra una diferencia que necesitamos conservar: que un operador se presente como auditor no demuestra que esté autorizado.

Del comportamiento al impacto

Una respuesta que sigue una instrucción ajena puede demostrar influencia sobre el modelo. Para afirmar acceso indebido, escalada o impacto operativo necesitás evidencia adicional de la frontera correspondiente. Si el agente propone cambiar un ticket y el servidor lo rechaza, registrá ambas cosas: la propuesta fue inducida y el control de ejecución la contuvo.

Ese es el hilo de la guía. Vamos a seguir una entrada desde su origen hasta su posible efecto, sin dar por probado un salto porque el anterior haya funcionado.

La idea rectora del playbook

Los LLMs pueden recibir instrucciones con jerarquía, pero no separan de manera infalible la instrucción legítima del contenido no confiable. El NCSC propone analizar prompt injection como un problema de confused deputy: un componente con privilegios puede atender una solicitud de menor confianza como si tuviera autoridad para hacerlo.

Por eso, las instrucciones y los clasificadores de seguridad deben acompañarse de autorización, validación de parámetros y límites de ejecución fuera del modelo. Una fuente de terceros puede aportar información; eso no le concede los permisos del usuario, del agente o del servicio que la leyó. En cada salto, verificá quién pide la acción, sobre qué recurso y con qué autoridad.

El próximo paso es distinguir el riesgo adversarial de otras fallas y decidir qué dimensiones entran al encargo.