Cómo proteger código generado por IA antes de publicarlo

Crear una aplicación utilizando ChatGPT, Claude, Gemini, Copilot u otros asistentes de inteligencia artificial nunca había sido tan fácil. Una persona puede describir lo que necesita, copiar algunos fragmentos de código y disponer en pocas horas de una página web, una API, un panel administrativo o incluso un sistema completo conectado a una base de datos.

El problema aparece cuando esa aplicación pasa de funcionar en una computadora local a estar disponible en Internet. Que el código funcione no significa que sea seguro. Una aplicación generada con IA puede contener contraseñas expuestas, consultas SQL inseguras, permisos excesivos, dependencias vulnerables o paneles administrativos accesibles para cualquiera.

Los asistentes de inteligencia artificial son extraordinariamente útiles para acelerar el desarrollo, pero no sustituyen una revisión de seguridad. Incluso un código perfectamente estructurado y aparentemente profesional puede incorporar errores que solo aparecen cuando un atacante comienza a probar entradas inesperadas, modificar parámetros o buscar credenciales olvidadas.

Por eso, antes de publicar una aplicación creada total o parcialmente mediante IA conviene pasar por un checklist mínimo de seguridad.

Puede leer también | Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos

El error más peligroso: confiar en el código porque funciona

Imagine que pide a un asistente:

“Crea un sistema de usuarios con login, base de datos MySQL y un panel administrativo”.

En pocos segundos puede recibir cientos de líneas de código aparentemente completas.

El formulario funciona. El usuario inicia sesión. La base de datos almacena la información. El panel muestra correctamente los registros.

Pero todavía quedan muchas preguntas:

• ¿Las contraseñas están correctamente protegidas?
• ¿Las consultas a la base de datos pueden sufrir una inyección SQL?
• ¿Un usuario normal puede acceder al panel administrativo cambiando una URL?
• ¿Existe una API key escrita directamente dentro del código?
• ¿Las dependencias utilizadas tienen vulnerabilidades conocidas?
• ¿Se validan realmente los archivos que puede subir un usuario?
• ¿Los mensajes de error revelan información interna?

Una aplicación puede aprobar todas las pruebas funcionales y fallar completamente desde el punto de vista de la seguridad.

Checklist rápido antes de publicar una aplicación creada con IA

Control	Qué verificar
1. Secretos	No existen API keys, contraseñas o tokens dentro del código.
2. Autenticación	Las contraseñas se almacenan con algoritmos adecuados y las sesiones están protegidas.
3. Autorización	Cada usuario solo puede acceder a los recursos que realmente le corresponden.
4. Entradas	Los datos recibidos se validan siempre en el servidor.
5. Base de datos	Las consultas utilizan parámetros y nunca concatenan directamente entradas del usuario.
6. Dependencias	Las librerías están actualizadas y sin vulnerabilidades críticas conocidas.
7. Archivos	Las cargas tienen restricciones de tipo, tamaño, ubicación y nombre.
8. Configuración	Debug está deshabilitado y no se muestran errores internos.
9. HTTPS	Todo el tráfico sensible utiliza conexiones cifradas.
10. API	Existe autenticación, límites de uso y validación de solicitudes.
11. Logs	Se registran eventos relevantes sin almacenar contraseñas o tokens.
12. Infraestructura	Servidor, contenedores y servicios tienen únicamente los permisos necesarios.
13. Copias de seguridad	Existe respaldo probado de la información crítica.
14. Escaneo	El código pasa por herramientas automáticas de seguridad.
15. Revisión humana	Alguien comprende y revisa el código antes del despliegue.

1. Busca contraseñas y API keys antes de hacer público el repositorio

Este es probablemente uno de los errores más comunes cuando se programa rápidamente con inteligencia artificial.

Durante las pruebas resulta tentador escribir directamente una clave dentro del programa:

API_KEY = "mi-clave-secreta"

Puede funcionar perfectamente en desarrollo, pero nunca debería llegar así a un repositorio público ni a una aplicación distribuida.

También deben buscarse:

• Contraseñas de bases de datos.
• Tokens de GitHub o GitLab.
• Credenciales AWS, Google Cloud o Azure.
• Claves privadas SSH.
• Tokens de Telegram, Slack o Discord.
• Credenciales SMTP.
• Claves de Stripe, PayPal u otras plataformas de pago.
• Tokens de OpenAI, Anthropic, Google u otros servicios de IA.

