Crear un SaaS con IA: lo que falta para cobrarle al cliente

Crear un SaaS con IA funciona muy bien para validar una idea: en pocos días, una herramienta de prompts entrega inicio de sesión, base de datos y pantallas que funcionan. Lo que no garantiza es quién ve los datos de quién. Antes del primer cliente que paga, falta revisar la autorización en la base, las claves expuestas, el respaldo y el deber legal cuando algo se filtra.

Las guías en portugués que enseñan a armar un SaaS sin programar se detienen en la publicación: la más completa, actualizada en junio de 2026, resume la seguridad en media frase, y otra, de marzo, llega al primer cliente que paga sin tocar el tema. Este artículo cubre el tramo entre el prototipo y el camino de un SaaS después de la validación.

Wama creó ManyFeed, un SaaS propio de prueba social construido con IA en el proceso, así que aquí no hay sermón contra la herramienta. El punto es otro: el código generado pasa la prueba de funcionar mucho antes de pasar la prueba de proteger.

¿Hasta dónde funciona crear un SaaS con IA?

Funciona hasta el momento en que el producto empieza a guardar datos de otra persona. Para probar flujo, precio e interés, un prototipo generado con prompts es una forma barata y rápida de poner algo clicable frente a quien compraría.

El límite aparece en otro lugar. Las herramientas de IA están optimizadas para entregar código que corre, y correr no es lo mismo que restringir el acceso. Por eso la revisión humana del código escrito por IA no es una formalidad: en Wama, todo resultado que sale de Claude Code pasa por lectura humana antes de llegar al cliente.

El prototipo responde si alguien quiere el producto. No responde si el producto aguanta clientes que no se conocen usando la misma base, y es en ese punto donde aparece el escalón entre mostrar y operar.

Lo que las investigaciones de 2026 encontraron en apps hechas con IA

En el informe de Veracode sobre seguridad del código generado por IA, publicado en julio de 2026, los modelos escriben código sintácticamente correcto casi siempre, pero pasan las pruebas de seguridad en el 56% de las tareas. En el primer informe el índice era 55%: los modelos mejoraron en programar, no en proteger.

Symbiotic Security, empresa que vende una herramienta de seguridad para código generado por IA, analizó 1.072 apps hechas en plataformas de vibe coding con base de datos en Supabase y publicó en junio de 2026 que el 98% tenía al menos una falla. En el 16% había una falla crítica, y en 172 de ellas cualquier persona podía borrar registros de la base sin iniciar sesión.

Escape, otra empresa de pruebas de seguridad, examinó más de 5.600 aplicaciones públicas creadas con estas herramientas y encontró más de 2.000 vulnerabilidades y 175 casos de datos personales expuestos, incluidos historiales médicos, en una investigación publicada en octubre de 2025 y actualizada en junio de 2026. Y los investigadores de Georgia Tech contaron 35 vulnerabilidades públicas atribuidas a código de herramientas de IA solo en marzo de 2026, frente a 6 en enero, según una nota de investigación de la Cloud Security Alliance.

¿Qué fallas se repiten en un SaaS hecho con IA?

Tres fallas se repiten en los estudios y en lo que las propias plataformas documentan. La primera es la autorización en la base de datos. En proyectos con Supabase, la regla que decide quién lee cada fila se llama RLS (Row Level Security), y la documentación de Supabase sobre RLS advierte que una tabla expuesta sin esa regla puede ser leída y modificada por cualquier rol con permiso sobre ella.

El detalle que toma desprevenido al fundador: en proyectos existentes, la tabla nueva ya nace con permiso para leer, insertar, modificar y borrar para visitantes sin sesión y para usuarios con sesión, y crear una política no quita esos permisos. La pantalla funciona perfectamente mientras la base está abierta.

La segunda falla es una clave secreta dentro del código que va al navegador, como la de pagos o la de una API de IA. Una de las plataformas más usadas del rubro informó, en junio de 2025, que empezó a bloquear cerca de 1.200 claves privadas por día pegadas directamente en el código por los usuarios. La tercera es un inicio de sesión sin regla de dueño: la persona entra, cambia el número del registro en la dirección y abre los datos de otro cliente. Ninguna de las tres aparece en una prueba de clics, y todas están entre lo que suele romperse primero cuando un SaaS crece.

Una prueba de una tarde antes del primer cliente que paga

Puedes descubrir buena parte del problema sin saber programar, siempre que la prueba se haga en tu propia app y con cuentas de prueba. Ningún punto reemplaza una revisión técnica; muestran si es urgente.

1. Dos cuentas, un cliente espiando al otro. Crea dos cuentas, carga datos en la primera, entra con la segunda e intenta abrir las mismas pantallas cambiando el identificador en la dirección. Si los datos aparecen, la protección está solo en la interfaz.

2. RLS activado en todas las tablas. En el panel de Supabase, revisa tabla por tabla y ejecuta el verificador de seguridad (Security Advisor). Una tabla con datos de clientes y RLS desactivado es el punto más grave de la lista.

3. Claves fuera del navegador. Abre el código fuente de la página publicada y busca palabras como secret y service_role. La clave pública de Supabase aparece ahí a propósito y solo es segura con RLS activado; una clave secreta de pagos, de API de IA o de administración nunca debería aparecer.

