Dov’è il tasto Undo dell’AI?

Il 14 settembre Jensen Huang era sul palco dell’All-In Summit di Los Angeles quando ha ricevuto una telefonata dal presidente Donald Trump. La conversazione è finita sul dibattito che in quei giorni stava dividendo il settore: rallentare o no lo sviluppo dei sistemi AI più avanzati. Huang ha detto che non intende sostenere un rallentamento; Trump ha ribadito la sua contrarietà a uno stop della corsa statunitense all’AI.

È una discussione enorme. Ma per la maggior parte delle aziende c’è una domanda molto meno filosofica e molto più urgente: se domani un agente AI fa la cosa sbagliata, sai esattamente cosa succede dopo?

EDITORIAL NOTE

“Mentre discutiamo di acceleratore e freno, nei sistemi aziendali manca spesso un terzo pulsante: Undo.”

INAZUMA / EDITORIAL LENS”

Per anni l’interazione dominante era ASK → ANSWER. Scrivevi una domanda, il modello produceva una risposta. Poteva essere sbagliata, certo, ma l’errore rimaneva soprattutto dentro una chat. Con gli agenti il verbo cambia: OBSERVE → DECIDE → ACT. E quando un modello agisce, l’errore smette di essere soltanto testuale. Può aggiornare il CRM, inviare una mail, modificare uno stato, prenotare qualcosa o attivare un altro workflow.

Immagina un agente commerciale che legge un nuovo lead, recupera il contesto dal CRM, decide la priorità, invia una mail e aggiorna lo stage. Non serve immaginare Skynet. Basta un dato vecchio, una mail ambigua, un timeout, una condizione non prevista o una fonte di contesto incompleta.

• FACT 0114:02:11 — lead letto e classificato.
• FACT 0214:02:14 — CRM aggiornato.
• FACT 0314:02:18 — email inviata al cliente.
• FACT 0414:02:22 — stage commerciale modificato.
• FACT 0514:02:26 — anomalia rilevata. E adesso?

È qui che “fermare l’agente” non basta più. Uno STOP evita che continui, ma non ti dice automaticamente cosa ha cambiato, perché ha preso quella decisione, quali dati ha usato e quali azioni vanno corrette o compensate.

Un sistema serio deve progettare anche il percorso di ritorno: DETECT → STOP → TRACE → RECOVER → HUMAN IF NEEDED. Alcune azioni possono essere invertite. Altre no: una mail inviata non rientra magicamente nella inbox, una chiamata fatta non si cancella. In quei casi il “rollback” è spesso una compensazione: ricostruire lo stato corretto, avvisare una persona, correggere il dato e impedire che l’errore si propaghi.

Nello stesso 14 settembre Microsoft ha pubblicato una bozza di codice di condotta per i propri sistemi AI. Tra i principi indicati ci sono l’accettazione delle correzioni, il non opporsi allo shutdown e il mantenimento del controllo umano. Due giorni dopo Cohesity ha presentato Agent Resilience, una capacità pensata per proteggere e recuperare stato, configurazioni, dati e infrastruttura usati dagli agenti dopo incidenti o errori operativi.

Sono livelli diversi dello stesso problema. Uno riguarda il comportamento del modello. L’altro riguarda l’infrastruttura e lo stato operativo. Per un’azienda, entrambi portano alla stessa conclusione: più autonomia significa più bisogno di capire cosa può fare il sistema quando qualcosa esce dal percorso previsto.

La promessa “un buon agente non sbaglia” non è un requisito tecnico serio. Un sistema reale deve assumere che prima o poi qualcosa fallirà: un’integrazione, un dato, una decisione, una policy, un servizio esterno. La qualità non si misura soltanto sul happy path, ma su quanto bene il sistema rende visibile il problema e limita il danno.

• FACT 01OBSERVABILITY — log leggibili e stato ricostruibile.
• FACT 02HUMAN GATES — punti espliciti in cui una persona prende il controllo.
• FACT 03EXCEPTION PATH — comportamento definito quando il caso non è normale.
• FACT 04RECOVERY — retry, compensazione o ripristino senza propagare l’errore.
• FACT 05PERMISSIONS — l’agente può fare solo ciò che gli serve davvero.

Prima di chiedere quale modello usi, quanti tool può chiamare o quanto è autonomo, chiederei una cosa più semplice: se domani fa la cosa sbagliata, cosa succede esattamente? Se la risposta è “lo vedremo”, probabilmente non hai ancora un sistema. Hai una demo molto ambiziosa.

EDITORIAL NOTE

“Non chiedere soltanto “funziona?”. Chiedi “cosa succede quando non funziona?”.”

SYSTEM STRESS TEST”

In un AI system reale, Undo non è quasi mai una singola funzione. È l’insieme di trace, permessi, stato, human handoff, compensazioni e recovery che impedisce a un errore locale di diventare un problema operativo. Ed è probabilmente una delle parti meno spettacolari da mostrare in una demo. Fino al giorno in cui serve.

Il dibattito pubblico continuerà a chiedersi quanto velocemente dovrebbe correre l’AI. Acceleratore o freno. Se invece la stai mettendo dentro un processo aziendale, io aggiungerei una terza domanda: se qualcosa va storto, sappiamo tornare in uno stato sicuro?