Chi è responsabile della piattaforma di negoziazione? Un modello operativo aziendale

Il procurement dovrebbe essere responsabile della piattaforma di negoziazione in quanto prodotto aziendale. Dovrebbe controllarne la roadmap, la metodologia di negoziazione, i flussi di lavoro con i fornitori, l’adozione e i risultati commerciali. Ciò non significa che il procurement debba approvare ogni conseguenza legale, finanziaria, tecnica, di sicurezza o operativa generata tramite la piattaforma.

Il modello operativo corretto per una piattaforma di negoziazione prevede responsabilità federate con un unico responsabile di prodotto, non una vaga responsabilità condivisa. Il legale definisce gli standard giuridici e gestisce le eccezioni. La finanza controlla i presidi finanziari e convalida il valore. L’IT gestisce il funzionamento tecnico. Sicurezza e privacy sono responsabili dei rispettivi controlli. I team business definiscono i requisiti e valutano i compromessi operativi. Un dirigente designato o un comitato di governance risolve le eccezioni rilevanti e accetta il rischio aziendale.

Risposta in breve

Assegnate al procurement un unico responsabile di prodotto, accountable, per la piattaforma di negoziazione. Attribuite a legale, finanza, IT, sicurezza/privacy e team business diritti espliciti di controllo o decisionali nei rispettivi ambiti. Richiedete l’approvazione di persone designate per aggiudicazioni rilevanti a fornitori, eccezioni sostanziali, impegni vincolanti e accettazione del rischio. Affidate a un organo di indirizzo interfunzionale la definizione delle policy, non la gestione ordinaria del prodotto, e formalizzate queste responsabilità in autorizzazioni, flussi di lavoro e registrazioni probatorie.

Perché un unico responsabile non significa che una sola funzione controlli tutto

Una piattaforma di negoziazione è più di un software. Ai fini di questo modello operativo, comprende la tecnologia, i dati, le integrazioni, i playbook, i modelli, le policy, i flussi di lavoro, le approvazioni e le registrazioni utilizzati per preparare, condurre, documentare o analizzare una negoziazione di procurement.

Questo ambito comporta diverse forme di responsabilità:

• Responsabilità di prodotto aziendale: priorità, progettazione dei flussi di lavoro, adozione, livelli di servizio e risultati.
• Responsabilità dei controlli: definizione e manutenzione di un controllo specifico, come l’approvazione delle clausole o l’accesso privilegiato.
• Responsabilità decisionale: autorità umana di accettare una conseguenza commerciale, legale, finanziaria, operativa o di sicurezza.
• Responsabilità tecnica: architettura, integrazioni, affidabilità, gestione del ciclo di vita e supporto.
• Responsabilità del rischio: autorità di accettare un livello definito di rischio aziendale.

Confondere questi ruoli causa due problemi ricorrenti. Nel primo, l’IT diventa il responsabile nominale perché gestisce l’applicazione, anche se non può definire la metodologia di procurement. Nel secondo, un comitato è indicato come responsabile congiunto della piattaforma, senza che nessuno risponda delle priorità o dei risultati.

Un modello migliore di responsabilità della piattaforma di negoziazione attribuisce al procurement la responsabilità del prodotto, preservando al contempo l’autorità specifica di ciascun ambito.

La ripartizione delle responsabilità aziendali

Procurement: prodotto aziendale e processo di negoziazione

Di norma, il procurement dovrebbe essere responsabile di:

• Roadmap del prodotto e priorità aziendali.
• Metodologia di negoziazione e standard di preparazione.
• Flussi di lavoro rivolti ai fornitori.
• Playbook commerciali e strutture delle concessioni.
• Adozione e formazione degli utenti delle categorie.
• Reportistica sulle prestazioni e miglioramento dei flussi di lavoro.
• Escalation delle eccezioni commerciali.

Il procurement può guidare una raccomandazione di aggiudicazione, ma non dovrebbe accettare unilateralmente scostamenti legali sostanziali, convalidare i risparmi che ha dichiarato o approvare spese oltre i limiti dell’autorità delegata.

