O problema do 'quem pode ver o quê': adicionando permissões de usuário ao seu app criado com IA

O momento em que o seu app criado com IA deixa de ser só para você é o momento em que as permissões viram um problema de verdade. Até então, toda página mostra tudo. Toda lista mostra todas as linhas. Todo botão funciona para todo mundo. É um app de um jogador se fingindo de multijogador.

Aí você adiciona o seu primeiro colega de equipe, ou o seu primeiro cliente, ou o seu primeiro testador beta — e ele vê uma coisa que não deveria ver. Talvez seja o salário do colega. Talvez seja um rascunho que não estava pronto. Talvez sejam as configurações de admin, acidentalmente expostas.

Este é o problema do “quem pode ver o quê”, e é a maior coisa que os criadores não técnicos erram ao lançar um projeto de criador de apps com IA. A boa notícia: você não precisa virar um especialista em segurança para resolver. Você só precisa de uma forma clara de conversar sobre isso com o seu criador de apps com IA.

Por que o seu app criado com IA começa permissivo

Quando você descreve um app a um criador de apps com IA — “quero um CRM onde eu possa adicionar clientes e notas” — o criador otimiza para uma coisa: fazer funcionar para a pessoa que está descrevendo. O app padrão é “todo mundo que estiver logado pode ver tudo”. Isso é ótimo para uma ferramenta pessoal. É um desastre no momento em que um segundo usuário aparece.

Isso não é um bug no criador de apps com IA. É o resultado natural de você não ter dito a ele quem pode ver o quê. O criador não tem ideia de que a sua lista de clientes é sensível, ou de que as “Notas” podem conter coisas que você não quer que os clientes vejam. Você tem que dizer.

As três perguntas a fazer antes de adicionar um segundo usuário

Antes de convidar qualquer pessoa, pergunte-se três coisas. Anote as respostas — você vai alimentá-las ao seu criador de apps com IA no próximo passo.

1. Quais são os papéis?

Não as pessoas — as categorias. A maioria dos apps tem entre dois e quatro. Para um portal de freelancer: “Eu” e “Cliente”. Para uma ferramenta interna: “Admin”, “Gerente”, “Membro da equipe”. Para um app de comunidade: “Moderador”, “Membro”, “Visitante”. Resista à vontade de passar de quatro papéis cedo. Cada papel dobra as regras que você tem que acompanhar.

2. Para cada papel, o que ele pode ver?

Percorra cada página do seu app, mentalmente. Para cada uma, pergunte: um Cliente deveria ver esta página? Ele deveria ver todos os dados nela, ou só os próprios? Deveria ver a página, mas com alguns campos escondidos?

O padrão mais simples: os donos veem tudo; todos os outros veem apenas aquilo a que receberam acesso explicitamente. Isso funciona para 80% dos apps sem muita personalização.

3. Para cada papel, o que ele pode fazer?

O mesmo exercício, mas para botões e ações. Um Membro pode apagar um projeto? Um Cliente pode editar o próprio perfil mas não o próprio plano? Um Gerente pode convidar pessoas novas? A maioria dos criadores não técnicos esquece este passo por completo e acaba com apps onde qualquer usuário logado pode apagar o banco de dados inteiro com um clique.

Conversando com o seu criador de apps com IA sobre permissões

Quando você tiver as respostas, o prompt para o seu criador de apps com IA se escreve sozinho. Ele fica assim:

Atualize este app para suportar dois papéis: Dono e Cliente.

Os Donos podem ver todos os clientes, todos os projetos e todas as faturas. Os Donos podem criar, editar e apagar qualquer coisa.

Os Clientes só podem ver os próprios projetos e as próprias faturas. Eles não podem ver a lista de clientes, a página de equipe nem a página de configurações. Eles podem ver os projetos deles mas não editá-los. Eles podem ver e pagar as próprias faturas.

Quando um Cliente estiver logado, esconda os links de navegação para Configurações e Equipe. Se um Cliente tentar visitar essas páginas pela URL, redirecione-o para o painel dele.

Três coisas importam nesse prompt:

Seja específico por página e ação. “Os Clientes podem ver os projetos deles” é vago. “Os Clientes podem ver mas não editar os próprios projetos na página /projects” é algo que um criador de apps com IA consegue de fato implementar.
Diga o que acontece com a navegação. Esconder o link não é o mesmo que bloquear a página. Você quer os dois.
Cubra o caso de digitar a URL. Caso contrário, um usuário curioso pode colar /admin na barra do navegador e entrar direto.

Os quatro erros que vejo toda semana

Depois de ver muitos criadores lançarem o primeiro app multiusuário, os mesmos erros aparecem:

Esconder o botão não é esconder os dados. Se você disser ao seu criador de apps com IA para “esconder o botão de apagar para os Clientes”, o botão some da tela. Mas a operação de apagar subjacente ainda funciona se alguém descobrir como chamá-la. A correção: diga também ao criador para “rejeitar pedidos de apagar de contas que não sejam Donos no backend”. Se o criador não souber o que “backend” significa no seu app, peça para “bloquear a ação no lado do servidor, não só esconder o botão”.

Um papel para dois trabalhos. As pessoas confundem “quem paga” com “quem usa o app”. Um Cliente te pagando por um trabalho e um Cliente-funcionário usando o painel que você construiu para aquele cliente não são o mesmo papel. Se você os misturar, vai passar o mês seguinte remendando regras pontuais. Dois papéis. Sempre.

Deixar os usuários convidarem usuários desde o primeiro dia. É tentador adicionar “Convidar um colega” logo de cara. Não. Para os seus primeiros 10 usuários, convide-os você mesmo, na mão, a partir de um painel de admin que só você pode ver. Convites self-service são uma categoria inteira de regras de permissão (quem pode convidar quem? qual papel os convidados recebem? eles podem convidar outros?). Espere até de fato precisar.

Confiar no que o criador de apps com IA diz sem checar. Os criadores de apps com IA vão te dizer, com confiança, que as permissões estão configuradas. Talvez estejam. Talvez não. Sempre teste entrando como um não-dono e tentando fazer coisas ruins: clicar em botões de apagar, colar URLs de admin, editar campos que você não deveria conseguir editar. Se qualquer coisa que não deveria funcionar funciona, peça ao criador para corrigir especificamente.

Um checklist rápido antes de convidar qualquer pessoa

Antes de mandar aquele primeiro convite para um segundo usuário, percorra isto:

Eu consigo listar os papéis do meu app numa mão.
Para cada papel, eu sei quais páginas ele deveria ver e quais não.
Eu entrei como um não-dono e confirmei que as páginas erradas estão escondidas.
Eu tentei colar uma URL de admin no navegador como um não-dono e fui bloqueado.
Eu tentei clicar em botões de apagar ou editar que deveriam estar fora dos limites e fui bloqueado.
Se algo der errado, eu tenho uma forma de remover o acesso de um usuário rápido.

Se qualquer um desses itens não passar, essa é a próxima conversa com o seu criador de apps com IA — antes de mandar o convite, não depois.

A única mudança de mentalidade que ajuda

Construir permissões para um app multiusuário é, na maior parte, sobre imaginar que você é uma versão levemente xereta do seu usuário mais malcomportado. Não malicioso — só curioso. Ele vai clicar em coisas. Vai colar URLs. Vai tentar ver o que tem na página de “Configurações” que ele notou na sua captura de tela.

O seu trabalho — e o do seu criador de apps com IA — é garantir que, quando ele olhar, a resposta seja consistente: ou ele pode ver porque são os dados dele, ou não pode ver porque não são. Sem arestas. Sem páginas de admin acidentalmente expostas. Sem “esqueci que aquela página existia”.

A maioria dos criadores não pensa em permissões até algo constrangedor acontecer. A boa notícia: gastar 20 minutos pensando em papéis antes de lançar te poupa as 20 horas de corrigir isso depois, mais o e-mail que você não quer escrever ao cliente que viu a coisa errada.

Construindo algo com um lado multiusuário? Da próxima vez que você se sentar com o seu criador de apps com IA, comece a sessão listando os papéis do seu app em voz alta. É o hábito de cinco minutos mais fácil de criar, e ele vai pegar a maioria dos piores erros antes de eles acontecerem.