Controllo e sicurezza dell'AI: quando gli utenti vogliono disattivare e le difese impongono limiti

A South Philadelphia, il bibliotecario Charlie Bailey fa spegnere Apple Intelligence e Gemini a una ventina di adulti, telefono alla mano, menu proiettati, passo dopo passo. Il laboratorio si chiama “Avoiding AI”. La tesi è semplice: cresce la richiesta di controllo diretto sui dispositivi mentre i fornitori alzano barriere tecniche. Tra spegnere funzioni, attivare agenti vocali e applicare guardrail, chi progetta e testa prodotti AI deve bilanciare autonomia dell’utente e protezione del sistema.

Utenti che cercano controllo pratico: i workshop per disattivare l’AI

Bailey parte dalla frustrazione per strumenti “imposti” e dalla sensazione di trovarli “ovunque”. Poi traduce l’ansia in azione concreta. Sessanta minuti di lavoro. Prima la panoramica su chatbot e strumenti consumer. Poi la pratica: scorri le impostazioni, segui i passaggi, conferma sul tuo schermo. La didattica è sul dispositivo, non su slide. Conta l’esecuzione corretta, non l’opinione.

L’esempio non parla di boicottaggi o di principi astratti. Parla di gesture, menu, toggle. Mostra una domanda puntuale: sapere dove si trova l’interruttore. Quando un’istituzione di quartiere dedica un’ora a disattivare funzioni di produttori globali, segnala uno scarto tra design e aspettative. Il controllo esplicito non è un optional per una nicchia: è una richiesta con cui fare i conti in fase di prodotto e di QA.

Interfacce che spostano il controllo verso il dispositivo: comandi vocali e agenti

OpenAI porta ChatGPT Voice sull’app desktop di ChatGPT. La voce non resta alla conversazione: può avviare agenti e completare azioni sul computer. La modalità usa la famiglia di modelli vocali ChatGPT‑Live, presentata a inizio mese. L’obiettivo dichiarato è eseguire compiti quando servono. Il sistema funziona con ChatGPT Work e con Codex. Può attivare skill di “computer use”, consultare siti e applicazioni e poi completare l’azione.

Su macOS entra in gioco Appshots. Con il consenso dell’utente, l’app accede a ciò che è visibile sullo schermo, inclusi gli alt‑text. L’assistente può riferirsi a elementi a display mentre esegue i passaggi. La funzione è opzionale e si può scegliere se abilitarla. OpenAI descrive l’aggiornamento desktop come “più capace” della versione mobile al lancio.

Qui il controllo prende un’altra forma. La voce diventa un telecomando che orchestra più passaggi e che, se manca un dato, chiede un chiarimento e riprende l’esecuzione. È un aumento di potere operativo sul dispositivo. Ma è anche un ampliamento della superficie in cui automatizzare azioni. Il confine tra “io decido” e “l’assistente agisce” richiede segnali chiari, revoche rapide e tracciabilità. Sono scelte di UX e di architettura, non solo di modello.

Difese tecniche: hardening dei modelli e guardrail operativi

Sul lato difese, Anthropic indica Opus 5 come il modello “meno soggetto a prompt injection” tra i propri. La System Card lo riporta a pagina 73. Boris Cherny, il 25 luglio 2026, scrive: “Opus 5 is our least prompt injectable model yet.” La valutazione resta qualitativa. Cita PI evals e red teaming; non fornisce numeri o casi. Il confronto è interno all’organizzazione.

La linea è chiara: ridurre la probabilità che un’istruzione ostile scardini vincoli o policy. È hardening di modello, non un filtro a valle. Serve, ma non sostituisce processi e controlli applicativi. Soprattutto quando l’AI scrive codice o opera in ambienti che richiedono continuità di risposta.

