El proveedor entregó el módulo de cotizaciones dos semanas antes de lo previsto. En la reunión de cierre, alguien de tu equipo pregunta de pasada cuánto de ese código escribió una IA. Nadie sabe bien. Tampoco sabe nadie si alguna de las 40 dependencias nuevas viene con una licencia que obligue a publicar el código, ni de quién es el sistema si mañana cambias de proveedor.
El desarrollo de software con inteligencia artificial ya es lo normal en casi cualquier equipo, y eso está bien: se avanza más rápido en lo repetitivo. El problema es que el código generado por IA trae riesgos que no aparecen en la demo. Puede traer vulnerabilidades conocidas, dependencias que nadie eligió a conciencia, fragmentos parecidos a código con licencia y dudas sobre la propiedad intelectual. Si quieres el panorama general de qué hace la IA dentro de un equipo, lo contamos en Desarrollo de software con inteligencia artificial hoy. Aquí vamos a lo que conviene controlar cuando ese código termina en un sistema tuyo.
El código compila, pero eso no dice nada de su seguridad
Veracode publicó en marzo de 2026 una actualización de su estudio sobre seguridad del código generado por IA. Llevan más de 150 modelos evaluados con las mismas 80 tareas de programación, y los resultados casi no se han movido en dos años:
- Más del 95% del código generado es sintácticamente correcto.
- Solo alrededor del 55% pasa las pruebas de seguridad. En el 45% restante, el modelo introdujo una vulnerabilidad conocida cuando nadie le pidió explícitamente que cuidara la seguridad.
- Hay diferencias grandes por lenguaje. Python anda cerca de 62% y Java apenas en 29%.
- Los modelos se defienden bien contra inyección SQL, pero fallan en la gran mayoría de los casos de cross-site scripting (15% de aprobación) y de inyección en logs (13%).
Coincide con lo que vemos en proyectos: la IA escribe código que funciona en el primer intento y que nadie cuestiona porque funciona. La revisión de seguridad no puede depender de que el modelo "se acuerde" de validar entradas.
Dependencias que no existen (todavía)
Hay un riesgo menos conocido. A veces el asistente sugiere instalar una librería que no existe. Un estudio presentado en USENIX Security 2025 analizó 576.000 muestras de código en Python y JavaScript. En promedio, los modelos comerciales inventaron al menos un 5,2% de los paquetes que recomendaban, y los de código abierto un 21,7%. En total aparecieron 205.474 nombres de paquetes inventados distintos.
El problema aparece cuando un atacante registra ese nombre inventado en npm o PyPI con código malicioso adentro. A esa técnica se le conoce como slopsquatting. Si el desarrollador copia la instrucción de instalación sin mirar, el paquete malicioso entra al proyecto.
La defensa es aburrida y funciona. Cada dependencia nueva se revisa antes de entrar: si existe hace tiempo, quién la mantiene, cuántas descargas tiene y qué licencia trae. Y el proyecto debe tener un archivo de bloqueo de versiones (package-lock, poetry.lock o equivalente) versionado en el repositorio.
Licencias de código abierto: el fragmento que se parece demasiado
Un modelo entrenado con código público puede devolver un bloque casi idéntico a uno que existe en un repositorio con licencia GPL o similar. Si ese bloque termina en tu sistema, podrías quedar con obligaciones de licencia que nadie revisó.
Las herramientas empresariales ya tienen controles para esto. GitHub Copilot, por ejemplo, tiene una política llamada "Suggestions matching public code" que la organización puede configurar para bloquear o permitir esas sugerencias, y una función de code referencing que muestra de qué repositorio viene el código coincidente y qué licencia aplica. Ojo con un detalle: según el anuncio de GitHub de febrero de 2026, el agente de código de Copilot no respeta el modo de bloqueo. Las coincidencias quedan marcadas en el registro de la sesión, pero no se bloquean. Si tu proveedor trabaja con agentes, alguien tiene que leer esos registros.
Hay otra pregunta que vale la pena hacer: ¿el equipo usa planes empresariales con estas políticas activadas o cuentas personales? Con cuentas personales, la empresa no controla nada de lo anterior.
¿De quién es el código que escribió la IA?
Aquí hay más zonas grises de las que nos gustaría, así que conviene separar lo que está claro de lo que no.
Lo claro, en Chile: la Ley 17.336 de propiedad intelectual protege los programas computacionales. Su artículo 8 dice que, si un programa se produce por encargo de un tercero, los derechos se entienden cedidos a ese tercero, "salvo estipulación escrita en contrario". O sea, el contrato manda. Si el contrato dice otra cosa, el código puede no ser tuyo aunque lo hayas pagado.
Lo que no está claro: la ley chilena no dice nada específico sobre obras generadas por IA. Como referencia, la Oficina de Derechos de Autor de Estados Unidos concluyó en su informe de enero de 2025 que el contenido generado por IA solo se protege cuando un humano determinó suficientes elementos expresivos, y que escribir un prompt no alcanza. Usar IA como apoyo dentro de una obra humana más grande no impide la protección. Esa es la postura de Estados Unidos, no la ley chilena, pero muestra hacia dónde va la discusión.
Con eso en mente, en un contrato de desarrollo a medida revisaríamos estos puntos (no es asesoría legal; para la redacción final, consulta con tu abogado):
| Cláusula | Qué debería decir |
|---|---|
| Titularidad | Que el código fuente, la documentación y las pruebas son del cliente, incluido lo escrito con asistencia de IA |
| Uso de IA | Qué herramientas usa el proveedor, con qué tipo de cuenta y bajo qué condiciones de datos |
| Licencias de terceros | Un inventario de dependencias y sus licencias como parte del entregable |
| Revisión | Que todo el código, generado o no, pasa por revisión humana antes de integrarse |
| Confidencialidad | Que no se pegan datos personales, credenciales ni código sensible en herramientas sin acuerdo empresarial |
| Entrega | Repositorio completo, con historial, a nombre del cliente al cerrar el proyecto |
Cómo se controla en el día a día
Ninguna de estas medidas es nueva. Lo que cambió es el volumen: cuando la IA escribe más código por día, la revisión manual sola no alcanza y hay que automatizar los controles.
- Revisión humana en cada pull request, con un responsable con nombre. El pull request debe indicar si hubo código generado.
- Análisis estático de seguridad (SAST) corriendo en el pipeline de CI/CD, no solo antes del pase a producción.
- Análisis de composición de software (SCA) para detectar dependencias con vulnerabilidades o licencias problemáticas.
- Escaneo de secretos, porque un asistente puede dejar una clave de API pegada en el código sin que nadie lo note.
- Pruebas automatizadas de las reglas de negocio. Las revisamos en detalle en Pruebas de software automatizadas con IA: qué sí funciona.
- Una política escrita de uso de IA para el equipo: qué herramientas, con qué cuentas y qué información nunca se pega en un prompt.
Si el proveedor tiene todo esto conectado al pipeline, la pregunta de cuánto código escribió la IA pierde importancia. Lo que te interesa es que todo el código haya pasado por los mismos controles, venga de donde venga.
Preguntas frecuentes
¿El código generado por IA es menos seguro que el escrito por personas?
No necesariamente, pero sí repite fallas conocidas con frecuencia. Según Veracode, cerca del 45% de las muestras generadas sin instrucciones de seguridad traía una vulnerabilidad. Revisión humana y análisis automático en el pipeline son lo que hace la diferencia.
¿Puedo prohibirle a mi proveedor que use IA?
Puedes, pero perderías parte de la velocidad que hoy entrega. Suele dar mejor resultado exigir transparencia: qué herramientas usa, con qué cuentas, y que todo el código pase por los mismos controles de revisión y seguridad.
Si la IA escribió parte del código, ¿sigue siendo mío?
En Chile, el software hecho por encargo se entiende cedido al cliente salvo que el contrato diga otra cosa. Como la ley no regula específicamente lo generado por IA, conviene que el contrato diga de forma expresa que todo el código es tuyo.
Desarrollo con IA, con controles desde el primer commit
En Disrupsoft desarrollamos aplicaciones web y móviles a medida, con GitHub y CI/CD como parte del trabajo diario. Si estás evaluando un proyecto y quieres revisar desde el inicio cómo se va a controlar el código, conversemos sobre tu desarrollo a medida.
