Progetta l’approvazione umana in una piattaforma di negoziazione basata sull’IA

La governance di una piattaforma di negoziazione basata sull’IA dovrebbe partire da una regola chiara: l’automazione può analizzare, redigere, formulare raccomandazioni e comunicare entro limiti definiti, ma non dovrebbe vincolare l’azienda, superare l’autorità delegata, risolvere eccezioni soggette a controllo o inviare comunicazioni sensibili ai fornitori senza l’approvazione di una persona responsabile.

Un solido flusso di approvazione delle negoziazioni distingue quindi l’assistenza ordinaria dalle decisioni che comportano rischi commerciali, legali, di conformità, finanziari o relazionali. L’approvazione umana deve essere una decisione esplicita di una persona dotata delle competenze e dell’autorità pertinenti, non il silenzio, un avviso non aperto o un clic formale dopo l’esecuzione.

Risposta rapida

Richiedi l’approvazione umana per impegni vincolanti, deroghe ai limiti commerciali approvati, eccezioni alle policy, concessioni rilevanti, deroghe agli avvisi di rischio e azioni significative rivolte ai fornitori. Consenti l’automazione per domande esplorative, pianificazione, analisi, promemoria e proposte entro un perimetro negoziale preautorizzato. Ogni approvazione dovrebbe indicare la decisione, le evidenze, l’esposizione cumulativa, l’approvatore, l’autorità, la data e l’ora e l’azione conseguente.

Quali azioni richiedono l’approvazione umana?

Una piattaforma di negoziazione dovrebbe fermarsi e richiedere l’approvazione quando un’azione rientra in una di queste sei categorie.

1. Un impegno vincolante

L’approvazione umana resta obbligatoria prima di accettare un’offerta finale, aggiudicare una fornitura, firmare o modificare un contratto, emettere un ordine di acquisto, rinnovare un accordo o assumere un impegno di pagamento.

I canali elettronici non rendono innocui gli impegni. L’US E-SIGN Act stabilisce che, in generale, a un contratto, una firma o un documento non può essere negato valore legale per il solo fatto di essere elettronico. Per questo i controlli tecnici sull’esecuzione sono importanti: chiedere ai dipendenti di verificare in seguito un’accettazione generata dall’IA non sostituisce adeguatamente la prevenzione dell’invio non autorizzato (E-SIGN Act).

2. Una deroga al perimetro negoziale

Il perimetro negoziale è il limite leggibile da una macchina entro il quale può operare la negoziazione basata sull’IA. Dovrebbe comprendere:

• Fasce di prezzo e costo totale approvate
• Volume massimo ed esposizione complessiva nel tempo
• Durata del contratto e struttura dei rinnovi
• Concessioni consentite
• Clausole approvate e formulazioni alternative
• Fornitori e persone giuridiche ammissibili
• Tipi di dati e comunicazioni consentiti
• Autorità per utente, categoria, entità e transazione

Il superamento di qualsiasi limite richiede la decisione della persona competente. Un’elevata confidenza del modello non modifica questo requisito: la confidenza descrive un risultato, non l’autorità aziendale.

3. Un’eccezione a policy o procedura

Gli esempi includono una decisione di fornitura esclusiva, una deroga alla gara competitiva, un fornitore non approvato, una due diligence incompleta, un acquisto retroattivo, un ordine suddiviso, un metodo di pagamento non standard o la deroga a un avviso di rischio.

La persona che richiede un’eccezione non dovrebbe essere l’unica ad approvarla. La negoziazione con intervento umano è significativa solo se il revisore può respingere autonomamente la richiesta e bloccare l’esecuzione.

4. Una concessione rilevante

Una concessione trasferisce valore economico, legale o strategico. Gli esempi includono un prezzo più alto, un pagamento anticipato, volumi garantiti, esclusiva, un impegno più lungo, rimedi ridotti, livelli di servizio inferiori, rinuncia a pretese o minori tutele per privacy e sicurezza.

La piattaforma dovrebbe calcolare le concessioni in modo cumulativo. Cinque concessioni apparentemente modeste possono comportare un’esposizione maggiore di una sola concessione chiaramente rilevante. Dovrebbe inoltre registrare che cosa ha ottenuto in cambio l’acquirente: una concessione senza contropartita merita un esame più rigoroso.

