Human in the Loop: il controllo umano nell’era della Agentic AI

Tempo di lettura: 16 minuti

Negli ultimi mesi mi sono trovato più volte davanti alla stessa tentazione: collegare un altro strumento. Sì, in stile, “ancora uno e poi basta” (come recitava lo slogan di una vecchia pubblicità di patatine fritte).

Un nuovo MCP, una chiave API, un accesso aggiuntivo, un’integrazione che evita due passaggi manuali. Dentro Cursor, ma non solo. Il meccanismo è sempre lo stesso: se uno strumento può leggere i dati, un altro può elaborarli e un terzo può eseguire l’azione, perché non mettere tutto in fila e lasciare che il processo vada avanti da solo?

Tecnicamente ha senso.

Ed è proprio quando tutto comincia a funzionare bene che nasce il problema.

Perché a un certo punto non stai più chiedendo alla AI di aiutarti a svolgere un compito. Le stai concedendo una parte crescente del processo decisionale, insieme agli strumenti necessari per trasformare quella decisione in un’azione.

Può leggere file, interrogare servizi esterni, usare API, modificare codice, accedere a repository, lavorare sul browser, generare contenuti, analizzare dati. In alcuni casi può anche concatenare queste operazioni senza chiederti molto altro.

È il terreno naturale della Agentic AI: sistemi che non si limitano a produrre una risposta, ma perseguono un obiettivo attraverso una sequenza di azioni.

Affascinante. O, come si dice oggi, Top.

Ma più capacità concediamo a un agente, più importante diventa decidere dove deve fermarsi.

Per me il punto è esattamente questo.

Non voglio rinunciare all’automazione. Voglio evitare che l’automazione diventi opaca.

Human in the Loop, non Man in the Middle

Nelle prime note vocali da cui è nato questo articolo avevo dettato MITM.

Era semplicemente l’acronimo sbagliato nel posto sbagliato. Così vedete che questo blog non è perfetto, io non sono perfetto e le cavolate le diciamo tutti.

BTW – I brief per gli articoli di questo blog nascono spesso, anche se non sempre (a volte sono scritti con la mia penna stilografica), da appunti vocali dettati a Letterly App, che come ho spiegato in altre occasioni, ad es. sul canale Telegram @pistakkioseo, è un’app che mi ha cambiato letteralmente l’approccio professionale, AI assisted. Ma torniamo alla nostra sigla.

MITM significa Man in the Middle ed è un concetto ben noto nella sicurezza informatica: un soggetto si interpone nella comunicazione tra due endpoint e può intercettare, alterare o osservare ciò che passa tra loro.

Qui stiamo parlando di tutt’altro. Ma voglio sfruttare l’imprecisione che avevo fatto nel mio brief vocale per puntualizzare.

Il termine corretto è HITL, Human in the Loop.

In un sistema Human in the Loop, l’essere umano non osserva semplicemente ciò che la macchina sta facendo. Rimane parte attiva del processo e interviene nei punti in cui è necessaria una decisione, una verifica o un’autorizzazione.

Il sistema può analizzare, proporre e preparare l’azione.

Ma non procede oltre senza un intervento umano.

Curiosamente, l’idea di stare “in mezzo” al processo non era poi del tutto sbagliata.

L’acronimo sì.

Ed è proprio la posizione dell’umano dentro il processo che oggi mi interessa di più. Non perché la AI debba essere rallentata per principio, ma perché l’autonomia non è un valore assoluto.

È una variabile da progettare.

HITL, HOTL e il posto dell’umano nel loop

Non esiste un solo modo per mantenere l’essere umano dentro un processo automatizzato.

La distinzione più utile, soprattutto quando si parla di sistemi agentici, è quella tra Human in the Loop e Human on the Loop.

Nel modello HITL, l’intervento umano è parte necessaria del processo. Il sistema può analizzare, proporre, preparare un’azione, ma a un certo punto deve fermarsi. Serve una decisione umana prima di procedere.

In forma molto semplice:

propose → approve → act

