Las reglas de recompensas por errores de Apple y Google convergen mientras el spam de IA obliga a tomar medidas

Las reglas de recompensas por errores de Apple y Google han llegado al mismo punto de inflexión tras una oleada sin precedentes de informes de vulnerabilidades de baja calidad generados por IA.

Según se informa, Apple limitó la cantidad de informes activos que los investigadores pueden mantener a través de su portal de seguridad. También introdujo un periodo de espera después de que los investigadores alcancen ese límite. Sus normas públicas ahora contemplan pausas más prolongadas y la expulsión definitiva ante envíos inválidos reiterados.

La comparación importa porque Google ya había endurecido su programa de vulnerabilidades de código abierto tras lo que calificó como un aumento masivo de informes generados por IA. GitHub siguió el mismo camino con requisitos de participación más estrictos y una estructura de recompensas rediseñada. En conjunto, estas medidas muestran que el descubrimiento automatizado de vulnerabilidades ha chocado con un recurso escaso: la revisión experta humana.

El conflicto no es simplemente IA contra investigadores de seguridad. Es descubrimiento escalable frente a evidencia verificable. Un sistema de IA puede proponer cientos de debilidades plausibles, pero un equipo de seguridad aún debe reproducir cada afirmación y determinar si los atacantes pueden explotarla.

Ese desequilibrio genera una inversión incómoda. Se suponía que la IA ayudaría a los defensores a localizar fallos graves más rápido. En cambio, los envíos sin validar pueden enterrar los informes que merecen atención inmediata.

Apple impuso nuevas barreras en su cola de seguridad

La respuesta de Apple apunta al volumen de envíos, pero sus normas públicas se centran de forma más directa en la validación y el comportamiento de los investigadores.

Según el informe original sobre la cuota, Apple introdujo un límite para los informes de vulnerabilidades activos y un periodo de enfriamiento para los investigadores que lo alcancen. Según se informa, los investigadores pueden solicitar un límite superior cuando su trabajo justifique capacidad adicional.

Esa restricción operativa es independiente de las sanciones publicadas en las directrices actuales de Security Bounty de Apple. Apple afirma que puede suspender el procesamiento de informes durante 180 días cuando un investigador presenta reiteradamente hallazgos no aptos.

Más de dos periodos de suspensión pueden derivar en la expulsión permanente del programa. Durante una suspensión, los investigadores suelen perder acceso a recompensas, reconocimiento en avisos de seguridad y el procesamiento ordinario de informes.

Apple ofrece excepciones limitadas. Un investigador suspendido aún puede presentar evidencia que capture una Target Flag aplicable o que incluya una virtualización completamente empaquetada de iOS o macOS.

Una Target Flag es un valor protegido colocado dentro de un sistema de Apple para demostrar que un exploit alcanzó un límite de seguridad específico. Convierte una afirmación teórica en evidencia medible.

Las directrices de presentación de informes de Apple ahora identifican varias cualidades que debe tener un envío válido. Un informe necesita una explicación precisa, un exploit funcional o una prueba de concepto fiable, y pasos de reproducción concisos.

La empresa indica explícitamente a los investigadores que eviten las descripciones extensas generadas por herramientas de IA. También clasifica como no aptos los hallazgos teóricos de IA sin una validación adecuada.

Estas disposiciones no prohíben la investigación asistida por IA. Trazan una línea entre utilizar IA durante una investigación y trasladar la salida no probada de un modelo de IA a la cola de Apple.

Los términos del programa de Apple refuerzan esa distinción. La empresa puede finalizar la participación tras spam reiterado, afirmaciones falsas o envíos asistidos por IA sin revisar.

Esta combinación brinda a Apple varios niveles de aplicación. Una cuota del portal limita el volumen simultáneo. Una suspensión de 180 días aborda el comportamiento repetido de baja calidad. La exclusión permanente sigue disponible para investigadores que no mejoren.

La distinción importa porque las cuotas por sí solas no pueden identificar la calidad. Un investigador meticuloso podría tener varios hallazgos legítimos bajo investigación activa. Un remitente de spam podría presentar menos informes que aun así consuman muchas horas.

Por ello, Apple permite que una evidencia más sólida funcione como excepción. La explotación fiable, el comportamiento reproducible y la confirmación del objetivo pueden permitir que un informe supere los controles de volumen.