Los secretos deberían almacenarse mediante variables de entorno o sistemas específicos de gestión de secretos.

Herramientas como GitHub Secret Scanning pueden detectar determinados secretos incluidos accidentalmente en repositorios, mientras que la función Push Protection puede bloquear algunos de ellos antes de que sean enviados al repositorio.

2. Si una clave ya llegó a GitHub, borrarla del archivo no es suficiente

Este punto es especialmente importante.

Si una API key, contraseña o token fue publicado en un repositorio, debe considerarse potencialmente comprometido.

No basta con modificar el archivo y realizar otro commit.

La credencial podría permanecer dentro del historial de Git o haber sido copiada anteriormente.

La acción correcta normalmente consiste en:

1. Revocar la credencial expuesta.
2. Generar una nueva.
3. Actualizar la aplicación.
4. Eliminar el secreto del repositorio y, cuando corresponda, de su historial.
5. Investigar si la credencial fue utilizada de forma no autorizada.

3. Revisa cómo se almacenan las contraseñas

Una aplicación nunca debería guardar contraseñas de usuarios en texto plano.

Tampoco deberían protegerse simplemente utilizando algoritmos criptográficos generales como una implementación directa de SHA-256.

Para contraseñas se utilizan funciones específicamente diseñadas para este propósito, como Argon2id, bcrypt o scrypt, utilizando configuraciones apropiadas.

Si el asistente de IA creó manualmente una función de cifrado de contraseñas, conviene revisarla con especial atención.

En seguridad existe una regla práctica muy útil: no inventar criptografía propia cuando existen bibliotecas ampliamente revisadas para resolver el problema.

4. Comprueba la autorización, no solamente el login

Autenticación y autorización no son lo mismo.

La autenticación responde:

¿Quién eres?

La autorización responde:

¿Qué tienes permiso para hacer?

Una aplicación puede tener un excelente formulario de login y continuar siendo insegura si cualquier usuario autenticado puede modificar la URL y acceder a información de otras personas.

Por ejemplo:

/facturas/1001
/facturas/1002
/facturas/1003

Si un usuario puede cambiar el número y visualizar una factura que pertenece a otra persona, existe un problema de control de acceso.

Por ello, el servidor debe verificar permisos en cada recurso sensible, independientemente de lo que muestre la interfaz.

5. Nunca confíes en la validación realizada solamente en JavaScript

Un asistente de IA puede crear un formulario con excelentes validaciones en el navegador.

Pero esas validaciones pueden ser modificadas o evitadas.

Todo dato recibido desde el exterior debe considerarse potencialmente no confiable.

Esto incluye:

• Campos de formularios.
• Parámetros de una URL.
• Cabeceras HTTP.
• Cookies.
• Archivos.
• JSON enviado a una API.
• Datos procedentes de servicios externos.

La validación importante debe realizarse siempre también en el servidor.

6. Revisa las consultas SQL generadas por la IA

Las consultas construidas mediante concatenación de cadenas son una señal de alarma.

Un patrón como este debe revisarse:

SELECT * FROM usuarios WHERE email = ' + email_usuario

La alternativa correcta consiste normalmente en utilizar consultas parametrizadas, prepared statements u ORM correctamente configurados.

La inyección sigue siendo uno de los riesgos clásicos de las aplicaciones web y continúa apareciendo cuando datos controlados por usuarios son interpretados como instrucciones.

7. No instales automáticamente todas las librerías que sugiera la IA

Los asistentes pueden generar rápidamente archivos como:

• package.json
• requirements.txt
• pom.xml
• composer.json
• Cargo.toml

Pero cada dependencia adicional introduce software que también deberá mantenerse.

Antes de desplegar conviene revisar:

• Si el paquete realmente existe.
• Quién lo mantiene.
• Cuándo fue actualizado.
• Si posee vulnerabilidades conocidas.
• Si realmente es necesario.
• Qué dependencias adicionales instala.

La seguridad de la cadena de suministro de software se ha convertido en un problema especialmente importante porque una aplicación puede ser segura y, aun así, incorporar una dependencia comprometida o vulnerable.

8. Escanea automáticamente las dependencias

