Skip to main content

Uso di LLM in Rendicontazione

Principio guida

Un LLM può rendere Rendicontazione più semplice da usare e più efficace nel supportare le decisioni, ma deve operare come strato di assistenza sopra dati e calcoli deterministici.

Il motore di forecasting, la selezione delle tariffe, i blocchi temporali, le allocazioni e i valori ufficiali dei report devono rimanere riproducibili, verificabili e governati da regole di dominio. L'LLM può interpretare richieste, proporre azioni e spiegare risultati, ma non deve diventare la fonte dei valori ufficiali.

Casi d'uso consigliati

1. Import intelligente

L'LLM può assistere l'onboarding di nuovi formati di file:

  • riconoscere fogli, intestazioni e colonne non standard;
  • proporre il mapping verso i modelli canonici di dipendenti, progetti, ferie e consuntivi;
  • riconoscere sinonimi come “Costo/h”, “Tariffa oraria” e “Hourly cost”;
  • suggerire la riconciliazione di nomi o codici simili;
  • spiegare righe ambigue, scartate o incomplete.

Il mapping proposto deve essere mostrato in anteprima e approvato da un utente autorizzato. Dopo l'approvazione viene salvato come configurazione versionata e applicato in modo deterministico agli import successivi.

2. Spiegazione del forecasting

L'LLM può trasformare risultati, warning e vincoli del motore in una spiegazione comprensibile, per esempio:

Il progetto Alfa rimane scoperto di 240 ore perché tre risorse raggiungono il limite annuale e 80 ore di capacità sono assorbite da ferie pianificate ad agosto.

La spiegazione deve utilizzare esclusivamente dati strutturati prodotti dal motore: domanda scoperta, capacità, ferie, limiti, costi e vincoli attivi. Ogni affermazione quantitativa deve essere riconducibile alla relativa fonte.

3. Suggerimenti per risolvere criticità

A partire da un forecast deterministico, l'assistente può proporre opzioni quali:

  • spostare ore tra risorse compatibili;
  • estendere il periodo del progetto;
  • aggiungere una risorsa con ruolo o livello adeguato;
  • ridurre una sovrallocazione;
  • anticipare la verifica di ferie non ancora pianificate;
  • evidenziare che nessuna soluzione soddisfa tutti i vincoli correnti.

Le proposte non modificano direttamente i dati. L'utente seleziona un suggerimento, verifica le modifiche strutturate e avvia eventualmente una simulazione.

4. Scenari what-if conversazionali

L'utente può formulare richieste come:

Cosa succede se il progetto termina due mesi dopo e aggiungo una risorsa quadro da settembre?

L'LLM traduce la richiesta in parametri strutturati, mostra l'interpretazione e richiede conferma. Il sistema esegue quindi il normale motore di forecasting in uno scenario isolato; l'LLM confronta il risultato con la baseline e ne spiega le differenze.

Nessuna simulazione deve alterare il piano ufficiale fino a un'esplicita approvazione tramite i normali casi d'uso applicativi.

5. Controllo qualità dei dati

Regole e analisi statistiche individuano le anomalie; l'LLM le raggruppa, assegna un contesto e suggerisce verifiche. Esempi:

  • costo orario molto distante da risorse equivalenti;
  • tariffa di un ente assente o ambigua;
  • dipendente senza ruolo, macro-livello o società;
  • associazioni incompatibili con periodo di impiego o progetto;
  • ferie, consuntivi o scostamenti anomali;
  • possibili duplicati nell'import.

L'LLM non deve stabilire autonomamente che un dato sia errato né correggerlo senza conferma.

6. Sintesi e supporto ai report

L'assistente può produrre una bozza di:

  • sintesi mensile per progetto;
  • spiegazione degli scostamenti forecast/consuntivo;
  • riepilogo delle modifiche retroattive;
  • nota di accompagnamento al report;
  • relazione sintetica per il finanziatore.

Ore, costi e percentuali devono essere inseriti a partire da report strutturati, mai calcolati o completati dal modello. La bozza resta modificabile e deve essere approvata prima dell'esportazione o dell'invio.

7. Interrogazione in linguaggio naturale