El cambio también restringe qué se considera un descubrimiento de vulnerabilidades útil. Ya no basta con encontrar código sospechoso. Los investigadores deben explicar cómo un atacante alcanza ese código y qué control, datos o privilegios obtiene.

Ese estándar es conocido por los cazadores de errores con experiencia. Lo que cambió es la necesidad de expresarlo directamente en respuesta al volumen generado por IA.

Por qué la respuesta de Apple y Google llegó ahora

La ofensiva de Apple y Google refleja una asimetría económica: las máquinas generan afirmaciones de seguridad a bajo coste, mientras los ingenieros deben invalidarlas una por una.

Los modelos generativos pueden analizar código, describir patrones inseguros, redactar narrativas de ataque y dar formato a informes de aspecto profesional. Ninguna de esas capacidades establece que una vulnerabilidad funcione en una configuración de producto compatible.

Un modelo podría identificar un desbordamiento de búfer en código inalcanzable. Podría malinterpretar un límite de permisos o inventar una función inexistente. También puede exagerar el impacto de un defecto rutinario de software.

Cada afirmación puede seguir pareciendo creíble a primera vista. Los ingenieros de seguridad deben inspeccionar el código pertinente, configurar un entorno de pruebas, reproducir el comportamiento y evaluar la exposición en el mundo real.

Google describió exactamente este problema cuando modificó su Open Source Software Vulnerability Reward Program en marzo de 2026. La empresa afirmó haber experimentado un aumento masivo de informes generados por IA durante varias semanas.

Google observó condiciones de activación alucinadas, impacto de seguridad insignificante y hallazgos en rutas de código inalcanzables. En consecuencia, su actualización de reglas de OSS exigió pruebas más sólidas para algunas partes del programa.

Según el nivel del repositorio, la evidencia aceptable puede incluir una reproducción con OSS-Fuzz o un parche integrado. OSS-Fuzz es el servicio de fuzzing continuo de Google para software de código abierto.

Posteriormente, Google eliminó las recompensas monetarias y el reconocimiento público para algunas vulnerabilidades de productos de nivel inferior y otros problemas de seguridad. Ese cambio modificó la estructura de incentivos, no solo el formato de los informes.

Apple adoptó una vía operativa diferente. Su límite comunicado controla la cantidad de casos activos vinculados a un investigador. Su política escrita amenaza con suspensiones cuando los informes reiterados siguen siendo teóricos o inválidos.

Ambos enfoques introducen fricción antes de que desaparezcan los escasos recursos de triaje. Ninguno supone que una redacción pulida equivalga a una vulnerabilidad verificada.

La palabra “slop” puede ocultar el mecanismo real. El problema no es que una IA haya redactado una frase. El problema es que la generación automatizada elimina el coste natural que antes limitaba los informes especulativos.

Antes de la IA generativa, elaborar un envío de vulnerabilidad convincente exigía un trabajo manual considerable. Normalmente, un investigador tenía que inspeccionar un objetivo, desencadenar un comportamiento inesperado y documentar resultados reproducibles.

La IA reduce el coste de producir el documento sin reducir necesariamente el coste de producir la evidencia. Eso genera más informes cuya apariencia supera su sustancia técnica.

Una recompensa puede amplificar este comportamiento. Cuando incluso un único envío aceptado podría recibir un pago, los sistemas automatizados pueden generar muchos intentos especulativos.

El remitente paga poco por cada afirmación adicional. La organización receptora paga un coste de revisión experta cada vez.

Este es un problema clásico de colas. Si las llegadas inválidas aumentan más rápido que la capacidad de revisión, los casos legítimos esperan más tiempo independientemente de su calidad.

Incorporar más revisores solo ofrece una respuesta parcial. Es difícil contratar ingenieros experimentados de seguridad de productos, y el trabajo de triaje compite con la corrección, el análisis de amenazas y la respuesta a incidentes.

El triaje automatizado puede ayudar a priorizar informes, pero introduce otra capa de verificación. Un clasificador podría suprimir un informe poco convencional que describa deficientemente un exploit genuino.

