Hoy cualquiera puede crear una aplicación con IA sin saber programar: se describe lo que se quiere en Lovable, Bolt, Replit, v0, Google AI Studio o un asistente como Claude o ChatGPT, y en unos minutos hay algo que funciona. A esa forma de trabajar se le llama vibe coding. El problema es que «funciona» no quiere decir «es segura»: la IA hace lo que le pides, y casi nunca le pides lo que no sabías que hacía falta. Esta guía repasa los cuidados que no te puedes saltar, qué puede salir mal en cada caso y cómo pedírselo a la propia IA.
Lo que hay detrás de una aplicación
No hace falta saber programar para entender dónde está el riesgo. Casi todas las aplicaciones tienen las mismas partes:
La clave está en la primera caja. Todo lo que llega al navegador o al teléfono del usuario, aunque no se vea en pantalla, se puede leer: basta con abrir las herramientas del navegador. Por eso la parte de la aplicación que ve el usuario, el frontend, nunca puede guardar secretos ni decidir por sí sola quién puede hacer qué. Eso le toca al servidor, el backend, o a las reglas de la base de datos. Muchas herramientas de IA crean aplicaciones en las que la pantalla habla directamente con la base de datos: funcionan, pero entonces las reglas de acceso son lo único que separa tus datos de cualquier curioso.
Los cuidados, uno por uno
1. Las claves, fuera de la vista
Tu aplicación usará servicios de fuera: un modelo de IA, un sistema de pagos, el envío de correos, un mapa. Cada uno te da una clave de API, una contraseña larga que identifica tu cuenta y que cobra a tu tarjeta. Si esa clave queda en el código que ve el usuario o se sube a un repositorio público, cualquiera puede usarla en tu nombre. No es un riesgo teórico: según el informe anual de GitGuardian, en 2025 aparecieron 28.65 millones de secretos nuevos en el código público de GitHub, y los de servicios de IA crecieron un 81 % en un año.
- Las claves van en el servidor o en las «variables de entorno» y los «secretos» que ofrece la plataforma, nunca escritas en el código de las pantallas.
- Si una clave se ha filtrado, borrarla del código no basta: hay que anularla y crear otra en el panel del servicio.
- Usa claves distintas para pruebas y para la aplicación real.
2. La base de datos, cerrada por defecto
Servicios como Supabase o Firebase, los más usados por estas herramientas, permiten que la aplicación hable directamente con la base de datos. Lo que impide que un desconocido lea todas las tablas son las reglas de acceso (en Supabase se llaman Row Level Security; en Firebase, Security Rules). Si faltan o están mal escritas, la base de datos queda abierta aunque la aplicación parezca funcionar perfectamente. Es exactamente lo que pasó con las 170 aplicaciones de Lovable.
- Comprueba en el panel de tu base de datos que las reglas están activadas en todas las tablas. Supabase y Firebase avisan cuando no lo están: no ignores esos avisos.
- Lo mismo con el almacenamiento de archivos (fotos, documentos): una carpeta pública es pública para todo internet.
3. Que cada usuario vea solo lo suyo
Iniciar sesión no basta. El fallo más común en aplicaciones hechas deprisa es que, una vez dentro, un usuario puede ver lo de otro cambiando un número: si tu cita está en una dirección que termina en /cita/1042, ¿qué pasa si alguien escribe /cita/1043? La aplicación tiene que comprobar, en el servidor o en las reglas de la base de datos, que esa cita es tuya, no solo que has iniciado sesión.
4. Inicio de sesión: no lo inventes
Las contraseñas no se guardan tal cual en la base de datos, y un sistema de inicio de sesión tiene muchos detalles fáciles de hacer mal: recuperar la contraseña, cerrar sesión, limitar los intentos. No dejes que la IA lo fabrique desde cero: pídele que use el sistema de usuarios que ya trae la plataforma (Supabase Auth, Firebase Authentication, Clerk o el de tu herramienta), que está probado por millones de aplicaciones.
5. Datos personales: los mínimos
Cada dato que guardas es un dato que se puede filtrar. Si no necesitas la fecha de nacimiento, la dirección o una foto del documento de identidad, no las pidas. Y lo que prometas borrar, bórralo: en 2025, la aplicación de citas Tea sufrió la filtración de unas 72,000 imágenes, entre ellas unas 13,000 fotos de verificación y documentos de identidad que sus usuarias habían enviado, guardadas en un almacenamiento mal configurado.
- Pide solo lo que la aplicación necesita para funcionar.
- Explica en un aviso de privacidad qué guardas, para qué y cómo pedir que se borre. En Europa lo exige el RGPD; en México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares; en casi todos los países hay una ley parecida.
- No pegues datos reales de clientes en el chat de la IA para hacer pruebas: usa datos inventados.
6. La factura: pon límites antes de publicar
Los servicios de IA, las bases de datos y el alojamiento cobran por uso. Un error que repite una llamada sin parar, un bot que llena tus formularios o una clave robada pueden convertir una aplicación de pocos dólares al mes en una factura de cientos o miles.
- Pon un límite de gasto y alertas por correo en cada servicio de pago (los de IA y las nubes lo permiten).
- Limita cuántas veces puede usar cada persona las funciones caras, como generar texto o imágenes con IA.
- Protege los formularios públicos con un captcha o algo similar.
7. Paquetes que no existen
Las aplicaciones se construyen con piezas de código de otros, los paquetes o dependencias. A veces la IA recomienda un paquete que no existe: suena razonable, pero se lo ha inventado. Un estudio presentado en la conferencia USENIX Security 2025 analizó 576,000 programas generados por 16 modelos y encontró 205,474 nombres de paquetes inventados distintos: de media, un 5.2 % de los paquetes que proponían los modelos comerciales y un 21.7 % de los abiertos. El peligro es que un atacante registre ese nombre con código malicioso y espere a que alguien lo instale. Se le llama slopsquatting.
- Antes de instalar un paquete que no conoces, búscalo en su registro oficial (npmjs.com para JavaScript, pypi.org para Python): mira si tiene años de historia, descargas y una web propia.
- Desconfía de un paquete creado hace pocos días con un nombre muy parecido a uno famoso.
- Incluso los paquetes conocidos pueden verse comprometidos, como pasó con LiteLLM en PyPI: actualiza con prudencia y activa los avisos de seguridad de tu repositorio.
8. Si tu aplicación usa IA por dentro
Muchas aplicaciones nuevas no solo están hechas con IA: también la usan, para resumir correos, responder a clientes o actuar como asistente. Entonces aparece un riesgo nuevo, la inyección de instrucciones (prompt injection), que la fundación OWASP pone en el primer puesto de su lista de riesgos de las aplicaciones con IA:
Hoy no hay una forma de evitarlo del todo, así que la defensa es limitar lo que la IA puede hacer. Un asistente que solo responde preguntas sobre tu tienda es poco peligroso; uno que puede leer el correo, borrar registros y hacer pagos necesita que una persona confirme cada acción importante.
9. Copias de seguridad y versiones
La IA a veces rompe lo que funcionaba al arreglar otra cosa, y los agentes que actúan solos pueden hacer cosas graves. En julio de 2025, el agente de Replit borró la base de datos de producción de un proyecto de Jason Lemkin, fundador de SaaStr, durante un periodo en el que había ordenado no tocar nada. Replit respondió separando automáticamente las bases de datos de desarrollo y de producción.
- Guarda una versión cada vez que algo funcione. Casi todas las herramientas lo hacen con Git o con un historial propio: aprende a volver atrás antes de necesitarlo.
- Ten dos copias de la aplicación: una de pruebas, donde la IA puede romper cosas, y la real, con los datos de verdad.
- Activa las copias de seguridad automáticas de la base de datos y comprueba alguna vez que se pueden restaurar.
- No le des a un agente permiso para tocar la base de datos real sin pedirte confirmación.
10. Probar sin saber leer el código
No necesitas entender el código para descubrir muchos fallos. Antes de publicar, haz estas pruebas:
- Dos cuentas: crea dos usuarios y comprueba que uno no puede ver nada del otro, ni siquiera cambiando números en la dirección.
- Sin sesión: cierra la sesión y pega en el navegador la dirección de una página privada. No debería dejarte entrar.
- Datos raros: escribe textos muy largos, emojis, campos vacíos o un número negativo donde va un precio.
- En el teléfono y con mala conexión: muchos fallos solo aparecen ahí.
- Una revisión de seguridad: pídele a la IA que revise la aplicación como lo haría un auditor, y usa el escáner de seguridad de tu herramienta si lo tiene. Ayuda, pero no es una garantía: la misma IA que cometió el error puede no verlo.
11. Derechos y licencias
Que la IA escriba el código no aclara de quién es. En Estados Unidos, la Oficina de Derechos de Autor concluyó en enero de 2025 que las instrucciones por sí solas no convierten al usuario en autor de lo que genera la IA: lo protegible es lo que aporta una persona, como elegir, ordenar y modificar. Si tu aplicación es un negocio, lee las condiciones de la herramienta que usas, revisa las licencias de los paquetes y no copies imágenes ni textos de otros por el hecho de que la IA te los haya puesto.
¿Hasta dónde puedes llegar solo?
Una aplicación para organizar las recetas de tu familia puede tener fallos sin consecuencias. Una que guarda datos de clientes, cobra dinero o maneja información de salud o de menores necesita que alguien que sepa la revise antes de publicarla, igual que un local abierto al público necesita una instalación eléctrica revisada aunque la decoración la hayas hecho tú.
Lista antes de publicar
- No hay claves ni contraseñas en el código que llega al navegador ni en el repositorio.
- Las reglas de acceso están activadas en todas las tablas y en el almacenamiento.
- Con dos cuentas, ninguna ve lo de la otra; sin sesión, no se entra a nada privado.
- El inicio de sesión es el de la plataforma, no uno fabricado a mano.
- Solo se piden los datos necesarios, y hay un aviso de privacidad.
- Hay límites de gasto y alertas en todos los servicios de pago.
- Todos los paquetes existen y son conocidos.
- Si la aplicación usa IA, esta no puede hacer nada irreversible sin confirmación.
- Hay una versión guardada, una copia de pruebas y copias de seguridad de la base de datos.
- Si la aplicación cobra o guarda datos delicados, la ha revisado alguien que sabe.
Para seguir
Si quieres entender mejor lo que hace la IA por ti, empieza por los diez consejos para aprender a programar con IA y por lo que cambia en el oficio. Para los conceptos de fondo: cómo hablan el navegador y el servidor, por qué confía el navegador en una web y dónde van la configuración y los secretos. Y si tu aplicación está hecha en PHP, los fallos de seguridad típicos de PHP explican con más detalle varios de los riesgos de esta guía.
Fuentes: CVE-2025-48757 y la declaración de Matt Palmer; Spracklen y otros, «We Have a Package for You!» (USENIX Security 2025); GitGuardian, State of Secrets Sprawl 2026; Fortune sobre el caso de Replit; The Record sobre la filtración de Tea; OWASP, LLM01: Prompt Injection; Oficina de Derechos de Autor de EE. UU., Copyright and Artificial Intelligence.