Gli esseri umani si aggrappano per la vita mentre l’IA accelera la consegna del software

Per gran parte della storia dello sviluppo software, le persone hanno rappresentato il controllo. Un sviluppatore apporta una modifica, un’altra persona la revisiona, qualcuno la approva e, infine, viene distribuita.

L’IA sta accelerando l’intero sistema mentre continuiamo a cercare di mantenere le persone al centro. Gli sviluppatori ora possono creare codice e modifiche in pochi secondi. Gli agenti possono operare su repository, strumenti, infrastrutture e altri sistemi con un coinvolgimento umano ridotto.

Il nostro istinto è reinserire gli esseri umani nel processo. Rivediamo la pull request, approviamo la chiamata allo strumento, controlliamo la modifica e confermiamo la distribuzione perché vogliamo assicurarci che l’IA non abbia fatto qualcosa che non doveva fare. Ci stiamo aggrappando per la pelle.

Quel istinto ha senso. La revisione umana ci ha fornito un modo per mantenere il controllo mentre il software avanza verso la produzione. Ma l’IA sta iniziando a operare a una velocità e a un volume tali che gli esseri umani non possono più rimanere l’unità di scala per la governance.

L’IA si sta già muovendo più velocemente della revisione umana

La prima ondata di IA generativa nello sviluppo software si è concentrata principalmente sull’aiutare gli sviluppatori a scrivere codice più velocemente. Questo da solo cambia la consegna del software. Più codice significa più modifiche alle applicazioni, alle infrastrutture e ai database che attraversano test, sicurezza, revisione, distribuzione e produzione.

Il problema non è necessariamente che l’IA crei modifiche di qualità inferiore. Produce più modifiche, più velocemente. Se il controllo di tutta questa nuova produzione è affidato a un’altra persona che revisiona ogni modifica, alla fine la logica non regge più.

Stiamo già vedendo segnali in tal senso. Anthropic ha recentemente riferito che gli utenti di Claude Code approvano circa il 93 % delle richieste di permesso. L’azienda ha scoperto che richieste ripetute possono generare affaticamento da approvazione, con le persone che prestano meno attenzione man mano che il numero di approvazioni aumenta. Anthropic sta ora utilizzando un classificatore automatico per valutare le azioni e bloccare quelle potenzialmente pericolose, invece di chiedere a una persona di approvare tutto.

Riflettete su cosa significhi questo per la supervisione umana. Se qualcuno clicca su approva il 93 % delle volte, aggiungere un’altra approvazione non garantisce necessariamente più controllo. A un certo punto, l’umano diventa un ulteriore passaggio nel flusso di lavoro.

Possiamo usare l’IA per creare più software. Non possiamo rispondere creando un’operazione di revisione umana altrettanto ampia dietro di essa.

L’IA sta passando dalla creazione di codice all’esecuzione di azioni

Gli assistenti di codifica hanno conferito all’IA un ruolo nello sviluppo. Gli agenti danno all’IA la capacità di partecipare a gran parte del ciclo di vita del software (SDLC). Un agente può ricevere un obiettivo, decidere come realizzarlo, utilizzare strumenti, osservare i risultati e regolare le proprie azioni successive.

Nell’ingegneria del software, ciò può significare modificare file, eseguire comandi, interagire con repository, chiamare API, testare codice o lavorare con l’infrastruttura. Le persone stanno anche diventando più a loro agio nel lasciare che gli agenti operino autonomamente. In uno studio su milioni di interazioni uomo‑agente, Anthropic ha scoperto che gli utenti esperti di Claude Code hanno utilizzato l’approvazione automatica completa in più del 40 % delle sessioni, circa il doppio rispetto ai nuovi utenti.

Ciò non significa che gli agenti autonomi gestiscano ambienti di produzione ovunque oggi. Non è così. Tuttavia, lo sviluppo software ci offre uno sguardo anticipato su dove sta andando questa tendenza.

Oggi, l’IA genera più cambiamenti e la revisione umana inizia a essere sotto pressione. Successivamente, l’IA parteciperà a più fasi del SDLC. Alla fine, gli agenti creeranno, convalideranno, distribuiranno, osserveranno e correggeranno le modifiche con un coinvolgimento umano molto ridotto.

