¿Están seguros mis datos en un creador web con IA?

Depende de qué datos. El proyecto que construyes es tuyo y puedes exportar su código a tu propio GitHub. Los datos de tus usuarios no viven en Zugo: viven en los servicios que conectas, como Supabase para la base de datos o Stripe para los cobros, bajo tus cuentas y tus reglas.

Esa separación es la respuesta útil, porque casi todas las preguntas sobre seguridad mezclan tres cosas distintas. Abajo están separadas una por una, con lo que resuelve la herramienta y lo que sigue siendo responsabilidad tuya.

¿Qué capas de datos hay en juego?

Tres, y confundirlas es lo que produce respuestas inútiles. Cada una tiene un dueño distinto y un riesgo distinto.

Lo que le cuentas a la herramienta. Tus prompts, la descripción de tu negocio, los textos que pegas. Es información de tu proyecto y conviene tratarla como tal: no metas en un prompt una lista de clientes ni datos personales de nadie.

Lo que recogen tus usuarios finales. Correos de un formulario, cuentas con contraseña, pedidos, mensajes. Esto no se guarda en el constructor. Se guarda en la base de datos que tú conectas, y ahí mandas tú.

Las credenciales de las integraciones. Claves de Stripe, de Supabase, de Resend. Son las llaves de tus propias cuentas en servicios de terceros y merecen el mismo cuidado que la contraseña del banco.

La consecuencia práctica es agradable: la parte más sensible de un proyecto real, que son los datos de los usuarios, nunca depende de que confíes en el constructor. Depende de que configures bien un servicio que ya es tuyo.

¿De quién es el proyecto que construyes?

Tuyo. Y la comprobación no es una promesa en una página de términos, es una función: la exportación de código a GitHub deja el proyecto completo en un repositorio de tu cuenta.

Ese es el criterio con el que conviene juzgar cualquier herramienta de este tipo. Si puedes llevarte el código, no estás atrapado; si no puedes, todo lo demás que diga la empresa importa menos de lo que parece.

Conviene hacer esa exportación al menos una vez aunque no pienses moverte a ningún sitio, porque además te sirve de copia de seguridad real. El procedimiento completo está en cómo exportar tu proyecto a GitHub.

Publicar tampoco te ata. El proyecto vive en una dirección tipo tu-slug.zugo.run y puedes conectar tu propio dominio, o desplegarlo en tu cuenta de Vercel si prefieres que la infraestructura también sea tuya.

¿Dónde viven los datos de tus usuarios?

En el servicio que conectes, siempre bajo tu cuenta. Esta tabla dice quién guarda qué en un proyecto típico con formulario, acceso y cobros.

La fila de las tarjetas merece una nota. Los datos de pago se manejan del lado de Stripe, así que tu web no los almacena y tú no cargas con la parte más delicada del cumplimiento. Cómo queda montado está en cobros con Stripe en un proyecto generado.

La primera fila es la que más cuidado exige, porque el control de acceso es donde se cometen los errores caros. Si tu proyecto tiene cuentas, revisa que cada usuario solo pueda leer lo suyo antes de publicar, y no después.

¿Qué sigue siendo responsabilidad tuya?

Bastante, y decirlo es más honesto que prometer seguridad integral. Ninguna herramienta de generación asume tus obligaciones legales ni revisa tu modelo de permisos por ti.

Las reglas de acceso a la base de datos. Que un usuario no pueda leer los registros de otro es una configuración concreta que hay que comprobar probándola, no asumiéndola. Los detalles prácticos están en cómo montar acceso de usuarios.

Los textos legales. Política de privacidad, aviso de cookies, base legal para tratar datos si operas en la Unión Europea. Se pueden redactar y montar en el sitio, pero decidir qué recoges y por qué es tuyo.

Las claves. No las pegues en un prompt, no las publiques en un repositorio público y rótalas si sospechas que se filtraron. Es el fallo más común y el más fácil de evitar.

Recoger menos. El dato que no pides no se puede filtrar. Un formulario de contacto con tres campos tiene menos superficie de riesgo que uno con doce, y además lo rellena más gente.

¿Qué comprobar antes de publicar un formulario?

Cinco pruebas, todas manuales y todas de menos de diez minutos. Se hacen con el proyecto ya publicado, porque en la vista previa no siempre se comporta igual.

Envía el formulario tú mismo y comprueba que el dato llega adonde crees que llega. Es sorprendente la cantidad de formularios en producción que no envían a ninguna parte y nadie lo nota durante semanas.

Crea dos cuentas de prueba y entra con la segunda para intentar ver lo de la primera. Si lo consigues, tienes un problema de permisos y es exactamente el tipo de fallo que hay que arreglar antes de tener usuarios reales.

Repite el pago de prueba con el modo de pruebas de Stripe antes de activar los cobros de verdad. Y por último, guarda una copia del proyecto antes de cualquier tanda grande de cambios, siguiendo cómo hacer copia de seguridad.

Cada corrección que salga de estas pruebas cuesta una edición de 3 créditos. Detectarlas antes de publicar es la diferencia entre un ajuste barato y un incidente con clientes delante.

¿Qué límites hay que decir en voz alta?

Cuatro, sin suavizar.

Esto no es una auditoría de seguridad. Una construcción se arranca en un entorno aislado antes de entregarse, y la que no abre se reporta como fallo. Eso comprueba que funciona, no que sea inexpugnable.

La lógica de permisos específica se afina con ediciones. Un modelo de roles con excepciones se construye por capas y hay que probarlo capa a capa, no confiar en un prompt.

Zugo no sustituye a un equipo de desarrollo cuando manejas datos sensibles a escala, sector regulado o requisitos de cumplimiento serios. Ahí necesitas gente que responda por ello.

El cumplimiento legal no viene incluido. Ninguna herramienta te vuelve conforme al RGPD por sí sola.

¿Cómo reducir el riesgo esta semana?

Tres acciones concretas, en este orden. Primero exporta el código a GitHub para tener una copia fuera de la plataforma. Es gratis en créditos y te quita de encima la peor pregunta, la de qué pasa si mañana no puedes entrar.

Segundo, haz las cinco pruebas del apartado anterior sobre el proyecto publicado y anota lo que falle. Agrupa todas las correcciones en un solo mensaje: cuatro arreglos juntos son una edición de 3 créditos, y por separado son 12.

Tercero, revisa qué datos estás pidiendo y quita los campos que no vas a usar nunca. Es la mejora de seguridad más barata que existe porque no cuesta ningún crédito. Puedes montar y probar todo este flujo en Zugo antes de abrirlo a nadie.