4. Registro con correo confirmado. Verifica que la cuenta solo se active después de confirmar el correo. El escaneo de junio de 2026 encontró la confirmación desactivada en 69 apps.

5. Un respaldo que se restaura. Restaura una copia de la base en un proyecto de prueba. Un respaldo que nunca se restauró es una hipótesis.

Repite con la segunda cuenta el recorrido de la primera sesión del producto: registro, primera acción y pantalla de inicio. Es el camino que todo cliente nuevo va a recorrer, así que es el primero que tiene que estar cerrado.

¿Qué exige la LGPD cuando se filtran datos?

Exige una comunicación rápida, y la obligación es de quien controla los datos, en general la empresa dueña del producto, no la plataforma donde se armó. Según el artículo 48 de la LGPD (la ley brasileña de protección de datos), el incidente que pueda causar un riesgo o daño relevante debe comunicarse a la ANPD (la autoridad brasileña de protección de datos) y a los titulares. La Resolución CD/ANPD n.º 15, de abril de 2024, fijó el plazo en tres días hábiles, según la página de comunicación de incidentes de la ANPD, actualizada en agosto de 2026.

La comunicación puede complementarse, de forma fundamentada, en hasta 20 días hábiles, pero avisar solo a la ANPD no cumple la obligación cuando hay un riesgo relevante: las personas afectadas tienen que saberlo. La autoridad puede aplicar las sanciones del artículo 52 a quien no comunica o no adopta medidas de seguridad compatibles con el riesgo.

La comunicación pide, entre otras informaciones, las medidas de seguridad adoptadas y los riesgos para los titulares. En una app sin registro de accesos, responder eso en tres días hábiles se vuelve adivinanza.

Seguir en el constructor, reforzar o reconstruir

La decisión depende menos de la herramienta y más de lo que guarda el producto y de cuántos clientes comparten la misma base. La tabla resume cuatro escenarios.

Cuando el cliente necesita ser dueño del código, Wama lleva el proyecto a desarrollo a la medida, y un área con sesión, un portal o un curso se convierten en un proyecto de producto digital, con alcance propio. Reconstruir no significa tirar el prototipo: las pantallas que los usuarios aprobaron se vuelven la especificación para el diseño de la interfaz que retiene al cliente.

¿Cuánto cuesta pasar del prototipo al producto?

Depende del camino elegido en la tabla. Reforzar una app pequeña es trabajo de revisión y configuración; reconstruir es un proyecto de producto, con diseño, arquitectura y pruebas. En Wama, un MVP de SaaS cuesta entre US$ 4.000 y US$ 20.000 y puede acercarse a US$ 40.000 según la complejidad, rango observado en una base de 50 a 100 presupuestos.

El prototipo ayuda en un punto específico: las decisiones de producto llegan probadas por usuarios reales. No acorta la ingeniería, y la experiencia de Wama con IA muestra lo mismo: la herramienta aceleró la construcción, no la decisión, y el plazo total de los proyectos no cambió. Para comparar propuestas, ten a mano los rangos de inversión de un MVP en Brasil.

Preguntas frecuentes sobre crear un SaaS con IA

¿Se puede crear un SaaS con IA sin saber programar?

Se puede crear un prototipo funcional, con inicio de sesión, base de datos y pantallas, y validar la idea con usuarios reales. Cobrarles a clientes sobre ese prototipo es otra etapa: exige revisar la autorización en la base, las claves, el registro y el respaldo, lo que pide a alguien capaz de leer el código o al menos la configuración.

¿La plataforma de IA no se encarga ya de la seguridad de la app?

En parte. Una de las plataformas más usadas del rubro empezó a correr una verificación antes de publicar, pero afirma, en su propio texto sobre seguridad, que no puede garantizar que la app salga 100% segura. La configuración de la base y de los permisos sigue siendo responsabilidad de quien publica y opera el producto.

¿Qué es RLS en Supabase?

RLS, o Row Level Security, es la regla de la base de datos Postgres que decide qué filas de una tabla puede leer o modificar cada usuario. En Supabase, una tabla expuesta sin RLS queda accesible para cualquier rol con permiso sobre ella, y por eso la documentación recomienda activar RLS en todas las tablas expuestas.

¿Tengo que avisar a la ANPD si la app filtra datos?

Si el incidente puede causar un riesgo o daño relevante a las personas afectadas, sí. Según la Resolución CD/ANPD n.º 15/2024, la comunicación va a la ANPD y a los titulares en tres días hábiles y puede complementarse después. La obligación es de quien controla los datos, en general la empresa dueña del producto.

¿El sitio web del producto también se puede hacer con IA?

Se puede, con un cuidado menor, pero no nulo: el formulario de contacto también guarda datos personales, y el escaneo de junio de 2026 encontró tablas de leads abiertas en 10 apps. La vara de estructura y conversión es otra, y está en la guía de cómo estructurar el sitio web que presenta el producto.

Si tu producto ya tiene gente usándolo y quieres decidir entre reforzar y reconstruir con quien diseña y desarrolla SaaS del briefing al deploy, habla con Wama sobre tu SaaS.