No resulta práctico revisar manualmente cientos de paquetes.

Existen herramientas que permiten automatizar parte del proceso.

Dependiendo de la tecnología utilizada pueden emplearse opciones como:

• npm audit para proyectos Node.js.
• pip-audit para proyectos Python.
• OSV-Scanner para detectar vulnerabilidades conocidas en dependencias.
• Trivy para analizar repositorios, imágenes de contenedores, vulnerabilidades, secretos y configuraciones.

Lo importante no es utilizar una herramienta específica, sino incorporar el análisis de dependencias dentro del proceso habitual de desarrollo.

9. Protege correctamente la carga de archivos

Las aplicaciones creadas con IA frecuentemente incorporan funciones para subir imágenes, PDF, documentos o archivos CSV.

Una implementación insegura podría permitir subir archivos ejecutables o colocar contenido malicioso directamente dentro de una carpeta accesible desde Internet.

Debe controlarse como mínimo:

• Tipo permitido.
• Tamaño máximo.
• Extensión.
• Contenido real del archivo cuando sea necesario.
• Nombre generado por el servidor.
• Ubicación donde será almacenado.
• Permisos del archivo.

No debe asumirse que un archivo es una imagen únicamente porque termine en .jpg.

Puede leer también | Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers

10. Desactiva el modo debug antes de publicar

Durante el desarrollo es útil disponer de mensajes detallados.

En producción pueden convertirse en una fuga de información.

Una página de error mal configurada puede revelar:

• Rutas internas del servidor.
• Consultas SQL.
• Nombres de tablas.
• Versiones de frameworks.
• Variables de entorno.
• Fragmentos de código.
• Direcciones internas.

Antes del despliegue debe comprobarse que la aplicación utiliza una configuración específica para producción y que los errores detallados quedan registrados internamente, pero no son mostrados al visitante.

11. Protege las APIs que la IA creó automáticamente

Otro problema frecuente aparece cuando el asistente genera rápidamente endpoints como:

GET /api/users
POST /api/users
DELETE /api/users/25

El hecho de que funcionen no significa que deban estar disponibles para cualquier visitante.

Cada API debería revisar:

• Autenticación.
• Autorización.
• Validación de datos.
• Límites de solicitudes.
• Tamaño máximo de entradas.
• Registro de operaciones sensibles.
• Protección frente a automatización abusiva cuando corresponda.

Una interfaz web puede ocultar un botón de eliminación, pero eso no protege el endpoint que existe detrás de ese botón.

12. Aplica el principio de mínimo privilegio

La aplicación no debería tener más permisos de los que necesita.

Esto es válido para:

• Usuarios de bases de datos.
• Contenedores.
• Servicios cloud.
• API keys.
• Usuarios Linux.
• Acceso a archivos.
• Agentes de inteligencia artificial.

Si una aplicación únicamente necesita leer determinados datos, no debería utilizar una cuenta con privilegios para eliminar toda la base de datos.

Este principio es todavía más importante cuando la propia aplicación incorpora agentes de IA capaces de utilizar herramientas, consultar documentos o ejecutar acciones.

13. Si tu aplicación utiliza IA, también debes proteger el modelo

Cuando ChatGPT, Claude u otro modelo no solo ayudó a escribir el código sino que además forma parte de la aplicación final, aparecen riesgos adicionales.

Entre ellos se encuentran:

• Prompt injection: entradas diseñadas para alterar el comportamiento esperado del modelo.
• Exposición de datos sensibles: información confidencial enviada o devuelta accidentalmente.
• Manejo inseguro de respuestas: utilizar directamente la salida del modelo como SQL, HTML, comandos o instrucciones ejecutables.
• Permisos excesivos: agentes capaces de ejecutar más acciones de las necesarias.
• Contenido externo no confiable: páginas o documentos que intentan manipular al modelo.

Una regla especialmente importante es no tratar la respuesta de una IA como si fuera automáticamente confiable.

Si el modelo devuelve información que posteriormente será utilizada por una base de datos, una API, un navegador o un sistema operativo, debe aplicarse validación antes de ejecutar cualquier acción.

14. Cuidado con los agentes que pueden borrar, enviar o modificar datos

Los nuevos asistentes pueden conectarse a correo electrónico, bases de datos, repositorios, sistemas empresariales y otras herramientas.