Team business: requisiti e conseguenze operative

Gli sponsor aziendali dovrebbero essere responsabili di:

• Requisiti e ipotesi sulla domanda.
• Compromessi relativi a servizio, qualità, capacità e implementazione.
• Conferma della fattibilità operativa della soluzione proposta.
• Accettazione dell’impegno aziendale risultante, entro i limiti della propria autorità.

Il team business non può delegare al procurement o all’IA per la negoziazione il proprio giudizio quando una posizione più economica comporterebbe un rischio operativo inaccettabile.

Legale: standard giuridici ed eccezioni

Il legale dovrebbe essere responsabile di:

• Modelli contrattuali e standard delle clausole.
• Playbook legali e posizioni non ammesse.
• Regole per l’escalation degli scostamenti.
• Approvazione delle eccezioni legali sostanziali.
• Consulenza sugli obblighi specifici delle diverse giurisdizioni.

La «responsabilità legale» non significa che il legale debba gestire il backlog della piattaforma. Significa che i consulenti autorizzati controllano gli standard giuridici e gli scostamenti rilevanti da tali standard.

Finanza: autorità, aspetti economici e convalida del valore

La finanza dovrebbe essere responsabile o esercitare il controllo su:

• Requisiti di budget e autorizzazione finanziaria.
• Definizioni e convalida dei risparmi.
• Aspetti economici dei pagamenti, rebate, ratei e calcoli dell’esposizione.
• Implicazioni per la rendicontazione finanziaria, ove pertinenti.
• Approvazione delle eccezioni finanziarie entro i limiti dell’autorità delegata.

Questa separazione è importante perché il team che negozia un beneficio non dovrebbe essere l’unico a convalidarne il valore dichiarato.

IT: responsabilità del servizio tecnico

L’IT dovrebbe essere responsabile di:

• Architettura e modelli di integrazione approvati.
• Affidabilità, supporto e ciclo di vita tecnico.
• Implementazione di identità, accessi e gestione delle modifiche.
• Flussi di dati tra sistemi di sourcing, contratti, ERP, identità e analytics.
• Gestione operativa dei fornitori tecnologici.

L’IT gestisce la tecnologia; il procurement definisce gli obiettivi del prodotto aziendale.

Sicurezza e privacy: controlli, monitoraggio ed escalation

I team di sicurezza e privacy dovrebbero essere responsabili dei propri requisiti, valutazioni, monitoraggio dei controlli e percorsi di escalation. Non dovrebbero diventare i responsabili predefiniti del rischio aziendale solo perché lo hanno individuato.

Il NIST Cybersecurity Framework 2.0 ha aggiunto Govern come funzione fondamentale e richiede che ruoli, responsabilità e autorità in materia di cybersicurezza siano definiti e comunicati. Considera inoltre la governance della cybersicurezza una questione di rischio aziendale, non un compito esclusivo dell’IT.

Sponsor esecutivo o comitato di governance: policy e propensione al rischio

Uno sponsor esecutivo designato o un organo di indirizzo interfunzionale dovrebbe decidere in merito a:

• Policy aziendali e livelli di rischio.
• Conflitti interfunzionali sostanziali.
• Nuovi utilizzi dell’IA per la negoziazione rivolti all’esterno o autonomi.
• Eccezioni significative ai controlli.
• Possibilità di implementare o mantenere in funzione capacità ad alto rischio.

Il comitato dovrebbe governare le policy, non diventare un secondo team di prodotto.

Una matrice RACI riutilizzabile per la responsabilità della piattaforma di negoziazione

Usate A per accountable (responsabile ultimo), R per responsible (esecutore), C per consulted (consultato) e I per informed (informato). Ogni riga dovrebbe avere un solo responsabile ultimo. «Dirigenza» indica lo sponsor, il comitato autorizzato o il responsabile del rischio designato nella policy aziendale.

