Eseguire i backup pianificati, controllare se sono riusciti e segnalare le anomalie: questo è uno dei compiti in cui la risposta si avvicina parecchio a "sì". Non perché sia un lavoro poco importante, ma proprio perché è un lavoro descritto in modo così rigoroso che un sistema può seguire il processo senza dover inventare nulla lungo il percorso.
Un backup viene eseguito secondo una pianificazione, segnala successo o fallimento, e questa segnalazione ha una forma fissa. Questo rende il livello di strutturazione elevato: c'è un trigger chiaro, un risultato atteso chiaro e un esito chiaro in caso di problemi. Non serve alcun contatto con il cliente, nessuna azione fisica e nessun apporto creativo — si tratta puramente di seguire un processo e riconoscere un esito. Un agente per i backup può monitorare la pianificazione, leggere i log, interpretare i codici di stato e, in caso di guasto, inoltrare automaticamente una segnalazione alla persona o al sistema giusto, in modo simile a come il monitoraggio delle prestazioni di sistema è già in gran parte automatizzato.
Anche il volume è favorevole: in un ambiente IT medio girano quotidianamente o settimanalmente decine o centinaia di attività di backup, distribuite tra server, database e postazioni di lavoro. È esattamente il tipo di ripetitività in cui un sistema automatizzato dimostra il proprio valore — non perché sia più intelligente di un amministratore, ma perché non salta mai un controllo per mancanza di tempo o stanchezza.
Il motivo per cui questo non è un "sì, completamente automatico" senza riserve sta nel costo dell'errore. Un backup mancato o non rilevato come fallito diventa un problema solo nel momento in cui si verifica una perdita di dati e serve un ripristino — e a quel punto il danno spesso non è più reversibile. È un ordine di rischio diverso rispetto a un'e-mail classificata in modo errato o a campi compilati male nei dati anagrafici. Per questo a questo compito si affianca una condizione non opzionale: un monitoraggio automatizzato con notifiche di allarme, e un protocollo di escalation che stabilisca chi controlla una segnalazione di guasto e entro quanto tempo. L'IA può occuparsi del controllo e della segnalazione; la responsabilità di ciò che accade nel momento in cui qualcosa va storto resta di una persona.
Per lo stesso motivo, il margine di giudizio e il punteggio di conformità sono bassi. In caso di backup fallito di un database di produzione c'è poco spazio per l'interpretazione — è un guasto da risolvere, non una situazione in cui un sistema può decidere autonomamente quanto sia grave il problema. E nei settori con obblighi di conservazione o di audit, come nel caso della tenuta di un registro di audit delle modifiche finanziarie, conta anche il fatto che la politica di backup stessa può essere parte di un requisito di controllo. Questo non cambia ciò che l'IA è tecnicamente in grado di eseguire, ma determina chi alla fine risponde della conformità.
In un'organizzazione con qualche file server e uno schema di backup ben definito, il compito è praticamente automatizzabile del tutto: l'agente controlla quotidianamente i codici di stato, invia un riepilogo ed effettua l'escalation solo in caso di errore. L'amministratore di sistema non dedica più tempo fisso a questo, salvo in caso di una segnalazione effettiva.
In un'organizzazione con molti sistemi diversi, migrazioni in corso o un ambiente in cui la politica di backup varia per cliente — come nel caso di un fornitore di servizi IT che lavora per più committenti — la situazione è diversa. Lì serve più interpretazione su cosa significhi esattamente un backup "riuscito" per ciascun contratto cliente, e il compito si sposta più verso una supervisione con approvazione umana.
Ciò che sta cambiando ora non è il fatto che i backup vengano controllati per la prima volta — questo avveniva già. La differenza è che il controllo non dipende più da qualcuno che al mattino legge un file di log. Il monitoraggio funziona in modo continuo, la segnalazione arriva automaticamente, e l'amministratore entra in gioco nel momento in cui bisogna davvero decidere qualcosa. Questo schema — un sistema che sorveglia il processo abituale e una persona coinvolta solo in caso di anomalia — lo ritroviamo anche nella comunicazione di guasti agli utenti e nella risoluzione di incidenti IT di primo livello. Nelle aziende dove l'ambiente IT è semplice e stabile, questo cambiamento è già molto avanzato. Nelle aziende con ambienti complessi e articolati — o al di fuori dell'IT, come nel settore edile dove sistemi e processi sono meno standardizzati — questo procede più lentamente, semplicemente perché manca ancora la struttura di cui un sistema ha bisogno per poter controllare.
Questa non è una questione di personale né un'affermazione sulle funzioni. Riguarda esclusivamente il compito: l'esecuzione e il controllo dei backup, a prescindere da chi lo svolge oggi o da quanto tempo richiede in una specifica organizzazione.
Se questo compito nel suo ambiente specifico sia effettivamente in gran parte trasferibile all'IA dipende dal numero di sistemi, dalla sensibilità all'errore dei suoi dati e dal fatto che sia già presente un monitoraggio automatizzato con un protocollo di escalation. Per farsi una prima idea senza avviare subito un'analisi approfondita, può compilare la quickscan gratuita: dodici domande, senza necessità di account, con un'indicazione di quale parte delle ore in questo profilo lavorativo è oggi trasferibile all'IA. L'analisi completa del lavoro, che mappa attività per attività il lavoro della sua azienda, è ancora in fase di sviluppo.
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.