HackerOne Hai con Claude Sonnet 4.5: 44% menos tiempo en triage de vulnerabilidades

Cuando Anthropic anunció Claude Sonnet 4.5 en septiembre de 2025, uno de los datos públicos que acompañó el lanzamiento se ha quedado pegado en el debate sobre IA aplicada a seguridad: HackerOne Hai —la plataforma de intake y triage de vulnerabilidades de HackerOne— integró el modelo y reportó una reducción del 44% en el tiempo promedio de triage, junto con un incremento del 25% en la precisión de la clasificación. No es un benchmark sintético; es un caso de uso público sobre un funnel real de reportes de bug bounty. Lo interesante a esta altura del 2026, con varios meses de operación encima, es qué cambió en el flujo para que esos números fueran posibles.

HackerOne opera el programa de bug bounty más grande del mundo: miles de investigadores externos envían reportes de vulnerabilidad a clientes (empresas, gobiernos, plataformas tech). Cada reporte entra al funnel de Hai, donde un analista de triage decide si es legítimo, si es duplicado, si necesita más información o si escala a un equipo del cliente. El volumen es brutal y la heterogeneidad enorme: reportes bien redactados conviven con duplicados, falsos positivos y vulnerabilidades reales mezcladas con prosa confusa. Si el triage se atasca, los investigadores pierden incentivo y los clientes pierden señal.

1. 1
   Sep 2025
   Lanzamiento de Claude Sonnet 4.5

   Anthropic publica el modelo con énfasis en agentes autónomos de larga duración y casos de seguridad.

2. 2
   Sep 2025
   HackerOne Hai integra Sonnet 4.5

   La plataforma de intake/triage de HackerOne pasa a usar Sonnet 4.5 como capa de pre-análisis.

3. 3
   Q4 2025
   Métricas en producción

   Anthropic publica como caso público una reducción del 44% en tiempo de triage y +25% en precisión.

4. 4
   2026
   Lectura retrospectiva

   Varios meses después, el patrón se discute como referencia para otros funneles de seguridad con criterio humano final.

De la documentación pública y la cobertura especializada se pueden extraer tres decisiones de diseño que sostienen el resultado. Ninguna es revolucionaria por separado; la combinación es lo que cuenta:

1. 1Sonnet 4.5 como capa intermedia, no como reemplazo del analista de triage. El reporte entra del investigador, el modelo enriquece (correlaciona con reportes previos, busca señales de duplicado, redacta un primer resumen estructurado) y el analista humano recibe un caso pre-razonado, no un texto crudo.
2. 2Aprobación humana obligatoria para cualquier comunicación con el investigador o con el cliente. El modelo propone, el analista decide. Esta restricción reduce el riesgo de que una alucinación se traduzca en pagar un duplicado o cerrar un reporte legítimo.
3. 3Feedback loop estructurado: cada decisión del analista (válido / duplicado / informativo / no aplica) vuelve al sistema para ajustar el ranking. Con suficiente volumen, la precisión de la clasificación inicial sube de forma medible.

Hay condiciones repetidas que aparecen en los análisis del caso y que explican por qué el patrón se sostiene en producción, no solo en el primer trimestre:

• OKAcceso del modelo a histórico estructurado de reportes y metadata, no a la infraestructura del cliente. El agente lee, no actúa sobre sistemas externos.
• OKGuardrails explícitos sobre las herramientas y plantillas que el modelo puede invocar. Cada nueva capacidad expuesta es una superficie adicional, como recordaron las CVE de Semantic Kernel.
• OKMétricas baseline definidas antes del despliegue. Sin ellas, el 44% sería marketing; con ellas, es evidencia.

“El cambio no es que el modelo decida más rápido: es que el analista llega al caso con contexto curado. Eso multiplica el rendimiento sin asumir riesgo nuevo.”

Las cifras agregadas miden eficiencia, pero hay un cambio cualitativo que rara vez aparece en los dashboards. Los equipos de triage que trabajan con un pre-análisis del modelo reportan tres efectos secundarios que importan tanto como el 44%. Primero, mejor onboarding: nuevos analistas aprenden a investigar leyendo los pre-resúmenes del modelo en casos resueltos, no peleando con runbooks dispersos. Segundo, menor rotación: el trabajo deja de ser principalmente "filtrar ruido" y pasa a ser principalmente "tomar decisiones" — un cambio que reduce la fatiga característica del rol. Tercero, mejor handoff al cliente: las escalaciones llegan con contexto completo, lo que reduce ida y vuelta y acorta el tiempo medio de resolución del reporte real.

En paralelo, conviene recordar que Sonnet 4.5 también fue objeto de un ejercicio de red teaming con Carnegie Mellon, cubierto en su momento por CyberScoop. Esa evaluación dejó la resistencia a prompt injection mejor documentada que la de su predecesor — una propiedad relevante para cualquier despliegue donde el modelo procese texto de origen externo, como ocurre justamente en el funnel de Hai con reportes enviados por investigadores desconocidos.

El patrón "modelo enriquece, humano decide, feedback loop ajusta" es replicable en cualquier dominio donde haya un funnel de entradas con mucho ruido y criterio humano final: soporte técnico nivel 1, mesas de ayuda IT, equipos de fraude bancario, customer success. Una reducción del 30-50% en tiempo de triage no es exclusiva del bug bounty; es un patrón de despliegue extensible a otros embudos operativos que reciban volumen alto, requieran clasificación rápida y mantengan a una persona como decisor final. Lo único intransferible es la disciplina del baseline.