Por ello, la respuesta de Apple y Google considera la validación humana como el punto de control esencial. La IA puede ayudar al descubrimiento, pero una persona sigue siendo responsable de demostrar la afirmación antes del envío.

La verdadera disyuntiva es acceso frente a señal

Los filtros más estrictos pueden proteger a los equipos de seguridad, pero también pueden perjudicar a los investigadores nuevos y retrasar hallazgos inusuales.

Los programas abiertos de recompensas por errores amplían el alcance defensivo de una empresa. Los investigadores independientes prueban configuraciones, componentes y rutas de ataque que los equipos internos podrían pasar por alto.

Esa apertura funciona porque la participación no requiere empleo, estatus institucional ni una relación previa con el proveedor. Un investigador con un hallazgo sólido puede entrar en la misma cola que una empresa de seguridad consolidada.

Los límites de envío alteran ese equilibrio. Preservan la capacidad de revisión, pero también hacen que el acceso dependa de la calidad previa de los informes o de la cuota disponible.

El riesgo se vuelve más claro cuando llegan juntos varios hallazgos legítimos. Un equipo de investigación que audita una gran plataforma podría identificar muchas vulnerabilidades relacionadas durante un único proyecto concentrado.

Si los casos anteriores siguen abiertos, el equipo puede alcanzar un límite de informes activos incluso cuando su nueva evidencia es sólida. Solicitar un aumento ofrece una posible solución, pero la decisión sigue en manos del operador del programa.

Apple tiene una razón legítima para proteger su cola. Su programa de seguridad cubre productos y servicios de cara al público utilizados en una amplia base de dispositivos.

La empresa afirma que solo el primer informe completo y accionable reúne los requisitos para recibir una recompensa. Esa regla hace que el envío oportuno sea importante cuando varios investigadores analizan la misma debilidad.

Por tanto, una cuota puede crear una carrera involuntaria. Los investigadores podrían priorizar el informe con más probabilidades de recibir una recompensa en lugar del problema con mayor impacto para los usuarios.

Apple intenta contrarrestar esta presión enfatizando la evidencia completa. Un informe apresurado sin una reproducción fiable sigue siendo no apto, incluso si llega primero.

La cuestión escéptica de la política es si Apple puede distinguir de forma coherente el volumen del abuso. La documentación pública explica qué hace que un informe sea accionable, pero no revela todos los umbrales de triaje ni las decisiones de escalado.

Los investigadores tampoco pueden medir de forma independiente cuántos informes inválidos de IA entran en el sistema de Apple. La empresa ha descrito el problema, pero no ha publicado un desglose mensual detallado.

Esa ausencia no invalida la respuesta de Apple. Limita la evaluación externa sobre si una cuota es proporcional y si mejora los tiempos de procesamiento.

Las preocupaciones históricas sobre los tiempos de respuesta de los proveedores hacen importante la transparencia. Los investigadores necesitan saber si el silencio refleja un informe débil, una investigación prolongada o una cola desbordada por envíos no relacionados.

Un filtro mal implementado podría desalentar la divulgación responsable. Un investigador que no pueda enviar un informe de forma privada podría posponerlo, acudir a otro coordinador o divulgarlo públicamente tras perder confianza en el proceso.

La divulgación pública antes de una corrección puede aumentar el riesgo para los usuarios. Las reglas de Apple también hacen que la divulgación prematura no sea apta para el pago de recompensas.

Por tanto, la empresa controla tanto el canal aceptado como las condiciones para mantener la elegibilidad. Este esquema funciona mejor cuando los investigadores reciben comentarios oportunos y específicos.

El estándar más defendible es una fricción basada en evidencia. Un investigador que presenta repetidamente hallazgos alucinados debería enfrentarse a restricciones. Un investigador con exploits reproducibles debería contar con una vía de escalado clara.

La excepción de Apple para Target Flag apunta en esa dirección. Privilegia el impacto verificable por encima de la reputación por sí sola.

Aun así, los Target Flags no cubren todas las categorías de vulnerabilidades. Algunos fallos lógicos importantes se resisten a una prueba sencilla basada en flags, y algunos informes requieren una evaluación contextual.

No es posible eliminar esta disyuntiva mediante una sola política. Apple debe filtrar con suficiente agresividad para proteger el triaje, pero mantenerse lo bastante abierta para captar investigaciones inesperadas.

