Passa al contenuto principale
Intermedio

La scala della fiducia

What you'll learn
  • Perché l'autonomia è una scala — un piolo alla volta — non un interruttore on/off
  • I cinque pioli, mappati per raggio d'impatto e reversibilità (non per quanto sia intelligente il modello)
  • Tre regole per scegliere il piolo giusto: parti basso, dimensiona sul caso peggiore, scegli per task
  • Come la scala si mappa sulle modalità di permesso di Claude Code
  • Dove si colloca CLAUDE.md — il file che trasforma 'guardrail che ho in testa' in guardrail che l'agente può davvero seguire

"Quanto dovrei lasciare che l'IA faccia da sola?" è la domanda dietro quasi ogni decisione sugli agenti — permessi di Claude Code, impostazioni di auto-approvazione, se lasciare che uno script giri incustodito. Le persone tendono a rispondere con un singolo interruttore on/off: o supervisioni tutto, o lo scateni.

Ecco invece una lente che usa AILmanac:

L'autonomia non è un interruttore, è una scala. La sali un piolo alla volta, e il piolo su cui stai dovrebbe essere impostato da quanto grave sarebbe un errore — non da quanto ti fidi del modello.

L'intuizione chiave è che la giusta quantità di autonomia non ha quasi nulla a che vedere con quanto sia "intelligente" l'IA. Riguarda il raggio d'impatto (quanto danno fa un'azione sbagliata) e la reversibilità (quanto facilmente puoi annullarla). Un modello brillante che fa senza supervisione una cosa irreversibile è un setup peggiore di un modello mediocre che ne fa una reversibile.

I cinque pioli​

Un modello che troviamo utile è pensare a cinque pioli distinti, dalla minore alla maggiore autonomia:

PioloCosa fa l'IAQuando è appropriatoCosa lo rende sicuro
1. Solo suggerireTi dice cosa farebbe; non compie azioniLavoro ad alto rischio o irreversibile; un dominio in cui non ti fidi ancora; stai ancora imparando in cosa è bravaSei tu l'esecutore. Nulla accade senza che tu lo faccia a mano.
2. Bozza da revisionareProduce l'artefatto vero (codice, email, query) ma si ferma prima di applicarloL'output è concreto e puoi controllarlo a occhio più velocemente di quanto lo scriverestiUn umano vero legge prima che qualcosa abbia effetto. Un diff che guardi davvero, non a volo.
3. Agire su cose reversibiliEsegue direttamente, ma solo su azioni a basso rischio e facilmente annullabiliL'azione ha un undo pulito: modifiche in version control, scritture su un branch di scarto, qualsiasi cosa che un singolo comando ripristiniLa reversibilità è il guardrail. Il costo di un errore è "annullalo", non "spiegalo al legale."
4. Agire e poi riportareFa il lavoro in autonomia, poi ti mostra esattamente cosa ha fattoTask ripetitivi e ben delimitati in cui revisionare dopo costa meno che sbarrare primaUn audit trail completo e onesto — un log, un diff, un riepilogo — che leggi davvero dopo.
5. Agire in autonomia dentro guardrailGira incustodito dentro limiti rigidiLoop stretti e ben compresi che hai visto riuscire molte volteI guardrail fanno la supervisione. Confini rigidi che l'IA non può oltrepassare, più un kill switch.

Come usare la scala​

Tre regole rendono tutto questo pratico:

Guided walkthrough1 of 3
  1. È economico salire un piolo dopo aver visto qualcosa funzionare; è costoso ripulire dopo aver concesso troppo troppo presto. La prima volta che punti un agente su un nuovo tipo di task, scendi a Solo suggerire o Bozza anche se sospetti che possa gestire di più.

Mapparla su Claude Code​

Claude Code è un posto pulito per vedere la scala in azione, perché il suo sistema di permessi è essenzialmente un insieme di manopole per scegliere il tuo piolo:

  • Pioli 1–2 sono la postura cauta di default: Claude propone modifiche e comandi, e tu ne approvi ciascuno. Rivedi ogni diff prima che finisca a segno.
  • Piolo 3 consiste nel consentire specifiche chiamate a strumenti reversibili — modifiche a file dentro un repo git in cui puoi fare git restore, esecuzioni su un branch usa e getta — bloccando comunque qualsiasi cosa distruttiva.
  • Piolo 4 consiste nell'allow-listare categorie di azioni sicure così Claude procede senza chiedere su quelle, per poi leggere il transcript e i diff dopo.
  • Piolo 5 è autonomia più piena per un loop stretto e provato — ed è solo sicuro quando i guardrail sono reali: permessi limitati, una working directory ristretta, e la possibilità di fermarlo.

Il meccanismo che ti permette di salire in sicurezza è il tuo CLAUDE.md. Quel file è dove metti per iscritto i guardrail: cosa è sempre permesso, cosa non deve mai accadere, quali percorsi sono off-limits, quando fermarsi e chiedere. I guardrail che tieni solo in testa non vincolano un agente — i guardrail scritti in CLAUDE.md sì. Se non sei sicuro come formularli, il generatore di CLAUDE.md ti dà un punto di partenza strutturato.

Il riassunto onesto: non concedere autonomia perché l'IA sembra capace. Concedila perché l'azione è reversibile, il raggio d'impatto è piccolo, e i guardrail sono scritti. Poi sali un piolo alla volta man mano che arriva l'evidenza.

Verifica

0/3
  1. Hai un prompt provato che non ha mai fallito in ~200 esecuzioni di test. Dovresti saltare direttamente al piolo 5 (autonomo)?
  2. Un task è reversibile nel 95% dei casi. L'altro 5% tocca dati di fatturazione in produzione. Quale piolo?
  3. Dove vivono davvero i guardrail che ti permettono di salire i pioli in sicurezza?
Key takeaways
  • L'autonomia è una scala, non un interruttore — sali un piolo alla volta man mano che si accumula l'evidenza.
  • Fissa il piolo per raggio d'impatto e reversibilità dell'azione peggiore plausibile, non per quanto intelligente sembri il modello.
  • La reversibilità è il guardrail sul piolo 3; un vero audit trail è il guardrail sul piolo 4; limiti rigidi + kill switch sono il guardrail sul piolo 5.
  • Scegli il piolo per task, non per strumento — lo stesso agente può essere al piolo 4 per la formattazione e al piolo 1 per le cancellazioni sul database nella stessa sessione.
  • I guardrail stanno in CLAUDE.md e nelle impostazioni dei permessi — non nella tua testa.

Correlati​

Prossimo​