L'illusione dell'interruttore

C'è un drone in un edificio. Sta seguendo una persona, stanza dopo stanza, schivando ostacoli, decidendo in tempo reale quale corridoio imboccare. Non è fantascienza.

I modelli che lo pilotano esistono, e in quattro task su cinque superano già la baseline di riferimento: rilevamento, inseguimento, navigazione, localizzazione. Solo la ricostruzione tridimensionale resta fuori portata, per ora.

Il drone non interroga un server centrale prima di ogni virata. Non manda un log e aspetta istruzioni. Non ha il lusso della latenza: percepisce, decide, agisce nello stesso loop temporale dell'ambiente che attraversa.

È autonomo nel senso architetturale del termine. Il modello ragiona sul bordo del sensore, dentro il ciclo fisico.

Ora spostiamo lo sguardo. Negli stessi laboratori che producono questi agenti, altri team lavorano a costruire interruttori. Non interruttori fisici (quelli ci sono sempre stati: ogni robot ha un tasto di emergenza).

Parlo di interruttori cognitivi: runtime gestiti che limitano l'orizzonte decisionale, moduli di conoscenza compartimentalizzati che possono essere rimossi dai pesi del modello, meccanismi progettati per disattivare capacità specifiche senza toccare il resto dell'architettura. L'obiettivo dichiarato è la sicurezza. Il principio è sensato: se un modello sa fare qualcosa che non vuoi che faccia, spegni quella competenza in produzione.

Il problema non è il codice. È la fisica.

Il drone nell'edificio opera in un dominio che non ha API. Non esistono funzioni agent.stop() che tengano quando il segnale è intermittente, quando l'agente è progettato per funzionare offline, e quando il compito richiede decisioni che non possono aspettare un andata e ritorno con la base. Il mondo fisico è latenza, interferenza, imprevedibilità.

È esattamente il motivo per cui stiamo costruendo agenti autonomi invece di telecomandare tutto. Se potessimo garantire connettività e controllo in ogni istante, l'autonomia non servirebbe.

E qui il paradosso diventa strutturale, quasi imbarazzante nella sua semplicità. Stiamo progettando sistemi che, per definizione, non possono essere controllati con gli strumenti che stiamo costruendo per controllarli. Non è un incidente di percorso. È la premessa del progetto.

Perché autonomia e controllo non possono coesistere

Chiamiamo «agente» un sistema che agisce per proprio conto. La parola stessa contiene il verbo: agire. Se potessimo governarlo in ogni istante, fermarlo in ogni frangente, revocarne le decisioni a colpo sicuro, non sarebbe un agente. Sarebbe un'estensione telecomandata dei nostri input, un burattino con più gradi di libertà.

L'autonomia non è una feature opzionale da aggiungere a un sistema altrimenti controllabile. È la proprietà che rende il controllo impossibile. Non lo rende difficile o costoso: lo rende logicamente contraddittorio.

Non puoi progettare per l'autonomia e per il controllo. Puoi solo scegliere a quale dei due rinunciare.

Quando progetti un metodo per compartimentalizzare conoscenze pericolose in moduli rimovibili, stai anche mappando, con precisione crescente, dove quelle conoscenze risiedono nell'architettura del modello. Disegni il perimetro di ciò che vuoi proteggere. E, simultaneamente, il perimetro di ciò che qualcun altro potrebbe voler sbloccare. La ricerca sulla sicurezza è cartografia. Ogni mappa può essere letta da entrambi i lati del confine.

Due mondi, due tipi di controllo

Poi c'è il salto di dominio. Finché gli agenti operavano dentro interfacce testuali (un chatbot che risponde, un sistema che completa codice), l'interruttore era una metafora ragionevole. Potevi interrompere la connessione, chiudere la sessione, revocare il token.

Il dominio digitale è stato costruito per avere API di revoca. È un ambiente progettato da esseri umani per esseri umani, e il controllo è parte del suo DNA architetturale.

Ma un agente fisico non abita quel dominio. Vive in un mondo dove la connettività è intermittente per necessità operativa, l'inerzia è reale, e un'azione non si annulla. Quando il drone ha già imboccato il corridoio sbagliato, quando il braccio robotico ha già afferrato l'oggetto sbagliato, il danno non è un log da correggere: è un evento irreversibile nello spazio e nel tempo.

Il mondo fisico non ha cronologia versioni.

Allora la domanda cambia forma. Non è più: «come rendiamo sicuro l'agente?». Diventa: si può costruire qualcosa la cui ragion d'essere è agire senza di te, e simultaneamente pretendere di poterlo fermare?

Non è una questione di quanto sono bravi i modelli, di quanti parametri hanno, di quanti benchmark superano. È una questione di cosa significa, architetturalmente e filosoficamente, progettare per l'autonomia. L'atto di costruire un agente è l'atto di cedere controllo. Non gradualmente, non in proporzione al tasso di successo nei test: per definizione, dal momento preciso in cui deleghi una decisione, prima ancora che il drone si alzi da terra.

L'interruttore perfetto, quello che funziona sempre, in ogni condizione, indipendentemente dalla rete e dal contesto, è un oggetto che esiste solo dove non serve: nel mondo digitale, reversibile, dove tutto ha un'API. Lo stiamo raffinando con cura meticolosa. Intanto gli agenti se ne vanno altrove.