È il modello che preferisco quando l’azione è sensibile, difficile da annullare, strategica o può produrre conseguenze esterne.

Nel modello HOTL, Human on the Loop, invece, il sistema può procedere autonomamente entro determinati confini, mentre l’essere umano osserva, controlla e mantiene la possibilità di intervenire.

Qui il flusso diventa:

act → observe → intervene

La distinzione non è soltanto terminologica. È una questione di architettura del controllo, come approfondisce anche una recente review accademica su HITL e human oversight.

La letteratura recente sull’Human-in-the-Loop e le linee guida europee sull’AI distinguono esplicitamente questi diversi livelli di supervisione umana. Non tutti i processi richiedono infatti un’approvazione preventiva per ogni singola azione, ma questo non significa che debbano diventare opachi o incontrollabili.

Il punto, quindi, non è stabilire se HITL sia “migliore” di HOTL.

È decidere quale livello di autonomia abbia senso concedere a ogni singolo task. Nella pratica uso entrambi, a seconda del tipo di task.

Ed è qui che, secondo me, la Agentic AI smette di essere soltanto una questione di efficienza e diventa una questione di progettazione del lavoro.

Quando un agente ha troppe chiavi

Una delle cose che mi rende più prudente nei workflow agentici è la facilità con cui si finisce per concedere troppi accessi allo stesso sistema.

Una API key per interrogare un servizio. Un token OAuth per un altro. Un MCP per collegare un ambiente esterno. Accesso al filesystem. Al browser. A un repository. A WordPress. A strumenti di analisi.

Presi singolarmente, sono tutti passaggi ragionevoli.

Il problema nasce quando cominciano a sommarsi.

Non perché una integrazione esponga automaticamente una chiave API o renda insicuro il sistema. Sarebbe una semplificazione sbagliata. Il punto è che ogni nuovo collegamento aumenta la superficie di fiducia del workflow.

Aumentano i secret da gestire, le doppie verifiche, i componenti autorizzati ad agire, i privilegi concessi e soprattutto il possibile blast radius di un errore.

Se un agente sbaglia mentre può soltanto leggere un dataset, il danno è limitato.

Se lo stesso agente può leggere il dataset, modificare un file, pubblicare una pagina, intervenire su un repository e usare credenziali verso servizi esterni, lo stesso errore assume un peso completamente diverso.

Qui torna utile un principio antico e molto poco glamour della sicurezza informatica: least privilege. Sì, insomma: Less is More.

Un sistema dovrebbe avere soltanto i permessi necessari per svolgere quel task.

Non quelli che potrebbe eventualmente usare.

È una distinzione apparentemente conservativa, ma in realtà molto pratica. Perché quando un workflow cresce, la domanda non dovrebbe essere soltanto:

“Che cosa posso collegare?”

Dovrebbe diventare:

“Che cosa ha davvero bisogno di poter fare questo agente?”

Un solo cervello con troppe mani

Strumenti come Cursor, Claude, Kimi o sistemi più apertamente agentici come OpenClaw (che ho testato, ma che per ora considero troppo pervasivo per i miei workflow professionali) rendono evidente un cambiamento importante: la AI non lavora più soltanto dentro una finestra di chat.

Sempre più spesso può leggere file, modificarli, eseguire comandi, interrogare servizi esterni, usare il browser, accedere a repository, orchestrare altri strumenti e intervenire direttamente sull’ambiente di lavoro.

In altre parole, ha molte più mani.

Ed è qui che per me cambia la natura del problema.

Il punto non è stabilire se un agente sia “affidabile” in senso astratto. Il punto è capire quante capacità operative stiamo concentrando dentro lo stesso sistema e con quale livello di fiducia.

Me ne accorgo banalmente anche attraverso Avira, il sistema di protezione che uso sulle mie workstation. Con strumenti come Cursor, Claude o Kimi attivi, in alcuni casi sembra di avere un flipper acceso sulla scrivania: avvisi, suoni, segnalazioni di attività sospette, tentativi di accesso, modifiche, comportamenti che un antivirus interpreta come potenzialmente anomali e che blocca o mette in quarantena.