Esto aumenta considerablemente su utilidad, pero también sus riesgos.

Un agente diseñado únicamente para consultar pedidos probablemente no necesite capacidad para eliminarlos.

Cuando exista una operación crítica —por ejemplo borrar información, efectuar un pago, publicar contenido o enviar un mensaje— resulta recomendable exigir una autorización adicional o intervención humana.

Cuanto mayor sea la consecuencia de una acción, menor debería ser la autonomía concedida al modelo.

15. Ejecuta un análisis automático del proyecto completo

Antes del despliegue puede resultar útil combinar varias técnicas.

Por ejemplo:

• SAST: análisis estático del código.
• SCA: análisis de dependencias y componentes.
• Secret scanning: búsqueda de claves y credenciales.
• Container scanning: revisión de imágenes Docker.
• IaC scanning: revisión de configuraciones Docker, Kubernetes o Terraform.

Herramientas open source como Trivy pueden analizar proyectos, dependencias, secretos y determinadas configuraciones desde una misma plataforma.

Esto no sustituye una auditoría, pero permite detectar una cantidad importante de problemas antes de publicar.

16. Prueba qué ocurre cuando el usuario hace exactamente lo contrario de lo esperado

Los desarrolladores normalmente prueban el camino correcto:

Usuario introduce email → contraseña → pulsa entrar → sistema responde correctamente.

Una revisión de seguridad necesita pensar también en escenarios diferentes.

• ¿Qué ocurre si el campo recibe 100.000 caracteres?
• ¿Qué pasa si falta un parámetro?
• ¿Puede utilizarse un ID negativo?
• ¿Qué sucede si un usuario intenta acceder al registro de otra persona?
• ¿Qué pasa si una API recibe solicitudes repetidas rápidamente?
• ¿Qué ocurre si se modifica manualmente una cookie?

Las aplicaciones deben diseñarse esperando entradas incorrectas, inesperadas e incluso deliberadamente maliciosas.

17. No permitas que la IA sea el único revisor de su propio código

Pedir a ChatGPT o Claude:

“Revisa si el código que acabas de generar tiene vulnerabilidades”

puede resultar útil.

Pero no debería convertirse en la única revisión.

El mismo modelo puede pasar por alto errores presentes en una solución que él mismo generó.

Una estrategia más sólida combina:

• Revisión humana.
• Pruebas automatizadas.
• Análisis estático.
• Escaneo de dependencias.
• Revisión de secretos.
• Pruebas de autorización.
• Pruebas específicas de seguridad.

18. Mantén registro de qué generó la IA y qué fue revisado

Cuando un proyecto crece rápidamente mediante prompts puede resultar difícil saber por qué existe determinada función.

Conviene conservar una estructura tradicional de desarrollo:

• Control de versiones.
• Commits pequeños.
• Pull requests cuando existe un equipo.
• Pruebas automatizadas.
• Documentación de decisiones importantes.
• Revisión antes de fusionar cambios.

La inteligencia artificial debería acelerar este proceso, no eliminarlo.

Una aplicación creada en una tarde también necesita mantenimiento

Publicar la aplicación no termina el trabajo.

A partir de ese momento aparecen nuevas responsabilidades:

• Actualizar dependencias.
• Aplicar parches.
• Revisar logs.
• Renovar certificados.
• Rotar credenciales.
• Responder ante vulnerabilidades.
• Realizar copias de seguridad.
• Probar restauraciones.

Una aplicación que hoy no presenta vulnerabilidades conocidas podría utilizar mañana una biblioteca para la que se publique una falla crítica.

Por eso la seguridad debe entenderse como un proceso continuo.

Puede leer también | Las mejores herramientas de código abierto para proteger su servidor Linux

El checklist definitivo antes de pulsar “Deploy”

Antes de publicar una aplicación generada con ChatGPT, Claude, Gemini, Copilot u otro asistente, revise nuevamente:

1. No existen secretos dentro del código o del historial Git.
2. Las contraseñas de usuarios utilizan funciones de hash adecuadas.
3. El servidor verifica permisos en todos los recursos sensibles.
4. Las entradas se validan en backend.
5. Las consultas SQL están parametrizadas.
6. Las dependencias fueron escaneadas.
7. Los paquetes innecesarios fueron eliminados.
8. La carga de archivos está limitada y controlada.
9. El modo debug está deshabilitado.
10. Los mensajes de error no revelan detalles internos.
11. Las APIs tienen autenticación y autorización.
12. Los servicios funcionan con mínimo privilegio.
13. Existen logs de eventos relevantes.
14. Existe una copia de seguridad y se sabe restaurarla.
15. El repositorio fue analizado para detectar secretos.
16. El código fue sometido a análisis de seguridad.
17. Las imágenes Docker y configuraciones de infraestructura fueron revisadas.
18. Las acciones críticas realizadas por agentes de IA requieren controles adicionales.
19. Las salidas generadas por un modelo no se ejecutan automáticamente sin validación.
20. Una persona comprende y revisó el funcionamiento del sistema antes de publicarlo.

Herramientas que pueden ayudarte

Herramienta	Uso principal
OWASP	Guías, riesgos y prácticas de seguridad para aplicaciones.
Trivy	Vulnerabilidades, secretos, contenedores y configuraciones.
OSV-Scanner	Vulnerabilidades conocidas en dependencias.
GitHub Secret Scanning	Detección de credenciales expuestas.
Semgrep	Análisis estático y patrones inseguros en código.
CodeQL	Análisis de código orientado a detectar vulnerabilidades.

No es necesario utilizar todas las herramientas disponibles. Lo importante es que la publicación de una aplicación incluya al menos una fase explícita de revisión de seguridad.

La IA escribe más rápido, pero la responsabilidad continúa siendo humana

ChatGPT, Claude y otros asistentes están cambiando profundamente la programación.

Una tarea que antes podía requerir varios días puede resolverse actualmente en horas.

Personas con poca experiencia también pueden construir prototipos que hace pocos años habrían requerido un equipo completo.

Esta democratización es positiva, pero introduce un riesgo evidente: también permite publicar aplicaciones complejas sin comprender completamente el código que las mantiene funcionando.

Por eso, una regla sencilla puede evitar muchos problemas:

nunca publiques código que no estés dispuesto a revisar, probar y mantener.

Recomendamos

• Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos
• Crea tu app sin saber programar con esta IA gratuita y fácil de usar
• Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
• ¿Por qué los desarrolladores deberían usar Linux?

En resumen

Los asistentes de inteligencia artificial pueden generar aplicaciones funcionales con una velocidad extraordinaria, pero la velocidad de desarrollo no reduce las exigencias de seguridad.

Antes de publicar una aplicación creada con IA deben revisarse secretos, autenticación, permisos, entradas, base de datos, dependencias, archivos, APIs, infraestructura y registros.

Cuando la propia aplicación utiliza un modelo de inteligencia artificial, también deben considerarse riesgos adicionales como prompt injection, exposición de información sensible, manejo inseguro de respuestas y permisos excesivos.

La mejor estrategia no consiste en desconfiar de la IA ni en evitar utilizarla, sino en integrarla dentro de un proceso de desarrollo seguro.

Conclusión editorial

La inteligencia artificial está eliminando muchas barreras para crear software, pero no está eliminando las vulnerabilidades.

ChatGPT o Claude pueden construir en minutos un sistema de autenticación, una API REST, una base de datos y una interfaz atractiva. El verdadero problema aparece cuando alguien confunde esa velocidad con seguridad.

El código generado por IA debe recibir el mismo tratamiento que cualquier código escrito por una persona: revisión, pruebas, análisis de dependencias, control de permisos y monitorización.

Incluso conviene aplicar una dosis adicional de precaución cuando el desarrollador no comprende completamente lo que el asistente produjo.

La nueva regla de la programación asistida por IA debería ser sencilla:

generar rápido, probar cuidadosamente y publicar solo después de revisar la seguridad.

Porque una aplicación creada en diez minutos puede necesitar solo unos segundos en Internet para comenzar a ser examinada por bots, scanners y atacantes.

Fuentes: OWASP Top 10:2025, OWASP Top 10 para aplicaciones LLM y GenAI, OWASP Secure Code Review Cheat Sheet, GitHub Push Protection y Trivy.

Etiquetas: inteligencia artificial, ChatGPT, Claude, programación, código generado por IA, ciberseguridad, OWASP, aplicaciones web, desarrollo seguro, seguridad de software.