Il problema del "chi vede cosa": aggiungere i permessi utente alla tua app creata con l'IA

Il momento in cui la tua app creata con l’IA smette di essere solo tua è il momento in cui i permessi diventano un problema vero. Fino ad allora, ogni pagina mostra tutto. Ogni elenco mostra ogni riga. Ogni pulsante funziona per chiunque. È un’app per giocatore singolo che finge di essere multigiocatore.

Poi aggiungi il tuo primo collaboratore, o il tuo primo cliente, o il tuo primo beta tester — e quello vede una cosa che non dovrebbe vedere. Magari è lo stipendio di un collega. Magari è una bozza che non era pronta. Magari sono le impostazioni di amministrazione, esposte per sbaglio.

Questo è il problema del “chi vede cosa”, ed è la singola cosa che chi non è tecnico sbaglia di più quando pubblica un progetto con un creatore di app con IA. La buona notizia: non devi diventare un esperto di sicurezza per risolverlo. Ti serve solo un modo chiaro per parlarne con il tuo creatore di app con IA.

Perché la tua app creata con l’IA parte permissiva

Quando descrivi un’app a un creatore di app con IA — “voglio un CRM in cui posso aggiungere clienti e note” — lo strumento ottimizza per una cosa sola: farla funzionare per la persona che la sta descrivendo. L’app di default è “chiunque abbia fatto l’accesso può vedere tutto”. Va benissimo per uno strumento personale. È un disastro nel momento in cui compare un secondo utente.

Questo non è un difetto del creatore di app con IA. È il risultato naturale del fatto che non gli hai detto chi può vedere cosa. Lo strumento non ha idea che la tua lista clienti sia riservata, o che le “Note” possano contenere cose che non vuoi far vedere ai clienti. Devi dirglielo tu.

Le tre domande da farsi prima di aggiungere un secondo utente

Prima di invitare chiunque, fatti tre domande. Scrivi le risposte — le darai al tuo creatore di app con IA nel passaggio successivo.

1. Quali sono i ruoli?

Non le persone — le categorie. La maggior parte delle app ne ha tra due e quattro. Per un portale da freelance: “Io” e “Cliente”. Per uno strumento interno: “Amministratore”, “Manager”, “Membro del team”. Per un’app di community: “Moderatore”, “Membro”, “Ospite”. Resisti alla tentazione di andare oltre i quattro ruoli all’inizio. Ogni ruolo raddoppia le regole di cui devi tenere traccia.

2. Per ogni ruolo, cosa può vedere?

Passa in rassegna ogni pagina della tua app, mentalmente. Per ciascuna, chiediti: un Cliente dovrebbe vedere questa pagina? Dovrebbe vedere tutti i dati che contiene, o solo i suoi? Dovrebbe vedere la pagina ma con alcuni campi nascosti?

Lo schema più semplice: i proprietari vedono tutto; tutti gli altri vedono solo ciò a cui è stato dato accesso esplicitamente. Questo funziona per l’80% delle app senza grandi personalizzazioni.

3. Per ogni ruolo, cosa può fare?

Stesso esercizio, ma per i pulsanti e le azioni. Un Membro può eliminare un progetto? Un Cliente può modificare il proprio profilo ma non il proprio piano? Un Manager può invitare nuove persone? Quasi tutti i non tecnici saltano del tutto questo passaggio e si ritrovano con app in cui qualsiasi utente loggato può cancellare l’intero database con un clic.

Parlare di permessi con il tuo creatore di app con IA

Una volta che hai le risposte, il prompt per il tuo creatore di app con IA si scrive da solo. Suona così:

Aggiorna questa app per supportare due ruoli: Proprietario e Cliente.

I Proprietari possono vedere tutti i clienti, tutti i progetti e tutte le fatture. I Proprietari possono creare, modificare ed eliminare qualsiasi cosa.

I Clienti possono vedere solo i propri progetti e le proprie fatture. Non possono vedere la lista clienti, la pagina del team o la pagina delle impostazioni. Possono visualizzare i propri progetti ma non modificarli. Possono visualizzare e pagare le proprie fatture.

Quando un Cliente è loggato, nascondi i link di navigazione a Impostazioni e Team. Se un Cliente prova a visitare quelle pagine tramite URL, reindirizzalo alla sua dashboard.

In quel prompt contano tre cose:

Sii specifico per pagina e per azione. “I Clienti possono vedere i propri progetti” è vago. “I Clienti possono visualizzare ma non modificare i propri progetti nella pagina /projects” è qualcosa che un creatore di app con IA può davvero realizzare.
Di’ cosa succede alla navigazione. Nascondere il link non è la stessa cosa che bloccare la pagina. Vuoi entrambe.
Copri il caso dell’URL digitato a mano. Altrimenti un utente curioso può incollare /admin nella barra del browser ed entrare dritto dentro.

I quattro errori che vedo ogni settimana

Dopo aver osservato un sacco di builder pubblicare la loro prima app multiutente, ricorrono sempre gli stessi errori:

Nascondere il pulsante non è nascondere i dati. Se dici al tuo creatore di app con IA di “nascondere il pulsante elimina per i Clienti”, il pulsante sparisce dallo schermo. Ma l’operazione di eliminazione sottostante funziona ancora se qualcuno capisce come richiamarla. La soluzione: dì anche allo strumento di “rifiutare le richieste di eliminazione dagli account non Proprietario lato backend”. Se lo strumento non sa cosa significhi “backend” nella tua app, chiedigli di “bloccare l’azione lato server, non solo nascondere il pulsante”.

Un ruolo per due lavori. Si tende a confondere “chi paga” con “chi usa l’app”. Un Cliente che ti paga per un lavoro e un dipendente del Cliente che usa la dashboard che hai costruito per quel cliente non sono lo stesso ruolo. Se li mescoli, passerai il mese successivo a rattoppare regole una alla volta. Due ruoli. Sempre.

Lasciare che gli utenti invitino altri utenti fin dal primo giorno. È allettante aggiungere subito “Invita un collega”. Non farlo. Per i tuoi primi 10 utenti, invitali tu, a mano, da un pannello di amministrazione che solo tu puoi vedere. Gli inviti self-service sono un’intera categoria di regole di permesso (chi può invitare chi? che ruolo ottengono gli invitati? possono invitare altri?). Aspetta finché non ti serve davvero.

Fidarsi di ciò che dice il creatore di app con IA senza controllare. I creatori di app con IA ti diranno, con sicurezza, che i permessi sono a posto. Forse lo sono. Forse no. Verifica sempre facendo l’accesso come utente non proprietario e provando a fare cose cattive: clicca i pulsanti elimina, incolla URL di amministrazione, modifica campi che non dovresti poter modificare. Se funziona qualcosa che non dovrebbe, chiedi allo strumento di correggerlo nello specifico.

Una rapida checklist prima di invitare chiunque

Prima di mandare quel primo invito a un secondo utente, passa in rassegna questo elenco:

So elencare i ruoli della mia app sulle dita di una mano.
Per ogni ruolo, so quali pagine dovrebbe vedere e quali no.
Ho fatto l’accesso come utente non proprietario e confermato che le pagine sbagliate sono nascoste.
Ho provato a incollare un URL di amministrazione nel browser come utente non proprietario e sono stato bloccato.
Ho provato a cliccare pulsanti di eliminazione o modifica che dovrebbero essere off-limits e sono stato bloccato.
Se qualcosa va storto, ho un modo per rimuovere velocemente l’accesso a un utente.

Se uno di questi punti non passa, ecco la prossima conversazione da fare con il tuo creatore di app con IA — prima di mandare l’invito, non dopo.

L’unico cambio di mentalità che aiuta

Costruire i permessi per un’app multiutente significa soprattutto immaginare di essere una versione un po’ ficcanaso del tuo utente peggiore. Non malintenzionato — solo curioso. Cliccherà cose. Incollerà URL. Proverà a vedere cosa c’è nella pagina “Impostazioni” che ha notato nel tuo screenshot.

Il tuo compito — e quello del tuo creatore di app con IA — è fare in modo che, quando guarda, la risposta sia coerente: o può vederlo perché sono i suoi dati, oppure non può vederlo perché non lo sono. Niente vie di mezzo. Niente pagine di amministrazione esposte per sbaglio. Niente “mi ero dimenticato che esistesse quella pagina”.

Quasi nessun builder pensa ai permessi finché non succede qualcosa di imbarazzante. La buona notizia: spendere 20 minuti a ragionare sui ruoli prima di pubblicare ti risparmia le 20 ore di correzioni dopo, più l’email che non vuoi scrivere al cliente che ha visto la cosa sbagliata.

Stai costruendo qualcosa con un lato multiutente? La prossima volta che ti siedi davanti al tuo creatore di app con IA, inizia la sessione elencando ad alta voce i ruoli della tua app. È l’abitudine da cinque minuti più facile da costruire, e intercetterà la maggior parte degli errori peggiori prima che accadano.