AI bug bounty: programas y recompensas por vulnerabilidades en IA 2026

Los programas de AI bug bounty son iniciativas formales mediante las que laboratorios de IA, hiperescalares y empresas que despliegan modelos en producción recompensan a investigadores externos por reportar vulnerabilidades en sus sistemas de inteligencia artificial. La categoría es muy reciente: aunque algunos programas tradicionales aceptaban hallazgos relacionados con IA desde hace años, los programas formalmente etiquetados como AI bug bounty empiezan a aparecer en 2023 y se consolidan entre 2024 y 2026. Cubren superficie distinta a la del bug bounty clásico, manejan severidad de otra manera y plantean retos de reproducibilidad propios de los sistemas probabilísticos.

Lo esencial

• El AI bug bounty recompensa el reporte responsable de vulnerabilidades en modelos y aplicaciones de IA.
• OpenAI, Anthropic, Google, Microsoft, Hugging Face y AWS Bedrock tienen programas formales activos en 2026.
• El scope típico incluye infraestructura, bypass de filtros con impacto de seguridad real y model behavior issues; suele excluir alucinaciones puras y desacuerdos de política de contenido.
• Las recompensas más altas se asignan a authorization bypass, training data extraction y prompt injection con consecuencias materiales.
• La reproducibilidad es el reto principal: los sistemas probabilísticos requieren varias ejecuciones para considerarse confirmados.

Por qué el AI bug bounty es una categoría aparte

Un programa de bug bounty tradicional se diseña para superficie determinista: aplicaciones web, APIs, binarios, infraestructura. Las clases de vulnerabilidad están bien tipificadas (XSS, SQLi, RCE, IDOR, SSRF), los criterios de severidad son comprensibles bajo CVSS y la reproducibilidad se demuestra con un caso de prueba determinista. El triador comprueba el bug, valora su impacto y asigna recompensa con un margen razonable de objetividad.

La superficie LLM rompe varias de esas asunciones. Una aplicación construida sobre un modelo de lenguaje añade vectores que no encajan en taxonomías clásicas: prompt injection directa e indirecta, jailbreak, extracción de prompts de sistema, fugas de datos memorizados durante el entrenamiento, abuso de herramientas conectadas y bypass de filtros de moderación. Algunas categorías tienen impacto técnico claro. Otras se sitúan en una zona ambigua entre seguridad, alineamiento y política de contenido.

A esto se suma que los modelos cambian. Una misma versión puede comportarse de forma distinta entre dos semanas si el proveedor aplica ajustes de alignment, refuerza filtros o despliega un nuevo punto de control. Un hallazgo válido el lunes puede no reproducirse el viernes sin que medie ninguna acción del reporter. Por estas razones la industria ha creado programas específicos en lugar de incrustar la IA en los bug bounty existentes.

Programas principales activos en 2026

OpenAI opera su programa a través de Bugcrowd. Acepta reportes sobre la plataforma, las APIs y los productos comerciales. El componente puramente relacionado con comportamiento del modelo se gestiona por canales separados, con guías específicas sobre lo que es vulnerabilidad reportable frente a lo que entra en política de uso. Publica niveles orientativos y mantiene hall of fame.

Anthropic gestiona divulgaciones responsables a través de HackerOne, además de un programa específico para investigación adversarial de modelos. Ha invitado de forma puntual a equipos externos a participar en ejercicios de red team antes de releases significativos, con compensación y reglas concretas. Su Responsible Scaling Policy aporta contexto sobre cómo encajan estos programas en el gobierno interno.

Google mantiene un AI Vulnerability Reward Program como extensión del VRP histórico. Cubre Gemini, productos Workspace con funciones de IA, Cloud AI y otras superficies. Las reglas distinguen entre bugs de software clásicos (VRP estándar) y categorías propias de IA, con rúbrica de severidad propia.

Microsoft opera el AI Bounty dentro del Microsoft Security Response Center, con foco en Copilot, Azure AI y otros servicios. Las categorías cubiertas incluyen inferencia, manipulación, divulgación de información sensible y violaciones de control de acceso. Las recompensas máximas para casos críticos figuran entre las más altas del mercado.