AWS avverte proprio su questo punto: applicare Amazon Bedrock Guardrails ai flussi di generazione di codice in streaming, senza adattarli al carico, può causare throttling, costi più alti e latenza maggiore. Gli assistenti di coding producono output lunghi, in tempo reale, spesso su sessioni parallele. Ogni segmento in streaming attiva nuovi controlli. Le regole pensate per prompt brevi non reggono su output continui. Il numero di invocazioni cresce e mette pressione al sistema.

Guardrails include moderazione dei contenuti, protezioni contro jailbreak e prompt injection, meccanismi per evitare la fuoriuscita del prompt e filtri per PII. Nel coding, questi filtri bloccano pattern pericolosi e redigono dati sensibili. Ma ogni barriera ha un costo operativo. Il messaggio è operativo, non teorico: calibra i filtri al carico reale o paghi in tempo e denaro.

Il trade‑off operativo: fiducia, usabilità e costi per chi progetta e testa

Mettiamo in fila i tre movimenti. Primo: l’utente vuole interruttori chiari per evitare AI non desiderate e chiede istruzioni pratiche, dispositivo per dispositivo. Secondo: le interfacce vocali estendono l’azione locale dell’assistente e promettono esecuzione di compiti a più passaggi, con accesso a ciò che è a schermo se l’utente acconsente. Terzo: i team rafforzano i modelli contro attacchi come il prompt injection e applicano guardrail che filtrano codice e contenuti, con effetti misurabili su latenza e costi se non tarati.

Il filo è la gestione del rischio. Rischio di azioni non volute, di fuga di prompt o di PII, di abuso tramite injection. Ma anche rischio di esperienza spezzata, di rallentamenti e di blocchi eccessivi. Spostare il controllo verso l’utente richiede percorsi di disattivazione riproducibili e verificabili. Spostare il controllo verso l’assistente richiede autorizzazioni granulari e log delle azioni. Alzare le difese richiede budget di latenza e un piano per i picchi.

Per product manager e sviluppatori non basta “aggiungere un toggle” o “accendere i guardrail”. Serve decidere cosa succede in streaming, come si segmentano i controlli, quando si chiede consenso, e come si espongono errori e rifiuti in modo utile. Per i team QA il campo di prova si allarga: dal modello alla pipeline, dall’app al sistema operativo.

Cosa richiede la pratica quotidiana dei team tecnici

Tre pratiche emergono dai fatti.

• Test su dispositivi reali per le opzioni di disattivazione. Il laboratorio di Bailey mostra cosa vuol dire “istruzioni chiare” quando si lavora con menu diversi e impostazioni nascoste. Il QA deve riprodurre questi percorsi e verificarne l’efficacia, non solo documentarli.

• Test di integrazione per interfacce vocali che agiscono sul computer. Con ChatGPT Voice su desktop, la pipeline passa dal parlato all’azione. Su macOS, Appshots aggiunge la vista dello schermo, con consenso. Vanno provati i casi in cui l’assistente chiede chiarimenti, revoca l’azione o opera con informazioni parziali.

• Stress test dei guardrail su flussi in streaming. AWS segnala throttling, costi e latenza quando si applicano regole non tarate a output lunghi e continui. Il QA deve misurare quante invocazioni attivano i filtri nei vari segmenti e come cambia il throughput quando aumentano le sessioni parallele.

Infine, la scelta del modello incide sul profilo di rischio. Adottare un modello che, per chi lo costruisce, risulta “molto difficile da prompt injectare” riduce una classe di attacchi, ma non cancella la necessità di controlli applicativi e di percorsi di consenso espliciti. Il confronto di Cherny resta interno. Non sostituisce valutazioni indipendenti né copre altre superfici di attacco.

La tensione di partenza resta produttiva se viene resa visibile nelle interfacce e misurata nelle pipeline: quando gli interruttori esistono, quando gli agenti dichiarano cosa faranno e quando i filtri dicono quanto costano in latenza, allora scelte di prodotto e di rischio diventano negoziabili dai team e, soprattutto, dagli utenti direttamente coinvolti.