IA nella contabilità: mantenere la tracciabilità GoBD nonostante la black box

Uno Steuerberater di Monaco ci ha raccontato di una revisione cliente che ancora lo turba. La contabilità sembrava pulita. I numeri quadravano. Poi ha chiesto a un junior come fosse stato categorizzato un certo lotto di ricevute, e la risposta è stata: “Le abbiamo incollate in ChatGPT e ha suggerito i conti.” Nessuno aveva registrato i prompt. Nessuno poteva riprodurre i suggerimenti. La registrazione contabile esisteva, ma il ragionamento dietro di essa era evaporato nell’istante in cui la finestra della chat si era chiusa.

Questo e il problema GoBD dell’IA in una sola scena. Non che l’IA avesse torto. Che nessuno potesse dimostrare che avesse ragione.

Cosa richiede davvero il GoBD, in parole semplici

Il GoBD sono i principi dell’autorità fiscale tedesca per la corretta tenuta e conservazione dei libri e delle registrazioni in forma elettronica. Non sono nuovi, e non sono vaghi sulle parti che qui contano. Tre requisiti si scontrano direttamente con il modo in cui funziona la maggior parte dell’IA generativa.

Nachvollziehbarkeit (tracciabilità). Una terza parte competente deve poter seguire come un’operazione commerciale sia diventata una registrazione contabile, entro un tempo ragionevole, senza il tuo aiuto. La voce deve ricondurre al documento sorgente, e il documento sorgente deve condurre in avanti alla voce. Devono funzionare sia un controllo progressivo sia uno retrogrado.

Nachpruefbarkeit (verificabilità). Le registrazioni devono essere verificabili. Un revisore dovrebbe poter prendere un numero e controllarlo rispetto alle prove sottostanti e alle regole che lo hanno prodotto.

Unveraenderbarkeit (immutabilita). Una volta registrata, una scrittura non può essere sovrascritta silenziosamente. Le modifiche devono essere registrate così che sia lo stato originale sia quello corretto sopravvivano entrambi.

C’e un quarto elemento che spesso si dimentica: la Verfahrensdokumentation. Ci si aspetta che tu documenti il processo attraverso cui i dati entrano nei tuoi libri contabili e vengono trasformati lungo il percorso. Se uno strumento tocca i dati, quello strumento fa parte del processo che devi descrivere.

Leggendo insieme questi quattro punti, la domanda si risponde da sola. Un assistente chat a testo libero che “suggerisce” assegnazioni di conto lascia una traccia riproducibile? No. Produce un processo che si potrebbe mettere per iscritto e che una terza parte potrebbe rieseguire? Non a meno che tu non abbia costruito da solo quell’impalcatura.

Perché un LLM standard infrange tutti e quattro i principi insieme

Un modello linguistico di grandi dimensioni genera il token successivo più probabile dato il contesto. Non recupera una cifra fissa e non esegue aritmetica in un modo che tu possa ispezionare. Fai la stessa domanda due volte e puoi ottenere due risposte diverse, entrambe espresse con la stessa calma sicurezza. Va bene per scrivere una bozza di email. E’ un problema quando l’output diventa parte di una registrazione rilevante ai fini fiscali.

Provalo tu stesso. Incolla un estratto di conto economico in un assistente generico e chiedi il margine lordo. Di solito otterrai un numero. Chiedilo di nuovo in una sessione nuova e potresti ottenere un numero leggermente diverso, o un arrotondamento diverso, o una cifra che la prima volta ha silenziosamente assunto l’IVA in un modo e la seconda volta nell’altro. Il modello non sta recuperando il tuo margine. Sta facendo pattern-matching verso qualcosa che assomiglia a un margine.

Ora sovrapponi il GoBD:

• La tracciabilità fallisce perché la risposta non può essere ricondotta a una riga sorgente specifica.
• La verificabilità fallisce perché rieseguire il prompt potrebbe non riprodurre la cifra.
• L’immutabilita fallisce perché non esiste alcuna registrazione di cosa il modello abbia visto o detto.
• La Verfahrensdokumentation non può essere scritta perché il processo non è abbastanza deterministico da poter essere descritto.

Nulla di tutto questo significa che l’IA sia inutilizzabile nella contabilità tedesca. Significa che l’IA non può essere il sistema di registrazione, e non può essere ciò che fa i calcoli.

Il rischio reale: la Schatten-KI

La versione pericolosa di tutto questo non è uno strumento autorizzato. E la Schatten-KI, l’IA ombra. Personale che incolla silenziosamente estratti di libro mastro, fatture e dati clienti in qualsiasi chatbot consumer sia aperto in un’altra scheda. Sembra innocuo perché e solo “chiedere aiuto”. Ma ogni incolla e un passaggio non documentato nel tuo processo contabile, e alcuni di quegli incolla sono anche un incidente di protezione dei dati in attesa di essere scoperto.