Ad ogni fase, eliminiamo un altro punto in cui una persona forniva il controllo. La domanda passa dal chiedersi se l’IA possa svolgere il lavoro a cosa l’IA dovrebbe essere autorizzata a fare autonomamente.

Il permesso non è autorità

Gli agenti hanno bisogno di accesso per svolgere lavori utili. Un agente che aiuta a distribuire software può necessitare di accesso a un repository, a un sistema CI/CD, a un ambiente cloud o a un database. Revocare tale accesso significa anche togliere gran parte di ciò che rende l’agente utile.

Tuttavia, accesso e autorità non sono la stessa cosa. Concedere a un agente il permesso di accedere a un sistema non significa che debba avere l’autorità di eseguire ogni azione disponibile all’interno di quel sistema.

Il controllo degli accessi tradizionale può indicarci se un agente ha il permesso di accedere a qualcosa. Abbiamo anche bisogno di un modo per determinare se l’azione specifica che desidera compiere debba avvenire. Questo diventa più importante quando il sistema che prende la decisione può interpretare un compito in modo diverso rispetto alla persona che lo ha assegnato, incontrare un ostacolo e scegliere un percorso alternativo, o utilizzare uno strumento legittimo in un modo non previsto.

OWASP descrive una versione di questo problema come Agenzia eccessiva. Evidenzia funzionalità, permessi e autonomia eccessivi come cause di azioni dannose e raccomanda un’approvazione indipendente per le azioni ad alto impatto.

NVIDIA sta affrontando lo stesso problema a livello di architettura. Il suo Open Agent Safety Platform posiziona l’applicazione delle politiche al di fuori dell’agente e sottolinea un punto semplice: non ci si può aspettare che un agente governi completamente il proprio comportamento.

Questo dovrebbe influenzare il modo in cui costruiamo l’SDLC dell’IA. Un agente potrebbe aver bisogno di autorizzazione per accedere a un database, a un ambiente infrastrutturale o a un sistema di distribuzione. Ciò non significa che l’agente debba decidere autonomamente che ogni modifica che desidera apportare sia sicura.

L’IA prende decisioni basate su probabilità. Non dovremmo consentire che ognuna di queste decisioni diventi automaticamente un’azione contro un sistema critico.

L’Umano nel Loop Non Può Essere la Soluzione Completa

La risposta ovvia è mantenere una persona davanti alle azioni di IA con conseguenze. Per alcune decisioni, è proprio quello che dovremmo fare. L’errore è trasformare il “human in the loop” nella risposta per ogni decisione.

Se ogni azione compiuta da un agente richiede che qualcuno la riveda e prema approva, abbiamo ricreato il collo di bottiglia che l’IA doveva eliminare. Peggio, un numero elevato di approvazioni può trasformare la supervisione in un’abitudine. Una persona che clicca approva tutto il giorno non esercita necessariamente il giudizio.

Dobbiamo essere più deliberati su dove avvengono le decisioni. L’IA può prendere decisioni entro il compito che le abbiamo assegnato. Le policy possono gestire le decisioni dove le regole sono già note. Le persone possono gestire le eccezioni e le decisioni che richiedono realmente un giudizio.

Una modifica a basso rischio che rispetta le policy stabilite non dovrebbe richiedere l’attenzione di qualcuno. Una modifica che viola la policy dovrebbe fermarsi automaticamente. Un’eccezione con conseguenze significative per il business, la sicurezza o le operazioni potrebbe richiedere l’intervento di una persona.

Questo è un modello molto diverso dal semplice inserimento di un umano in ogni loop. L’obiettivo non è eliminare gli esseri umani. È impedire che l’attenzione umana diventi il fattore da cui dipende ogni azione e rendere il percorso governato il percorso più semplice.

Posizionare il Controllo Dove Avviene l’Azione

Le imprese non standardizzeranno un unico modello di IA o un unico agente. Gli sviluppatori utilizzeranno diversi copiloti. I team sperimenteranno diversi modelli. L’IA comparirà all’interno degli strumenti per sviluppatori, dei prodotti di sicurezza, delle piattaforme dati e delle applicazioni interne.

Cercare di costruire un processo di governance diverso per ogni strumento di IA non sarà scalabile. Il controllo deve trovarsi più vicino all’azione che l’IA intende compiere.