Hugging Face mantiene un programa de divulgación responsable centrado en la plataforma, el hub de modelos y los servicios asociados, con foco en modelos maliciosos publicados, abuso de inference endpoints y problemas del ecosistema Spaces. AWS integra los servicios de IA generativa, incluido Bedrock, dentro de su programa general de seguridad; los hallazgos relevantes en flujos de modelos son admisibles bajo las reglas existentes.

Plataformas neutrales como HackerOne, Bugcrowd e Yeswehack triadan y gestionan muchos de estos programas. Las empresas que despliegan IA y quieren bug bounty propio suelen apoyarse en esa infraestructura y comunidad.

Scope típico: dentro y fuera

Lo que está dentro de scope es la intersección entre comportamiento del modelo y consecuencias de seguridad reales: bypass de filtros que permiten extraer información sensible, situaciones en las que el modelo divulga datos de otros usuarios o de la propia infraestructura, inyección de instrucciones que ejecuta acciones no autorizadas en herramientas conectadas, extracción parcial de datos memorizados durante entrenamiento cuando son sensibles y problemas en la infraestructura del modelo (orquestación, gateways, almacenamiento de embeddings).

Lo que típicamente queda fuera son las alucinaciones puras sin vector explotable, los desacuerdos con la política de contenido, los jailbreaks sin impacto real, los problemas de calidad de salida (sesgo, tono, estilo) y las quejas sobre comportamiento esperado del producto.

La frontera no siempre es nítida. Un jailbreak que permite a un menor recibir instrucciones de autolesión puede pasar de queja a vulnerabilidad reportable si el modelo está expuesto en un contexto de protección de menores con obligaciones legales. Un prompt injection que solo cambia el tono no es lo mismo que uno que invoca una API conectada con privilegios del usuario. Los programas serios documentan casos específicos en sus reglas para reducir disputas.

Categorías de recompensa y rangos orientativos

Las cifras concretas varían entre programas y se actualizan, por lo que conviene consultar las páginas oficiales antes de invertir tiempo. Como orientación cualitativa, estos son los rangos relativos habituales en 2026.

Authorization bypass y exposición cross-tenant: severidad crítica. Las recompensas más altas del programa suelen reservarse para casos en los que un usuario logra acceder a datos o capacidades de otro tenant o saltarse el control de acceso del producto. Estas situaciones se tratan como cualquier bug crítico clásico, independientemente de que el vector pase por un componente de IA.

Training data extraction con datos sensibles: severidad alta. Conseguir que un modelo divulgue verbatim fragmentos del corpus de entrenamiento se valora especialmente cuando los datos extraídos son personales, propietarios o sujetos a obligaciones de confidencialidad. La calidad de la prueba (volumen, fidelidad, persistencia entre ejecuciones) afecta la recompensa.

Prompt injection con impacto material: severidad media a alta. Una inyección indirecta que consigue que un agente conectado a herramientas ejecute acciones no previstas (enviar un correo, modificar un fichero, lanzar una llamada) se valora muy por encima de una inyección que solo cambia la salida visible. El impacto en sistemas reales es el multiplicador principal.

Denial of service contra la infraestructura del modelo: severidad media. Patrones de consulta que provocan consumo desproporcionado de recursos o degradación del servicio para otros usuarios encajan en la categoría tradicional de DoS, pero adaptados a la economía de inferencia.

Bypass de content filters sin impacto de seguridad claro: severidad baja o fuera de scope, según programa. Solo se aceptan cuando concurre un factor adicional (uso en contextos sensibles, posibilidad de daño verificable a terceros).

Diferencia con el bug bounty clásico en la práctica

La diferencia fundamental es la naturaleza probabilística. Un mismo prompt, ejecutado dos veces, puede producir salidas distintas. Los programas piden reproducibilidad sobre varias ejecuciones (típicamente tres o más) y valoran cuando el reporter aporta análisis estadístico sobre la fiabilidad del trigger. Las técnicas de jailbreak basadas en optimización adversarial requieren documentar la cadena exacta usada, los parámetros del modelo, la temperatura y cualquier otro factor relevante.

La evaluación de severidad también cambia. CVSS no encaja bien para todas las categorías de IA, y aunque algunos programas lo siguen usando como referencia, los triadores suelen aplicar rúbricas propias que ponderan impacto en terceros, probabilidad de explotación en producción real y reputación de la plataforma.