Questo è un modello iniziale, non una delega di autorità aziendale. I documenti di delega, le autorizzazioni di sistema, i mandati dei comitati e le prassi effettive devono essere coerenti con la matrice RACI.

La regola di progettazione fondamentale: separare configurazione, approvazione e assurance

Una piattaforma può formulare raccomandazioni, eseguire calcoli, instradare richieste, documentare e applicare i flussi di lavoro. Non dovrebbe però potersi autorizzare da sola ad approvare la propria configurazione, ignorare i controlli, accettare un’eccezione sostanziale, selezionare un fornitore o vincolare l’azienda.

Il NIST SP 800-53 tratta la separazione dei compiti e il principio del privilegio minimo. Applicati al procurement aziendale, questi principi implicano che la stessa persona non dovrebbe poter:

• Modificare una regola di negoziazione e approvare la transazione interessata.
• Modificare una soglia finanziaria e convalidare i risparmi risultanti.
• Modificare un playbook legale e approvare l’eccezione che ne deriva.
• Amministrare gli accessi privilegiati e verificare autonomamente i relativi log.
• Ottimizzare un modello e convalidarne autonomamente le prestazioni.

Se il personale disponibile non consente una separazione completa, documentate controlli compensativi, come una revisione di secondo livello, la ricertificazione degli accessi, report sulle eccezioni e verifiche a campione a posteriori.

Un modello operativo in cinque passaggi per la negoziazione con IA

1. Designare il responsabile del prodotto e i responsabili delle decisioni

Nominate nel procurement un Responsabile di prodotto della piattaforma di negoziazione. Elencate poi le persone autorizzate ad accettare ciascun tipo di conseguenza: commerciale, legale, finanziaria, operativa, di sicurezza e di privacy.

Non usate un campo generico «responsabile aziendale». Registrate un ruolo specifico e la fonte della relativa autorità.

2. Creare un registro dei diritti decisionali

Per ogni azione rilevante della piattaforma, documentate:

• Chi può avviarla?
• Chi può modificare la regola o il playbook su cui si basa?
• Chi la esamina?
• Chi la approva?
• Chi può derogare alla regola?
• Quali prove devono essere conservate?
• Chi monitora il risultato in modo indipendente?

Questo registro traduce una matrice RACI in un flusso di lavoro applicabile.

3. Classificare i casi d’uso in base alle conseguenze

Un’analisi a basso rischio e preapprovata può consentire raccomandazioni automatizzate e verifiche a campione successive. Aumentate il livello di governance se la piattaforma può comunicare con soggetti esterni, influire sull’inclusione dei fornitori, modificare impegni finanziari, trattare dati sensibili o formulare una posizione vincolante.

Il NIST AI Risk Management Framework 1.0 richiede ruoli chiari, una ripartizione delle responsabilità tra persone e IA, supervisione umana documentata, monitoraggio continuo e controlli sull’IA e sui dati di terze parti. Il NIST dichiara che il framework è in fase di revisione; le organizzazioni dovrebbero quindi verificare la versione corrente al momento dell’adozione.

4. Codificare l’autorità nel sistema

Allineate il registro dei diritti decisionali a:

• Controlli di accesso basati sui ruoli.
• Soglie di approvazione.
• Controlli a due persone per le modifiche sensibili.
• Playbook e modelli con versionamento.
• Registrazioni di audit protette.
• Accessi privilegiati con durata limitata.
• Avvisi per le azioni fuori mandato.

Per esempi di progettazione dei flussi di lavoro, consultate progettare l’approvazione umana in una piattaforma di negoziazione basata sull’IA.

5. Esaminare le prove, non solo l’adozione

Un modello operativo efficace per la negoziazione con IA richiede prove che i controlli funzionino come previsto. Tra le registrazioni utili figurano:

