Cómo el USENIX Security maneja el aumento de envíos de papers en la era IA

Introducción

El 35° Simposio de Seguridad USENIX (USS), que se realizará la próxima semana en Baltimore, batió un récord histórico con más de 3.000 envíos de papers, un aumento del 26% respecto a los 2.400 del año pasado. Este crecimiento no es exclusivo del USS: el Simposio de Seguridad en Sistemas Distribuidos (NDSS) pasó de 694 submissions en 2024 a 1.481 en 2025. Los organizadores atribuyen parte del incrementos al uso de herramientas de IA, pero afirman que, por ahora, su impacto negativo es mínimo gracias a medidas proactivas.

El desafío no es menor: un estudio publicado en abril de 2026, «More Versus Better: Artificial Intelligence, Incentives, and the Emerging Crisis in Peer Review», revealed que desde el lanzamiento de ChatGPT en 2022, el volumen de envíos a revistas académicas aumentó un 42%. En este contexto, el USS implementó herramientas y políticas específicas para mitigar riesgos asociados al uso de IA, sin caer en una vigilancia excesiva que dañe la confianza en la comunidad.

Qué ocurrió

En enero de 2026, los co-organizadores del USS, Ben Stock (CISPA Helmholtz Center) y Elissa Redmiles (Georgetown University), publicaron un transparency report detallando las acciones tomadas para enfrentar el uso de IA en el proceso científico. El documento identifica dos prácticas inaceptables: referencias inexistentes (posiblemente alucinadas por modelos) y el uso de IA en las revisiones por pares.

El equipo desarrolló una herramienta automática que extrae referencias de los PDFs enviados, las contrasta con bases como DBLP y arXiv, y marca las no verificadas para revisión manual. Como resultado, rechazaron 21 papers (1,78% de los 1.181 envíos en la primera ronda) por contener 3 o más referencias falsas. Además, detectaron más de 100 papers con al menos una referencia no confirmada, pero decidieron no investigarlos para evitar sobrecargar al equipo, reconociendo que algunos podrían ser falsos positivos por errores de tipeo o citas incompletas.

En el lado de las revisiones, prohibieron explícitamente el uso de IA para escribir evaluaciones, ya que viola la confidencialidad del proceso. Identificaron 5 casos entre 496 revisores (1%) donde hubo evidencia suficiente de uso de IA, y removieron a los involucrados del comité, permitiendo a los autores afectados reenviar sus trabajos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para los equipos técnicos, el caso del USS ofrece lecciones directas sobre cómo gestionar el uso de IA en entornos colaborativos sin sacrificar la integridad. En el ámbito de DevOps y seguridad, el riesgo de hallucinations en documentación, scripts o políticas es real: un estudio de 2024 mostró que el 30% de los comandos generados por LLMs para tareas de Linux eran incorrectos o peligrosos (fuente: Kaizeng). En cloud, el problema se amplifica: código generado automáticamente para Terraform o Helm charts puede contener referencias a recursos inexistentes o configuraciones inseguras.

El enfoque del USS —detectar patrones objetivamente verificables (como referencias falsas) en lugar de perseguir el uso de IA en general— es aplicable a equipos de infraestructura. Por ejemplo:

• Validar automáticamente las dependencias declaradas en Chart.yaml (Helm) o requirements.txt (Python) contra repositorios oficiales.
• Auditar scripts generados por IA con herramientas como ShellCheck (para bash) o rustfmt (para Rust) antes de deployarlos.
• Implementar políticas de revisión por pares para cambios críticos en IaC (Infraestructure as Code), usando GitHub CODEOWNERS o Gerrit.

El impacto actual es moderado: los organizadores del USS no ven evidencia de que los envíos generados por IA sean un problema significativo. Sin embargo, el 1,78% de rechazo por referencias falsas demuestra que el riesgo existe y puede escalar.

Detalles técnicos