Nel mio caso, molti di questi avvisi sono falsi positivi legati ad attività che ho autorizzato personalmente.

Ma proprio per questo non li ignoro.

Controllo comunque che ciò che Avira segnala corrisponda a ciò che mi aspettavo che il tool facesse.

Perché il problema dell’Agentic AI non è che un agente possa fare molte cose.

È che possa fare troppe cose con lo stesso grado di fiducia.

E quando lettura, decisione ed esecuzione finiscono tutte nello stesso punto, mantenere il controllo non è più una formalità.

Diventa una scelta architetturale.

Il pulsante “Approve” non basta

Una delle illusioni più comode dei workflow agentici è pensare che basti inserire un punto di approvazione umana per poter dire: perfetto, abbiamo mantenuto l’Human in the Loop.

Formalmente può anche essere vero. Occhio, l’AI Slop viene fuori da questa “metodologia”.

Sostanzialmente, dipende da che cosa è successo prima.

Immaginiamo un agente che abbia già raccolto i dati, deciso quali fossero rilevanti, escluso quelli considerati marginali, interpretato i segnali, formulato un’ipotesi, scelto una strategia e preparato l’azione da eseguire.

A quel punto arriva una finestra:

Approve?

Se tutto ciò che resta all’essere umano è premere sì o no, il problema non è più soltanto quello dell’automazione.

È quello della perdita di contesto.

Per approvare davvero qualcosa, devo poter capire almeno tre cose: che cosa è stato fatto, perché è stato fatto e su quali elementi si basa la proposta che sto autorizzando.

Altrimenti non sto controllando il processo.

Sto semplicemente mettendo una firma umana alla fine.

Questo è il punto in cui l’Human in the Loop rischia di diventare una forma elegante di rubber stamping: la macchina svolge il ragionamento, prepara la decisione e conserva gran parte del contesto operativo; l’essere umano interviene solo nell’ultimo centimetro del percorso.

Ma un’approvazione senza comprensione non è vera supervisione.

Il problema diventa ancora più evidente quando il sistema lavora bene.

Se un agente sbaglia spesso, siamo naturalmente portati a controllarlo. Se invece produce per settimane risultati plausibili, coerenti e generalmente corretti, il nostro livello di attenzione tende inevitabilmente a scendere.

È umano.

Ed è proprio lì che nasce il rischio più sottile.

Non quello dell’errore evidente, ma quello della fiducia automatica.

Il pulsante “Approve” può allora trasformarsi rapidamente da momento decisionale a gesto riflesso.

Leggo velocemente.
Mi sembra corretto.
Confermo.
Si va avanti.

A quel punto l’essere umano è ancora formalmente e tecnicamente dentro il loop, ma cognitivamente potrebbe esserne già uscito.

Per questo, quando penso a HITL, non penso a un checkpoint messo alla fine di una catena automatizzata.

Penso a un workflow nel quale l’umano conserva abbastanza osservabilità da poter ricostruire il percorso.

Quali dati sono stati usati?
Quali sono stati esclusi?
Quale ipotesi ha formulato il sistema?
Quali alternative sono state scartate?
Che cosa succede se autorizzo l’azione?
E, soprattutto, posso tornare indietro?

Non serve trasformare ogni processo in un audit forense.

Serve però evitare che l’efficienza cancelli la leggibilità.

Perché più un agente diventa autonomo, più il valore dell’intervento umano si sposta dal semplice “dare il permesso” alla capacità di comprendere il contesto nel quale quel permesso viene richiesto.

Questo, per me, è il vero Human in the Loop.
Non esserci formalmente.
Sapere perché sei lì e a che punto sei.

Un esempio concreto, per me, è ilparoliere.online, il dizionario della lingua italiana che ho costruito da zero con la AI.

Oggi contiene 600 lemmi, tutti letti, riletti, controllati e validati da me, uno per uno, prima della pubblicazione. Non sono molti rispetto ai grandi vocabolari della lingua italiana, ma la quantità non è il criterio principale.

La selezione è deliberata.

