La domanda più ambiziosa nell'AI finanziaria in questo momento non è "un LLM può rispondere a una domanda su un bilancio?" ma "un LLM può gestire il denaro di un'azienda nel tempo senza rimanerne senza?". Yi Han et al. con Can LLM Agents Be CFOs? (arXiv:2603.23638) costruisce EnterpriseArena per testare esattamente questo, e la risposta è: a malapena, e non nei modi che ci si aspetterebbe.
Il paper
EnterpriseArena è una simulazione di 132 mesi (11 anni) di allocazione delle risorse a livello di CFO. Ogni passo temporale rappresenta un mese. L'agente riceve osservazioni parziali dei dati finanziari aziendali, documenti aziendali anonimizzati e segnali macroeconomici tratti dai dati di FRED, CBOE e S&P Global. Ha un budget di 20 chiamate a strumenti al mese suddivise in quattro operazioni — verifica della posizione di cassa, revisione dei documenti finanziari, analisi delle condizioni di mercato e proiezione dei flussi di cassa — e deve scegliere una delle tre azioni: chiudere i conti (riconciliazione), richiedere finanziamenti (capitale o debito, con risultati stocastici) o passare. Il vincolo principale è che il saldo di cassa dell'azienda deve rimanere non negativo ad ogni passo temporale; la violazione termina l'episodio con un punteggio di zero. Subordinatamente alla sopravvivenza, l'agente massimizza la valutazione aziendale terminale secondo la formula di punteggio Rev_T × 5 + Cash_T − 5.000 × N_strumenti, che penalizza esplicitamente l'uso eccessivo degli strumenti.
Undici LLM sono stati valutati, tra cui Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B e Qwen3.5-9B, insieme a un basamento di esperti umani validato da due professionisti finanziari rispettivamente con 8 e 14 anni di esperienza.
Idee chiave
- I tassi di sopravvivenza variano enormemente tra i modelli: Qwen3.5-9B sopravvive nell'80% delle esecuzioni, Gemini-3.1-Pro nel 50%, Claude-Haiku-4.5 e GLM-5 ciascuno nel 20%, e GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B e Mixtral-8x7B ciascuno allo 0%. La media complessiva degli LLM è del 26%.
- I modelli più grandi non superano in modo affidabile quelli più piccoli: Qwen3.5-9B (9B parametri, 80% di sopravvivenza, valutazione terminale di $78,8 milioni) batte decisamente Qwen3.5-397B (397B parametri, 20% di sopravvivenza) e GPT-5.4 (0% di sopravvivenza).
- Il divario con gli umani è ampio: il basamento umano raggiunge il 100% di sopravvivenza e una valutazione terminale di $152,2 milioni ± $29,6 milioni; la media degli LLM è di $28,2 milioni con il 26% di sopravvivenza.
- La chiusura contabile è il collo di bottiglia critico: gli esperti umani chiudono i conti (riconciliazione) nel 94,3% dei passi temporali; gli LLM in media nel 19,3%. Questa è l'azione che produce bilanci certi e consente decisioni razionali successive.
- La raccolta di informazioni senza azione è letale: Qwen3.5-397B utilizza strumenti di analisi di mercato e previsione ad un alto tasso durante tutta la simulazione, ma non chiude quasi mai i conti (tasso di chiusura contabile dello 0,0%) e non richiede quasi mai finanziamenti, esaurendo la liquidità nonostante "sapesse" cosa stava succedendo.
- La penalità sul budget degli strumenti è importante: la formula di punteggio penalizza attivamente gli agenti che controllano in modo compulsivo piuttosto che agire, un vincolo che rispecchia il costo opportunità reale.
Cosa regge — e cosa no
Il design a doppio obiettivo — sopravvivenza come vincolo rigido più valutazione terminale — è una delle scelte più forti nei recenti benchmark per agenti. Riflette come operano realmente i CFO: non puoi ottimizzare la crescita se sei a corto di denaro. L'anonimizzazione delle date di calendario e delle identità aziendali impedisce ai modelli di fare pattern-matching su risultati storici memorizzati, che è un genuino miglioramento metodologico rispetto ai benchmark finanziari che utilizzano ticker e date reali.
La tassonomia delle modalità di fallimento che gli autori identificano attraverso casi di studio è credibile: GPT-5.4 raggiunge un tasso di passaggio del 99,1% (ovvero agisce a quasi ogni passo temporale non facendo nulla), mentre Qwen3.5-397B scambia l'analisi per azione. Si tratta di modalità di fallimento comportamentalmente distinte con rimedi diversi.
Di cosa sono meno convinto: l'ambiente macroeconomico stocastico utilizza rumore gaussiano per approssimare gli shock di mercato, cosa che gli stessi autori riconoscono non poter replicare eventi del cigno nero o l'irrazionalità umana. Anche il budget di 20 chiamate al mese è alquanto arbitrario — i CFO reali non affrontano questo tipo di vincolo sul tasso di interrogazione nella propria memoria, il che solleva la domanda se il benchmark stia misurando il giudizio finanziario a lungo termine o qualcosa di più vicino a RAG-sotto-pressione-di-risorse. La struttura a singolo agente è un'altra limitazione esplicita che gli autori menzionano: i CFO reali operano all'interno di gerarchie di controller, analisti FP&A e team di tesoreria, e il paper non tenta di simulare questo.
La scoperta che la dimensione del modello non predice la sopravvivenza è sorprendente e probabilmente genuina, ma il meccanismo non è ben spiegato. Gli autori lo notano senza chiarire completamente se si tratti di un fallimento nel seguire le istruzioni, nella coerenza del contesto lungo o nella calibrazione del rischio.
Perché questo è importante per l'AI finanziaria
L'azione di chiusura contabile in EnterpriseArena è essenzialmente l'asserzione balance di Beancount e il passo di riconciliazione contabile — il momento in cui l'agente si impegna a una visione certa dello stato finanziario prima di agire. La scoperta che gli LLM saltano questo passaggio nell'80% dei casi si mappa direttamente sul problema di sicurezza del write-back: un agente che evita la riconciliazione prima di agire è un agente che agisce su uno stato obsoleto o allucinato. Per l'automazione di Beancount, ciò suggerisce che il passo di riconciliazione dovrebbe essere obbligatorio e verificabile — non opzionale — in qualsiasi ciclo di agente.
Anche l'orizzonte di 132 mesi è direttamente analogo alla gestione contabile pluriennale. La scoperta che la consapevolezza situazionale sostenuta si degrada nel tempo è lo stesso degrado che ci aspetteremmo in un agente Beancount che gestisce cinque anni di cronologia transazionale: anche se l'agente ha tutti i dati nel contesto, potrebbe non agire in modo coerente al mese 60. Ciò suggerisce che punti di controllo di riconciliazione forzati periodici — non solo interrogazioni reattive — sono necessari in sessioni di agente Beancount di lunga durata.
La trappola della raccolta di informazioni in cui cade Qwen3.5-397B è un utile avvertimento progettuale: gli agenti dotati di molti strumenti di recupero possono preferire il recupero all'impegno, specialmente quando il costo di un'azione sbagliata (corruzione della contabilità) è elevato. Vincoli sul budget degli strumenti del tipo utilizzato da EnterpriseArena potrebbero aiutare a far rispettare la disciplina d'azione negli agenti di write-back di Beancount.
Cosa leggere dopo
- EcoGym (arXiv:2602.09514) — benchmark economico complementare a lungo orizzonte attraverso ambienti Vending, Freelance e Operation su oltre 1.000 passi; nessun modello domina in tutti e tre, suggerendo che le modalità di fallimento in EnterpriseArena non sono idiosincratiche per un singolo design di benchmark.
- AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, presentazione orale ICLR 2025) — riformula la progettazione del flusso di lavoro come ricerca nello spazio del codice con MCTS e feedback LLM; se EnterpriseArena mostra che i comportamenti degli agenti progettati manualmente falliscono, AFlow è il passo successivo ovvio per scoprire automaticamente pipeline migliori.
- ToolLLM: Facilitating Large Language Models to Master 16.000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — il framework fondamentale di addestramento e valutazione per l'uso degli strumenti; comprendere come viene appreso il comportamento di chiamata agli strumenti in ToolLLM chiarisce se il fallimento di evitamento dell'azione in EnterpriseArena è un problema di addestramento o di prompt.