• Raccomandazioni accettate, modificate, respinte o ignorate.
• Motivazioni delle deroghe umane.
• Eccezioni legali e finanziarie.
• Transazioni che superano i mandati approvati.
• Modifiche privilegiate e ricertificazioni degli accessi.
• Contestazioni dei fornitori relative agli impegni.
• Valore previsto, convalidato e realizzato.
• Errori del modello, deriva e risultati non supportati.
• Malfunzionamenti dei controlli e decisioni correttive.
• Azioni vincolanti confrontate con le autorizzazioni umane.

Le prove relative alle deroghe meritano particolare attenzione. Deroghe ripetute possono rivelare dati scadenti, mandati irrealistici, formazione insufficiente, limiti del modello o rischi specifici di una categoria.

Requisiti probatori per tipo di decisione

Le linee guida sulla conformità del Dipartimento di Giustizia degli Stati Uniti del settembre 2024 chiedono se i processi relativi a terze parti stabiliscano una motivazione aziendale, termini contrattuali e di pagamento adeguati, la conferma che il lavoro sia stato svolto e una remunerazione proporzionata ai servizi. Chiedono inoltre come le organizzazioni utilizzino i dati per valutare il rischio dei fornitori durante il rapporto. Ciò avvalora il collegamento tra le registrazioni delle negoziazioni e la due diligence, la contrattualistica, i pagamenti e il monitoraggio continuo dei fornitori.

Quando una piattaforma di negoziazione influisce su impegni, rebate, prezzi, ratei o pagamenti, i team di controllo finanziario dovrebbero valutare la rilevanza e la progettazione del sistema. Il PCAOB AS 2201 tratta il modo in cui le transazioni vengono avviate, autorizzate, elaborate e registrate, compreso l’effetto dell’IT su tale flusso. L’applicabilità dipende dall’organizzazione e dal caso d’uso.

Esempio ipotetico: rinnovo di un contratto logistico

Esempio ipotetico: non costituisce prova né parametro di riferimento.

Un’azienda sta rinnovando un accordo logistico regionale. La sua piattaforma di negoziazione analizza i prezzi precedenti, prepara pacchetti di proposte e segnala un’offerta del fornitore che combina una tariffa unitaria più bassa con un impegno minimo di volume più lungo.

Secondo il modello operativo:

1. Il procurement è responsabile del piano di negoziazione e dello scambio con il fornitore.
2. Lo sponsor aziendale convalida le previsioni della domanda e la fattibilità operativa dell’impegno.
3. La finanza valuta gli aspetti economici dei pagamenti e convalida il valore dichiarato.
4. Il legale esamina l’impegno non standard e le clausole di recesso.
5. IT e sicurezza restano responsabili dei controlli della piattaforma, ma non approvano il compromesso commerciale.
6. Un comitato o firmatario umano autorizzato decide se l’azienda debba accettare il pacchetto.

La piattaforma può evidenziare il compromesso e conservare le prove. Non può decidere che il rischio legato alla domanda sia accettabile per l’azienda.

Un team procurement che valuta dove collocare questo flusso di lavoro può confrontare le più ampie funzionalità di negoziazione con IA con le esigenze di processo descritte nel software per la negoziazione nel procurement. Ad esempio, Negotiations.AI sarebbe pertinente solo se il flusso di lavoro concreto richiedesse preparazione strutturata, raccomandazioni, revisione e approvazione umana documentata; le funzionalità del prodotto dovrebbero comunque essere verificate durante la valutazione.

Revisione umana da mantenere esplicita

L’approvazione umana da parte di una persona responsabile dovrebbe restare obbligatoria quando un’azione:

• Seleziona o esclude un fornitore in un processo di procurement rilevante.
• Supera soglie di budget, responsabilità, prezzo, durata, sconto o impegno.
• Si discosta da una clausola o posizione legale approvata.
• Utilizza dati sensibili, personali, soggetti a controlli sulle esportazioni o commercialmente riservati.
• Crea o rivela un potenziale conflitto di interessi.
• Modifica termini di pagamento, rebate, impegni minimi o trattamento contabile.
• Invia un’offerta vincolante o perfeziona un accordo.
• Ignora controlli di sicurezza, sanzioni, concorrenza, privacy o conformità.
• Dipende da un risultato che i revisori non possono verificare o spiegare adeguatamente.
• Accetta un rischio residuo di sicurezza, privacy, legale, finanziario o relativo all’IA.