5. Una questione legale, etica, normativa o di controllo finanziario

Sono necessari approvazione ed eventuale escalation in caso di corrispondenze con elenchi di sanzioni o di titolarità, sospetti di corruzione, conflitti di interesse, sospetta manipolazione delle offerte, problemi relativi a informazioni sulla concorrenza, indicatori di frode, questioni riguardanti dati personali, dubbi sui controlli delle esportazioni e possibili effetti contabili rilevanti.

L’OFAC descrive lo screening basato sul rischio e la valutazione degli avvisi per determinare se un’attività debba essere bloccata, respinta, interrotta o autorizzata. Le sue linee guida evidenziano inoltre carenze nella due diligence, nello screening, nel processo decisionale e nell’escalation (introduzione all’OFAC). Il negoziatore non dovrebbe revocare unilateralmente un blocco obbligatorio di conformità.

6. Un’azione significativa rivolta al fornitore

Richiedi l’approvazione per rifiuti, esclusioni, sospensioni, risoluzioni, accuse di condotta scorretta, minacce di contenzioso, lettere di diffida, richieste di recupero, dichiarazioni pubbliche o messaggi che potrebbero ragionevolmente essere interpretati come posizione definitiva dell’azienda.

Un messaggio può creare rischi anche se non perfeziona un contratto. Contano il tono, l’autorità apparente e le conseguenze operative.

Una matrice riutilizzabile dei diritti decisionali

Usa la matrice seguente come punto di partenza, quindi adattala all’autorità delegata, al rischio della categoria, alle giurisdizioni e ai controlli esistenti. È una raccomandazione, non uno standard legale universale.

Alcuni controlli non dovrebbero mai poter essere aggirati dal solo negoziatore: blocchi relativi alle sanzioni, autorità di firma e di acquisto, separazione dei compiti, limiti di finanziamento, regole sui conflitti di interesse, restrizioni sulle informazioni relative alla concorrenza e divieti riguardanti sicurezza, privacy, blocchi legali o segnalazioni normative.

Progetta il flusso di lavoro attorno all’autorizzazione, non al giudizio del modello

Il modello non dovrebbe decidere se la propria azione è autorizzata. Separa i componenti:

1. Il modello propone. Redige una domanda, un’opzione, una concessione o una risposta.
2. Un servizio deterministico di policy valuta. Verifica autorità, soglie, clausole, stato del fornitore, esposizione cumulativa, classificazione dei dati e tipo di azione.
3. Il flusso di approvazione delle negoziazioni instrada la richiesta. Individua gli approvatori necessari e impedisce l’autoapprovazione quando è richiesta indipendenza.
4. La persona decide. L’approvatore accetta, respinge, modifica, richiede ulteriori evidenze o sospende la negoziazione.
5. Un servizio di esecuzione agisce. Solo un’azione approvata viene rilasciata, firmata, pubblicata o inviata.
6. La registrazione di audit chiude il ciclo. Input, output, approvazioni, modifiche, comunicazioni in uscita e impegni conseguenti vengono conservati.

Questa separazione attribuisce all’IA una discrezionalità limitata, anziché un mandato generale. I team che confrontano le architetture dei sistemi possono valutare come un flusso di lavoro di negoziazione basato sull’IA governato supporti la preparazione e l’esecuzione, mentre una valutazione più ampia di software per la negoziazione negli acquisti dovrebbe verificare integrazioni, controlli sull’autorità e verificabilità.

Il NIST AI Risk Management Framework richiede ruoli, responsabilità, canali di comunicazione e processi di supervisione umana definiti. Il relativo Playbook raccomanda inoltre di individuare le capacità che richiedono supervisione e di verificare che tale supervisione funzioni in modo affidabile (NIST AI RMF Core). Sono principi utili per progettare i controlli, anche se le linee guida del NIST non prescrivono una matrice universale per gli acquisti.

Che cosa deve vedere un approvatore

Un avviso che dice «approvazione richiesta» non è sufficiente. Il fascicolo di approvazione dovrebbe rispondere a queste domande:

• Quale azione viene proposta?
• Quale limite, clausola, policy o regola di autorità ha attivato la revisione?
• Qual è la motivazione commerciale?
• Che cosa è già stato concesso nel corso dell’intera negoziazione?
• Quale valore reciproco è stato ottenuto?
• Quali informazioni mancano o sono incerte?
• Quali alternative restano disponibili?
• Che cosa succede se l’approvatore respinge o ritarda l’azione?
• Chi ha l’autorità e sono necessarie ulteriori approvazioni?
• Quale messaggio o documento esatto verrà inviato al fornitore?

L’interfaccia dovrebbe consentire al revisore di respingere, modificare o sospendere l’azione proposta. Una revisione significativa richiede contesto e tempo sufficienti, competenze adeguate, autorità effettiva e un meccanismo efficace per fermare l’azione.

Per preparare il flusso di lavoro prima di creare una richiesta di approvazione, consulta Un processo di pianificazione della negoziazione in otto fasi.

Un modello di approvazione a quattro livelli

Un modello pratico di negoziazione con intervento umano può classificare le azioni in quattro livelli.

Anche il livello 1 deve essere soggetto a vincoli. Una domanda ordinaria non deve divulgare informazioni riservate, implicare un’accettazione o invitare alla condivisione di informazioni sensibili per la concorrenza. Le bozze destinate ai fornitori possono includere formulazioni non vincolanti finché una persona autorizzata non rilascia la versione finale.

Esempio ipotetico: concessioni di rinnovo che si accumulano

Esempio ipotetico: le cifre sono scelte illustrative per la progettazione, non parametri di riferimento esterni.

Un team di acquisti aziendale autorizza una piattaforma di negoziazione a discutere il rinnovo di un software entro i parametri approvati di prezzo, durata, trattamento dei dati e livelli di servizio. Durante lo scambio, l’IA propone tre mosse:

1. Accettare un modesto aumento del prezzo unitario.
2. Prolungare la durata in cambio di un tetto al prezzo.
3. Ridurre i crediti per disservizi per ottenere un’assistenza potenziata.

Ogni mossa potrebbe sembrare accettabile se considerata isolatamente. Nel complesso, però, aumentano il costo nel tempo, riducono la flessibilità e indeboliscono i rimedi. Il flusso di lavoro dovrebbe quindi valutare l’intero pacchetto, non soltanto il messaggio più recente.

La piattaforma prepara un fascicolo di approvazione che mostra il perimetro iniziale, le modifiche cumulative, il valore ottenuto, le alternative ancora disponibili e la risposta esatta. Il responsabile del budget esamina l’esposizione economica, mentre l’ufficio legale valuta la modifica ai rimedi. Non viene inviato alcun messaggio finché entrambe le decisioni non sono registrate.

In un flusso di lavoro concreto di Negotiations.AI, la rilevanza emerge in questa fase di instradamento: il sistema usato per la negoziazione negli acquisti dovrebbe conservare proposta, evidenze, verifica dell’autorità, modifiche umane e rilascio in uscita in un’unica registrazione collegata. È un requisito del flusso di lavoro, non un’affermazione secondo cui tutti i prodotti lo implementino allo stesso modo.

Dati necessari al motore di approvazione

La governance di una piattaforma di negoziazione basata sull’IA è affidabile solo quanto i dati di policy e di transazione a sua disposizione. Tra gli input utili figurano:

• Autorità delegata per persona, entità, categoria e tipo di transazione
• Fasce approvate di prezzo, costo, volume ed esposizione
• Disponibilità del budget e classificazione contabile
• Valore del contratto, durata e spesa aggregata per fornitore
• Libreria delle clausole, formulazioni alternative e gravità delle deroghe
• Concessioni precedenti ed effetto economico cumulativo
• Identità del fornitore, titolarità effettiva e istruzioni di pagamento
• Esiti relativi a sanzioni, controlli delle esportazioni, frodi e soggetti soggetti a restrizioni
• Dichiarazioni sui conflitti di interesse
• Valutazioni di sicurezza informatica, privacy, resilienza e rischio del fornitore
• Storico delle offerte e motivazione della fornitura esclusiva
• Giurisdizione, legge applicabile e requisiti normativi
• Classificazione dei dati e autorizzazioni alla divulgazione
• Autorità, formazione, ruolo e conflitti dell’utente
• Informazioni mancanti, guasti degli strumenti e output anomali
• Prompt completi, documenti recuperati, proposte, approvazioni e registri delle comunicazioni in uscita

