La inteligencia artificial está cambiando la forma en que se construye software. Hoy, muchos equipos pueden producir mucho más código en mucho menos tiempo. Sin embargo, esa velocidad no elimina la necesidad de revisar riesgos: los equipos de seguridad siguen teniendo que evaluar vulnerabilidades, gestionar dependencias, priorizar correcciones y decidir qué se puede aceptar.
El problema aparece cuando el volumen del cambio se dispara. Si la salida de software crece de 10 a 50 veces, la seguridad deja de ser solo una cuestión de “encontrar fallos”. El reto real es evitar que la seguridad se convierta en el freno del proceso —o, peor aún, que el control del software entregado se pierda.
En este artículo revisamos las ideas clave de un seminario centrado en el verdadero costo de construir a máquina, y las traducimos a un enfoque claro para equipos que quieren seguridad en desarrollo con IA sin frenar la adopción.
Por qué el volumen de código rompe el enfoque tradicional
Durante años, la seguridad de aplicaciones siguió un ciclo bastante reconocible: los desarrolladores escriben código, las herramientas de escaneo detectan problemas, los equipos de seguridad priorizan y, finalmente, los ingenieros corrigen lo que sea más importante. Este modelo funcionaba cuando la tasa de cambio era manejable y el backlog de hallazgos podía absorberse con tiempo y capacidad humana.
Cuando la IA acelera la producción, esa lógica se tensiona. Un aumento de código también suele significar un aumento de componentes, dependencias, hallazgos y correcciones necesarias. Y ojo: escanear más no resuelve el problema. Puede crear un backlog aún más grande, desplazando el trabajo crítico y extendiendo el tiempo de exposición.
Seguridad en desarrollo con IA: el riesgo deja de ser un solo backlog
Con tasas de entrega más altas, la seguridad deja de ser únicamente una lista de vulnerabilidades por corregir. En la práctica, el riesgo se manifiesta en varios niveles: qué entra en producción, qué dependencias se incorporan, qué controles se aplican y quién responde cuando algo sale mal.
Además, hay un segundo frente que agrava la situación: los mismos modelos y capacidades que ayudan a los equipos defensivos también pueden ser aprovechados por atacantes. Si tanto la producción de software como las capacidades de los adversarios aceleran, los equipos de seguridad se ven presionados “desde ambos lados”.
Por eso, el desafío central se resume así: ¿cómo avanzar al ritmo de la IA sin aceptar un ritmo de riesgo propio de la IA?
El cambio de enfoque: de “remediar CVE” a “mantener guardarraíles”
Una parte del seminario aborda un punto incómodo: hay señales de que la remediación impulsada solo por CVE empieza a romperse cuando el volumen y la velocidad superan lo que los equipos pueden revisar y corregir de forma realista.
La conversación no se limita a cuestionar si el código generado por IA es seguro. Va más allá, hacia una pregunta más dura: qué pasa con la seguridad cuando el software crece más rápido que la capacidad humana de evaluarlo.
En ese escenario, los equipos necesitan controles diseñados para el desarrollo actual, no para una realidad de hace cinco años. En vez de depender de ciclos reactivos, la meta es anticipar fallos y reducir la probabilidad de que el riesgo llegue a producción.
Qué debería incluir un modelo operativo nuevo
Si quieres aplicar seguridad en desarrollo con IA, conviene pensar en un modelo operativo que funcione con la nueva velocidad. El seminario propone mirar “más allá” de los debates habituales y centrarse en cómo escalar los controles sin convertirse en el cuello de botella.
Algunas líneas clave que se desprenden de ese enfoque:
- Evaluación continua del impacto: no basta con detectar; hay que decidir con rapidez qué corregir, qué mitigar y qué aceptar.
- Fortalecer el “secure-by-default”: orientar la construcción para que las decisiones seguras sean el punto de partida.
- Controles que resistan el aumento de escala: evitar que los procesos de gestión de vulnerabilidades se desborden cuando el volumen sube.
- Guardarraíles antes de producción: asegurar que existan mecanismos que hagan que el código llegue con requisitos de seguridad claros.
- Gobernanza del riesgo: alinear seguridad, desarrollo y negocio para que la exposición sea entendida y gestionada.
El aspecto de gobernanza: quién asume el riesgo
Uno de los puntos más relevantes es que el desarrollo asistido por IA se está convirtiendo rápidamente en una decisión que va más allá de ingeniería. Cuando se modifica el ritmo de construcción, también cambia la forma en que la organización acepta exposición.
Por eso, los líderes de seguridad necesitan poder responder preguntas como:
- ¿Quién es responsable del riesgo cuando el software se entrega a máquina?
- ¿Cuánta exposición está aceptando la organización?
- ¿Cómo se explican esas decisiones a la dirección y a los equipos de gobierno?
La recomendación implícita en la charla es clara: no se trata de frenar a los desarrolladores. Las empresas adoptan IA para construir más rápido. El objetivo es lograr que la seguridad acompañe esa velocidad con controles pensados para el presente.
Cómo construir seguridad sin frenar la velocidad
Entonces, ¿qué puedes hacer de manera práctica para mejorar tu estrategia? La idea central es diseñar controles alrededor de cómo se construye software hoy. Eso implica revisar los flujos de trabajo y ajustar el “cómo” más que solo el “qué” se escanea.
En lugar de perseguir una cantidad ilimitada de detecciones, busca un enfoque que:
- reduzca el riesgo antes de que el código llegue a producción,
- mantenga prioridades realistas incluso cuando el volumen de hallazgos sube,
- defina claramente responsabilidades y decisiones bajo presión de tiempo.
Si lo haces bien, el resultado no es solo “más seguridad”, sino seguridad sostenible: un sistema que no se rompe cuando la tasa de cambios aumenta.
Qué aprender del seminario y cómo aplicarlo
El seminario “The True Cost of Building at Machine Speed” se enfoca en el costo real de acelerar la construcción. El valor para tu equipo está en que aborda la brecha entre velocidad de desarrollo y capacidad de control, explicando por qué el modelo tradicional pierde eficacia cuando el software crece a un ritmo que excede la revisión humana.
Además, la sesión discute por qué la IA puede ampliar la superficie de ataque, en qué puntos los procesos actuales de gestión de vulnerabilidades pueden tener dificultades a escala y dónde es necesario reforzar guardarraíles antes de que el código llegue a producción.
Finalmente, también entra en la dimensión de gobernanza: cómo entender y comunicar la exposición aceptada cuando el desarrollo asistido por IA se vuelve parte de la operación diaria.
Conclusión: la seguridad debe ir a la misma velocidad que el software
La IA acelera el desarrollo, y eso es una oportunidad —pero también crea un riesgo nuevo cuando el volumen crece más rápido que la capacidad de revisar y remediar. La respuesta no puede ser simplemente “hacer más escaneo” ni “frenar a los equipos”.
Para lograr seguridad en desarrollo con IA, necesitas un modelo operativo nuevo: controles diseñados para el ritmo actual, prioridades sostenibles, guardarraíles antes de producción y gobernanza que deje claro quién asume qué riesgo. Así, puedes mantener la velocidad sin perder el control de lo que realmente se entrega.
Fuente: https://thehackernews.com/2026/08/shipping-1050-more-code-watch-this.html