Un clic umano non costituisce automaticamente una supervisione significativa. I revisori devono disporre di prove pertinenti, tempo sufficiente, competenze, indipendenza e autorità effettiva per respingere la raccomandazione.

Lista di controllo per l’implementazione

Prima di approvare il modello operativo della piattaforma di negoziazione, verificate che:

• Il procurement abbia un unico responsabile di prodotto designato.
• Ogni decisione sostanziale abbia un unico responsabile umano.
• Le responsabilità di legale, finanza, IT, sicurezza/privacy e business siano documentate.
• Le regole di delega dei poteri e di firma siano coerenti con le autorizzazioni della piattaforma.
• Chi modifica i playbook non possa approvare le proprie eccezioni sostanziali.
• Il valore finanziario sia convalidato in modo indipendente.
• Le modifiche privilegiate siano registrate e verificate.
• I nuovi usi dell’IA per la negoziazione siano sottoposti a una valutazione del livello di rischio prima della messa in produzione.
• L’automazione rivolta ai fornitori sia soggetta a controlli più rigorosi rispetto alle raccomandazioni interne.
• Le comunicazioni vincolanti richiedano l’approvazione di una persona autorizzata.
• Le motivazioni delle deroghe e i malfunzionamenti dei controlli siano conservati.
• Il responsabile esecutivo del rischio possa sospendere un caso d’uso o una funzionalità.
• La conservazione delle registrazioni, la due diligence dei fornitori, la contrattualistica e i controlli sui pagamenti siano collegati al flusso di lavoro.

Fatti, ipotesi, stime e raccomandazioni

Un’etichettatura chiara evita che una proposta di modello operativo venga scambiata per un requisito universale.

Fatti verificati

• Il NIST CSF 2.0 include la funzione Govern e richiede ruoli, responsabilità e autorità in materia di cybersicurezza definiti.
• Il NIST AI RMF 1.0 descrive pratiche di governance, supervisione umana, monitoraggio e gestione dei rischi dell’IA di terze parti.
• Il NIST SP 800-53 include controlli di separazione dei compiti e privilegio minimo.
• Le linee guida sulla conformità del DOJ trattano la motivazione relativa alle terze parti, i termini, le prove del lavoro svolto, la remunerazione e i dati per il monitoraggio continuo del rischio dei fornitori.
• Il PCAOB AS 2201 tratta l’autorizzazione delle transazioni e l’effetto dell’IT sui flussi transazionali negli audit pertinenti.

I link alle fonti riportati sopra supportano direttamente queste affermazioni.

Ipotesi

Questo modello presuppone che la piattaforma supporti le negoziazioni aziendali con i fornitori, possa contenere dati commerciali e di approvazione e non agisca come agente contrattuale autonomo senza restrizioni. Presuppone inoltre che le policy esistenti in materia di deleghe, privacy, sicurezza, conservazione e controlli finanziari restino prevalenti.

Se la piattaforma invia offerte autonomamente, esclude fornitori, trasmette offerte vincolanti o perfeziona accordi, aumentate il livello di governance e richiedete una revisione specialistica.

Stime

Qui non vengono stimate proporzioni di personale, durata dell’implementazione, tassi di risparmio, soglie di approvazione o frequenza dei test. Tali scelte dovrebbero riflettere il volume delle transazioni, il rischio, la regolamentazione, l’architettura, la criticità dei fornitori e la capacità organizzativa.

Raccomandazioni

La ripartizione delle responsabilità, la matrice RACI, il registro decisionale e le soglie di revisione sono raccomandazioni. Nessuna regola universale impone al procurement di essere responsabile di ogni piattaforma di negoziazione. Un altro responsabile di prodotto può essere appropriato quando un’altra funzione è effettivamente responsabile del processo aziendale, dei risultati, delle risorse e dell’adozione.

