La domanda che gira in ogni sala macchine italiana è sempre la stessa: l’AI generativa è un acceleratore reale per chi gestisce infrastruttura, o l’ennesimo strato di hype da smaltire? La risposta onesta, dopo mesi di uso quotidiano in produzione, è che dipende da cosa le chiedi e da quanto sei disposto a verificare. Perché una cosa è certa: l’AI velocizza, ma non solleva mai il sistemista dalla responsabilità dell’output.
Dove accelera davvero: script, ricerca e primo drafting
Nella pratica quotidiana l’AI si è rivelata utile soprattutto in tre ambiti concreti. Il primo è la costruzione di script: bash, PowerShell, playbook Ansible, snippet Python per automazioni ripetitive. Non parliamo di scrivere l’automazione critica al posto tuo, ma di partire da una bozza funzionante in trenta secondi invece che da un foglio bianco. Il secondo è la ricerca: avere un unico punto dove interrogare sintassi, opzioni di comando, flag di configurazione poco documentati, senza saltare tra dieci schede del browser e forum del 2014.
Il terzo è il drafting rapido: bozze di documentazione, commenti a un manifest, spiegazioni da allegare a un ticket. In tutti questi casi il pattern che funziona è sempre lo stesso: chiedi, ottieni, verifichi la fonte, adatti al contesto reale. L’AI comprime i tempi morti, non il lavoro di giudizio. Chi la usa così — come faccio io — recupera ore ogni settimana. Chi la usa come oracolo infallibile, prima o poi paga il conto.
Dove ti frega: l’output plausibile ma sbagliato
Il rischio non è l’errore evidente, che vedi e scarti. Il rischio è l’output plausibile: sintatticamente perfetto, ben formattato, convincente… e concettualmente sbagliato. Un flag che nella versione del tool che usi in produzione non esiste più o ha cambiato comportamento. Una direttiva in un manifest Kubernetes che “compila” ma applica una policy di rete diversa da quella che intendevi. Uno snippet di configurazione storage che sembra ordinato ma imposta un valore di replica pericoloso.
Sono errori che passano tutti i controlli superficiali proprio perché l’AI è brava a sembrare autorevole. Ed è qui che si vede la differenza tra chi conosce l’infrastruttura e chi si affida ciecamente. Il presidio non negoziabile resta la verifica delle fonti e il test in ambiente controllato prima di qualsiasi apply. L’AI è un collega junior molto veloce e molto sicuro di sé: prezioso per accelerare, mai da far firmare da solo.
Il flusso: velocità sì, ma senza far uscire dati sensibili
Sul tema sovranità e riservatezza il principio guida è semplice: quello che entra nel prompt esce dal tuo perimetro. Per chi lavora su infrastruttura sovrana o gestisce dati di clienti, questo è il vero discrimine tra uso professionale e leggerezza da sanzione. Le regole minime che consiglio di adottare:
- Redaction sistematica: mai incollare IP reali, hostname, credenziali, nomi cliente, topologie complete. Si astrae, si anonimizza, si generalizza il problema prima di sottoporlo.
- Modelli locali o self-hosted per tutto ciò che tocca dati o configurazioni realmente sensibili: un LLM ospitato in casa, anche più modesto, tiene il dato dentro il perimetro e ti mette al riparo dai dubbi sul trasferimento verso provider extra-UE.
- SaaS solo per il generico: sintassi, concetti, drafting astratto. Comodo, potente, ma da usare come se ogni parola finisse in un log di terzi — perché spesso è così.
- Policy scritta e nota al team: cosa si può mettere nel prompt e cosa no. Senza regola esplicita, ognuno decide da sé, e basta un incollaggio distratto.
Il trade-off è reale e va accettato consapevolmente: il SaaS è più comodo e più capace, il modello locale è più scomodo e a volte meno brillante, ma è l’unico compatibile con un controllo sovrano serio e con l’impianto dell’AI Act. La regola pratica: più il dato è sensibile, più il modello deve essere vicino a te.
Cosa automatizzare per primo, cosa non delegare mai
A un CIO o CISO che vuole introdurre l’AI nel team ops il consiglio è di partire dalle cose ad alto attrito e basso rischio:
- Generazione di script e bozze di automazione, sempre sottoposte a review umana prima dell’esecuzione.
- Ricerca e consultazione come punto unico di interrogazione, con verifica delle fonti.
- Documentazione e commenti: drafting che poi il tecnico rifinisce.
E poi la lista di ciò che non va categoricamente delegato all’AI in autonomia:
- L’apply diretto in produzione di configurazioni o manifest senza revisione e test.
- Le decisioni di sicurezza: regole firewall, policy di accesso, gestione delle chiavi.
- La gestione dei dati sensibili del cliente o della topologia sovrana.
- Qualsiasi cosa dove un errore plausibile ma sbagliato costi più del tempo che ti fa risparmiare.
La regola d’oro è che l’AI accelera il lavoro dell’esperto, non lo sostituisce. Toglile la supervisione umana e stai solo automatizzando i tuoi errori più velocemente.
Il verdetto
Conviene muoversi. Non per moda, ma perché il guadagno di produttività su scripting, ricerca e drafting è concreto e misurabile già oggi, a patto di due condizioni non negoziabili: verifica sistematica di ogni output e un flusso che protegga il dato sovrano — redaction, modelli locali per il sensibile, policy scritta. Chi introduce l’AI con questa disciplina recupera tempo reale e resta compliant. Chi la vede come pilota automatico prima o poi la vedrà rompersi in produzione. Il verdetto dal campo è 1: muoversi sì, ma da professionisti che restano al comando.