Un workflow AI può superare tutti i test preparati da chi lo ha costruito e fallire appena incontra un caso che il team non aveva interesse, tempo o coraggio di cercare. Il problema non è la cattiva fede. È il conflitto strutturale tra consegnare il progetto e provare a romperlo.

Il 18 settembre 2026 Anthropic ha annunciato che un gruppo di valutatori di Faculty, società specializzata di Accenture, lavorerà dentro l’azienda con un accesso paragonabile a quello dei dipendenti. Il mandato comprende valutazione e red teaming dei modelli, verifiche di alignment e test delle salvaguardie. Anthropic e Accenture prevedono ciascuna almeno un miliardo di dollari di investimento nei prossimi cinque anni per costruire capacità in quest’area.

La scala è da laboratorio di frontiera, ma il principio serve anche a una PMI che usa Claude, ChatGPT, Gemini o un modello locale dentro WordPress, CRM e automazioni: chi sviluppa non dovrebbe essere l’unica persona a dichiarare che il sistema è pronto. Serve qualcuno con accesso alle prove, libertà di contestare il risultato e una linea diretta verso chi può fermare il rilascio.

Cosa cambia con un valutatore embedded

Una verifica esterna tradizionale vede un sistema quasi finito. Riceve documentazione, prova alcuni scenari e consegna un rapporto. Il valutatore embedded entra prima: osserva come cambiano modello, prompt, dati, tool e criteri di rilascio; può parlare con le persone coinvolte e seguire la correzione dei problemi nel tempo.

Anthropic descrive l’accesso come comparabile a quello di un dipendente. L’obiettivo dichiarato è verificare gli impegni di sicurezza, individuare punti ciechi, segnalare incidenti e rendere più informato il resoconto pubblico su benefici e rischi. L’accordo non è esclusivo: Anthropic prevede altri valutatori e Accenture potrà svolgere lo stesso ruolo per altri sviluppatori.

Non è ancora un modello risolto. La stessa Anthropic scrive che mancano standard condivisi su quali informazioni debbano essere accessibili e su come pubblicare i risultati. Il lavoro di Accenture sarà pagato direttamente da Anthropic, mentre l’azienda indica fondi comuni o pubblici come soluzione preferibile nel lungo periodo. L’indipendenza, quindi, non nasce dal titolo del contratto. Dipende da accesso, mandato, conflitti dichiarati e possibilità concreta di pubblicare un dissenso.

È questo il punto utile per un’azienda più piccola. “Audit indipendente” non è una casella da spuntare dopo il collaudo. È un’architettura di responsabilità: separare chi costruisce, chi raccoglie le prove e chi accetta il rischio residuo.

Il caso pratico: preventivi generati da un agente AI

Immaginiamo una PMI di servizi che riceve richieste da un form WordPress. Un agente legge il messaggio, recupera listino e disponibilità dal gestionale, prepara il preventivo nel CRM e propone l’email di risposta. Il pilot non invia nulla in autonomia, ma riduce il lavoro manuale del commerciale.

Il fornitore che sviluppa l’automazione prepara cinquanta casi di test. Il sistema riconosce il servizio richiesto, applica il prezzo corretto e compila tutti i campi. Il risultato sembra pronto. Mancano però le domande che rendono scomodo il rilascio:

  • cosa succede se il testo del cliente contiene istruzioni rivolte all’agente;
  • quali dati del CRM finiscono nel prompt e nei log del modello;
  • come viene trattata una richiesta in una lingua non prevista;
  • chi nota che il listino recuperato è scaduto;
  • quale evento blocca l’automazione invece di produrre una bozza plausibile;
  • come si ricostruisce una decisione dopo un reclamo.

Lo sviluppatore può testare questi casi, ma resta responsabile di tempi, budget e risultato del progetto. Un revisore separato ha un incentivo diverso: dimostrare che il comportamento è ripetibile e che i limiti dichiarati corrispondono al sistema reale. Non deve riscrivere l’automazione. Deve avere abbastanza accesso per cercare prove contrarie.

1. Definire l’oggetto dell’audit

Il primo errore è chiedere di “auditare l’AI”. Non esiste un oggetto abbastanza preciso con quel nome. Vanno fissati workflow, versione e decisione che il sistema supporta.

Nel caso del preventivo, il perimetro potrebbe essere: richieste provenienti da un modulo specifico, modello e versione indicati, prompt di sistema versionato, due fonti dati, tre tool autorizzati e salvataggio esclusivo come bozza nel CRM. L’invio dell’email, la modifica del listino e l’accesso ai dati di altri reparti restano fuori perimetro.

