La adopción de la IA en los equipos de ingeniería es ahora una práctica habitual. McKinsey (2025) informa de que el 88 % de las organizaciones utilizan la IA en al menos una función empresarial. En el propio desarrollo de software, su uso sigue creciendo a medida que las empresas integran asistentes de codificación y agentes automatizados en sus procesos.
Mientras tanto, el informe WEF Global Cybersecurity Outlook 2025 señala un fuerte aumento de la explotación de la cadena de suministro de software, impulsado por la complejidad de las dependencias, la opacidad de los componentes generados por IA y la visibilidad limitada de cómo los sistemas modernos ensamblan los artefactos finales. Los responsables de seguridad identifican el compromiso de la cadena de suministro como uno de los riesgos más difíciles de contener, ya que el desarrollo asistido por IA aumenta el volumen de código y configuraciones que entran en producción sin mejoras proporcionales en la gobernanza.
A partir de nuestra experiencia práctica, examinaremos la seguridad del desarrollo aumentada por la IA desde la perspectiva de los profesionales que se enfrentan activamente a estos retos. Demostraremos cómo las empresas pueden integrar de forma práctica las prácticas modernas de evaluación de riesgos en su ciclo de vida de desarrollo específico y en su proceso de selección de proveedores, centrándonos en los riesgos reales, los mitos generalizados y las expectativas de cumplimiento que configuran la estrategia de ingeniería actual.
El desarrollo aumentado por IA como nueva normalidad
Al igual que en otros segmentos, la IA también se ha convertido en una parte habitual del desarrollo de software. Ahora, la mayoría de los equipos de ingeniería confían en herramientas de IA para el andamiaje, la refactorización y la velocidad de implementación. La asistencia automatizada puede liberar hasta un día del tiempo de los desarrolladores. Sin embargo, estas ganancias no se traducen automáticamente en una entrega más rápida. La capacidad de productividad para los procesos de planificación, revisión y lanzamiento sigue siendo la misma. Aunque aumenta la producción, la IA no repara los cuellos de botella del flujo de trabajo.
Calidad de la seguridad: más código, más puntos débiles
A medida que crece el uso de la IA, los problemas de seguridad habituales adoptan nuevas formas. El código generado tiende a seguir patrones comunes en los datos de entrenamiento, lo que significa que puede reproducir debilidades sutiles. Por lo general, estas se manifiestan como:
- validación insuficiente de las entradas
- configuraciones predeterminadas inseguras
- lógica de gestión de errores débil
- flujos de serialización o deserialización inseguros
Individualmente, estos problemas pueden parecer pequeños. A gran escala, se convierten en vulnerabilidades significativas, especialmente cuando los desarrolladores confían en sugerencias aparentemente pulidas. Este volumen cada vez mayor de cambios creados por máquinas aumenta los riesgos de seguridad de la IA en partes del código base que los equipos no esperan revisar detenidamente.
Expansión de la cadena de suministro a través de la automatización
Las herramientas de IA ahora influyen en áreas que van mucho más allá de simples fragmentos de código, lo que afecta a las opciones de dependencia, las plantillas de configuración y los procesos de compilación. Sin embargo, dado que la IA aprende de los datos producidos por humanos, inevitablemente refleja los errores humanos, algo que vemos con frecuencia en nuestras revisiones de código profesionales.
Por ejemplo, al auditar Project Science (una plataforma de gestión de presupuestos para proyectos de TI), identificamos una vulnerabilidad de seguridad crítica: los datos confidenciales se almacenaban en una carpeta de acceso público. A pesar del uso de herramientas automatizadas, la IA no detectó este riesgo.
Esto ilustra una preocupación creciente en la cadena de suministro de software. Las sugerencias automatizadas pueden introducir silenciosamente:
- archivos de configuración que nadie ha editado manualmente
- pasos de CI/CD modificados
- valores predeterminados permisivos elegidos por comodidad
Cada inserción automatizada añade nuevos puntos que hay que rastrear para garantizar el cumplimiento de la IA y la integridad de la cadena de suministro.
Cinco mitos que frenan el uso seguro de la IA
Los equipos que adoptan la IA suelen dar por sentado que la automatización puede incorporarse a los hábitos de desarrollo existentes sin cambiar su enfoque respecto al riesgo, la gobernanza o la calidad del código. Esa suposición es precisamente lo que expone a las empresas a los costes ocultos de una mala integración de la IA, problemas que permanecen invisibles hasta que ralentizan la entrega, complican las auditorías o crean oportunidades para los atacantes. Tras revisar y resolver problemas en entornos de desarrollo de software mejorados con IA en diferentes productos, estas son las cinco ideas erróneas que con mayor frecuencia causan problemas a los equipos.
Mito 1: La IA escribe código seguro
La IA genera código que funciona, pero no código que resista la presión. En la práctica, los asistentes suelen reproducir las soluciones más «comunes» desde el punto de vista estadístico, muchas de las cuales contienen debilidades sutiles. He visto cómo los controladores generados superaban las revisiones de seguridad porque parecían pulidos, pero en realidad omitían silenciosamente la validación adecuada o se basaban en valores predeterminados permisivos. Se trata de pequeñas grietas que se amplían con la escala y socavan la seguridad del software de IA cuando no se controlan.
Mito 2: Nuestros escáneres lo detectarán
Los escáneres tradicionales se especializan en patrones conocidos, incompatibilidades de dependencias y fallos basados en firmas. Lo que no detectan es la tendencia de la IA a alterar la forma del propio sistema. En varios proyectos de clientes, los escáneres rutinarios pasaron sin problemas, mientras que un paso de compilación sugerido por la IA descargó un binario no verificado, que las herramientas de seguridad nunca detectaron porque se encontraba fuera de la ruta de código que examinaban. Estas lagunas se vuelven especialmente peligrosas cuando la IA influye en configuraciones, canalizaciones o reglas de automatización que nadie ha tocado manualmente.
Mito 3: SBOM significa que nuestra cadena de suministro es segura
Una lista de materiales de software estándar (SBOM) recoge bibliotecas, paquetes y versiones. Pero, como hemos aprendido por experiencia, no revela casi nada sobre cómo se generó o transformó el código mediante la automatización. Hemos auditado sistemas en los que la SBOM enumeraba tres dependencias, mientras que la plantilla de implementación generada incorporaba dos más durante el tiempo de ejecución. Sin un registro paralelo que describa el modelo, la configuración de generación y los artefactos derivados de la IA, los equipos de cumplimiento normativo terminan teniendo una visión incompleta de cómo se ensambla realmente el software.
Mito 4: El proveedor de LLM se encarga del cumplimiento normativo
Las certificaciones de los proveedores no se extienden al uso diario del modelo por parte de su equipo. Los resultados seguros dependen de sus propias indicaciones, pasos de revisión y controles de acceso. Puede utilizar un LLM empresarial totalmente certificado, pero filtrar reglas comerciales confidenciales en los registros de indicaciones porque los controles internos no coinciden con el nivel de gobernanza del modelo. La herramienta parece cumplir con la normativa, pero el flujo de trabajo no. Aquí es donde la innovación bienintencionada se convierte en un riesgo operativo.
Mito 5: Los reguladores no examinan el código de IA
Hoy en día, los organismos reguladores tratan los artefactos generados por la IA como parte de la cadena de suministro de software. Las auditorías del ciclo de vida del desarrollo de software (SDLC) ahora incluyen cómo los equipos validan el código generado, registran el uso de los modelos y gestionan las decisiones automatizadas. Hemos guiado a empresas a través de revisiones en las que superaron sus medidas de seguridad tradicionales, pero fracasaron cuando se les pidió que mostraran cómo se rastreaban, validaban y aprobaban los cambios influenciados por la IA. La brecha comienza cuando no hay barreras operativas claras.
La nueva superficie de riesgo: cuando la IA se convierte en parte de su cadena de suministro
Una vez que la IA participa en la generación de código, deja de comportarse como un inocuo impulso a la productividad y comienza a actuar como un proveedor externo integrado en su cadena de herramientas. Aquí es donde se originan la mayoría de los riesgos del desarrollo de la IA. Los equipos que amplían sus prácticas de gobernanza a los flujos de trabajo de IA mantienen el control; los equipos que no lo hacen suelen heredar sistemas frágiles sin darse cuenta. Para que quede claro, así es como se desglosa el riesgo.
Capas de riesgo aumentado por la IA
La IA remodela la cadena de suministro de software al introducir nuevos responsables de la toma de decisiones, nuevos artefactos y nuevas vías para que los errores entren en el sistema. Cada capa introduce una forma diferente de aumentar el riesgo si no se supervisa:
- Capa de modelo: los modelos externos tienen orígenes opacos. Los sesgos ocultos, las debilidades heredadas o los pesos manipulados pueden influir en los resultados, especialmente cuando los equipos comienzan a escalar los modelos de IA sin validar su procedencia.
- Capa de datos: los datos de entrenamiento y ajuste pueden contener ejemplos defectuosos o manipulados. Estos patrones resurgen en el código generado, lo que refuta los mitos comunes sobre la seguridad de la IA de que «los mejores modelos significan automáticamente resultados más seguros».
- Capa de solicitud/uso: los desarrolladores suelen pegar lógica sensible en las herramientas o dirigir involuntariamente los modelos hacia valores predeterminados inseguros. Los hábitos de uso cotidianos se convierten en una exposición a largo plazo.
- Capa de canalización: las sugerencias de IA modifican los pasos, scripts o permisos de CI/CD. Pequeños cambios automatizados «por comodidad» alteran el comportamiento del sistema de formas que los escáneres rara vez detectan.
- Capa de artefactos: algunos problemas solo aparecen en la aplicación compilada, como configuraciones generadas, rutinas de inicio o plantillas de implementación que nunca han sido revisadas por humanos.
Solo humanos frente a IA aumentada
A medida que la IA se convierte en parte de la cadena de herramientas, el modelo de amenazas pasa de ser lineal e impulsado por humanos a ser por capas y parcialmente opaco. El contraste se hace evidente cuando se compara un flujo de trabajo de desarrollo tradicional con uno moldeado por la participación de la IA:
Quién escribe el código
Desarrolladores empleados
Desarrolladores + LLM externos
Riesgo principal de la cadena de suministro
Bibliotecas de terceros
Bibliotecas + modelos + indicaciones + configuraciones sugeridas por IA
Visibilidad
SBOM captura los componentes principales
Las SBOM a menudo omiten los resultados de la IA y el linaje de los modelos
Enfoque de la revisión
Revisión manual y pruebas
Revisión + gobernanza de herramientas, modelos y flujos de trabajo
La IA cambia no solo lo que entra en el sistema, sino también cómo evoluciona, lo que hace que la supervisión proactiva sea esencial a medida que los proyectos crecen.
El cumplimiento normativo y las reglas ya están remodelando la IA en el desarrollo de software
Los reguladores ahora tratan la IA como parte de la cadena de suministro de software, no como un experimento periférico. Hoy en día, varios marcos ya influyen en la forma en que los equipos diseñan y validan los sistemas que se basan en la generación de código. La Ley de IA de la UE exige controles basados en el riesgo, documentación del comportamiento de los modelos y trazabilidad de las decisiones automatizadas, mientras que el Marco de Gestión de Riesgos de IA del NIST establece expectativas en torno a la gobernanza, la supervisión y el uso responsable de los modelos. Los organismos nacionales de ciberseguridad, como la CISA en Estados Unidos, amplían estos principios a la integridad de la cadena de suministro de software y a las superficies de ataque habilitadas por la IA.
En los tres casos, el mensaje es coherente: trazabilidad y control. Los equipos deben mostrar dónde se utiliza la IA, cómo se revisan los cambios generados por la IA y cómo se aplica la protección de datos a lo largo del ciclo de vida del desarrollo. Los registros de auditoría, la procedencia de los modelos y las SBOM ampliadas son ahora señales fundamentales de un desarrollo seguro aumentado por la IA, en consonancia directa con las expectativas de los compradores empresariales.
Estos marcos también requieren que la IA se incluya en los modelos de amenazas modernos. Dado que los modelos influyen en las dependencias, las rutas lógicas y los flujos de trabajo automatizados, los reguladores los consideran parte de la superficie de ataque en lugar de herramientas. Para cualquier organización que preste servicios de desarrollo de inteligencia artificial, la alineación con estas normas reguladoras en evolución es una prueba de madurez técnica.
Esta claridad reguladora crea una ventaja: los equipos que ponen en práctica estos requisitos desde el principio crean productos listos para ser examinados y adoptados por las empresas.
Desarrollo seguro aumentado por IA en la práctica
Los fundadores que adoptan el desarrollo de software asistido por IA a menudo se preguntan cómo es realmente la «seguridad» cuando la IA se convierte en parte del proceso de entrega. En la práctica, se trata de establecer las barreras de protección adecuadas para que la IA acelere el progreso sin introducir responsabilidades silenciosas. Los equipos de ingeniería maduros gestionan esto mediante un pequeño conjunto de patrones repetibles que protegen el negocio, no solo el código.
- Reglas de uso de la IA definidas: los límites claros sobre dónde se permite la IA en el producto garantizan que la lógica sensible, las ideas propias y los datos de los clientes nunca terminen en sistemas no gestionados. Esto significa que su aplicación aumentada con IA crece de forma segura sin correr el riesgo de exponer la propiedad intelectual o incurrir en incumplimientos normativos.
- Flujo de aprobación basado en el impacto: no todos los cambios generados por la IA conllevan el mismo riesgo. La lógica de alto impacto, como la autenticación, los pagos y las reglas de flujo de trabajo, requiere validación humana, mientras que los andamios rutinarios se mueven más rápido. Esto mantiene la velocidad alta al tiempo que protege las partes del producto que determinan la confianza y los ingresos.
- Trazabilidad de modelos y artefactos: cada vez más empresas esperan visibilidad sobre el origen de los modelos, los archivos generados y las dependencias automatizadas. El seguimiento de estos componentes dentro de flujos de trabajo seguros demuestra que el enfoque profesional reduce la posibilidad de sorpresas en la cadena de suministro.
- Validación de la compilación final: los incidentes del mundo real se derivan cada vez más de lo que se incluye en el artefacto compilado. El escaneo de contenedores y compilaciones empaquetadas detecta archivos ocultos o comportamientos que la IA puede introducir. Esto minimiza el riesgo operativo de problemas inesperados en tiempo de ejecución.
- Preparación del equipo para los patrones de IA: Las empresas que se adelantan forman a sus desarrolladores para que comprendan cómo se comporta la IA, cuándo confiar en ella y cuándo ignorarla. Esta disciplina cultural refleja las mejores prácticas y demuestra un enfoque responsable de la adopción de la IA.
Estas capacidades son las que aporta un socio de ingeniería sólido desde el primer día. Permiten que la IA acelere el desarrollo sin comprometer la seguridad, el cumplimiento normativo o la escalabilidad a largo plazo, lo que permite a los fundadores innovar con confianza mientras protegen el negocio.
La seguridad diseñada gana
El desarrollo aumentado por IA ofrece una ventaja inmensa, y sus decisiones en materia de gobernanza, flujos de trabajo y socios de ingeniería determinan si se convierte en una ventaja competitiva o en una responsabilidad cada vez mayor. Los riesgos son reales, desde código generado defectuoso hasta exposición de la cadena de suministro, y los mitos de que «las herramientas lo detectarán todo» o «el proveedor cumple con la normativa, por lo que estamos cubiertos» siguen siendo algunas de las suposiciones más perjudiciales en equipos que se mueven rápidamente.
La buena noticia es que la adopción segura de la IA es totalmente factible. Cuando los fundadores tratan la IA como parte de su cadena de suministro, incorporan medidas de protección en sus procesos y trabajan con socios que entienden tanto de software como de seguridad, posicionan sus productos para una incorporación más fluida a la empresa y una mayor confianza de los inversores.
¿Está listo para crear con confianza en lugar de con conjeturas? Póngase en contacto con nosotros hoy mismo para ver cómo nuestro equipo puede ofrecerle un desarrollo seguro e impulsado por la IA adaptado a su negocio.
Descubra cómo ayudamos a una plataforma de gestión de presupuestos a reforzar su arquitectura backend, eliminar fallos de seguridad críticos y preparar su código base para un crecimiento escalable