La versión del modelo es información esencial. Un hallazgo contra GPT-4-turbo de hace tres meses puede no reproducirse en el modelo actual sin que el reporter haya hecho nada distinto. Los programas registran versión exacta, fecha y, cuando aplica, configuración del despliegue.

Finalmente, el factor de tiempo es delicado. Algunas vulnerabilidades requieren cambios profundos en el modelo (un nuevo round de fine-tuning, ajustes de alignment) y no se resuelven con un parche en horas o días. Los timelines de divulgación responsable se negocian caso a caso.

Workflow para un reporter

Un investigador que quiere participar de forma seria sigue una secuencia ordenada.

Identificación. Probar técnicas conocidas (prompt injection en variantes, extracción de prompts de sistema, intentos de fugas de datos) sobre la superficie pública del producto. La curiosidad estructurada es más productiva que el ataque al azar.

Confirmación de impacto. Antes de invertir tiempo en redactar el reporte, validar que el comportamiento tiene consecuencias materiales y que encaja con el scope publicado. Un fallo interesante pero fuera de scope no se va a recompensar y consume tiempo del triador.

Reproducibilidad. Ejecutar la misma técnica varias veces. Documentar el porcentaje de éxito, el modelo y versión, parámetros, fecha y hora. Si el ataque depende de contexto previo, capturar la conversación completa.

Redacción. Un buen reporte incluye resumen ejecutivo, descripción técnica, prompts exactos, salidas obtenidas (capturas y texto), análisis de impacto, sugerencias de mitigación cuando aplica y declaración explícita de no haber accedido a datos de terceros más allá de lo estrictamente necesario.

Divulgación responsable. Enviar a través del canal oficial del programa. Respetar embargos. No publicar detalles antes de que el proveedor confirme la corrección o autorice la difusión. La reputación a largo plazo en bug bounty depende tanto de la calidad técnica como de la conducta durante la divulgación.

Tooling útil

PyRIT (Microsoft) está enfocado a equipos red sobre IA generativa, con orquestación multi-turno y catálogos de probes. Garak (NVIDIA) es una suite con cientos de tests prefabricados, práctica para barridos iniciales sobre una superficie nueva. Promptfoo se orienta a evaluación y regresión, útil para automatizar la verificación de un hallazgo entre versiones.

Implementaciones de referencia disponibles en GitHub (GCG, AutoDAN y derivados) permiten reproducir técnicas conocidas y construir variantes propias. Más allá del tooling, los reporters experimentados mantienen catálogos propios adaptados a productos concretos y a las categorías que más han rendido. Es trabajo artesanal con valor real.

Casos públicos en disclosure 2024 a 2026

La comunidad ha documentado de forma continuada jailbreaks contra ChatGPT desde 2023. OpenAI ha cerrado muchas variantes y publicado mitigaciones sobre clases de ataque (DAN, role playing extremo, prompts en idiomas con menor cobertura de alignment). El patrón confirma que el alignment no es robusto frente a esfuerzo adversarial sostenido.

En 2024 se publicaron escenarios de prompt injection indirecto contra Microsoft Copilot, donde contenido externo (correos, documentos compartidos) inducía comportamientos no previstos al ser procesado por el asistente. Microsoft introdujo guardrails reforzados y avisos al usuario. Google ha gestionado divulgaciones sobre Gemini relacionadas con manejo de contexto y filtros de salida dentro de su VRP extendido a IA. Anthropic publica post mortems sobre clases de ataque encontradas durante red team interno y por colaboradores externos.

Estos casos comparten un patrón: ninguna plataforma pretende ofrecer un modelo inmune al abuso adversarial, todas han establecido canales formales de divulgación y bug bounty específico, y la dinámica con la comunidad de investigadores se ha profesionalizado entre 2023 y 2026.

Implementar un bug bounty AI para tu propia empresa

No toda organización está lista para abrir un programa formal. Hay pre-requisitos sin los que el programa genera más fricción que valor.

Madurez de seguridad mínima. El bug bounty asume un proceso interno capaz de absorber, triar y corregir hallazgos en plazos razonables. Sin equipo de seguridad funcional, pipelines de despliegue ágiles y coordinación con producto, los reportes se acumulan sin resolución y el programa pierde credibilidad.

Runbook de respuesta a incidentes para IA. Un programa AI bounty genera categorías que el IR clásico no cubre bien: cómo escalar un jailbreak con consecuencias regulatorias, quién decide si una clase de ataque obliga a degradar capacidades del producto, cómo se comunica internamente y al regulador. Estos procesos deben existir antes de invitar a la comunidad.