Limiti e situazioni in cui questo modello potrebbe non essere applicabile

Questo modello potrebbe richiedere modifiche per il procurement regolamentato, le gare del settore pubblico, gli ambienti della difesa o soggetti a controlli sulle esportazioni, i servizi finanziari, i gruppi fortemente decentralizzati o i sistemi che assumono impegni esterni autonomamente.

Presenta inoltre limiti pratici:

• Una matrice RACI non conferisce autorità legale o aziendale.
• I framework NIST sono generalmente volontari, salvo adozione tramite policy, regolamento o contratto.
• Le implicazioni per i controlli finanziari dipendono dallo status dell’azienda, dalla rilevanza e dalla progettazione del sistema.
• Le norme su privacy, firma, registrazioni, lavoro, concorrenza e IA variano a seconda della giurisdizione.
• I team di sicurezza possono definire e valutare i controlli senza avere l’autorità di accettare il rischio aziendale.
• Un comitato non può compensare l’assenza di un responsabile di prodotto.
• La revisione umana non funziona se gli approvatori non dispongono di prove o non possono contestare il risultato.

Il principio duraturo è semplice: centralizzare la responsabilità del prodotto, federare i controlli di dominio e lasciare le decisioni rilevanti a persone identificabili.

Approfondimenti

• NIST Cybersecurity Framework 2.0
• NIST Artificial Intelligence Risk Management Framework 1.0
• NIST SP 800-53 Rev. 5.1
• Dipartimento di Giustizia degli Stati Uniti: valutazione dei programmi di conformità aziendale
• PCAOB AS 2201

FAQ

La piattaforma di negoziazione dovrebbe essere responsabilità del procurement o dell’IT?

Di norma, dovrebbe essere responsabilità del procurement in quanto prodotto aziendale, perché il procurement definisce i metodi di negoziazione, i flussi di lavoro con i fornitori, le priorità di adozione e i risultati commerciali. L’IT dovrebbe essere responsabile di architettura, integrazioni, affidabilità, supporto e ciclo di vita tecnico. Se l’IT controlla la roadmap aziendale solo perché gestisce il software, la responsabilità è attribuita in modo errato.

Chi è responsabile del rischio legato alla negoziazione con IA?

I responsabili dei controlli individuano, valutano e monitorano i rischi nei rispettivi ambiti. Un dirigente designato, con autorità documentata, dovrebbe accettare il rischio residuo sostanziale legato all’IA. Il procurement è responsabile delle decisioni sul prodotto, ma non dovrebbe accettare rischi aziendali legali, finanziari, di privacy o di sicurezza oltre i limiti dell’autorità delegata.

La matrice RACI può sostituire i documenti di delega dei poteri?

No. Una matrice RACI chiarisce le responsabilità operative, ma non conferisce autorità di firma, spesa, deroga o accettazione del rischio. Le policy aziendali, i mandati dei comitati, le autorizzazioni di sistema e i documenti di delega devono essere coerenti con essa.

Quando può agire la piattaforma senza approvazione preventiva?

Solo per azioni circoscritte e a basso impatto autorizzate dalle policy, come analisi interne o raccomandazioni entro regole approvate. La selezione di fornitori con conseguenze rilevanti, le eccezioni sostanziali, le offerte vincolanti, la stipula dei contratti e l’accettazione del rischio aziendale dovrebbero mantenere l’approvazione di una persona responsabile.

Quali prove di governance sono più utili?

Iniziate dalle registrazioni delle decisioni e delle deroghe: chi ha autorizzato il mandato, cosa ha raccomandato la piattaforma, cosa ha modificato la persona e perché è stata accettata un’eccezione, nonché se l’impegno finale è rimasto entro i limiti dell’autorità. Queste registrazioni aiutano a verificare sia la qualità delle decisioni sia l’efficacia dei controlli.

Esclusione di responsabilità: questo articolo fornisce indicazioni operative generali e non costituisce consulenza legale, finanziaria, di audit, sicurezza o normativa.