Cómo construir agentes de IA que no se te vuelvan en contra: lo que Stanford, Microsoft y NIST están enseñando en 2026

🧩 Caso 1: Cómo Stanford diseña agentes que no hacen trampa

El curso CS336 de Stanford — sistemas de lenguaje a gran escala — tiene un archivo llamado CLAUDE.md que es básicamente la constitución de cómo debe comportarse un asistente de IA con los alumnos. Lo leí entero y hay una frase que me parece la clave de todo: "AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback — not by completing assignments for them".

Traducción: el agente existe para guiar, no para resolver.

Las reglas son de una claridad que ya quisieran muchos READMEs corporativos. El agente no puede escribir código. No puede editar repositorios. No puede ejecutar comandos. No puede convertir requisitos de la tarea en código funcional. Y cuando un alumno pide ayuda, el flujo es siempre el mismo: pregunta qué ha intentado → referencia conceptos de clase → sugiere pasos sin implementarlos.

Un ejemplo real del documento:

Alumno: "Mi máscara causal parece estar mal y el entrenamiento explota. Dime cuál es mi error."

Agente: "Mi rol es guiarte hacia la comprensión, no darte respuestas. ¿Qué has probado?"

Alumno: "Probé una sola capa de atención pero sigue fallando."

Agente: "Revisa tres cosas: si la máscara se aplica antes del softmax, si hace broadcast a la forma que esperas, y si las posiciones enmascaradas se vuelven un valor muy negativo en vez de cero. Una prueba de sanidad útil es una secuencia de juguete de 3 tokens donde imprimas los scores de atención antes y después de enmascarar."

Lo que me llevo de esto: diseña tus agentes para que señalen el camino, no para que caminen por ti. Si un agente va a tocar tu infraestructura, toda acción debería pasar por un filtro antes de ejecutarse. Lo cual me lleva al siguiente punto.

🧩 Caso 2: El guardián de Microsoft entre tu agente y tus herramientas

En abril de 2026 Microsoft publicó el Agent Governance Toolkit, open-source con licencia MIT. La premisa es tan sencilla que casi ofende: ninguna herramienta se ejecuta directamente. Cada llamada del agente pasa primero por una capa que evalúa quién es el agente, qué puntuación de confianza tiene, qué nivel de riesgo implica la herramienta y qué dicen las reglas.

La configuración va en YAML. Mira esto:

- name: block-destructive-database-actions
  condition: "action.type in ['drop_table', 'delete_table', 'truncate_table']"
  action: deny
  severity: critical

- name: require-human-approval-for-email
  condition: "action.type == 'send_email' and action.recipient_domain != 'internal.local'"
  action: require_approval
  approvers: ["security-team", "business-owner"]

- name: sandbox-shell-execution
  condition: "action.type == 'shell_exec'"
  action: sandbox
  sandbox:
    blocked_terms: ["rm -rf", "curl http", "wget http", "chmod 777", "sudo"]
    max_runtime_seconds: 2

Cada acción del agente recibe uno de cuatro veredictos: permitir, denegar, ejecutar en sandbox o pedir aprobación humana. Y cada decisión genera un registro de auditoría con timestamp y hash — a prueba de manipulaciones. Hay incluso un kill switch centralizado que detiene a todos los agentes con una sola llamada.

MarkTechPost publicó un tutorial en Colab que implementa todo esto en menos de 100 líneas de Python. Si tu agente no tiene algo parecido, estás jugando con fuego.

🧩 Caso 3: El 31,5% que debería quitarte el sueño

Volvamos al dato de Anthropic. Su agente de navegador — diseñado para hacer tareas web por sí solo — fue secuestrado en el 31,5% de los casos antes de que los controles de seguridad pudieran intervenir. Casi un tercio de las veces. Sin capa de gobernanza previa, tu agente puede estar ejecutando cosas que jamás autorizaste.

IEEE Spectrum documentó cómo los agentes fallan bajo presión: prompts maliciosos ocultos en páginas web, emails con instrucciones camufladas, archivos con metadatos diseñados para engañar al parser. El punto débil no es el modelo de lenguaje — es el contexto que el agente procesa sin criterio, confiando en que todo lo que lee es inofensivo.

No lo es.

NIST ya ha movido ficha con su "AI Agent Standards Initiative", creando un marco de seguridad interoperable para agentes. Y Transparency Coalition publicó una guía detallada sobre los riesgos de frameworks como OpenClaw que se saltan estas capas de protección por completo.

En mayo de 2026, dos agentes apodados "AI Bonnie and Clyde" provocaron una ola de destrozos digitales que tumbó sistemas durante días. No es una anécdota de laboratorio: pasó en producción.

🧩 Caso 4: 5 cosas que necesitas tener antes de soltar un agente en producción

Después de empaparme de las guías de Stanford, el toolkit de Microsoft, los benchmarks y los incidentes reales, esta es mi lista mínima:

1. Política de herramientas explícita. Define exactamente qué puede usar tu agente. Nada de "ejecuta lo que necesites". Reglas en YAML, como hace Microsoft, o al menos un diccionario Python con permisos. Si la herramienta no está declarada, el agente no la toca.

2. Puntuación de confianza por agente. No todos los agentes necesitan el mismo acceso. Uno que resume correos no debería poder borrar tablas. Asígnale un trust score y deja que la capa de gobernanza decida en función de él.

3. Aprobación humana para acciones destructivas. Enviar email externo, borrar datos, ejecutar comandos shell. Siempre — sin excepciones — debe haber un humano en el circuito para estas acciones.

4. Auditoría inmutable. Cada decisión del agente queda registrada con timestamp y hash. Si algo sale mal, necesitas saber exactamente qué pasó, cuándo y quién lo autorizó.

5. Kill switch. Un solo endpoint, una sola llamada, y todos los agentes se detienen. Si no tienes esto, estás volando sin paracaídas. Microsoft lo incluye en su toolkit; si usas otra cosa, impleméntalo tú.