Approvazioni umane e audit: nel mio CRM l'agente propone, la persona decide

In breve. In Accordo le decisioni di business sopra soglia aspettano un umano nominato: la policy è codice deterministico versionato, un test afferma che l'agente non può decidere al suo posto, e ogni verdetto lascia audit e trace. Lo provo in tre punti: una demo riproducibile, un rinnovo deciso dal vivo nel pilot, e l'esempio pubblico su accordo.dev. Pubblicato il 6 ottobre 2026.

Due rinnovi passano, il terzo aspetta

La scena è registrata, non raccontata. Da un progetto creato con lo scaffolder, un agente fa avanzare due rinnovi mentre il terzo — 80.000 euro — resta in approval_pending: richiesto dall'agente, deciso da nessuno, con lo step di valutazione della policy commerciale che mostra il punto esatto del fermo. La registrazione è prodotta con VHS dallo script nel repository: gli stessi comandi, rieseguiti, danno la stessa scena.

Il meccanismo dietro è una policy con una soglia di valore: a regime, un rinnovo pari o sopra la soglia aspetta una persona nominata. La regola vive in un file versionato, quindi ogni decisione porta con sé la versione esatta della regola che l'ha governata. Quando la soglia cambierà, le decisioni vecchie resteranno legate alla regola vecchia: la storia non si riscrive.

Il divieto scritto come test

La parte che mi interessa di più non è la soglia, è il divieto. Nei test del workflow c'è un'asserzione esplicita: l'attore dell'approvazione non può essere l'agente. Non è una convenzione documentata che un agente frettoloso può ignorare: è un test che fallisce se il percorso di approvazione accetta una decisione non umana.

Il limite sta scritto accanto, ed è onesto citarlo per intero: l'attore è affermato, non autenticato, e il divieto vale contro un agente onesto, non contro un attaccante. L'autenticazione non la fornisce il framework — la porta il deploy con il suo adattatore — e in sviluppo locale l'header attore è una dichiarazione, non un'identità. Un divieto con il perimetro scritto resta un controllo; senza, sarebbe una speranza con un test sopra.

È lo stesso principio che uso nei controlli progettati: chi esegue non certifica. Qui applicato al CRM: chi propone lo sconto non approva lo sconto.

Il rinnovo deciso dal vivo

Il 7 settembre 2026 il percorso è girato dal vivo nel pilot gestito: una persona autenticata ha sottoposto un rinnovo alla decisione, il worker l'ha liquidato e l'esito è rimasto persistito dopo il riavvio. A essere provata è la singola operazione del pilot, non l'intero catalogo dei casi d'uso né un servizio pubblico — la distinzione è scritta nel registro della milestone, non aggiunta da me.

Lo stesso giro era già passato in locale con entrambi i database riavviati: dashboard, POST, richiesta, claim, mutazione del tenant, settle, Done, riavvio di entrambi i database, ancora Done, ancora una riga sola. Il resoconto completo del pilot è nel diario di Accordo sul campo: qui conta il punto di principio. Una decisione umana che attraversa coda, worker e restart e resta una riga sola è una decisione che il sistema sa custodire, non solo registrare.

Il preventivo da 180.000 euro su accordo.dev

Il terzo punto di prova è pubblico. Su accordo.dev gira l'esempio del preventivo Q-1042 da 180.000 euro, scontato del 25% oltre la soglia del 20% fissata in policy. La transizione dell'agente viene rifiutata dalla policy standard-sales-discount v1; Sarah Rossi, sales manager nominata, approva alle 14:02; l'audit registra la decisione sul run 4d2a91 e il flusso riprende.

Tre dettagli mi sembrano quelli giusti da guardare. Il primo: la transizione rifiuta da sola, non chiede all'agente di comportarsi bene. Il secondo: l'approvatore ha nome e ruolo, non è "l'admin". Il terzo: il run resta tracciato, così la decisione si può rileggere settimane dopo con la versione di policy che la governava.

Le decisioni che restano umane per disegno

Le approvazioni sopra soglia sono il caso visibile, ma il disegno ne copre altri due che contano di più sul lungo periodo.

Il primo è la chiusura a tentativi esauriti: quando una richiesta operativa finisce i tentativi, resta visibile in attesa e solo un operatore può abbandonarla — i token di deploy vengono rifiutati con 403. Chiudere una richiesta esausta resta una decisione della persona, non un nuovo tentativo automatico. L'ho visto dallo stesso lato nel retry che riceveva la riga morta: cancellazione ed esaurimento sono decisioni, non errori da riprovare.

Il secondo è il confine legale: base giuridica, validità del consenso e interpretazione GDPR sono decisioni umane, scritte nei confini che non si muovono del pilot. Un caso d'uso resta differito proprio perché aspetta una decisione legale umana su quale tracciato di consenso autorizzi il contatto in uscita — e il documento dice chiaro che non è una chiamata ingegneristica.

Fatti e limiti, separati

Fatti: demo con rinnovo da 80.000 euro fermo in approval_pending, riproducibile dallo script VHS; policy a soglia con test che vieta la decisione all'agente; rinnovo deciso dal vivo il 7 settembre 2026 con esito persistito dopo restart; esempio pubblico Q-1042 con approvazione nominata e audit su run 4d2a91; chiusure esauste solo da operatore; confini legali umani.

Limiti: il divieto all'agente vale contro agenti onesti, non attaccanti; l'attore è affermato finché il deploy non fornisce autenticazione; la policy copre i rinnovi con una soglia di valore, non pipeline arbitrarie — il new business non passa dalla policy dei rinnovi. Una demo, un pilot e un esempio pubblico non misurano quanto il disegno regga in produzione: misurano che il disegno esiste e gira. La tesi completa è nel pillar sull'autonomia sotto controllo.

Domande frequenti

Perché non basta istruire l'agente a chiedere?

Perché un'istruzione è un auspicio con una probabilità sopra. Un test che fallisce se il percorso accetta una decisione non umana è un vincolo: l'agente può dimenticare l'istruzione, non può far passare il test.

Chi può chiudere una richiesta esausta?

Solo un operatore umano, con un comando dedicato. I token di deploy sono rifiutati. La richiesta resta visibile in attesa finché qualcuno non decide: niente sparisce in silenzio, niente si chiude da solo.

L'audit cosa registra esattamente?

Chi ha deciso, cosa, quando, sotto quale versione di policy, e su quale run. La combinazione che serve settimane dopo: non solo il verdetto, ma la regola che lo governava e il percorso che l'ha eseguito.