Scopri di più sui seguenti prodotti beqom
Immagina un manager davanti allo schermo durante un ciclo retributivo. Digita, semplicemente: "Perché l'aumento di stipendio di Marco ha un limite massimo quest'anno?"
Vuole una risposta chiara, corretta e difendibile. Se tutto funziona correttamente, i team HR dispongono di un agente in grado di rispondere a domande simili in pochi secondi, su scala globale per un organico distribuito in diversi continenti, e sono in grado di sostenere un confronto con un comitato aziendale, un auditor o un dipendente che ne chiede il motivo. Se il sistema non funziona, occorre spiegare a quell'auditor perché l'IA ha inventato una fascia retributiva mai esistita.
L'elemento, controintuitivo, che abbiamo appreso sviluppando questa soluzione sul campo, su scala enterprise è che l'IA più utile, in una piattaforma di gestione delle retribuzioni, è quella che non vede mai i dati effettivi. Non parliamo di "non li memorizza" o di "non dovrebbe guardarli". È strutturalmente impossibilitata a farlo. E, lungi dal renderla meno efficace, questa totale separazione è proprio ciò che la rende così affidabile da poter essere messa a disposizione dei team HR che gestiscono la retribuzione di centinaia di migliaia di persone.
Andiamo scoprirne i motivi, e le ragioni per cui si tratta di una sfida ingegneristica ben più interessante del semplice "collegare un chatbot".
Perché non è consigliabile affidare direttamente i dati retributivi a un LLM?
La retribuzione rappresenta uno stress test per le applicazioni basate su LLM, poiché tre elementi indipendenti creano, contemporaneamente, degli ostacoli.
Primo ostacolo: le normative. La retribuzione è uno degli ambiti più controllati in assoluto con leggi sulla parità retributiva, Direttiva UE sulla trasparenza retributiva, audit interni, comitati aziendali e altro. "L'ha suggerito l'IA" non è una risposta accettabile ad una domanda sul perchè di una certa retribuzione. In questo settore, le decisioni devono essere spiegabili, riproducibili e riconducibili a una formula precisa, non basate su sensazioni o istinti.
Secondo ostacolo: il contesto. Anche volendo mostrare tutto al modello, non è possibile farlo. Inserire i dati retributivi di 100.000 dipendenti in una context window esaurisce il budget di token, fa impennare la latenza e fa perdere il filo al modello a metà elaborazione. Un'architettura basata sul principio di "fornire tutti i dati all'LLM" non si limita a causare fughe di dati: semplicemente non funziona.
Terzo ostacolo: l'aritmetica. I modelli LLM non sanno eseguire calcoli in modo affidabile. Se si chiede loro di calcolare un aumento di merito applicando alcune regole di business e diverse valute, basta un'allucinazione, all'apparenza plausibile, per comunicare a un manager la cifra sbagliata. In questo contesto, una singola cifra inventata non è semplicemente un errore durante una demo: è lo stipendio reale di una persona.
Tre ostacoli, una sola soluzione: non fornire i dati al modello e non lasciargli eseguire i calcoli. Sembra una limitazione che complica le cose; al contrario, si rivela una liberazione.
Cosa significa che l'IA è "esatta" se non vede mai i numeri?
Esistono due concetti completamente diversi che comunemente vengono definiti come "esattezza", e una buona architettura non permette che entrino in contatto.
- Rigore logico: il modo in cui rispondere alla domanda. Quale policy applicare, il significato del massimale, come guidare un responsabile attraverso la logica, cosa mostrare e in quale formato. Si tratta di linguaggio, struttura e semantica di settore. È esattamente ciò in cui un LLM eccelle in modo straordinario.
- Esattezza del calcolo: quali sono i numeri. Il valore del massimale, l'importo riparametrato, la conversione valutaria. Si tratta di aritmetica e di regole di business. È esattamente l'ambito in cui un LLM risulta rischioso.
Un approccio "ingenuo" fonde questi elementi e spera per il meglio. Un'architettura basata sul principio di data blindness li separa fin dalla progettazione: il modello gestisce il ragionamento, un motore deterministico gestisce i numeri, e i due ruoli non vengono mai invertiti. Il modello stabilisce la logica di analisi per elaborare la risposta, ma non determina mai il valore. Una volta fatta propria questa distinzione, l'intera architettura deriva in modo del tutto naturale.
Questa separazione non è una novità. L'occultamento dei dati al modello di pianificazione risale al pattern "dual LLM" di Simon Willison; la distinzione tra ragionamento ed esecuzione deterministica è ormai formalizzata nella letteratura scientifica; il principio "non lasciare che il modello esegua i calcoli" è ormai ampiamente condiviso. La novità è fare in modo che questo approccio funzioni in produzione, con processi di autorizzazione, conformità normativa e payroll reali, gestendo alcuni degli organici più ampi al mondo. È una sfida molto diversa rispetto al superamento di un semplice benchmark.
Dove emergono le prime difficoltà?
Fermarsi qui significherebbe limitarsi a fornire uno slogan pubblicitario; è proprio adesso che le cose si complicano davvero, e fingere il contrario è il modo più rapido per perdere la fiducia di un lettore tecnico.
I metadati sono informazioni. Rimuovere ogni nome non basta a risolvere il problema. I nomi di oggetti, dataset e analisi che vengono esposti possono rivelarsi indicativi. La semplice esistenza di una specifica analisi può suggerirne le finalità. Tracciare il confine tra i metadati necessari al modello per elaborare le informazioni e quelli che causano fughe di dati non visibili è un lavoro continuo e mirato, non un compito da effettuare una volta per tutte.
Anche le strutture possono rivelare informazioni riservate. Se si comunica al modello che "questa vista ha restituito due persone" in un contesto retributivo, si introduce potenzialmente un rischio di identificazione: la k-anonymity applicata a piccoli gruppi, una trappola classica. Il feedback strutturale è potente proprio perché trasmette informazioni, e le informazioni su gruppi molto ridotti possono renderli identificabili. Applichiamo euristiche che eliminano la cardinalità sugli endpoint a rischio e continuiamo a lavorare attivamente su questo fronte. Chiunque affermi che questo problema sia ormai risolto non opera in un settore regolamentato oppure non ne comprende la portata.
Questi limiti non sono un difetto dell'approccio, ne sono il punto di forza: un sistema di IA maturo sa esattamente quali sono i propri limiti. La sofisticazione non consiste nel sostenere che il modello sia in grado di fare tutto, ma nella precisione con cui si stabilisce cosa non debba assolutamente gestire.
Come beqom realizza tutto questo, in produzione
La tendenza attuale nell'IA basata su agenti è misurare la potenza in base a quanto si concede al modello: più autonomia, più accessi, più strumenti, più margine d'azione. L'approccio data-blind va nella direzione opposta. L'agente è più competente, più affidabile e più credibile in contesti in cui la fiducia è regolamentata proprio perché abbiamo limitato con rigore i suoi gradi di libertà. Vincolare le decisioni concesse al modello non significa indebolirlo, ma indirizzarlo con precisione. La maturità di un'applicazione IA aziendale non si misura da quanto delega al modello, ma dalla precisione della linea che traccia.
È esattamente così che è progettato l'agente AI all'interno della piattaforma di gestione delle retribuzioni di beqom. Analizza le policy retributive, le regole dei cicli e le logiche di calibrazione aziendali, senza mai accedere direttamente a salari reali, bonus o nomi. Ogni cifra visualizzata da un manager proviene da un motore deterministico, è riconducibile a una formula e rispetta i permessi specifici di quel responsabile. Per questo i team HR possono impiegarlo nei cicli retributivi attivi di alcune delle più grandi aziende al mondo, con la certezza che risponda pienamente ai requisiti di audit anziché aggirarli.
Se vuoi vedere come tutto questo funziona in concreto, prenota una demo con il nostro team.
