Il servizio Azure AI Face (parte di Azure AI Vision) offre quattro capacità distinte — detection, verification, identification e liveness detection — ciascuna con vincoli tecnici e di governance che l’esame ama mettere alla prova. La sfida a livello associate non è “come chiamo l’API”, ma “quale operazione serve in questo scenario e quali funzionalità sono soggette a restrizioni di Responsible AI”.

Detection: rettangoli, landmark e attributi

L’operazione Detect individua i volti in un’immagine e restituisce per ciascuno un face rectangle, opzionalmente i landmark (punti di riferimento come pupille, angoli della bocca, punta del naso) e alcuni attributi. Genera anche un faceId temporaneo (valido 24 ore) usato dalle operazioni di riconoscimento.

Attenzione a cosa è ancora disponibile: attributi come headPose, glasses, occlusion, blur, exposure, noise, mask e qualityForRecognition restano attivi. Invece emotion, age, gender, smile, hair, makeup e simili sono stati deprecati e ritirati per motivi etici: non li puoi più ottenere. qualityForRecognition è prezioso in fase di enrollment, perché ti dice se un volto ha qualità sufficiente prima di aggiungerlo a un gruppo.

La detection pura (rettangoli e attributi non identitari) non richiede approvazione: è liberamente utilizzabile, ad esempio per il conteggio di volti o il blur automatico per privacy.

Verification (1:1) e Identification (1:N)

  • Verification confronta due volti e risponde alla domanda “sono la stessa persona?”, restituendo isIdentical e un punteggio di confidence. È uno scenario 1:1, tipico dell’accesso a un’app dove confronti il selfie con un volto già registrato.
  • Identification confronta un volto contro molti (“chi è questa persona?”), scenario 1:N. Richiede un contenitore di persone da addestrare:
    • PersonGroup — fino a 1.000 persone (tier standard).
    • LargePersonGroup — fino a 1 milione di persone, per scala enterprise.
    • PersonDirectory — struttura dinamica che non richiede il re-training completo a ogni modifica.

Il flusso è: crei il gruppo, aggiungi Person con più immagini di riferimento, esegui Train, poi Identify restituisce i candidati con relativa confidence. Ricordati che il modello di recognition (es. recognition_04, il più recente e robusto anche con mascherine) va scelto alla creazione del gruppo e deve coincidere con quello usato in detection.

Liveness detection: anti-spoofing

La liveness detection verifica che davanti alla camera ci sia una persona reale, non una foto stampata, uno schermo o un video (attacco di spoofing/presentation attack). Si implementa tramite gli SDK client (mobile e web frontend) integrati con un orchestratore backend, non con una semplice chiamata REST all’immagine: il flusso è progettato appositamente perché il server non si fidi di un frame arbitrario. Puoi combinarla con la verifica (“liveness with verify”) per confermare in un colpo solo che il soggetto è vivo e che è la persona attesa.

Limited Access e Responsible AI

Questo è il cuore concettuale dell’unità. Le capacità di identità — Identify, Verify e Liveness — sono soggette alla Limited Access policy di Microsoft:

  • Devi registrarti compilando un intake form e dichiarare un caso d’uso approvato e ammissibile.
  • L’accesso è concesso solo a clienti gestiti da Microsoft e per scopi conformi; usi come sorveglianza o identificazione in tempo reale in spazi pubblici non sono ammessi.
  • Senza approvazione, le operazioni di riconoscimento non funzionano, anche se il codice è corretto.

La detection non identitaria resta invece aperta. Questa asimmetria — detection libera, riconoscimento gated — è esattamente ciò che l’esame verifica.

Trappole tipiche d’esame

  • Scenario: devi rilevare “quanto è felice” o l’età di un volto. → Risposta: non è possibile, gli attributi emotion/age/gender sono deprecati; scegli una risposta che non li usa.
  • Scenario: un login confronta il selfie dell’utente con la sua foto registrata. → È Verification (1:1), non Identification.
  • Scenario: devi trovare a chi appartiene un volto tra migliaia di dipendenti. → Identification (1:N) con LargePersonGroup/PersonDirectory + Train prima di identificare.
  • Scenario: l’app deve impedire che qualcuno usi una foto o un video per autenticarsi. → Liveness detection tramite SDK, non semplice detection su immagine.
  • Scenario: hai implementato Identify ma ricevi errori di accesso/negazione. → Le funzionalità di identità richiedono Limited Access: serve richiesta approvata con caso d’uso ammissibile, non è una questione di codice o di chiave.