Google y GitHub muestran que se trata de un cambio en la industria

Apple no actúa sola, y el modelo emergente de la industria recompensa el impacto demostrado por encima del volumen de descubrimientos automatizados.

La actualización de Google de marzo de 2026 ofrece la comparación más clara. La empresa reconoció que la IA puede acelerar la investigación de vulnerabilidades, al tiempo que insistió en que los investigadores validen sus resultados durante la investigación.

Google no rechazó informes simplemente porque la IA hubiera contribuido a ellos. Elevó los requisitos de prueba para determinados niveles de repositorios y redujo los incentivos para las categorías de menor valor.

Su Vulnerability Reward Program más amplio ahora incluye factores de calidad del informe, como la precisión técnica, la capacidad de respuesta y la exactitud factual. Las reglas publicadas identifican el “AI slop” como una señal negativa de calidad.

Ese lenguaje refleja un cambio: ya no se juzga únicamente la supuesta vulnerabilidad, sino también el proceso de envío. Los investigadores deben demostrar que comprenden el objetivo y que pueden responder a preguntas de seguimiento.

GitHub adoptó otra variante en julio de 2026. Reestructuró su programa público de recompensas y creó una vía permanente solo por invitación para investigadores seleccionados.

La empresa también añadió un requisito de señal de HackerOne a su programa público. Signal es una medida de reputación basada en la frecuencia con la que los informes de un investigador reciben resultados favorables.

GitHub afirmó que el requisito se diseñó para reducir los envíos de bajo esfuerzo y generados por IA. Los informes presentados a partir del 27 de julio entraron en la estructura revisada.

Los cambios de GitHub muestran cómo un programa abierto puede ir convirtiéndose gradualmente en uno condicionado por la reputación. Los nuevos investigadores reciben oportunidades limitadas para establecer un historial útil.

El modelo de Apple actualmente parece depender menos de una puntuación de reputación de terceros. En su lugar, combina criterios para los informes, límites de casos activos y sanciones progresivas.

Las tres empresas están resolviendo el mismo problema de asignación con controles diferentes.

Google aumenta los requisitos de evidencia y restringe las categorías elegibles. GitHub ajusta el acceso, la reputación y las recompensas. Apple limita la ocupación de la cola y penaliza los envíos inválidos repetidos.

Estos enfoques pueden mejorar la señal, pero cada uno conlleva un riesgo de exclusión distinto. Los requisitos de evidencia favorecen a los investigadores con herramientas maduras. Las barreras de reputación favorecen a los participantes establecidos. Las cuotas favorecen a quienes cierran rápidamente sus casos anteriores.

El patrón se extiende más allá de las grandes empresas tecnológicas. Los mantenedores de proyectos de código abierto también han informado de denuncias de vulnerabilidades generadas por IA que consumen tiempo voluntario.

Estos proyectos afrontan un desequilibrio aún más marcado. Una biblioteca popular puede tener solo unos pocos mantenedores, mientras que los escáneres automatizados pueden producir informes de forma continua.

Las plataformas de recompensas por errores han respondido con reglas más estrictas contra las hipótesis de IA no validadas. Algunas exigen pruebas manuales y confirmación antes de que un investigador presente un hallazgo.

Esta convergencia deja clara una cosa: la industria no está prohibiendo la investigación de seguridad asistida por máquinas. Está retirando recompensas y atención de las afirmaciones generadas por máquinas sin una verificación humana responsable.

Esa distinción dará forma a los futuros agentes de seguridad. Las herramientas que solo produzcan informes plausibles perderán valor. Las que reproduzcan exploits, recopilen trazas y expliquen rutas de ataque alcanzables seguirán siendo útiles.

La oportunidad competitiva reside en la automatización de evidencias. Un agente de seguridad no debería detenerse después de identificar código sospechoso.

Debería construir un caso de prueba, confirmar la versión afectada, aislar las condiciones previas y registrar la exposición resultante de privilegios o datos. Los investigadores humanos deben examinar después esas evidencias antes de la divulgación.

Por tanto, la comparación entre Apple y Google es más que una historia de políticas. Define los requisitos de producto para la próxima generación de herramientas de seguridad automatizadas.

