El 7 de mayo de 2026, la empresa de ciberseguridad RedAccess reveló que miles de aplicaciones creadas con herramientas de «vibe coding» como Lovable, Replit, Base44 o Netlify estaban abiertas a cualquiera, datos incluidos: historiales médicos, cifras financieras, presentaciones de estrategia. La seguridad del vibe coding no se decide dentro de la herramienta, sino antes. Su prototipo puede pasar a producción el día en que usted haya decidido quién debe ver qué dato, y haya comprobado que es así.
Lo esencial
- RedAccess afirma haber encontrado 380 000 aplicaciones y recursos accesibles públicamente, creados con Lovable, Base44, Replit y Netlify, de los cuales unos 5 000 contenían datos empresariales sensibles.
- Según WIRED, alrededor del 40 % de las aplicaciones sin protección examinadas por los investigadores exponían datos sensibles, cerca de 2 000.
- Las plataformas responden que una aplicación pública es una elección del usuario, no un fallo. Tienen parte de razón, y ese es precisamente el problema.
- Una IA escribe el código que usted le pide. Si nadie ha decidido quién puede ver qué, no lo decidirá por usted.
- Antes de pasar a producción: un documento de requisitos que lo diga y, después, una prueba sencilla desde una ventana de navegación privada.
Qué está pasando: la seguridad del vibe coding, en entredicho
Se llama vibe coding a crear una aplicación describiéndosela a una IA, sin escribir uno mismo el código. Estas herramientas permiten a un responsable de marketing, a un comercial o a un fundador sin formación técnica publicar una herramienta en una tarde.
El equipo de Dor Zvi, cofundador de RedAccess, encontró estas aplicaciones con simples búsquedas en Google y Bing. Fue fácil: Lovable, Replit, Base44 y Netlify alojan las aplicaciones de sus usuarios en sus propios dominios. Los investigadores compartieron sus resultados con WIRED y Axios, que los publicaron el 7 de mayo de 2026.
Los dos medios no describen las cifras del mismo modo, así que prefiero darle ambas versiones:
- Axios: RedAccess encontró 380 000 recursos accesibles públicamente creados con estas cuatro herramientas, de los cuales unos 5 000 contenían datos empresariales sensibles.
- WIRED: más de 5 000 aplicaciones no tenían prácticamente ninguna seguridad ni autenticación; alrededor del 40 % de ellas, cerca de 2 000, parecían exponer datos privados.
En ambos casos los ejemplos son los mismos: los turnos de trabajo de un hospital con datos personales de médicos, las compras de publicidad detalladas de una empresa, una estrategia comercial, las conversaciones completas del chatbot de un minorista con sus clientes, nombres y datos de contacto incluidos. Algunas aplicaciones solo pedían iniciar sesión con cualquier dirección de correo. En algunos casos, según Dor Zvi, habrían permitido obtener derechos de administrador. La página de presentación del informe de RedAccess da el mismo orden de magnitud: el 40 % de las aplicaciones empresariales creadas con IA examinadas exponían datos sensibles.
También hay que señalar los límites. WIRED no pudo confirmar que todos los datos fueran reales; algunas aplicaciones podían ser pruebas llenas de datos ficticios. Y las plataformas cuestionaron el método. Para Replit, «que las aplicaciones públicas sean accesibles en internet es el comportamiento esperado». Lovable recuerda que la configuración de una aplicación es «en última instancia responsabilidad de su creador». Wix, propietaria de Base44, habla de «una elección de configuración del usuario, no de una vulnerabilidad de la plataforma».
Un investigador citado por WIRED, Joel Margolis, resume el fondo del problema: las herramientas de programación con IA «hacen lo que usted les pide. Y a menos que les pida hacerlo de forma segura, no se esforzarán especialmente en ello».
Qué cambia para usted
Para una pyme, estas herramientas son una verdadera oportunidad: una herramienta interna que costaba semanas de desarrollo puede existir en unas horas. Pero desplazan la decisión de publicar. Ya no pasa por un informático que se pregunta quién tiene acceso a qué; se toma con un clic, por la persona que necesita la herramienta.
RedAccess describe de hecho este fenómeno como una nueva forma de shadow AI: después de los empleados que pegan expedientes de clientes en ChatGPT, los que construyen aplicaciones, las conectan a los datos de la empresa y las publican sin que nadie lo sepa.
Dos consecuencias concretas:
- Puede que usted no sepa qué está funcionando. Un panel de ventas, un formulario de candidaturas o un seguimiento de obra creado por un colaborador puede estar en línea, en una dirección que cualquiera puede encontrar con un buscador.
- La responsabilidad sigue siendo suya. Las plataformas lo dicen sin rodeos: el ajuste de visibilidad corresponde al creador. Si la aplicación contiene datos de clientes o de empleados, es su empresa la que responde, como por cualquier otro archivo.
Y para el fundador que tiene un prototipo generado con IA y se pregunta si puede lanzarlo, la respuesta honesta es: todavía no, mientras no sepa responder a la pregunta «quién ve qué».
Lo que he aprendido
Desarrollé TSFind, un directorio de proveedores, con la ayuda de Claude Code, un asistente de programación con IA. Uno de los problemas centrales del proyecto era justamente este: exponer datos públicos, las fichas y las reseñas, sin exponer los datos privados, las pruebas, los contactos y las suscripciones.
Al principio dejé que el navegador consultara directamente la base de datos, protegida por reglas que deciden, fila por fila, quién puede leer qué. Cuanto más se enriquecía el modelo de datos, más difícil era mantener esas reglas correctas: hicieron falta varias correcciones sucesivas para resolver, uno por uno, los avisos de seguridad de la base. Acabé cambiando de arquitectura: todas las lecturas y escrituras pasan ahora por el servidor, que elige con precisión lo que devuelve, y las reglas siguen activas como segunda línea de defensa.
Lo que me llevo: la IA me hizo ganar mucho tiempo en el código, pero ninguno en esa decisión. Fui yo quien tuvo que entender el riesgo, decidir la arquitectura y comprobar el resultado. Una IA entrega lo que se le describe; no se pregunta por sí misma qué debe seguir siendo privado.
Es también el consejo que di a Justin Gary, diseñador de juegos y CEO de Stone Blade Entertainment, durante un hackathon sobre IA: empiece por un documento de requisitos, lo que en inglés se llama un PRD. Lo contó en su artículo: 45 minutos para redactar el PRD con Claude, 15 minutos para revisarlo y luego 2 horas para obtener un prototipo funcional con Lovable. El documento de requisitos es donde se escribe, entre otras cosas, qué datos guarda la aplicación y quién debe acceder a ellos. Es el método que aplico en mis proyectos de aplicaciones: primero los requisitos, después el código. Ya hablaba de ello, antes de la IA, a propósito de las herramientas no-code y la improvisación.
Qué hacer en concreto
1. Hacer el inventario
Pregunte a sus equipos qué aplicaciones han creado con una herramienta de IA, en qué plataforma y con qué datos. Prometa que no habrá reproches: usted quiere una lista completa, no culpables.
2. Hacer la prueba de la ventana privada
Abra la dirección de cada aplicación en una ventana de navegación privada, sin haber iniciado sesión. Si ve datos, todo el mundo los ve. Cree después una segunda cuenta de prueba: si ve los datos de la primera, la aplicación no separa a sus usuarios.
3. Escribir quién debe ver qué
Para cada aplicación basta una página: qué datos contiene y, para cada uno, quién tiene derecho a verlo (todo el mundo, los usuarios conectados, solo su propietario, el administrador). Es el corazón del documento de requisitos. Si no existe, escríbalo ahora.
4. Corregir los ajustes, o retirar la aplicación
Ponga en privado lo que no tiene por qué ser público, exija una autenticación real y compruebe que ninguna clave secreta se encuentra en el código enviado al navegador. Si la aplicación contiene datos reales que no sabe proteger, retírela mientras se corrige.
5. Decidir qué sigue siendo un prototipo
Un prototipo con datos ficticios es una excelente herramienta de discusión. Una herramienta que maneja datos de clientes merece una arquitectura pensada, una revisión por alguien distinto de su autor y un responsable designado. Decida, aplicación por aplicación, de qué lado está.
Preguntas frecuentes
¿Puedo poner en producción una aplicación creada con IA?
Sí, si sabe qué datos contiene, quién debe acceder a ellos, y lo ha comprobado usted mismo, como mínimo con la prueba de la ventana privada y una segunda cuenta. El origen del código importa menos que la comprobación.
¿Son responsables las plataformas de vibe coding?
Ofrecen ajustes de visibilidad y de acceso, y consideran que su uso corresponde al usuario. Piense lo que piense de ello, es usted quien responde de los datos de sus clientes: no confíe en los ajustes por defecto.
¿Hay que prohibir estas herramientas en la empresa?
No. Son útiles, y la prohibición empuja a usarlas a escondidas. Funciona mejor una regla sencilla: se prototipa libremente con datos ficticios, y nada toca datos reales sin documento de requisitos ni comprobación.
Para ir más lejos
Diseño y desarrollo aplicaciones y automatizaciones a medida, empezando por los requisitos, y también puedo revisar un prototipo existente antes de su puesta en producción. Para hablar de su caso: una llamada de 20 minutos.
Fuentes
- Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, Andy Greenberg, WIRED, 7 de mayo de 2026.
- AI vibe-coding apps leak sensitive data, Sam Sabin, Axios, 7 de mayo de 2026.
- Report: The Shadow Builders Inside Your Organization, RedAccess, 8 de octubre de 2026.
- A Game Designer's Guide to Vibe Coding, Justin Gary, Substack, 3 de junio de 2025.
Foto de portada: Kelly Sikkema / Unsplash, licencia Unsplash.
Etiquetas: vibe coding, seguridad de aplicaciones, IA generativa, protección de datos, documento de requisitos, aplicaciones a medida