Se una modifica generata dall’IA entra in una pipeline di distribuzione, dovrebbe affrontare le stesse policy di una modifica generata da un umano. Se un agente vuole modificare l’infrastruttura, i dati o un database di produzione, i controlli su quel sistema non dovrebbero scomparire perché è cambiato l’attore.

La fonte della modifica non determina il rischio. È la modifica stessa a farlo. Un sviluppatore, un assistente di codifica, un processo automatizzato o un agente autonomo possono percorrere un percorso diverso verso la stessa azione, ma tale azione può comunque essere soggetta alla stessa policy prima di diventare decisiva.

Ciò consente anche alla tecnologia di evolversi senza costringere le aziende a ricostruire la governance ogni volta. I modelli cambieranno. Gli agenti diventeranno più capaci. I controlli sui sistemi critici possono rimanere coerenti.

NIST adotta un approccio simile basato sul rischio nel suo AI Risk Management Framework, che considera la governance come qualcosa che deve operare lungo l’intero ciclo di vita dell’IA piuttosto che come un’unica approvazione finale. Per la consegna del software, ciò significa inserire i controlli nel percorso già intrapreso dall’IA invece di aggiungere un ulteriore processo manuale.

Quando l’Umano Se Ne Va, le Prove Non Possono Andarsene Con Lui

C’è un altro problema nascosto nel modello di revisione umana. Quando si rimuove la persona dal processo, non si perde solo la revisione. Si può anche perdere la persona che ha contribuito a dimostrare che la revisione è avvenuta.

Ciò diventa un problema serio per le aziende con requisiti di sicurezza, conformità e audit. Devono comunque sapere cosa è cambiato, chi o cosa ha avviato la modifica, quale policy è stata applicata, se è stata superata, chi ha approvato un’eccezione, dove è stata eseguita la modifica e cosa è accaduto successivamente.

Non si può automatizzare la modifica e lasciare le prove manuali. In un processo guidato dall’uomo, i team possono ricostruire le prove in seguito da ticket, approvazioni, log delle pipeline, screenshot e conversazioni. Questo approccio diventa più difficile man mano che il volume delle modifiche cresce e risulta irrealistico quando le macchine creano ed eseguono modifiche in modo continuo.

Le prove devono diventare parte del processo di consegna. Le decisioni di policy, le approvazioni, le eccezioni, le distribuzioni e i risultati dovrebbero generare registri mentre il lavoro avviene. Le prove di audit diventano un sottoprodotto della consegna del software invece di qualcosa che i team assemblano a posteriori.

Ciò lascia due compiti distinti per la governance in un SDLC guidato dall’IA. Prima di un’azione, determinare se dovrebbe avvenire. Dopo l’azione, dimostrare cosa è accaduto.

Gli Umani Non Scompariranno. Il Nostro Lavoro Sta Cambiando.

È un istinto comprensibile misurare il controllo in base a quante volte una persona è coinvolta. Più revisioni sembrano più sicure. Più approvazioni sembrano più sicure. Tenere un umano in ogni loop sembra più sicuro.

L’IA metterà alla prova questa ipotesi. Se l’IA continua ad aumentare la quantità di software che possiamo creare, gli umani non saranno in grado di revisionare ogni modifica, approvare ogni azione, monitorare ogni distribuzione e ricostruire ogni decisione in seguito. Cercare di farlo rallenterà l’IA o trasformerà la supervisione umana in un timbro di approvazione.

Il ciclo di vita del software basato sull’IA necessita di una diversa divisione del lavoro. L’IA può gestire più attività mentre le policy regolano le decisioni ripetibili e le persone intervengono quando qualcosa richiede davvero un giudizio. Le evidenze dovrebbero essere generate automaticamente lungo il percorso.

Daremo più accesso all’IA perché è così che diventa utile. Daremo più autonomia agli agenti perché è così che ne otteniamo più leva. La sfida è assicurarsi che maggiore accesso e autonomia non diventino silenziosamente autorità illimitata.

Gli esseri umani non devono aggrapparsi più strettamente. L’obiettivo non è meno controllo. È un modello di controllo che non dipende dal fatto che dobbiamo trattenere ogni decisione noi stessi. Dobbiamo creare i controlli che ci permettano di allentare la presa senza perdere il controllo.