Non ci sono, almeno per ora, parole come “gatto” o “cane”, senza nulla togliere agli amici a quattro zampe. Preferisco lavorare su termini che abbiano una maggiore densità concettuale, linguistica, tecnica o culturale e sui quali abbia senso aggiungere anche una vera nota editoriale.

La AI mi ha permesso di accelerare enormemente progettazione, sviluppo, strutturazione dei contenuti e gestione di una quantità di dati che, affrontata in modo tradizionale, avrebbe richiesto tempi molto più lunghi.

Ma il processo non è mai stato “costruisci un dizionario e fammi sapere quando hai finito”.

Sono rimasto Human in the Loop dall’inizio alla fine.

Ho definito l’architettura, validato le scelte, controllato le singole fasi, corretto gli errori, affinato la struttura e deciso quando un passaggio fosse abbastanza solido da diventare la base di quello successivo.

La differenza si vede soprattutto oggi.

Il progetto è scalabile, può crescere senza dover essere ripensato ogni volta da capo e mantiene una cura molto alta anche nei dettagli più piccoli.

Non diventerà probabilmente mai un Treccani e non ne ha nemmeno l’ambizione. Ma, mantenendo lo stesso ritmo editoriale, arrivare progressivamente a qualche migliaio di lemmi è un obiettivo perfettamente realistico.

Con una differenza per me importante: Il Paroliere non ha pubblicità, non ha cookie, non ha tracker e non ha paywall. È un progetto aperto e artigianale, non una macchina per accumulare pagine.

Non perché la AI abbia lavorato poco.

Al contrario, ha lavorato moltissimo.

Ma ha lavorato dentro un processo nel quale la delega non coincideva con la rinuncia al controllo.

Per me è HITL applicato bene: non intervenire manualmente su tutto, ma restare responsabili dell’architettura dentro cui l’automazione lavora.

Anche nell’analisi dei dati voglio vedere dove metto le mani

Lo stesso principio vale nell’analisi dei dati.

La AI è molto utile per aggregare dataset, trovare anomalie, classificare query, confrontare periodi, proporre cluster, evidenziare pattern e ridurre una massa di informazioni a qualcosa di leggibile.

È esattamente uno dei punti nei quali l’automazione ha più senso.

Ma un pattern non è ancora una decisione.

Se in Google Search Console vedo una perdita di impression, posso chiedere alla AI di individuare le query coinvolte, confrontare intervalli temporali, separare brand e non brand, raggruppare URL e cercare correlazioni.

Tutto molto utile.

Il problema nasce se salto direttamente dall’anomalia alla conclusione.

Una perdita di visibilità può dipendere da un problema tecnico, da un cambiamento nella SERP, dalla stagionalità, da una contrazione della domanda, da una variazione del search intent, da una cannibalizzazione interna, da un competitor oppure semplicemente da rumore statistico.

Il dato non contiene automaticamente la propria interpretazione.

Ed è qui che voglio ancora vedere dove metto le mani.

Non significa fare manualmente ciò che una macchina può elaborare meglio e più velocemente. Significa conservare la sequenza del ragionamento: sapere quali dati sono entrati nell’analisi, quali confronti sono stati fatti e perché una certa ipotesi è diventata più credibile delle altre.

La AI può abbreviare il percorso.
Non deve renderlo invisibile.

Perché anche la separazione dei task, a volte, non è inefficienza.

È parte stessa dell’analisi.

Il Metodo Pistakkio®: automatizzare l’attrito, non il giudizio

Nel Metodo Pistakkio®, il criterio che applico è semplice: automatizzare ciò che crea attrito, non ciò che richiede giudizio.

Raccolta dati, normalizzazione, confronto, classificazione, preparazione di output e prime analisi sono attività che la AI può accelerare molto.

Le priorità, invece, restano un altro mestiere.

Decidere dove intervenire, con quale ordine, con quale rischio accettabile e con quale impatto sul cliente non è un passaggio accessorio del workflow.

È il workflow.