Tratta questi input in base al loro stato. Una registrazione dell’autorità può essere un fatto verificato. La domanda prevista può essere una stima. Una dichiarazione del fornitore sulla capacità futura può restare un’ipotesi non verificata. Una formulazione alternativa generata dal modello è una raccomandazione. L’interfaccia utente dovrebbe etichettare queste categorie, anziché fonderle in un’unica narrazione sicura di sé.

Come definire le soglie senza inventare uno standard

Nessuna delle fonti citate stabilisce una soglia monetaria universale, una percentuale di variazione del prezzo o una durata contrattuale che richieda sempre l’approvazione. Una regola come «escalare ogni variazione del cinque per cento» è una scelta specifica dell’organizzazione, non un parametro di riferimento verificato.

Definisci le soglie in base a:

• Schemi esistenti di autorità delegata
• Regole aziendali di rilevanza e di budget
• Rischio della categoria e continuità delle forniture
• Sensibilità delle clausole e dei dati
• Esposizione cumulativa, non limitata al singolo messaggio
• Concentrazione dei fornitori e difficoltà di sostituzione
• Obblighi di giurisdizione e settore
• Reversibilità dell’azione proposta

Le norme SEC sui controlli interni offrono un’utile analogia per la progettazione delle autorizzazioni: descrivono la ragionevole garanzia che transazioni, spese, incassi e accesso ai beni avvengano con l’appropriata autorizzazione della direzione o del consiglio di amministrazione. Non impongono l’approvazione manuale di ogni condizione commerciale generata dall’IA (norma SEC sui controlli interni).

Verifica che la revisione umana sia effettiva

Un flusso di approvazione delle negoziazioni può sembrare controllato e tuttavia produrre approvazioni automatiche e superficiali. Verificalo con esercitazioni basate su scenari:

• Un acquirente può inviare un’accettazione cambiando l’oggetto del messaggio o il canale?
• Suddividere una concessione in più mosse minori consente di evitare l’escalation?
• Chi richiede un’eccezione può approvarla autonomamente?
• Il flusso mantiene il blocco se cambiano l’identità del fornitore o i dati di pagamento?
• L’approvatore può esaminare il documento esatto da inviare?
• Il sistema distingue una raccomandazione da un’evidenza verificata?
• I revisori possono respingere o modificare senza ostacoli eccessivi?
• Che cosa succede quando un approvatore non è disponibile?
• Se un’integrazione non funziona, il sistema blocca per impostazione predefinita un’azione rilevante?
• Il team può ricostruire chi sapeva cosa, chi ha deciso cosa e chi ha inviato cosa?

Anche il volume degli avvisi è importante. Troppe escalation di scarso valore incoraggiano revisioni superficiali. Assegna livelli di rischio al flusso di lavoro, fornisci fascicoli decisionali completi ed esamina periodicamente le deroghe, i tempi di approvazione, le eccezioni ricorrenti e le modifiche successive all’approvazione. Non ridurre gli avvisi solo per aumentare la velocità: rimuovili soltanto quando l’azione sottostante può essere gestita in sicurezza entro un perimetro aggiornato.

Limiti e casi che richiedono ulteriori analisi

Questo quadro presuppone un acquirente commerciale che utilizza l’IA per negoziare con i fornitori. Gli appalti pubblici, gli acquisti regolamentati, l’occupazione, le transazioni con i consumatori o le negoziazioni in ambito clinico, della difesa o in altri contesti specializzati possono richiedere controlli diversi.

L’AI Act dell’UE è diventato generalmente applicabile il 2 agosto 2026, fatte salve le disposizioni transitorie e le eccezioni. L’articolo 14 include requisiti di supervisione umana per i sistemi classificati legalmente ad alto rischio, comprese le capacità di monitorare, interpretare, ignorare o sovrascrivere gli output e interrompere il funzionamento. Un sistema per negoziare con i fornitori non è automaticamente ad alto rischio solo perché negozia: la classificazione dipende dall’uso previsto e dalle categorie previste dal regolamento (Regolamento (UE) 2024/1689). Se necessario, richiedi una consulenza specifica per giurisdizione e caso d’uso.