La IA puede encontrar vulnerabilidades reales, pero la prueba sigue siendo el cuello de botella

El argumento más sólido contra una prohibición general de la IA es sencillo: los sistemas automatizados ya contribuyen a descubrimientos de seguridad auténticos.

Google ha promovido la investigación de vulnerabilidades asistida por IA mediante proyectos como Big Sleep, un agente desarrollado por Google DeepMind y Project Zero. El proyecto combina el razonamiento de modelos con herramientas de seguridad consolidadas.

Ese trabajo muestra por qué las empresas están evitando prohibiciones absolutas. La IA puede explorar grandes bases de código, generar hipótesis y ayudar a los investigadores a analizar interacciones complejas.

Las reglas de Apple preservan esa distinción. Se refieren a hallazgos de IA sin una validación adecuada, no a todos los hallazgos desarrollados con ayuda de IA.

Un investigador puede usar un modelo para inspeccionar código fuente o mejorar un informe. El envío final debe seguir describiendo el comportamiento observado, el comportamiento esperado, el mecanismo eludido y un resultado de ataque creíble.

Una prueba de concepto fiable sigue siendo fundamental. Una prueba de concepto es una prueba mínima que demuestra la vulnerabilidad bajo condiciones definidas.

Para cadenas de ataque complejas, Apple solicita versiones compiladas y de código fuente, las cargas útiles necesarias y todo lo requerido para ejecutar la cadena. Ese requisito sitúa la reproducibilidad por encima de la confianza narrativa.

Apple tiene motivos para preservar la investigación externa de alta calidad. En una actualización anterior sobre recompensas, la empresa afirmó haber pagado más de 35 millones de dólares a más de 800 investigadores desde que abrió el programa público en 2020.

También informó de múltiples recompensas individuales de 500.000 dólares. Estas cifras muestran que los envíos externos no son una parte periférica del proceso de seguridad de Apple.

El desafío consiste en mantener ese canal útil a medida que se expande la automatización. Si los equipos de triaje dedican demasiado tiempo a refutar escenarios fabricados, el valor de todo el programa disminuye.

Sin embargo, el triaje automatizado no puede tratarse como infalible. Un exploit inusual puede parecer un falso positivo porque cruza un límite que los revisores no esperaban.

Un filtro basado en modelos también puede recompensar una estructura convencional de informe. Los investigadores que utilicen un inglés menos pulido o metodologías desconocidas podrían recibir puntuaciones más bajas pese a contar con evidencias válidas.

Apple afirma que sus informes reciben revisión humana, mientras que la IA ayuda a priorizar los casos entrantes. Esa división puede reducir el trabajo administrativo sin entregar las decisiones finales por completo a un clasificador.

Los detalles siguen siendo importantes. Los investigadores necesitan saber si la priorización automatizada influye en el tiempo de respuesta, la elegibilidad o solo el orden de la cola.

Los falsos negativos crean un riesgo distinto al del spam. Un informe inválido rechazado desperdicia el tiempo de un investigador. Un informe válido rechazado puede dejar expuestos millones de dispositivos.

La solución no es aceptar todas las afirmaciones generadas. Es dejar claras las apelaciones, la escalada y los estándares de evidencia para que los hallazgos sólidos puedan recuperarse de una clasificación errónea inicial.

Los equipos de seguridad también deberían medir los resultados, no solo el volumen reducido. Una política exitosa debería acortar el tiempo necesario para validar informes críticos sin suprimir el número de hallazgos de alto impacto aceptados.

Los investigadores también tienen responsabilidades. Deben reproducir la salida del modelo, probar las versiones afectadas, describir las condiciones previas y eliminar el lenguaje especulativo que no esté respaldado por experimentos.

La prosa generada por IA puede hacer que la incertidumbre parezca certeza. La revisión humana debe invertir esa tendencia separando las observaciones de las suposiciones.

Un informe útil debería responder cuatro preguntas concretas. ¿Qué entrada desencadena el comportamiento? ¿Qué configuración compatible se ve afectada? ¿Qué límite de seguridad falla? ¿Qué obtiene el atacante?

Cuando faltan esas respuestas, más texto no mejora el informe. Aumenta el coste de encontrar la evidencia que falta.

