El open source lleva dos años corriendo, sin querer, el experimento que a cualquier empresa le costaría explicar en una junta directiva: qué pasa cuando miles de personas pueden aportar código o reportes generados por IA, sin filtro de entrada, sin capacitación previa y con el único incentivo de que su nombre aparezca en un commit.
Los resultados ya están documentados, proyecto por proyecto, y no son ambiguos.
En curl, la tasa de reportes de seguridad válidos cayó de más del 15% a menos del 5% durante 2025 — el resto, “AI slop”: reportes generados por IA que parecen plausibles pero no corresponden a nada real. Daniel Stenberg, su creador, terminó cerrando el programa de recompensas por vulnerabilidades en enero de 2026: el volumen de ruido superó lo que un equipo humano puede separar a mano.
En el kernel de Linux, el equipo de seguridad pasó de dos o tres reportes de este tipo por semana hace dos años, a entre cinco y diez por día. Vale la nota honesta: para 2026 la mayoría de esos reportes ya son correctos — la curva mejoró. Pero el patrón que dejó fue permanente: alguien tiene que revisar cada uno, y ese alguien sigue siendo humano.
Oracle prohíbe cualquier contribución con código generado por IA en OpenJDK, así sea parcial — mientras permite exactamente eso en GraalVM, otro proyecto propio. La contradicción no es entre Oracle y el resto de la industria. Es interna: la misma empresa no confía en la práctica que promueve en público.
QEMU prohibió las contribuciones de IA por completo en 2024, por incertidumbre de derechos de autor y procedencia. En mayo de 2026 relajó la regla — pero solo para cambios mecánicos, bugs menores y documentación. El código central sigue prohibido sin el permiso explícito y previo de un mantenedor.
Rust no se “abrió” a la IA como sugiere el titular fácil: cinco equipos específicos del repositorio principal adoptaron, en agosto de 2026, una política acotada — usar el modelo para analizar, revisar o sugerir está bien; usarlo para crear no, y todo debe declararse por adelantado.
Y el kernel de Linux tiene la regla más limpia de todas, escrita en su documentación oficial: un agente de IA no puede firmar el Developer Certificate of Origin. Solo una persona puede certificar legalmente el origen de una contribución. La IA puede aparecer etiquetada como “Assisted-by” — nunca como quien firma.
Seis proyectos, seis decisiones independientes, un mismo punto de llegada: ninguno prohibió usar IA. Todos exigieron que alguien, con nombre y responsabilidad, certificara lo que entra.
La diferencia entre esos proyectos y una empresa de doce personas no es el problema — es la visibilidad. Curl tiene un programa de recompensas público y una lista de correo donde se puede medir la caída de señal semana a semana. Tu equipo interno no tiene ese termómetro. El mismo incentivo — entregar rápido, que se vea terminado, evitar la pregunta incómoda de “¿esto realmente funciona?” — existe igual, solo que nadie lo está midiendo.
Por eso el proceso importa más que la herramienta. En HELMQ trabajamos con la misma premisa que terminó adoptando cada uno de estos proyectos por separado: la IA puede generar, pero la responsabilidad de lo que se integra la firma una persona senior, revisando lo que la IA produjo antes de que llegue a ti. No es una política nueva que inventamos. Es la misma conclusión a la que llegó, por caminos distintos, la ingeniería más exigente que existe.
Más sobre cómo estructuramos esa revisión: Cómo trabajamos.
Fuentes
- Daniel Stenberg — The End of the curl Bug-Bounty (ene-2026)
- LWN.net — Kernel security report volume (2026)
- InfoQ — Oracle’s conflicting GenAI policies (jun-2026)
- Lista de correo qemu-devel — Relajación de la política de IA (may-2026)
- Inside Rust Blog — rust-lang/rust is adopting an LLM policy (ago-2026)
- kernel.org — Coding assistants / DCO policy
20 de agosto de 2026