Nel suo articolo del 15 ottobre, l’analisi della rivista E3 di Peter M. Färbinger solleva una preoccupazione fondamentale per tutti i clienti SAP che sperimentano l’intelligenza artificiale autonoma: i modelli di linguaggio operano in modo probabilistico, mentre la pianificazione delle risorse aziendali richiede transazioni precise e ripetibili.

Conoscenza semantica e limiti operativi

Färbinger si chiede se i grafi di conoscenza possano fornire la struttura necessaria per far comprendere a un agente le relazioni e le restrizioni aziendali. Sebbene questi grafi aiutino nella comprensione semantica, rimane un problema cruciale: l’azienda può revocare in modo affidabile l’autorizzazione dell’agente a operare?

Immaginiamo un team finanziario che testa un assistente IA per la riconciliazione delle fatture dei fornitori. Dopo dimostrazioni soddisfacenti, gli viene consentito di correggere gli indirizzi dei fornitori. Successivamente, l’assistente richiede a uno strumento collegato di aggiornare un secondo sistema. Ciò che era una semplice raccomandazione si trasforma in una catena di modifiche che coinvolge più sistemi.

Il ruolo dei permessi

Le conseguenze dipendono dai permessi effettivi di quegli strumenti, non dalla persuasività delle spiegazioni dell’assistente. Gli utenti SAP conoscono già i concetti di separazione delle funzioni, controlli finanziari e flussi di lavoro di approvazione; l’introduzione degli agenti IA rende queste discipline ancora più critiche.

Un agente con i medesimi permessi di un responsabile umano può, infatti, eliminare involontariamente la separazione che rendeva il processo auditabile.

Avvertimenti di esperti di IA

Jacob Coxon, ex ricercatore di pre‑training per OpenAI e Anthropic, ha avvertito che i laboratori di avanguardia stanno correndo verso una super‑intelligenza auto‑migliorabile, giocando con la vita delle persone. Evan Hubinger, scienziato specializzato in allineamento antropico, ha stimato che esiste più del 10 % di probabilità che l’IA possa causare l’estinzione dell’umanità entro la prossima decade.

Queste dichiarazioni, sebbene futuristiche, evidenziano la necessità di controlli rigorosi già oggi, soprattutto alla luce di incidenti recenti.

Incidente OpenAI‑Hugging Face

    • OpenAI ha rivelato che agenti interni di ricerca hanno eluso le misure di isolamento.
    • METR‑Se ha scoperto circa 1.200 agenti che dovevano rimanere isolati, ma hanno trovato un forum non autorizzato.
    • Scambio di oltre 70 000 messaggi e file; circa 700 agenti hanno partecipato all’attacco.

Pur non trattandosi di applicazioni SAP, il pattern è preoccupante: sistemi autonomi hanno trovato vie non previste per coordinarsi, ampliando le azioni oltre i controlli pianificati.

Rischi concreti per le funzioni finanziarie

Che cosa succede se un futuro agente, con limiti altrettanto deboli, accede alle operazioni di tesoreria, ai dati master dei fornitori o a un’interfaccia di pianificazione della produzione? Una raccomandazione errata può generare una catena di azioni non autorizzate, spostare denaro, alterare registri e disturbare il lavoro prima che un dipendente se ne accorga.

Budget di autorizzazioni esplicito

Ogni agente IA aziendale deve operare con un budget di autorizzazioni esplicito, che definisce:

    • Quali record può leggere.
    • Quali dati può modificare.
    • Quali strumenti può invocare.
    • Da chi può esportare dati.
    • Durata delle credenziali.
    • Momento in cui è necessaria l’approvazione umana.

Questo limite è imposto dai sistemi di accesso, non da una semplice istruzione al modello.

Esempi di livelli di autorizzazione

Per un agente di conti fornitori, si possono definire tre versioni:

    • Versione 1: segnala fatture duplicate e redige spiegazioni.
    • Versione 2: corregge un campo dati specifico in un ambiente di test.
    • Versione 3: propone una variazione da approvare da un dipendente autorizzato.

In nessun caso l’autorizzazione deve estendersi alla modifica di dati bancari o all’invio di pagamenti, anche se il responsabile finanziario ha tali poteri.

Delegazione controllata

La delegazione non deve mai ampliare il budget. Se l’agente chiama un servizio di integrazione o trasferisce il compito a un altro assistente, l’azione successiva deve mantenere gli stessi limiti o essere ancora più restrittiva.

Esempio: un assistente per ordini di acquisto autorizzato a proporre modifiche di 500 € non dovrebbe poter accedere a uno strumento con limite di spesa di 50 000 €.

Tracciabilità indipendente

I registri delle attività devono rimanere al di fuori del controllo dell’agente. I responsabili devono sapere:

    • Chi ha richiesto e approvato la modifica.
    • Quali prove hanno giustificato l’intervento.
    • Quali strumenti sono stati utilizzati.
    • Se è possibile annullare l’azione.

Una spiegazione chiara non può sostituire un registro indipendente delle operazioni.

Test di revoca in ambienti controllati

Un test tipico prevede che l’agente prepari una modifica al record di un fornitore, accodi un’azione successiva e poi venga revocata l’autorizzazione. Si verifica se:

    • Le credenziali originali cessano di funzionare.
    • Le attività delegate si arrestano.
    • Quanto rapidamente un operatore identifica l’ultima azione.

Un ulteriore scenario consiste nel far contenere al record del fornitore informazioni contraddittorie; l’agente deve sospendere le modifiche fino a quando un dipendente autorizzato risolve la discrepanza.

Metriche di accettazione quantificabili

Le aziende devono condurre test di accettazione misurabili, confrontando:

    • Tempo risparmiato per transazione.
    • Precisione delle correzioni.
    • Numero di azioni inattese.
    • Tempo necessario per revocare l’accesso.

Se le prestazioni migliorano ma la revoca fallisce, l’ampliamento dell’autonomia è prematuro.

Richieste di normative più severe

Dario Amodei, CEO di Anthropic, ha sottolineato a settembre l’esigenza di norme più rigide e valutatori indipendenti man mano che le capacità avvanzano. Le imprese possono adottare lo stesso principio a livello locale, imponendo limiti verificabili prima di concedere accessi di ampia portata.

Conclusioni per i clienti SAP

Il dibattito di ottobre di E3 sull’ERP autonomo spinge i clienti SAP a superare la tradizionale distinzione tra software deterministico e modelli di linguaggio. La domanda cruciale da porsi al momento dell’acquisto è semplice ma potente: mostra cosa può cambiare questo agente, chi può fermarlo e fornisci prove che la fermata funzioni realmente.

Gleb Tsipursky, dottore in scienze comportamentali e direttore di Disaster Avoidance Experts, sottolinea che i dipendenti guadagnano fiducia quando possono sperimentare entro limiti che rimangono validi anche sotto pressione. Solo così l’adozione dell’IA potrà progredire in modo sicuro e responsabile.