Alineamiento legal. Las reglas son un contrato implícito. Hay que definir safe harbor para investigadores que actúen de buena fe, qué datos pueden tocar, qué cuentas usar, qué herramientas están permitidas, con validación de asesoría jurídica especializada.

Elección de plataforma. HackerOne, Bugcrowd e Yeswehack son las opciones más comunes, con triage profesional gestionado, comunidades activas y herramientas de coordinación. Gestionarlo internamente reduce coste por reporte pero exige equipo dedicado.

Scope progresivo. Conviene empezar con un alcance acotado (un producto, severidad alta y crítica) y ampliar según el equipo demuestre capacidad de respuesta. Abrir scope completo el día uno suele saturar.

Preguntas frecuentes

¿Cuánto suelen pagar los AI bug bounty?

Las recompensas varían mucho. Los hallazgos críticos (authorization bypass, exposición cross-tenant) en programas de hiperescalares pueden alcanzar cifras de cinco a seis dígitos en USD. Los hallazgos de severidad media (prompt injection con impacto acotado, divulgación menor) suelen situarse entre cientos y miles. La cifra exacta depende del programa, la calidad del reporte y el impacto demostrado. Cada programa publica sus rangos.

¿Es viable vivir freelance de AI red teaming y bug bounty?

Para un perfil con experiencia consolidada en seguridad ofensiva y conocimientos de IA aplicada, sí, pero es competitivo. Los reporters que más rentabilizan combinan participación en varios programas, especialización en clases concretas y, a menudo, complemento con consultoría y formación. La curva de aprendizaje es alta y los ingresos los primeros meses suelen ser bajos.

¿El EU AI Act obliga a tener bug bounty?

No de forma explícita. El reglamento exige evaluaciones de robustez, exactitud y ciberseguridad para sistemas de alto riesgo, y red teaming para modelos de propósito general con riesgo sistémico. Un programa de bug bounty es una forma razonable de complementar estas obligaciones, pero no es el único mecanismo aceptado. Para muchos proveedores acaba siendo recomendable por gestión de riesgo, no por obligación textual.

¿Una alucinación es bug?

En general no, salvo que cause daño material a terceros en un contexto regulado. Una alucinación que afecta a la calidad de salida sin consecuencias jurídicas es un problema de producto, no una vulnerabilidad. Una alucinación que induce a un agente conectado a una API a invocar la función equivocada con datos sensibles puede entrar en scope porque hay impacto técnico real.

¿Es reportable un prompt injection sin impacto demostrado?

Depende del programa. Algunos aceptan demostraciones de prompt injection puro como prueba de concepto con recompensa baja, otros solo pagan si el reporter aporta una cadena de explotación que llegue a acción material. Antes de invertir tiempo conviene leer las reglas del programa concreto.

¿Mi startup de IA necesita bug bounty desde el día uno?

No. Si todavía está construyendo, lo prioritario es threat modeling interno, guardrails básicos, evaluación adversarial con tooling como Garak o PyRIT y un ejercicio externo puntual antes de abrir el producto a un volumen significativo. Un bug bounty formal cobra sentido cuando hay base de usuarios material, proceso de respuesta a incidentes funcionando y disposición a aceptar reportes externos de forma continuada.

Recursos relacionados

• AI red teaming: cómo evaluar la seguridad de modelos de IA y LLMs
• Pentesting de modelos IA y LLM: metodología
• OWASP Top 10 para LLM explicado
• Qué es prompt injection y cómo se ataca a aplicaciones LLM
• Seguridad de agentes IA autónomos: riesgos

Audita tu IA con Secra

En Secra evaluamos aplicaciones LLM, agentes autónomos y modelos integrados con ejercicios adversariales alineados con MITRE ATLAS, OWASP Top 10 for LLM Applications y los requisitos del EU AI Act. Acompañamos a equipos que quieren prepararse antes de abrir un programa formal de AI bug bounty, validar el scope inicial con un ejercicio externo independiente o reforzar guardrails después de un incidente.

Si su organización ha desplegado IA generativa en flujos materiales y necesita una evaluación adversarial seria, puede contactarnos en secra.es/contacto para una conversación inicial y definir alcance.