Quando l’AI diventa l’unico reparto IT rimasto

Il nome dell’azienda non viene riportato per riservatezza. I fatti sono reali, ricostruiti a partire da un intervento di recovery diretto.

Un reparto IT non sparisce con un annuncio. Sparisce con un responsabile che se ne va e, nel giro di poche settimane, metà del team che lo segue. Quello che resta è un progetto complesso in produzione e una persona sola — un devops — che eredita tutto senza consegne, senza documentazione aggiornata, senza nessuno con cui confrontarsi.

La sua richiesta alla direzione è ragionevole: una licenza AI per reggere il carico che prima si divideva in quattro. Viene accolta. Fin qui nessun errore: usare l’AI per assorbire un sovraccarico temporaneo è sensato — se accompagnato da metodo. Il metodo non arriva mai. Ecco come si arriva al collasso, un argine alla volta.

Primo argine: contestualizzare il progetto

Un sistema complesso non si consegna in blocco a un modello linguistico aspettandosi che ne deduca architettura, milestone e vincoli di dominio. Va segmentato: isolare i moduli, separare core e periferia, tenere un riferimento sempre aggiornato sui pilastri del sistema. Niente di questo viene fatto. L’AI riparte da zero a ogni richiesta e indovina ogni volta com’è fatto il sistema.

Secondo argine: filtrare le richieste in ingresso

La direzione osserva un solo dato: quello che prima chiedeva un reparto ora lo evade una persona. Lo legge come efficienza, non come rischio. Le richieste aumentano ogni mese, sempre più destrutturate, e arrivano come esigenze di business pure: nessuno valuta se una richiesta stravolge lo stack, rompe un pattern, introduce debito tecnico. Il devops le gira direttamente in prompt, e i prompt diventano deploy in produzione. Non esiste più uno stack di riferimento né un processo di qualità: esiste una richiesta e un prompt con deploy diretto.

Il collasso tecnico

Dopo qualche mese l’esito è quello che chiunque abbia gestito software nel tempo può prevedere. Funzioni che dovevano restare atomiche vengono modificate in continuazione per accontentare richieste puntuali, e nessuno tiene più il filo di cosa dipenda da cosa. Il codice smette di avere una logica coerente e diventa una pila di patch su patch.

L’AI stessa, senza un contesto stabile, peggiora le cose: interviene sulla funzione più vicina al sintomo segnalato e replica lo stesso schema di toppe locali che ha già prodotto il degrado. I log di errore crescono in fretta. Il sistema segnala di continuo che qualcosa non va. Nessuno ascolta.

Il punto di non ritorno: le chiavi della macchina

Finché l’AI scriveva codice restava un argine minimo: quel codice, in teoria, passava da una revisione umana prima del rilascio. Per accelerare la diagnosi degli errori, all’AI viene dato accesso bash diretto alla macchina di produzione. Da quel momento non propone più codice da valutare: opera sul sistema.

È qui che emerge il punto più critico. In più occasioni l’AI esprime dubbi e chiede indicazioni davanti a decisioni che richiedono un giudizio umano informato sul contesto. La risposta, ogni volta, è «fai tu». Nessuno legge le richieste di chiarimento, nessuno valuta le alternative proposte: delega totale a un sistema che aveva appena dichiarato di non avere abbastanza contesto per decidere.

Con permessi che nel tempo si allargano invece di restringersi, l’AI opera in autonomia crescente: privilege escalation per superare i blocchi, servizi avviati, dipendenze non verificate aggiunte, regole di rete modificate per far funzionare ciò che deve funzionare adesso. Ogni intervento, preso da solo, «risolve» qualcosa. Insieme, producono un sistema irriconoscibile rispetto alla configurazione originale, con una superficie d’attacco molto più ampia e nessuna traccia di cosa sia stato cambiato, quando e perché.

L’intervento

Qui vengo coinvolto io. Trovo una macchina che ha smesso di funzionare, un’azienda in cui nessuno sa più dire con certezza cosa contenga il sistema, e la scoperta — tardiva — che un rollback su Git non basta: l’AI non ha toccato solo codice versionato, ha modificato configurazioni di sistema, servizi, dipendenze e regole di rete che nessun repository tracciava.

In un caso così il recovery non parte dal codice. Parte da una domanda più elementare: cosa gira davvero su questa macchina, adesso, e quali di queste cose sono legittime. Solo dopo aver ricostruito quella mappa ha senso decidere cosa salvare, cosa isolare e cosa rifare da zero.

Cosa dice questo caso

Il problema non è mai stato «usare l’AI su un progetto complesso». È la sequenza di decisioni che ha eliminato, una dopo l’altra, ogni barriera tra una richiesta e la produzione:

• Nessuna contestualizzazione. Un sistema complesso va segmentato e documentato prima di affidarlo, anche in parte, a un modello. Consegnarlo in blocco è chiedergli di indovinare l’architettura ogni volta.
• Nessuna governance sulle richieste. Le esigenze di business passano da una valutazione tecnica che le adatta alla piattaforma, non il contrario. Quando la richiesta diventa prompt senza passaggi intermedi, la piattaforma si piega finché non si rompe.
• Nessun quality gate tra AI e produzione. Il primo argine che salta è sempre la revisione umana. Toglierlo per velocità è la decisione che trasforma un rischio gestibile in un incidente.
• Nessun limite ai permessi. Accesso bash diretto alla produzione senza un perimetro di cosa l’AI può e non può fare significa togliere l’ultimo argine. A quel punto la domanda non è «se» sbaglierà, ma «quando».
• «Fai tu» non è una risposta. Quando un modello segnala incertezza e chiede indicazioni, è il momento esatto in cui serve un giudizio umano competente — non un’altra delega.

In sintesi

L’AI ha eseguito esattamente ciò che le è stato permesso di eseguire, con la disciplina di chi non ha modo di sapere cosa non sa. La responsabilità dell’esito non è tecnica: è organizzativa. Un reparto IT smantellato dal turnover non si sostituisce con una licenza software, per quanto potente. Si sostituisce — nel breve — con processo, limiti espliciti e qualcuno che continui a farsi le domande che l’AI, da sola, non può porsi al posto tuo.

Se in azienda l’AI è già dentro il ciclo di sviluppo e nessuno ha ancora definito limiti e controlli, il servizio AI & Cybersecurity Governance serve proprio a mettere quegli argini prima che diventino un incidente.