La IA puede escribir y revisar código, pero los humanos siguen siendo los responsables del riesgo.

El lanzamiento de Claude Code Security por parte de Anthropic marca un punto de inflexión decisivo entre el desarrollo de software asistido por IA y el rápido avance de nuestro enfoque de la ciberseguridad moderna. Si bien esta nueva capacidad de Claude puede identificar vulnerabilidades en el código generado por IA, esto crea un único punto de confianza y fallo, y un experto humano debe seguir evaluando esos hallazgos y determinar la ruta de corrección adecuada. Este enfoque cuenta con el apoyo de personas como Justin Greis, director ejecutivo de la consultora Acceligence, quien declaró a CSO Online: «Para aquellos que confían ciegamente en cualquier herramienta de análisis de código, ya sea de IA o de otro tipo, para sustituir los fundamentos de las buenas prácticas de seguridad y la codificación segura, esta es una señal de alarma para no externalizar la experiencia que protege la propuesta de valor del producto o servicio que están desarrollando». 

En ese sentido, el modelo no difiere fundamentalmente de las herramientas SAST tradicionales. Es más avanzado en su razonamiento, pero un caso de uso sensible al riesgo sigue dependiendo de la intervención humana para interpretar, validar y remediar los problemas que detecta de forma segura.

La amenaza para las organizaciones no es la capacidad de la IA, sino la autonomía incontrolada de la IA y la escasa supervisión dentro del ciclo de vida del desarrollo de software. Cuando la IA genera y evalúa código, una gobernanza sólida y precisa se convierte en un control fundamental. 

La definición cada vez más amplia del término «desarrollador»

La IA ha reducido las barreras de entrada para la creación de aplicaciones y software. Sin embargo, el hecho de que algo se pueda hacer rápidamente con IA no significa que se esté haciendo de la forma más segura o resistente, ni que el proyecto en sí esté listo para el usuario. La premisa fundamental del vibe coding es entrar en el «estado de flujo» y ocuparse más tarde de los trámites de desarrollo a nivel empresarial, como la seguridad. 

El «desarrollador» actual puede ser:

• Un ingeniero tradicional que utiliza la IA para acelerar las tareas de codificación.
• Un gestor de productos crea prototipos de funciones mediante indicaciones.
• Un analista de datos que automatiza scripts mediante IA.
• Un ingeniero de control de calidad que utiliza la inteligencia artificial para generar casos de prueba.

Desde el punto de vista de la seguridad organizativa, quién escribe el código importa mucho menos que el impacto que tiene el código una vez que llega a la fase de producción. Desde el punto de vista del cumplimiento normativo y el riesgo, si la interacción de una persona con la IA da lugar a que el código entre en el ciclo de vida del desarrollo de software (SDLC) sin la supervisión de seguridad adecuada y específica de la empresa, se introduce un riesgo organizativo, un riesgo que debe comprenderse, medirse y mitigarse.

Por qué el juicio humano sigue siendo importante

A medida que más personas adquieren la capacidad de generar código que podría afectar a la producción o a bases de código sensibles, el perfil de riesgo de una organización se amplía. La gobernanza debe evolucionar para permitir el desarrollo impulsado por la IA a gran escala, al tiempo que se garantiza que los controles necesarios para proteger la empresa sigan estando firmemente implantados.

La IA puede, con bastante fiabilidad, generar código y señalar posibles vulnerabilidades. Lo que no puede hacer es validar si ese código es adecuado en el contexto de su arquitectura, flujos de datos, modelo de identidad, obligaciones normativas o tolerancia al riesgo, y esta es una información fundamental que afecta a la eficacia de cualquier programa de seguridad. Además, implementar una herramienta como Claude Code en el SDLC es una cosa, pero herramientas como BaxBench demuestran, mediante un amplio análisis de datos, que diferentes modelos (por ejemplo, Opus frente a Sonnet 4.5 frente a Sonnet 3) ofrecen resultados diferentes en términos de seguridad y precisión, lo que se traduce en una enorme diferencia en el dinero real que una empresa acabará pagando por su uso a medida que impulsa el desarrollo de código seguro y funcional.

El software seguro no es simplemente un código que supera un análisis. Debe seguir patrones adecuados y seguros que se ajusten perfectamente al diseño del sistema, la intención comercial y la política de la empresa. Eso requiere criterio. Cuando los desarrolladores dependen en gran medida de la IA para generar o incluso revisar el código, existe un riesgo real de que su comprensión del código base se vea mermada. Si un ingeniero no puede explicar completamente por qué un fragmento de código funciona o es seguro, la organización ya ha perdido una capa de control.

La validación no es lo mismo que la detección. La responsabilidad no es lo mismo que la automatización. La IA puede ayudar, pero no puede asumir responsabilidades (y hasta la fecha no existe ninguna legislación que exima a los seres humanos de las consecuencias de las acciones indebidas de la IA).

La supervisión humana no es un concepto obsoleto. En un entorno de desarrollo impulsado por la IA, es la principal garantía que asegura que el código que entra en el ciclo de vida del desarrollo de software ha sido revisado, comprendido y aprobado conscientemente. Sin ese nivel de juicio, la velocidad se convierte en exposición.

La educación debe ser la base para una adopción segura de la IA.

En este contexto, la formación en codificación segura pasa de ser algo deseable a convertirse en un control empresarial fundamental. Los «desarrolladores» evolucionarán de operadores a coordinadores, y la formación pasará de centrarse en el desarrollo de código seguro a evaluar la seguridad del código generado por la IA.

Las habilidades necesarias para validar el código generado por IA, anticipar clases emergentes de vulnerabilidad de IA, como la inyección de comandos, y comprender cómo los patrones de IA interactúan con su arquitectura no se pueden aprender a través de módulos de cumplimiento episódicos. Deben ser continuas, prácticas, estar integradas en los flujos de trabajo existentes y ser medibles en función de los resultados de riesgo reales. 

Gobernanza del software de IA: la capa de control que nos falta

Muchos programas de seguridad siguen tratando la seguridad de las aplicaciones como una función secundaria. En un entorno impulsado por la IA, ese modelo deja de tener el mismo impacto en la reducción de riesgos. Lo que se necesita es una gobernanza del software de IA: un verdadero plano de control empresarial para un ciclo de vida de desarrollo de software impulsado por la IA. Esta disciplina abarca el ciclo de vida del desarrollo de software impulsado por la IA y establece una supervisión estructurada de la creación, revisión y aprobación del código.

Eso incluye:

• Visibilidad del uso de herramientas de IA en todos los equipos
• Atribución clara del código generado por IA dentro del SDLC
• Correlación entre los cambios en el código y las señales de riesgo y los requisitos normativos
• Aplicación de normas de codificación segura en los flujos de trabajo de los desarrolladores.
• Mejora continua de las habilidades y capacidad cuantificable de codificación segura.
• Reducción demostrable del riesgo de seguridad antes de que el código llegue a producción.

La gobernanza es lo que une la detección y la decisión, asegurando que las ganancias en productividad no se logren a costa de la responsabilidad.

La IA seguirá transformando la forma en que se crea el software, y abandonarla no es ni realista ni deseable. Al fin y al cabo, las ganancias en productividad e innovación son demasiado significativas. Sin embargo, trabajar para extraer valor de forma segura requiere una supervisión disciplinada y una validación humana intencionada, y esta infraestructura tampoco puede precipitarse ni ignorarse.