Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
ChangelogCome viene creato un modello
La conservazione richiede un ancoraggio a un Utente. Una sessione creata senza
vendor_data non ha un Utente, quindi non può conservare un modello; l’eliminazione restituisce ineligible_no_vendor_user e l’embedding viene eliminato insieme alla sessione.
Cosa contiene un modello
I modelli sono limitati al tuo tenant e vengono usati solo su tua istruzione all’interno della tua applicazione: rilevamento di volti duplicati e di account multipli, Autenticazione biometrica e le tue liste facciali. Non vengono mai usati per l’addestramento di modelli, per analisi, per il confronto tra organizzazioni diverse, per i segnali condivisi di Networks né per l’elaborazione antifrode indipendente di Didit.
Oggetto modello
Stato
Come vengono usati i modelli nel confronto
Un modelloactive partecipa esattamente allo stesso confronto di un volto di una sessione ancora esistente: rilevamento automatico dei duplicati durante le nuove sessioni, l’API Ricerca facciale autonoma, Autenticazione biometrica e le tue liste facciali. Una corrispondenza con un modello conservato viene riportata con source: "retained_template", con il vendor_user_id e il vendor_data dell’utente proprietario, e con il biometric_template_id. Non include mai un id di sessione, un’immagine di confronto, dati identificativi o uno stato, perché la sessione che ha prodotto il volto non esiste più. Vedi report della Ricerca facciale.
Un modello conservato non viene mai inserito in una blocklist. Se il volto della sessione eliminata era presente in una blocklist facciale, la voce della blocklist mantiene una propria voce biometrica indipendente e un proprio ciclo di vita: rimuovere la voce dalla lista elimina la voce della blocklist, mentre eliminare definitivamente il modello non interviene sulla lista.
Punti di eliminazione
Tutti i seguenti punti rimuovono il modello dal confronto ed eliminano il modello memorizzato:
Riportare la policy dell’applicazione a
delete_with_session impedisce la creazione di nuovi modelli, ma non elimina quelli esistenti. Eliminali esplicitamente.
Le eliminazioni rimuovono prima il modello memorizzato e solo dopo contrassegnano il modello come eliminato. Quindi, se un’eliminazione restituisce 503, il modello passa a purge_failed, risulta già escluso dal confronto e può essere ripetuta in sicurezza. Ripetere un’eliminazione di un modello già eliminato restituisce already_purged.
Traccia di audit
Ogni tentativo di conservazione e di eliminazione, compresi i fallimenti e gli esiti di non idoneità, viene registrato con il soggetto che esegue l’operazione (retained_by / soggetto che elimina e relativo tipo), instruction_class, instruction_source, instruction_id, provenance_reference e l’esito. Invia un tuo instruction_id nelle eliminazioni, così puoi correlare la traccia di audit di Didit con il tuo registro delle cancellazioni. Le voci di audit non contengono mai immagini, vettori, campi identificativi o indirizzi email.
Blocchi legali
Un blocco legale è un’eccezione, mai una modalità di conservazione. Didit non applica blocchi di propria iniziativa: un blocco può derivare solo da un’istruzione documentata ai sensi del tuo accordo sul trattamento dei dati o da un ordine vincolante di un’autorità competente. Mentre un blocco è attivo, il modello viene contrassegnato comeheld_out_of_use: è escluso da ogni tipo di confronto e dal recupero ordinario, e non è mai ricercabile. Non esistono API per creare o rimuovere i blocchi. Se ricevi un ordine che riguarda i modelli conservati, contatta il tuo referente Didit.
Autorizzazioni e autenticazione
Gli endpoint dei modelli biometrici accettano solo chiavi API dell’applicazione (x-api-key). I token utente della Business Console vengono rifiutati con 403. Gli utenti della Console gestiscono i modelli tramite Lists → Modelli biometrici con le loro autorizzazioni lists.