Qué vigilar tras la ofensiva contra los informes de errores generados por IA

La siguiente prueba será determinar si unas reglas más estrictas mejoran la calidad de las respuestas sin alejar a investigadores creíbles.

La primera señal será el rendimiento de Apple en el procesamiento de informes. Tiempos de revisión inicial más cortos respaldarían el argumento de la empresa de que los envíos inválidos estaban consumiendo capacidad crítica.

Apple no publica actualmente un panel público detallado que cubra el tamaño de la cola, los motivos de rechazo y el tiempo de respuesta mediano. Una mayor transparencia facilitaría evaluar el efecto de la política.

Los investigadores aún pueden aportar evidencia indirecta. Los informes sobre acuses de recibo más rápidos, actualizaciones de estado más claras y menos casos de larga duración sugerirían que los controles están funcionando.

El patrón opuesto debilitaría la explicación de Apple. Si los informes legítimos siguen retrasándose después de las restricciones de volumen, el cuello de botella puede involucrar la dotación de personal, la coordinación interna o la capacidad de corrección.

La segunda señal será el trato a los investigadores de gran volumen. Según se informa, Apple permite solicitudes de aumento de cuota, creando una importante válvula de escape para los equipos con hallazgos validados.

Los observadores deberían vigilar si esas solicitudes reciben decisiones rápidas y si la evidencia, en lugar de la reputación por sí sola, determina la aprobación.

Un proceso de excepción que funcione bien permitirá a los equipos serios continuar auditorías concentradas. Un proceso opaco hará que el límite de informes activos parezca arbitrario.

Google ofrece una referencia externa útil. Sus mayores requisitos de prueba deberían reducir los informes inválidos, pero también podrían reducir la participación en proyectos de código abierto de menor nivel.

Las políticas de Apple y Google parecerán más defendibles si ambos programas mantienen fuertes tasas de descubrimiento mientras reducen el tráfico de bajo valor en la cola. La caída de los totales de envíos por sí sola no demostraría éxito.

La tercera señal vendrá de los proveedores de herramientas de seguridad y los agentes de IA. El mercado tiene ahora un incentivo claro para producir artefactos reproducibles en lugar de especulación pulida sobre vulnerabilidades.

Las herramientas útiles integrarán trazas de ejecución, información de versiones, entornos de prueba y condiciones previas de los exploits. También etiquetarán las inferencias inciertas en lugar de presentarlas como comportamiento confirmado.

Los operadores de programas podrían respaldar esa transición con esquemas de envío legibles por máquinas. Los campos obligatorios podrían separar los resultados observados, el impacto inferido, los detalles del entorno y los pasos de validación humana.

La evidencia estandarizada podría mejorar el enrutamiento automatizado sin sustituir el juicio experto. También facilitaría la auditoría de envíos masivos.

La pregunta más difícil es si los atacantes obtienen los mismos beneficios de la automatización sin enfrentarse a reglas de divulgación. No necesitan demostrar una vulnerabilidad ante un proveedor antes de explotarla.

Por tanto, los defensores no pueden responder a la mala automatización rechazando la automatización por completo. Necesitan mejores agentes, canales de validación más sólidos y una escalada humana más rápida para los hallazgos creíbles.

La política inmediata de Apple protege la puerta de entrada de su programa de recompensas. No resuelve el desafío más amplio del descubrimiento de vulnerabilidades a escala de máquinas.

Para los investigadores, el mensaje práctico es directo. Utilicen la IA para ampliar el espacio de búsqueda, pero presenten solo aquello que puedan reproducir y defender ante preguntas técnicas.

Para los líderes de ingeniería, la lección se extiende más allá de las recompensas por errores. Cualquier flujo de trabajo que acepte resultados de IA generados externamente necesita una puerta de control vinculada a la evidencia, la responsabilidad y el coste de revisión.

En última instancia, el cambio de política de Apple y Google se juzgará por lo que llegue a los ingenieros después del filtrado. ¿La cola contiene menos informes o contiene mejores informes?

Esa diferencia debería guiar la siguiente fase. Sigan los tiempos de respuesta, observen cómo funcionan las solicitudes de excepción y busquen agentes de seguridad que produzcan evidencia en lugar de texto seguro de sí mismo.