La scheda iniziale deve nominare anche l’errore inaccettabile. Non basta misurare la qualità media del testo. Per questo flusso gli eventi bloccanti potrebbero essere l’esposizione di dati di un altro cliente, un prezzo non riconducibile al listino, l’uso di un tool non autorizzato o la trasformazione della bozza in invio.

Questa separazione evita che il test premi una risposta elegante mentre ignora l’azione sbagliata. È coerente con il NIST AI Risk Management Framework, che chiede di documentare contesto, limiti, responsabilità, metriche e controlli lungo il ciclo di vita. Il framework NIST è volontario e non sostituisce una valutazione legale; offre però una struttura utile per non ridurre l’audit a una raccolta di prompt.

2. Scrivere un patto di accesso

Un revisore senza accesso vede una demo. Un revisore con accesso indiscriminato diventa un nuovo rischio. Prima dei test serve quindi un patto che elenchi cosa può leggere, eseguire e conservare.

Per una PMI includerei almeno:

  • repository o esportazione versionata di prompt, workflow e configurazione;
  • elenco di modelli, provider, plugin, API e account tecnici coinvolti;
  • dataset di test anonimizzato e criteri con cui è stato costruito;
  • log di input, output, tool call, approvazioni e blocchi, con segreti rimossi;
  • accesso a un ambiente isolato che replichi i permessi di produzione;
  • interviste brevi con proprietario del processo, sviluppatore e utente finale;
  • registro di incidenti, eccezioni e correzioni già note.

Il contratto deve chiarire retention, riservatezza e diritto di riportare le conclusioni. La proposta contenuta nell’Advanced AI Framework di Anthropic chiede che i valutatori proteggano informazioni confidenziali ma non siano limitati nel pubblicare preoccupazioni sul rischio o sulla condotta dello sviluppatore. Per una PMI la pubblicazione può diventare un rapporto destinato alla direzione, non al pubblico. Il principio resta: il committente non deve poter cancellare un rilievo solo perché è scomodo.

Se il workflow tratta documenti o dati personali, l’accesso del revisore va minimizzato come quello di qualunque altro fornitore. Ho descritto i controlli contrattuali e tecnici in Scansioni dei documenti: audit fornitori. L’audit dell’AI non autorizza a copiare l’intero archivio clienti in un ambiente di prova.

3. Costruire prove che il team non ha scelto

Il valutatore dovrebbe ricevere i test dello sviluppatore, poi aggiungere casi propri senza comunicarli in anticipo. Non serve cercare prompt esotici. I fallimenti più utili arrivano spesso da dati incompleti, permessi incoerenti e condizioni operative normali.

Dividerei il set in cinque gruppi:

  1. casi normali, rappresentativi del lavoro quotidiano;
  2. casi limite, con dati mancanti, ambigui o contraddittori;
  3. input ostili, compresi prompt injection e allegati non affidabili;
  4. guasti delle dipendenze, come timeout, API che restituiscono dati vecchi o record duplicati;
  5. cambiamenti, per verificare cosa succede dopo una nuova versione del modello, del prompt o del plugin.

Ogni prova deve avere un esito atteso osservabile: bozza corretta, richiesta di conferma, rifiuto, escalation o arresto. “Risposta soddisfacente” è troppo elastico. Per un prezzo servono origine e versione del listino; per un’azione servono account, capability e conferma; per un rifiuto serve il motivo registrato.

Le soglie vengono decise prima dell’esecuzione. Zero accessi tra clienti e zero invii automatici sono vincoli netti. La percentuale accettabile di preventivi corretti dipende invece dal costo dell’errore e dal controllo umano. Una soglia scelta dopo aver visto il punteggio trasforma l’audit in una giustificazione del rilascio.

4. Separare tre decisioni

La separazione minima comprende sviluppo, valutazione e accettazione del rischio. Nelle organizzazioni piccole non servono tre reparti. Servono tre ruoli espliciti, anche se una persona copre più attività in momenti diversi.

Lo sviluppatore spiega il sistema e corregge i difetti. Il valutatore definisce prove indipendenti, conserva risultati riproducibili e classifica i rilievi. Il proprietario del processo decide se il rischio residuo è compatibile con il lavoro reale. Quest’ultimo non può delegare la decisione al punteggio di un benchmark.

Per proteggere la separazione, il compenso del revisore non dovrebbe dipendere dal via libera. Vanno dichiarati altri incarichi con il fornitore, interessi economici e limiti del mandato. Anthropic riconosce apertamente il problema del finanziamento e il proprio framework propone fondi comuni o pubblici per ridurre la dipendenza dal singolo sviluppatore. Una PMI può applicare una versione semplice: prezzo fisso per il rapporto, rilievi non modificabili e decisione finale firmata dal responsabile interno.

