Livelli di autonomia e classificazione del rischio

Perché il rischio si classifica prima dei controlli

Un agente che aggiunge un’etichetta a una issue e un agente che modifica il file di configurazione di una pipeline compiono entrambi una scrittura, ma il costo di un errore non è confrontabile: nel primo caso la correzione è un clic, nel secondo si può alterare ciò che finisce in produzione. La domanda da cui partire non è quindi quanta autonomia concedere all’agente in generale, ma quanto costa che quella singola azione sia sbagliata.

Conviene valutare tre dimensioni distinte. Il rischio operativo guarda alla reversibilità e all’ampiezza dell’effetto: un commento si cancella, un branch si abbandona, un rilascio no. Il rischio di sicurezza guarda ai privilegi che l’azione esercita, ai segreti che tocca e alle destinazioni di rete che raggiunge. Il rischio di conformità guarda a tracciabilità, separazione dei compiti e prove che un revisore esterno dovrà poter ricostruire.

Le protezioni di base del cloud agent di Copilot, che gira su GitHub e consegna il lavoro come pull request in bozza, sono già disegnate su questa logica. L’agente resta confinato a un solo branch, non spinge sul branch predefinito e non fa merge; la pull request in bozza deve essere revisionata e unita da una persona; i workflow di GitHub Actions restano bloccati finché qualcuno con permesso di scrittura li approva; e chi crea un’automazione non può approvare la propria pull request. Il controllo umano non è distribuito in modo uniforme: è concentrato dove l’effetto diventa difficile da annullare.

I livelli di automazione e la soglia di confidenza

Il prodotto mette a disposizione un modo esplicito per dichiarare questa scelta. In Settings, nella sezione Planning, sotto Agent suggestions for issues si trova l’impostazione Automation level, con quattro valori. Full control trattiene ogni modifica per la revisione e non applica niente da sé. Cautious, che è il valore predefinito, applica automaticamente solo le modifiche ad alta confidenza e mette in attesa tutto il resto. Balanced applica ciò che è di routine e privo di ambiguità, trattenendo i casi incerti. Full automation applica tutto, tranne ciò che l’agente stesso segnala come incerto.

Il meccanismo sotto è una confidence assegnata a ogni modifica su tre gradi, alta, media o bassa: il livello scelto per il repository stabilisce la soglia, e ciò che sta sotto diventa un suggerimento in attesa invece di un’azione compiuta. A ogni azione supportata si accompagna una rationale, cioè la ragione registrata della modifica, visibile accanto all’azione. Le proposte pendenti si accettano o rifiutano una per una, oppure in blocco, e si ritrovano con il qualificatore di ricerca has:suggestions.

Attenzione al perimetro, perché è l’errore più frequente su questo punto: questi livelli governano le modifiche alle issue, cioè etichette, campi, tipo di issue, assegnatari e chiusura, e valgono in modo trasversale quando quelle modifiche arrivano dalle automazioni del cloud agent, dai GitHub Agentic Workflows o dalle API REST e GraphQL. Impostare Full automation non elimina la revisione umana sul codice: la pull request in bozza continua a richiedere una persona che la unisca.

Esprimere lo stesso giudizio sulle altre superfici

La Copilot CLI, che lavora in locale, dimensiona il controllo sui tool anziché sui campi di una issue. Si restringe l’insieme disponibile con --available-tools o --excluded-tools e si concede o si nega l’esecuzione con --allow-tool e --deny-tool; le regole di negazione prevalgono sempre su quelle di concessione, anche in presenza di --allow-all. Le approvazioni legate a un percorso finiscono in permissions-config.json, i domini approvati nella lista allowedUrls delle impostazioni, e /reset-allowed-tools revoca quanto concesso nella sessione. La modalità autopilot porta l’agente a procedere da sé per più passaggi, e la documentazione stessa suggerisce di affiancarla al local sandboxing, che applica una politica sul filesystem con negazione per difetto, o di spostare la sessione in una cloud sandbox prima di concedere permessi ampi.

Nel Copilot SDK la stessa decisione si scrive in codice: l’hook onPreToolUse viene invocato prima che un tool esegua e restituisce un permissionDecision fra allow, deny e ask, con un permissionDecisionReason mostrato a chi usa l’agente. È il punto naturale in cui tradurre una classificazione di rischio in comportamento: consentire le letture, chiedere conferma sulle scritture in aree sensibili, negare il resto.

Nei GitHub Agentic Workflows, scritti in Markdown e compilati in un workflow di Actions, il vincolo è dichiarativo: i permessi partono in sola lettura e le scritture passano solo da ciò che si dichiara sotto safe-outputs.

permissions:
  contents: read
  issues: read
safe-outputs:
  create-issue:

Il tetto della conformità e ciò che l’esame verifica

L’autonomia concedibile ha un limite superiore che non appartiene al team di prodotto. Le policy di enterprise e organizzazione lo fissano, e in caso di conflitto fra enterprise prevale di norma l’impostazione più restrittiva, mentre fra organizzazioni le funzionalità sensibili risultano disattivate ovunque se lo sono in una. Sul versante Responsible AI la documentazione insiste sulla supervisione umana come tutela e sul rischio di eccessivo affidamento: un output errato può essere difficile da individuare, quindi la revisione va mantenuta soprattutto dove l’applicazione è critica. Ciò che rende sostenibile un livello alto di autonomia è la responsabilità ricostruibile a posteriori: commit firmati e attribuiti, log di sessione collegati, eventi nell’audit log e la vista delle sessioni degli agenti nei controlli AI a livello enterprise.

L’esame verifica proprio la capacità di calibrare, non di irrigidire. L’obiettivo dichiarato è massimizzare la velocità di consegna rimanendo conformi: un modello che chiede un’approvazione per ogni etichetta è sbagliato quanto uno che ne chiede nessuna, perché consuma l’attenzione dei revisori sulle azioni banali e la lascia esaurita quando arriva quella che conta.