Esempi di domande:

  • Quali progetti rischiano di non essere coperti nei prossimi tre mesi?
  • Quali dipendenti risultano sovrallocati?
  • Perché il costo previsto del progetto Alfa è aumentato?
  • Quali mesi non sono ancora stati consegnati?
  • Quali tariffe scadono entro fine anno?

L'LLM utilizza strumenti/API applicative autorizzate e con schema definito. Non deve generare ed eseguire SQL libero.

Funzioni da non affidare all'LLM

  • calcolare o approvare allocazioni ufficiali;
  • scegliere autonomamente la tariffa applicabile;
  • modificare il cursore del consuntivo o della consegna;
  • aggirare il blocco dei mesi consegnati;
  • eseguire correzioni retroattive senza conferma;
  • approvare ferie;
  • creare o modificare autonomamente dipendenti e progetti;
  • generare valori economici o ore ufficiali;
  • decidere permessi o confini di visibilità.

Architettura proposta

Tutte le chiamate ai modelli passano dall'llm-gateway condiviso; Rendicontazione non integra direttamente provider o SDK LLM. L'orchestrazione usa strumenti strutturati che espongono soltanto le capacità necessarie, per esempio:

  • get_forecast_explanation_inputs;
  • list_uncovered_project_demand;
  • get_employee_capacity_summary;
  • validate_import_mapping;
  • create_forecast_scenario;
  • compare_forecast_scenarios;
  • get_reporting_summary.

Ogni tool deve ricevere il contesto organizzativo dal backend, applicare i permessi e restituire output con schema versionato. Né organization_iduser_id forniti dal browser possono essere considerati attendibili.

Sicurezza, privacy e affidabilità

  • Minimizzare i dati inviati: preferire aggregati, ruoli e identificativi tecnici a dati personali completi.
  • Escludere informazioni non necessarie come dati fiscali, note HR riservate e contenuti non pertinenti.
  • Applicare tenant scope e permessi prima del recupero dei dati, non soltanto nel prompt.
  • Validare ogni output con JSON Schema prima di utilizzarlo nell'applicazione.
  • Trattare l'output come testo o proposta non attendibile; proteggerlo da prompt injection e uso come comando.
  • Registrare modello, versione prompt, tool invocati, fonti, latenza, costo e correlation ID.
  • Definire retention e redazione dei log senza conservare dati personali superflui.
  • Mostrare chiaramente quando il contenuto è generato dall'AI e richiede verifica.
  • Prevedere timeout, fallback deterministico e indisponibilità senza bloccare i flussi principali.

Valutazione e criteri di accettazione

Ogni funzionalità LLM deve avere un dataset di valutazione anonimizzato e metriche specifiche:

Caso d'usoMisure principali
Mapping importaccuratezza mapping, ambiguità rilevate, correzioni umane
Spiegazione forecastfedeltà ai dati, copertura delle cause, assenza di numeri inventati
Suggerimentivalidità rispetto ai vincoli, utilità valutata dagli operatori
Query naturaleselezione tool corretta, precisione della risposta, rispetto permessi
Sintesi reportcorrettezza dei valori, tracciabilità delle fonti, revisioni necessarie

Il rilascio è bloccato se il modello può produrre modifiche non confermate, accedere a dati di un'altra organizzazione o presentare valori non riconducibili alle fonti strutturate.

Roadmap consigliata

MVP avanzato

  1. Spiega il forecast e le ore scoperte.
  2. Raggruppamento e spiegazione delle anomalie dati.
  3. Proposta di mapping per nuovi formati di import, sempre con approvazione.

Release 1

  1. Interrogazione in linguaggio naturale tramite tool read-only.
  2. Sintesi mensili e bozze di note per i report.
  3. Suggerimenti strutturati per risolvere copertura e sovrallocazione.

Evoluzione successiva

  1. Scenari what-if conversazionali.
  2. Confronto e spiegazione di più scenari.
  3. Miglioramento continuo basato su feedback ed evaluation dataset versionati.
Prima funzionalità raccomandata

Spiega questo forecast e suggerisci come risolvere le ore scoperte” offre un buon rapporto tra valore, visibilità per il committente e rischio: il calcolo resta deterministico mentre l'LLM rende il risultato comprensibile e azionabile.