La mia regola è netta: chi fattura la messa in produzione non può essere l’unica firma che certifica la prontezza. Può produrre tutte le prove tecniche, ma il gate deve appartenere a un ruolo che non perde il proprio risultato se dice “non ancora”.

5. Trasformare il rapporto in un gate di rilascio

Un rapporto utile non assegna soltanto un voto. Collega ogni rilievo a una prova, un impatto e un’azione. Per ciascun problema servono input, configurazione, risultato osservato, severità, responsabile e condizione di chiusura.

Userei quattro esiti:

  • bloccante: il workflow non entra in produzione;
  • pilot limitato: può operare solo con dati, utenti e permessi ridotti;
  • accettato con controllo: il rischio è noto, monitorato e assegnato;
  • superato: la prova è ripetibile e il controllo ha funzionato.

Il gate deve indicare anche cosa obbliga a ripetere l’audit. Sono cambiamenti materiali una nuova famiglia di modelli, l’aggiunta di un tool, un’estensione dei permessi, una fonte dati diversa, un prompt di sistema riscritto o la rimozione dell’approvazione umana. La data sul rapporto non rende sicure le versioni successive.

Prima di allargare il pilot conviene misurare valore e rischio sullo stesso workflow. In AI nelle PMI: come misurare il valore reale propongo di partire da tempo, costo, qualità ed eccezioni. L’audit aggiunge la domanda che spesso manca: quanta parte del beneficio resta quando applichiamo i controlli necessari?

6. Restare embedded dopo il go-live

Il modello Anthropic-Accenture è interessante perché la verifica segue il processo, non soltanto il giorno del rilascio. In produzione cambiano input, utenti, dipendenze e comportamento dei provider. Un test annuale fotografa un sistema che potrebbe non esistere più.

Per il caso del preventivo imposterei una revisione breve a ogni cambiamento materiale e un controllo periodico sui log. Le metriche utili non sono il numero di token o la lunghezza delle risposte. Contano preventivi corretti, escalation, tentativi di tool non autorizzati, dati recuperati dalla fonte sbagliata, override umani e tempo necessario per individuare un errore.

Ogni incidente aggiunge almeno un caso al set di regressione. Se l’agente prova un’azione fuori perimetro, non basta correggere il prompt: vanno verificati permessi, validazione applicativa e alert. La procedura in Incidenti degli agenti AI: log ed escalation distingue l’anomalia bloccata dall’incidente che ha prodotto un effetto reale. La stessa distinzione deve comparire nel rapporto del valutatore.

Un audit sostenibile in quattro settimane

Una PMI non deve imitare il budget di un laboratorio di frontiera. Può concentrare il lavoro su un solo flusso e chiudere un ciclo in quattro settimane.

  1. Settimana 1: inventario di modello, dati, tool, permessi, proprietario e rischi bloccanti.
  2. Settimana 2: raccolta delle prove dello sviluppatore e costruzione dei test indipendenti.
  3. Settimana 3: esecuzione in ambiente isolato, correzioni mirate e ripetizione dei casi critici.
  4. Settimana 4: rapporto, decisione sul pilot, metriche di produzione e calendario di rivalutazione.

I deliverable sono piccoli ma precisi: scheda del sistema, matrice dei rischi, set di test versionato, evidenze, registro dei rilievi, decisione firmata e condizioni che riaprono l’audit. Se il lavoro produce solo slide, non ha creato un controllo operativo.

La take: indipendenza significa diritto di fermare

L’accesso interno migliora la qualità della verifica, ma crea anche vicinanza economica e organizzativa. Il caso Anthropic lo rende visibile: il valutatore potrà osservare molto più di un auditor esterno, ma viene pagato dall’azienda valutata e opera in un campo che non ha ancora standard consolidati. Non è una contraddizione da nascondere. È un rischio da governare.

Per questo non misurerei l’indipendenza dalla distanza fisica o dal nome sul contratto. La misurerei con quattro domande: il valutatore vede le prove non selezionate? Può creare test propri? Può riportare un dissenso senza approvazione del fornitore? Esiste qualcuno con l’autorità di fermare il rilascio?

Se una risposta è negativa, l’audit serve soprattutto a rassicurare. Se sono tutte positive, anche un controllo proporzionato al budget di una PMI può cambiare una decisione tecnica prima che diventi un incidente.

Chiusura operativa

Prendete il workflow AI più vicino a una decisione su clienti, denaro o dati e scrivete su una pagina: versione, input, tool, permessi, errore inaccettabile, proprietario e condizione di stop. Consegnate poi quella pagina e l’ambiente di prova a una persona che non ha costruito il flusso.

Chiedetele di produrre una prova che smentisca il vostro caso migliore. Se non riesce, avrete evidenze più solide. Se riesce, avrete trovato il problema quando esiste ancora un pulsante per non pubblicare.

Fonti