Un utente chiede di reimpostare una password o uno strumento di accesso, dopo che è stato accertato che chi lo richiede è davvero chi dice di essere. Questo avviene presso i collaboratori del servizio assistenza e gli amministratori IT, di solito all'interno di un sistema di identity management o di un sistema di servicedesk. È una delle richieste più comuni nell'ambito del supporto IT, e proprio per questo è un buon esempio per mostrare quando l'IA può assumere un compito e quando no.
Tre assi determinano qui il giudizio: volume, strutturazione e compliance.
Volume (5). I reset di password si verificano con estrema frequenza. Praticamente ogni organizzazione con un servicedesk ne gestisce decine o centinaia al giorno. Un volume elevato con uno schema ripetitivo è esattamente il tipo di lavoro in cui l'automazione si ripaga più rapidamente: ogni gestione automatizzata genera immediatamente un risparmio di tempo, perché il compito si ripete continuamente.
Strutturazione (5). Il processo prevede passaggi fissi: accertare l'identità, verificare l'autorizzazione, emettere una nuova password o un nuovo token, inviare una conferma. È necessaria poca interpretazione: l'input (una richiesta) e l'output (un reset) sono definiti in modo chiaro. Ciò rende tecnicamente semplice inserirlo in un flusso automatizzato o in un agente chatbot.
Compliance (3). È qui che si concentra la tensione. Un reset è sicuro solo se il controllo dell'identità è corretto. Chi ottiene accesso indebitamente tramite una verifica debole o aggirabile può arrivare a sistemi sensibili. Non è una questione di comodità, ma di sicurezza: è l'affidabilità della fase di verifica a determinare se l'automazione è responsabile, non l'azione di reset in sé.
Margine di giudizio (2) e creatività (1) sono bassi: non c'è quasi nessuna valutazione da fare, si tratta di eseguire secondo il protocollo. Il contatto con il cliente (4) è rilevante perché l'utente è spesso frustrato (escluso da un sistema), ma questo non richiede empatia su misura: una gestione chiara e rapida è di solito sufficiente. L'aspetto fisico (5) non gioca alcun ruolo; tutto avviene in digitale. I costi in caso di errore (3) sono moderati: uno strumento di accesso rilasciato per errore può causare danni, ma di solito è facilmente rimediabile bloccandolo di nuovo.
La combinazione di volume elevato, alta strutturazione e un rischio di compliance concentrato soprattutto nella fase di verifica porta al seguente giudizio: un agente IA può assumere oggi questo compito, a condizione che la verifica dell'identità sia impostata in modo affidabile e che sia disponibile un portale self-service in cui l'utente possa accedere autonomamente. Senza queste due condizioni, il compito si sposta automaticamente nella categoria due: l'IA può prepararlo o eseguirlo, ma una persona deve approvare il controllo dell'identità prima che il reset avvenga effettivamente.
Un esempio a titolo illustrativo. In un'organizzazione con autenticazione a più fattori, un registro del personale collegato e un portale in cui i dipendenti possono identificarsi con un secondo fattore di verifica, un reset è questione di secondi — completamente automatico, senza intervento del servicedesk. In un'organizzazione dove l'identità viene accertata solo per telefono ("qual è la sua data di nascita e il suo numero di dipendente"), la situazione è diversa: quella verifica è facile da aggirare e non si presta a un'automazione completa senza un controllo aggiuntivo. Stesso compito, giudizio diverso — proprio perché l'asse della compliance varia da organizzazione a organizzazione.
Nelle organizzazioni con requisiti di sicurezza elevati — ad esempio l'accesso a sistemi finanziari, cartelle cliniche o infrastrutture critiche — l'asse della compliance può pesare molto di più di quanto descritto qui. Lì è prassi che una richiesta di reset per determinati sistemi venga sempre valutata da una persona, anche quando il controllo dell'identità è a posto, semplicemente perché i costi di un reset errato sono inaccettabilmente elevati. Anche quando la gestione degli accessi fa parte di un processo di autorizzazione più ampio — in modo simile a quanto si osserva per lo screening di clienti e partner sulle liste sanzionatorie — l'accento si sposta dalla velocità all'accuratezza, e quindi dalla categoria uno alla categoria due.
Questi spostamenti sono proprio il motivo per cui un compito non va mai valutato in base al nome della funzione, ma in base agli otto assi, come strutturazione, volume e compliance. La stessa logica si applica ad esempio ai compiti di accesso e autorizzazione all'interno di quale lavoro può l'IA assumere negli acquisti, dove gli account dei fornitori e i diritti di pagamento richiedono valutazioni simili tra velocità e controllo.
Questo giudizio non dice nulla sulla domanda se un servicedesk possa diventare più piccolo o quale ruolo mantenga un collaboratore al suo interno. Riguarda il compito, non la persona che lo svolge attualmente. Le decisioni su personale e configurazione delle funzioni hanno requisiti legali propri e non rientrano nell'ambito di questa pagina.
Vuole sapere come il reset di password e accessi si colloca rispetto al resto delle attività del suo servicedesk o del suo reparto IT, e quale parte di esse è già oggi idonea all'automazione? La quickscan gratuita di ftetoai è composta da dodici domande, non richiede un account e fornisce un'indicazione di quale parte delle ore nel suo profilo può già essere assunta oggi dall'IA. La werkscan completa, che approfondisce sistemi e processi specifici, è ancora in fase di sviluppo — quindi non la offriamo ancora qui, ma la quickscan fornisce già una prima indicazione fondata.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.