Chiedere la foto di un documento per aprire un’area riservata risolve un problema e ne crea un altro: il sito diventa custode di nome, data di nascita, fotografia e numero identificativo. Una stima dell’età tramite selfie riduce i dati raccolti, ma introduce un modello probabilistico proprio nel punto in cui serve decidere chi passa e chi resta fuori. La scelta corretta non è quella con più tecnologia: è quella che dimostra la soglia necessaria conservando meno informazioni possibili.
Perché il confronto è diventato concreto
Apple ha aggiunto in iOS e iPadOS 27.2 la possibilità di confermare di essere adulti con una selfie, dove disponibile. La procedura acquisisce quattro angoli del volto; secondo la documentazione Apple, i modelli lavorano sul dispositivo e in Private Cloud Compute, i risultati vengono combinati sul dispositivo e le immagini sono eliminate dopo la conferma. Se il controllo non riesce, restano metodi alternativi come carta di credito o documento governativo.
Il punto interessante per una PMI non è copiare Apple. È capire che “verificare l’età” può indicare architetture molto diverse: stimare una soglia da un volto, controllare un documento oppure ricevere da un soggetto fidato una semplice prova “maggiorenne”. Mescolare questi tre passaggi porta facilmente a raccogliere più dati del necessario.
I quattro criteri che contano
Confronto selfie e documento su quattro criteri operativi: quantità di dati esposti, attrito per l’utente, qualità della decisione e complessità da gestire nel tempo. Il costo per singola verifica viene dopo. Un servizio economico che obbliga WordPress a conservare documenti, immagini o esiti dettagliati può trasformare un risparmio iniziale in un problema di sicurezza, assistenza e governance.
Anche il regolatore britannico Ofcom distingue fra metodi, non fra slogan: la sua guida sull’age assurance include sia facial age estimation sia photo-ID matching tra le tecniche che possono essere altamente efficaci. La sola autodichiarazione, invece, non viene considerata sufficiente per un controllo robusto a 18 anni. Quindi il campo “Inserisci la tua data di nascita” non è un’alternativa tecnica ai due approcci: è un livello di garanzia diverso.
Selfie: meno dati, più gestione dell’incertezza
La stima facciale ha un vantaggio immediato: non chiede all’utente di consegnare un documento completo. In un flusso ben progettato, il sito riceve solo l’esito necessario, per esempio “sopra la soglia”, e non la selfie. Questo riduce la superficie informativa e può rendere l’onboarding più rapido da smartphone.
Il limite è nel verbo stimare. Un modello non legge una data di nascita: produce una valutazione. Serve quindi una fascia di sicurezza attorno alla soglia, un percorso alternativo per chi viene respinto e una procedura di assistenza che non chieda documenti via email. Senza fallback, gli errori diventano abbandoni; con un fallback improvvisato, tornano a essere copie di documenti sparse fra caselle di posta e Media Library.
Per una PMI questo approccio funziona quando l’obiettivo è filtrare l’accesso con poco attrito e il fornitore può dimostrare cancellazione, minimizzazione, test di accuratezza e gestione delle contestazioni. Non basta la frase “AI-powered”: bisogna sapere quale dato arriva al sito, per quanto tempo resta e come viene revocato l’esito.
Documento: decisione più diretta, dati più pesanti
Il documento collega la verifica a una data di nascita dichiarata da un’autorità. È adatto quando il rischio richiede un’identificazione più forte o quando la stima non riesce. Ma caricare fronte e retro dentro WordPress è quasi sempre l’implementazione peggiore: il CMS, i backup, la CDN, i log e gli account amministrativi entrano tutti nel perimetro di dati che non servono alla normale pubblicazione del sito.
La variante migliore non è “documento sì o no”, ma “chi vede il documento”. Il blueprint europeo per l’age verification separa il soggetto che emette la prova dal servizio che la verifica. Il sito riceve una prova anonima della soglia d’età, non nome, data di nascita o numero del documento; la prova è pensata per un solo utilizzo, così da limitare il tracciamento fra servizi.
Questa architettura sposta il lavoro difficile verso un provider di identità o un wallet, ma lascia alla PMI responsabilità concrete: validare firma e scadenza della prova, impedire il riuso, registrare solo l’esito minimo e definire cosa succede quando il servizio esterno non risponde.
Come integrarlo in WordPress e nelle automazioni
WordPress dovrebbe orchestrare il flusso, non diventare un archivio d’identità. Il browser apre la verifica presso il provider; il ritorno passa da un endpoint server-to-server firmato; il sito salva un attributo minimo, una scadenza e un identificatore tecnico non riutilizzabile. Le immagini non entrano nella Media Library e i webhook vengono verificati prima di aggiornare il ruolo o l’accesso dell’utente.
Lo stesso principio vale per WooCommerce, membership e form: il frontend non decide da solo, il risultato non viaggia in un parametro modificabile e l’automazione non conserva il payload completo “per sicurezza”. È la stessa disciplina già utile quando si progettano permessi e limiti per agenti AI: ogni componente riceve solo l’autorità e i dati necessari al passaggio successivo.
Prima di scegliere un fornitore, chiederei cinque risposte verificabili: quale dato riceve il sito; dove avviene l’elaborazione; quando vengono eliminate selfie o documento; come funziona il fallback; quali log restano disponibili per audit e contestazioni. Se una risposta richiede di “fidarsi della piattaforma”, il progetto non è ancora pronto.
La scelta netta per una PMI
Per un sito che deve soltanto applicare una soglia d’età, sceglierei una prova di attributo fornita da un soggetto fidato. Se non è disponibile, userei la stima via selfie come percorso principale solo con cancellazione dichiarata, esito minimo e fallback documentale esterno. Eviterei invece l’upload diretto del documento in WordPress.
Il documento resta necessario nei casi in cui serve identificare davvero la persona, non soltanto stabilire se supera una soglia. Ma quando la domanda è “ha almeno 18 anni?”, archiviare l’intera identità è una risposta sproporzionata. La take finale è semplice: non scegliere fra volto e tessera; scegli l’architettura che restituisce al sito un sì o un no e trattiene tutto il resto fuori dal CMS.