I sondaggi tra i team finance tedeschi arrivano sempre allo stesso quadro: una larga parte dei dipendenti già usa strumenti IA sul lavoro, e una quota significativa lo fa senza che IT o management lo sappiano. Non puoi uscire da questa realtà scrivendo una policy. Le persone useranno lo strumento che fa loro risparmiare venti minuti. Il compito e dare loro un percorso autorizzato che sia anche quello sicuro dal punto di vista GoBD.

L’esposizione e concreta. Se un Betriebsprufer conclude che la contabilità non è nachvollziehbar, il caso peggiore non è una lettera severa. E’ una Verwerfung: le registrazioni vengono respinte e la base imponibile può essere stimata al loro posto. Una stima raramente gioca a tuo favore.

Come mantenere la traccia di audit quando l’IA e nel processo

Non risolvi questo problema vietando l’IA o fidandoti di più di essa. Lo risolvi cambiando di cosa l’IA e autorizzata a essere responsabile. Tre principi, in ordine.

1. I numeri vivono in un modello riconciliato, non nella chat

Prima che qualsiasi IA tocchi una cifra, i dati sottostanti devono essere assemblati in un unico modello finanziario riconciliato che si ricolleghi al libro mastro. Dati contabili, dati bancari, sotto-mastri, estratti caricati: raccolti insieme, abbinati e riconciliati con la fonte. Questa e l’unica fonte di verità, ed esiste indipendentemente da qualsiasi domanda che qualcuno ponga. L’IA non “conosce” il tuo fatturato. Lo cerca in un modello che già coincide con i tuoi libri.

Questo e il cuore di ciò che costruiamo in Rexfin: un unico modello riconciliato a cui ogni risposta si ricollega. Se vuoi i meccanismi di perché la riconciliazione debba venire prima dell’IA, l’articolo pilastro sui modelli finanziari sicuri per GoBD e AI Act espone l’argomento per intero.

2. I calcoli girano in un motore deterministico, non nel modello

L’LLM e bravo a capire una domanda in tedesco e a spiegare una risposta in linguaggio semplice. E’ scarso nell’aritmetica, e ancora peggiore in un’aritmetica che tu possa verificare. Quindi il calcolo deve avvenire in un luogo deterministico. Chiedi un margine lordo e gli stessi input producono lo stesso output ogni volta, secondo la stessa formula documentata. L’IA instrada la domanda. Il motore esegue il calcolo. Questa separazione e ciò che rende il risultato riproducibile, esattamente ciò che richiede la Nachpruefbarkeit. C’e una versione più approfondita di questo punto nell’articolo gemello su perché la qualità dei dati batte il modello.

3. Ogni cifra porta con se la propria provenienza e viene registrata

Quando l’IA riporta un numero, dovresti poterci cliccare sopra e vedere: quali documenti sorgente lo hanno alimentato, quale calcolo lo ha prodotto, e quando. E l’interazione stessa dovrebbe essere scritta in un log immutabile. Questo copre in un solo passaggio tracciabilità e immutabilita. Una cifra che può nominare la propria fonte e sopravvivere in una registrazione a prova di manomissione e una cifra che puoi difendere in una Prufung.

Mettendo insieme questi tre principi, la Verfahrensdokumentation quasi si scrive da sola, perché ora esiste un processo stabile e descrivibile: dati in ingresso, riconciliati, calcolati in modo deterministico, risposta con citazione, registrazione. Puoi consegnare questa descrizione a una terza parte e questa può seguirla.

Un breve bagno di realtà

Questo approccio ha limiti che vale la pena dichiarare apertamente. Non trasforma l’IA nel contabile. Un umano possiede ancora le registrazioni e le decisioni di giudizio. Non ti solleva dagli obblighi di protezione dei dati che derivano dall’alimentare il modello con le tue registrazioni. E nessuna architettura rimuove il dovere di mantenere effettivamente la Verfahrensdokumentation: la tecnologia lo rende possibile, ma sei tu a doverla tenere aggiornata.

Ciò che ottieni davvero e la cosa che il GoBD in realtà cerca. Non una macchina più intelligente. Una macchina difendibile.

Il test per qualsiasi IA che lasci avvicinare ai tuoi libri contabili e semplice, e puoi applicarlo in una demo: prendi un numero che ha prodotto e chiedile di mostrare come ci e arrivata. Se può nominare il documento sorgente, riprodurre il calcolo e dimostrare che non è stato alterato, ha un posto in una funzione finance tedesca. Se può solo suonare sicura di se, non ce l’ha.

Se vuoi vedere come funziona con il tuo stesso libro mastro, prenota una demo e porta una cifra che normalmente dovresti difendere davanti a un revisore.