El problema del "quién puede ver qué": cómo agregar permisos de usuario a tu app hecha con IA

El momento en que tu app hecha con IA deja de ser solo para ti es el momento en que los permisos se vuelven un problema de verdad. Hasta entonces, cada página muestra todo. Cada lista muestra cada fila. Cada botón funciona para todos. Es una app de un solo jugador haciéndose pasar por multijugador.

Luego agregas a tu primer compañero de equipo, o a tu primer cliente, o a tu primer beta tester — y ven algo que no deberían ver. Tal vez sea el salario de su compañero. Tal vez sea un borrador que no estaba listo. Tal vez sea la configuración de administrador, expuesta sin querer.

Este es el problema del “quién puede ver qué”, y es lo más grande en lo que se equivocan los creadores no técnicos cuando publican un proyecto con un creador de apps con IA. La buena noticia: no necesitas volverte experto en seguridad para resolverlo. Solo necesitas una forma clara de platicarlo con tu creador de IA.

Por qué tu app hecha con IA empieza siendo permisiva

Cuando le describes una app a un creador de IA — “quiero un CRM donde pueda agregar clientes y notas” — el creador optimiza para una sola cosa: que funcione para la persona que la describe. La app por defecto es “todo el que inicie sesión puede ver todo”. Esto está bien para una herramienta personal. Es un desastre en el momento en que aparece un segundo usuario.

Esto no es un error del creador de apps con IA. Es el resultado natural de que no le dijiste a quién se le permite ver qué. El creador no tiene idea de que tu lista de clientes es sensible, ni de que las “Notas” podrían contener cosas que no quieres que vean los clientes. Tienes que decírselo.

Las tres preguntas que debes hacerte antes de agregar a un segundo usuario

Antes de invitar a nadie, hazte tres preguntas. Anota las respuestas — se las pasarás a tu creador de IA en el siguiente paso.

1. ¿Cuáles son los roles?

No las personas — las categorías. La mayoría de las apps tienen entre dos y cuatro. Para un portal de freelancers: “Yo” y “Cliente”. Para una herramienta interna: “Administrador”, “Gerente”, “Miembro del equipo”. Para una app de comunidad: “Moderador”, “Miembro”, “Invitado”. Resiste la tentación de pasar de cuatro roles tan pronto. Cada rol duplica las reglas que tienes que tener en mente.

2. Para cada rol, ¿qué puede ver?

Recorre mentalmente cada página de tu app. Para cada una, pregúntate: ¿debería un Cliente ver esta página siquiera? ¿Debería ver todos los datos en ella, o solo los suyos? ¿Debería ver la página pero con algunos campos ocultos?

El patrón más simple: los dueños ven todo; todos los demás ven solo aquello a lo que se les dio acceso explícitamente. Esto funciona para el 80% de las apps sin mucha personalización.

3. Para cada rol, ¿qué puede hacer?

El mismo ejercicio, pero para botones y acciones. ¿Puede un Miembro borrar un proyecto? ¿Puede un Cliente editar su perfil pero no su plan? ¿Puede un Gerente invitar a gente nueva? La mayoría de los creadores no técnicos se saltan este paso por completo y terminan con apps donde cualquier usuario con sesión iniciada puede borrar toda la base de datos con un clic.

Cómo platicar de permisos con tu creador de IA

Una vez que tienes las respuestas, el prompt para tu creador de IA se escribe solo. Se ve así:

Actualiza esta app para que soporte dos roles: Dueño y Cliente.

Los dueños pueden ver todos los clientes, todos los proyectos y todas las facturas. Los dueños pueden crear, editar y borrar cualquier cosa.

Los clientes solo pueden ver sus propios proyectos y sus propias facturas. No pueden ver la lista de clientes, la página de equipo ni la página de configuración. Pueden ver sus proyectos pero no editarlos. Pueden ver y pagar sus propias facturas.

Cuando un Cliente tiene la sesión iniciada, oculta los enlaces de navegación a Configuración y Equipo. Si un Cliente intenta visitar esas páginas por URL, redirígelo a su panel.

Tres cosas importan en ese prompt:

Sé específico por página y por acción. “Los clientes pueden ver sus proyectos” es vago. “Los clientes pueden ver pero no editar sus propios proyectos en la página /projects” es algo que un creador de IA sí puede implementar.
Di qué pasa con la navegación. Ocultar el enlace no es lo mismo que bloquear la página. Quieres las dos cosas.
Cubre el caso de escribir la URL. Si no, un usuario curioso puede pegar /admin en la barra de su navegador y entrar tranquilamente.

Los cuatro errores que veo cada semana

Después de ver a muchísimos creadores publicar su primera app multiusuario, los mismos errores aparecen una y otra vez:

Ocultar el botón no es ocultar los datos. Si le dices a tu creador de IA que “oculte el botón de borrar para los Clientes”, el botón desaparece de la pantalla. Pero la operación de borrado por debajo sigue funcionando si alguien descubre cómo invocarla. La solución: dile también al creador que “rechace las solicitudes de borrado de cuentas que no sean Dueño en el backend”. Si el creador no sabe qué significa “backend” en tu app, pídele que “bloquee la acción del lado del servidor, no solo que oculte el botón”.

Un rol para dos trabajos. La gente confunde “los que pagan” con “los que usan la app”. Un Cliente que te paga por un trabajo y un Cliente-empleado que usa el panel que construiste para ese cliente no son el mismo rol. Si los mezclas, vas a pasar el siguiente mes parchando reglas hechas a la medida. Dos roles. Siempre.

Dejar que los usuarios inviten usuarios desde el día uno. Es tentador agregar “Invitar a un compañero” de inmediato. No lo hagas. Para tus primeros 10 usuarios, invítalos tú mismo, a mano, desde un panel de administración que solo tú puedas ver. Las invitaciones de autoservicio son toda una categoría de reglas de permisos (¿quién puede invitar a quién? ¿qué rol reciben los invitados? ¿pueden invitar a otros?). Espera hasta que de verdad lo necesites.

Confiar en lo que dice el creador de IA sin verificarlo. Los creadores de IA te dirán, con toda confianza, que los permisos están configurados. Quizá lo estén. Quizá no. Siempre prueba iniciando sesión como un usuario que no sea dueño e intentando hacer cosas indebidas: dale clic a los botones de borrar, pega URLs de administrador, edita campos que no deberías poder editar. Si funciona algo que no debería, pídele al creador que lo corrija de forma específica.

Una lista rápida antes de invitar a nadie

Antes de mandar esa primera invitación a un segundo usuario, repasa esto:

Puedo enumerar los roles de mi app con los dedos de una mano.
Para cada rol, sé qué páginas debería ver y cuáles no.
Inicié sesión como un usuario que no es dueño y confirmé que las páginas equivocadas están ocultas.
Intenté pegar una URL de administrador en el navegador como usuario que no es dueño y me bloqueó.
Intenté darle clic a botones de borrar o editar que deberían estar prohibidos y me bloqueó.
Si algo sale mal, tengo una forma de quitarle el acceso a un usuario rápido.

Si alguno de esos puntos no pasa, esa es la siguiente conversación con tu creador de IA — antes de mandar la invitación, no después.

El único cambio de mentalidad que ayuda

Crear permisos para una app multiusuario consiste sobre todo en imaginar que eres una versión un poquito metiche de tu usuario peor portado. No malicioso — solo curioso. Le va a dar clic a las cosas. Va a pegar URLs. Va a intentar ver qué hay en esa página de “Configuración” que notó en tu captura de pantalla.

Tu trabajo — y el de tu creador de IA — es asegurar que cuando mire, la respuesta sea consistente: o puede verlo porque son sus datos, o no puede verlo porque no lo son. Sin orillas sueltas. Sin páginas de administrador expuestas por accidente. Sin un “se me olvidó que esa página existía”.

La mayoría de los creadores no piensa en los permisos hasta que pasa algo vergonzoso. La buena noticia: dedicar 20 minutos a pensar en los roles antes de publicar te ahorra las 20 horas de arreglarlo después, más el correo que no quieres escribirle al cliente que vio lo que no debía.

¿Estás creando algo con un lado multiusuario? La próxima vez que te sientes con tu creador de apps con IA, empieza la sesión enumerando en voz alta los roles de tu app. Es el hábito de cinco minutos más fácil de adoptar, y atrapará la mayoría de los peores errores antes de que ocurran.