Herramientas y procesos del USS

• Detección de referencias falsas: La herramienta desarrollada por el USS extrae referencias de PDFs usando pdfplumber (Python) y las query contra:

– arXiv (preprints)

– Google Scholar

– DOI (Digital Object Identifier)

El umbral para rechazo fue 3 referencias no verificadas, una decisión basada en que 1-2 podrían ser errores humanos.

• Detección de uso de IA en revisiones: No se usaron herramientas de detección automática (como Turnitin o Copyleak). En cambio, se relied en el juicio humano: patrones como lenguaje genérico, repetición de frases o respuestas atípicamente rápidas. Los 5 casos confirmados fueron identificados por los metarevisores.

• Políticas claras:

– Prohibido: Usar IA para generar contenido sustancial (secciones enteras, código, referencias) o para escribir revisiones.

Lecciones para entornos técnicos

• Validación automática: En AWS, puedes usar AWS Config con reglas personalizadas para verificar que los recursos referenciados en CloudFormation o CDK existan. Por ejemplo:

  Resources:
    MySecurityGroup:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: SG for web servers
        VpcId: vpc-12345678  # Validar que este VPC existe
  

Una regla de Config como ec2-security-group-vpc-id-valid puede automatizar esta verificación.

• Análisis estático: Para código generado por IA en Rust, integrar cargo audit para detectar vulnerabilidades conocidas:

  cargo audit --advisories
  

En Debian, debsecan cumple un rol similar para paquetes:

  sudo apt install debsecan
  debsecan --only-fixed
  

• Provenance: Adoptar estándares como Sigstore o SLSA para firmar artefactos (containers, binarios) y verificar su origen, reduciendo el riesgo de código generado por IA sin supervisión.

Qué deberían hacer los administradores y equipos técnicos

1. Establecer políticas claras:

– Documentar estos lineamientos en un AI_POLICY.md en el repositorio del equipo.

1. Implementar controles automáticos:

– Referencias a recursos en IaC (usando terraform validate, helm lint).

– Sintaxis y buenas prácticas en scripts (shellcheck, hadolint para Dockerfiles).

– Dependencias (dependabot, renovate).

– Ejemplo para GitLab CI:

     validation:
       stage: .pre
       script:
         - terraform init -backend=false
         - terraform validate
         - helm lint ./charts/
         - shellcheck ./scripts/*.sh
     

1. Fortalecer la revisión por pares:

– Configuraciones de firewall/seguridad (ej.: reglas de Security Groups en AWS).

– Scripts que modifican datos o infraestructura.

– Usar checklists para revisiones, incluyendo items como «verificar referencias a recursos externos».

1. Capacitar al equipo:

– Compartir ejemplos reales, como el caso de 2023 donde un LLM generó un script Python que usaba os.remove con un path mal formateado, borrando archivos inesperados.

1. Monitorear y adaptar:

– Cantidad de PRs con referencias a recursos inexistentes.

– Incidentes causados por código generado por IA.

– Ajustar las políticas según la evolución del riesgo (ej.: prohibir IA en tareas críticas si los incidentes aumentan).

Conclusión

El caso del USENIX Security demuestra que el uso de IA en entornos técnicos puede gestionarse sin paranoia, pero tampoco sin naiveidad. Los organizadores logran contener los riesgos enfocándose en patrones verificables (referencias falsas, revisiones generadas por IA) y evitando una prohibición total que desincentivaría el uso legítimo. Para equipos de DevOps, seguridad e infraestructura, las lecciones son claras: implementar controles automáticos, fortalecer la revisión humana y establecer políticas pragmáticas. El objetivo no es eliminar la IA, sino asegurarse de que su uso no comprometa la integridad de los sistemas.

Fuentes

https://www.theregister.com/ai-and-ml/2026/08/07/how-the-famed-usenix-security-conf-is-managing-a-flood-of-papers-in-the-ai-era/5284374