L’approvazione umana non può inoltre correggere un obiettivo illecito, una fonte di dati vietata, una progettazione collusiva, un modello inaffidabile o un revisore strutturalmente in conflitto. Le linee guida del DOJ sulla valutazione dei programmi di conformità aziendale chiedono come le organizzazioni valutino gli effetti legali dell’IA, la integrino nella gestione dei rischi e mitighino gli usi impropri involontari o sconsiderati (Valutazione dei programmi di conformità aziendale del DOJ).

Infine, l’approvazione non dovrebbe sostituire i controlli della piattaforma. Se un’azione non deve mai avvenire senza autorizzazione, impediscine tecnicamente l’esecuzione. Non fare affidamento su un prompt che dice al modello come comportarsi o sulla memoria dell’utente perché intervenga.

Lista di controllo per l’implementazione

Usa questa lista prima di abilitare le attività rivolte ai fornitori:

• Definire gli atti vincolanti e le azioni rivolte ai fornitori.
• Codificare i perimetri commerciali, legali, relativi ai dati e all’autorità.
• Assegnare un responsabile nominativo a ogni categoria di approvazione.
• Impedire che il silenzio o la scadenza di un termine valgano come approvazione.
• Separare i servizi di raccomandazione, autorizzazione ed esecuzione.
• Misurare le concessioni cumulative e l’esposizione totale.
• Richiedere una revisione indipendente per le eccezioni soggette a controllo.
• Impedire ai negoziatori di revocare da soli i blocchi obbligatori.
• Etichettare fatti, ipotesi, stime e raccomandazioni.
• Mostrare agli approvatori l’azione esatta che si intende inviare.
• Conservare prompt, evidenze, modifiche, decisioni e rilasci.
• Verificare possibili elusioni, indisponibilità degli approvatori e guasti delle integrazioni.
• Esaminare falsi positivi, deroghe ed eccezioni ricorrenti.
• Riconvalidare autorità e policy quando cambiano ruoli o sistemi.

L’obiettivo non è inserire un clic umano ovunque. È riservare il giudizio umano responsabile alle azioni che comportano un’esposizione significativa, consentendo al contempo un’automazione controllata quando le azioni sono circoscritte, registrate e reversibili.

Approfondimenti

• NIST AI Risk Management Framework
• NIST Generative Artificial Intelligence Profile
• Legge sull’intelligenza artificiale dell’Unione europea
• OFAC Framework for Compliance Commitments

FAQ

Ogni messaggio ai fornitori dovrebbe richiedere l’approvazione umana?

No. Domande esplorative approvate, pianificazione, promemoria e condivisione autorizzata di fatti possono essere automatizzati entro un perimetro definito. Richiedi una revisione quando un messaggio potrebbe vincolare l’azienda, divulgare informazioni soggette a controllo, concedere valore, attivare un’eccezione o incidere in modo sostanziale sul rapporto con il fornitore.

Un punteggio elevato di confidenza del modello può sostituire l’approvazione?

No. La confidenza non equivale all’autorità delegata. Può influire sulla priorità della revisione, ma non può autorizzare una spesa, accettare condizioni legali, revocare un blocco di conformità o rilasciare una comunicazione vincolante.

Chi dovrebbe approvare un’eccezione richiesta dagli acquisti?

Dovrebbe approvarla il responsabile indipendente del controllo competente, per esempio governance degli acquisti, conformità, ufficio legale, finanza, privacy o sicurezza. Chi richiede l’eccezione non dovrebbe esserne l’unico approvatore e alcuni controlli potrebbero non consentire alcuna deroga.

Che cosa dovrebbe succedere se mancano i dati necessari all’approvazione?

Il sistema dovrebbe richiedere le evidenze mancanti o bloccare l’azione soggetta a controllo. Non dovrebbe dedurre l’autorità, presumere che la due diligence sia stata completata o trasformare informazioni mancanti in un’approvazione.

Una persona può ignorare la raccomandazione dell’IA?

Di norma sì, se agisce entro i limiti dell’autorità delegata. La motivazione va registrata. Ignorare una raccomandazione dell’IA è diverso dal derogare a un controllo obbligatorio, che richiede un’autorità separata o potrebbe essere vietato.

Avvertenza: questo articolo fornisce informazioni generali sulla governance e non costituisce consulenza legale, finanziaria, di conformità o in materia di acquisti.