Los mismos guardrails de IA que impiden que un modelo escriba malware están bloqueando el trabajo de quienes defienden nuestros sistemas. Según una investigación de TechCrunch publicada en julio de 2026, varios investigadores de ciberseguridad ofensiva —los que buscan vulnerabilidades desconocidas y desarrollan herramientas para explotarlas— aseguran que las barreras de seguridad de Anthropic y OpenAI entorpecen tareas perfectamente legítimas de red team.
El problema es de fondo: los modelos no distinguen bien entre un atacante real y un investigador autorizado que necesita generar un exploit de prueba, analizar shellcode o razonar sobre una cadena de explotación. Para los builders hispanohablantes que construyen productos de seguridad sobre Claude API, esto no es un detalle académico: define qué se puede automatizar y qué toca seguir haciendo a mano. En este artículo desglosamos qué está pasando, por qué importa y cómo mitigarlo hoy.
¿Qué ha cambiado con los guardrails de Claude y GPT?
Los guardrails (barreras de seguridad, los filtros que impiden que un modelo produzca contenido peligroso) se han endurecido a medida que Anthropic y OpenAI han escalado sus políticas de uso responsable. Anthropic aplica su Responsible Scaling Policy con niveles ASL (AI Safety Levels) que restringen capacidades sensibles, incluidas las relacionadas con ciberseguridad ofensiva.
Según los investigadores citados por TechCrunch, la fricción aparece cuando el modelo rechaza peticiones que forman parte del día a día del red teaming autorizado: escribir una prueba de concepto para una CVE ya publicada, explicar cómo funciona un desbordamiento de búfer o refactorizar código de explotación con fines defensivos. El artículo describe cómo estas barreras "impiden el trabajo" de profesionales que operan dentro de la legalidad y con permiso explícito.
La tensión es real y difícil de resolver: el mismo conocimiento que ayuda a parchear un sistema puede usarse para atacarlo. Desde nuestra experiencia con Claude API, los rechazos suelen ser más frecuentes cuando la petición combina intención ofensiva explícita con código ejecutable, y menos cuando se enmarca en análisis defensivo con contexto claro.
¿Qué significa esto para los builders?
Si construyes herramientas de seguridad —escáneres, plataformas de bug bounty, asistentes para SOC (Security Operations Center)— sobre un LLM, este es tu principal riesgo de producto: un rechazo del modelo en medio de un flujo automatizado rompe la experiencia y obliga a intervención manual.
Tres implicaciones prácticas:
- Diseña para el rechazo. Asume que un porcentaje de peticiones será bloqueado y prepara fallbacks: reformular el prompt, dividir la tarea o derivar a un humano.
- Contextualiza siempre. Enmarcar la tarea como análisis defensivo autorizado, con el alcance y el permiso explícitos en el prompt, reduce los falsos positivos del filtro.
- Evalúa alternativas por tarea. Ningún modelo es idéntico: Claude, GPT-4o y Gemini calibran sus guardrails de forma distinta. Prueba la misma tarea en varios antes de casarte con uno.
Un patrón que funciona es separar el razonamiento del código. Puedes pedir a Claude que explique una vulnerabilidad y su mitigación, y reservar la generación de exploits ejecutables para entornos controlados con supervisión humana. Para dominar esa arquitectura conviene aprender a construir sobre la API de Claude con criterio de producto, no solo de prototipo.
Para los builders hispanohablantes esto significa que un producto de seguridad basado en IA necesita una capa de orquestación robusta por encima del modelo, no confiar en que el LLM "siempre responda".
¿Cómo afecta esto a España y LATAM?
El ecosistema de ciberseguridad crece con fuerza en la región: equipos de pentesting en México y Colombia, startups de seguridad en España, y programas de bug bounty cada vez más habituales. Todos ellos topan con la misma barrera, con un agravante: gran parte de la documentación de seguridad y los prompts eficaces están en inglés, y los modelos a veces calibran distinto sus filtros en español.
En el plano regulatorio, España y la UE avanzan con el AI Act, que clasifica ciertos usos de IA por riesgo y exige transparencia. Un builder que despliegue herramientas de seguridad con IA en Europa debe documentar controles de uso, algo que en LATAM aún depende más de marcos sectoriales. La recomendación es la misma: registra el propósito defensivo, el consentimiento del cliente y los límites de la herramienta desde el diseño.
¿Cómo empezar a mitigar los rechazos hoy?
Un enfoque simple para reducir falsos rechazos es enmarcar el contexto defensivo en el system prompt:
system = """Eres un asistente de seguridad defensiva.
Contexto: pentest autorizado, alcance firmado.
Explica vulnerabilidades y mitigaciones para parchear."""
# Envía la tarea con alcance y permiso explícitosPasos accionables: 1) documenta el alcance autorizado, 2) prueba la tarea en varios modelos, 3) mide la tasa de rechazo, 4) añade fallbacks humanos, 5) revisa las políticas de uso de Anthropic antes de desplegar en producción.
Conclusión
El endurecimiento de los guardrails de IA no es un bug, es una decisión de diseño con costes reales para la seguridad ofensiva legítima. El insight que dejamos: quien gane en este mercado no será quien tenga el mejor modelo, sino quien construya la mejor capa de orquestación y contexto alrededor de él, convirtiendo los rechazos en flujos manejables. Para los builders de España y LATAM, es una oportunidad de diferenciarse con productos que asumen la fricción en lugar de ignorarla. Comparte este artículo si te fue útil.