Per questo non mi interessa costruire sistemi nei quali tutto procede autonomamente fino a un’approvazione finale.
Preferisco distribuire i punti di controllo dove servono davvero.
Non perché ogni task debba passare da me. Magari anche sì 😊.
Ma perché automatizzare il lavoro non deve significare automatizzare la responsabilità.

Non tutti i task meritano la stessa autonomia

Non tutti i processi richiedono lo stesso grado di controllo.

Alcuni task possono essere delegati completamente: operazioni meccaniche, delimitate, reversibili e facilmente verificabili.

Altri possono essere delegati con verifica: la AI produce un output, ma prima che venga utilizzato qualcuno lo controlla.

Poi ci sono i casi nei quali serve un vero Human in the Loop: il sistema prepara, propone, arriva fino a un certo punto e si ferma. L’azione successiva richiede una decisione umana.

Infine, c’è il modello Human on the Loop: il sistema procede autonomamente entro limiti definiti, mentre l’essere umano mantiene osservabilità e possibilità di intervento.

Non vedo questi livelli come una scala evolutiva in cui l’obiettivo finale sia eliminare l’umano.

Sono semplicemente diversi modi di distribuire l’autonomia.

La domanda utile non è:

“Quanto posso automatizzare?”

È:

“Quale grado di autonomia è coerente con il rischio, la reversibilità e il valore del task?”

Esiste anche l’Human out of the Loop.

Ma non è un achievement da sbloccare.

Approvare dal telefono non cambia il problema

Gli strumenti stanno rendendo sempre più semplice separare il luogo in cui il task viene eseguito da quello in cui viene approvato.

Una workstation può continuare a lavorare mentre una richiesta di autorizzazione arriva sul telefono.

È comodo.

Ma non cambia la natura del problema.

La qualità della supervisione non dipende dal dispositivo sul quale compare il pulsante.

Se ricevo una richiesta mentre sono in giro e vedo soltanto:

Approve?

la possibilità tecnica di premere “sì” non significa necessariamente che abbia abbastanza contesto per decidere bene. Magari sono in autobus.

Anche qui il punto resta lo stesso.

Non conta soltanto essere nel loop.

Conta esserci con abbastanza informazioni da capire che cosa stiamo autorizzando.

Chiosa: la responsabilità resta umana

La AI entrerà sempre più profondamente nei processi di lavoro.

Non è una previsione particolarmente audace. Sta già succedendo.

Per questo la responsabilità non riguarda più soltanto come usiamo noi la AI, ma anche come la usano le persone con cui lavoriamo.

Dipendenti, colleghi, consulenti, collaboratori esterni.

Quando affidiamo una parte del nostro lavoro a qualcuno, oggi stiamo affidando implicitamente anche il modo in cui quella persona decide di delegare alla AI.

E questo cambia il criterio con cui scegliamo le collaborazioni.

Non basta più chiedersi se qualcuno sia competente.

Occorre capire se sa dove fermare l’automazione, che cosa controllare e di che cosa assumersi la responsabilità.

Perché la AI può eseguire, proporre, accelerare e coordinare.
Ma la responsabilità non si delega.
E non si automatizza.

---

Tecnologia, ma con giudizio

Quattro letture su AI, ricerca, fiducia e potere delle piattaforme.

• Google e la ricerca AI: cosa direbbe Aaron Swartz Quando la risposta arriva prima ancora dei documenti, cambia il modo in cui cerchiamo, verifichiamo e costruiamo conoscenza.
• Motore di ricerca in ottica privacy: cercare non è mai neutrale Google, Qwant, DuckDuckGo, Brave ed Ecosia raccontano compromessi diversi tra comodità, riservatezza e sovranità digitale.
• HAL 9000 e i chatbot perlocutivi: quando la persuasione diventa circonvenzione Più una macchina appare competente, paziente e umana, più diventa necessario capire quali effetti vuole produrre su chi le parla.
• Dentro l’Intelligenza Artificiale: cosa direbbe oggi Pier Paolo Pasolini La AI osservata come ambiente culturale e dispositivo di omologazione, non soltanto come strumento tecnico da usare o rifiutare.