PROFESSIONISTI E PROFESSIONE
DI GIACOMO GRECI | 22 LUGLIO 2026
I professionisti dedicano attenzione crescente alla scelta del modello di intelligenza artificiale (ChatGPT, Claude, Gemini) ma trascurano un fattore che incide sulla qualità delle risposte in misura spesso superiore: il formato in cui i documenti vengono forniti al sistema. Un PDF scansionato, un Word con formattazione complessa e un file Markdown producono risultati radicalmente diversi, anche con lo stesso modello e lo stesso prompt. Questo articolo spiega cosa accade realmente quando un documento entra in un modello linguistico, perché il formato determina la qualità dell’output e come il professionista può intervenire concretamente per ottenere risposte migliori.
Quello che l’IA non fa: leggere
Occorre partire da un chiarimento che può sembrare banale ma che è alla radice di molti fraintendimenti operativi. Quando si carica un documento in ChatGPT, in Claude o in qualsiasi altro sistema di intelligenza artificiale, il modello non legge quel documento nel senso in cui lo legge un essere umano. Non vede una pagina impaginata. Non percepisce colonne, riquadri, grassetti, colori. Non distingue un’intestazione da un piede di pagina sulla base della posizione visiva. Non guarda una tabella e ne coglie la struttura a griglia con un solo sguardo.
Ciò che il modello riceve è una sequenza di frammenti di testo (tecnicamente chiamati token) disposti uno dopo l’altro, come le parole su un nastro. Tutta la ricchezza visiva del documento originale deve essere tradotta in questa sequenza lineare prima che il modello possa elaborarla. E la qualità di questa traduzione dipende interamente dal formato del file di partenza.
Questo significa che tra il documento come lo conosciamo noi e il documento come lo riceve l’IA esiste una catena di conversione. Ogni anello di questa catena può introdurre perdite, distorsioni, ambiguità. Chi comprende questa catena è in grado di intervenire là dove la qualità si perde. Chi la ignora attribuirà al modello limiti che in realtà appartengono al formato.
Il viaggio di un documento dal file al modello: la catena di conversione
Indipendentemente dalla piattaforma utilizzata, ogni documento attraversa tre fasi prima di raggiungere il modello linguistico.
Prima fase → Estrazione. Il sistema apre il file e ne estrae il contenuto testuale. Questa operazione è banale per un file di testo puro, complessa per un PDF e intermedia per un DOCX. Il risultato è una stringa di testo grezza, che può essere fedele all’originale o gravemente degradata a seconda del formato.
Seconda fase → Strutturazione. Il testo estratto viene organizzato in blocchi logici: paragrafi, intestazioni, tabelle, elenchi. Nei formati che possiedono una struttura semantica esplicita (Markdown, HTML, XML), questa fase è immediata. Nei formati che possiedono solo una struttura visiva (PDF), è una ricostruzione approssimativa che il parser deve tentare sulla base di indizi posizionali: spaziature, dimensioni del font, coordinate dei blocchi di testo.
Terza fase → Tokenizzazione. Il testo strutturato viene convertito nella sequenza di token che il modello effettivamente elabora. A parità di contenuto informativo, formati diversi generano quantità diverse di token, perché i residui della formattazione (tag XML, metadati, artefatti di conversione) occupano spazio nella sequenza senza apportare informazione utile.
Da questa descrizione emerge una verità operativa che i professionisti dovrebbero interiorizzare: la qualità della risposta dell’IA non dipende solo dal modello e dal prompt, ma dalla pulizia con cui il documento originale attraversa queste tre fasi. Un documento in formato nativo del modello le attraversa senza perdite. Un documento in formato opaco le attraversa perdendo informazione a ogni passaggio.
Il caso PDF: il formato più usato è il peggiore per l’IA
Questa affermazione può sorprendere, dato che il PDF è il formato standard della documentazione professionale: bilanci depositati, visure camerali, atti notarili, sentenze, circolari dell’Agenzia delle Entrate. Eppure, se si comprende la natura interna del formato, la ragione della sua inadeguatezza diventa evidente.
Un file PDF non è un formato di contenuto. È un formato di presentazione visiva. Al suo interno, il testo non è organizzato in paragrafi logici ma in istruzioni di posizionamento: “scrivi questa stringa alle coordinate x=142, y=680 con font Arial dimensione 11”. Quando un parser tenta di ricostruire il flusso del testo, deve leggere queste coordinate e indovinare l’ordine di lettura. Nella maggior parte dei casi ci riesce ragionevolmente bene. Ma nei casi che interessano di più il commercialista (documenti con colonne, tabelle, note a piè di pagina, intestazioni ripetute) il rischio di errore è significativo.
Le tabelle meritano un discorso a parte. Un bilancio in PDF contiene decine di tabelle che l’occhio umano legge senza difficoltà. Ma all’interno del file quelle tabelle non sono oggetti strutturati: sono insiemi di stringhe posizionate a coordinate diverse, senza alcuna indicazione esplicita di quale cella appartenga a quale riga e a quale colonna. Il parser deve ricostruire la griglia a partire dagli allineamenti e quando le colonne non sono perfettamente allineate (cosa frequente nei documenti prodotti da gestionali meno recenti) il risultato può essere una tabella smontata, con valori attribuiti alla colonna sbagliata.
A tutto ciò si aggiunge il caso dei PDF scansionati: verbali assembleari firmati e digitalizzati, atti notarili, documenti bancari. In questi file il testo non esiste affatto come dato digitale. Esiste come immagine. Prima di poter essere elaborato dal modello, deve passare attraverso un sistema di riconoscimento ottico dei caratteri (OCR), che introduce un ulteriore livello di errore: lettere confuse, numeri distorti, strutture non riconosciute. Un importo di 1.250.000 euro può diventare 1.250.0OO o 1.25O.OOO e il modello, che ragiona su token, non ha modo di accorgersi dell’errore.
Un test empirico istruttivo: si provi a caricare il medesimo bilancio in formato PDF nativo e in formato Markdown (convertito manualmente o con uno strumento automatico) nello stesso modello, ponendo la stessa domanda su un dato specifico contenuto in una tabella. Nella maggior parte dei casi, la versione Markdown produrrà una risposta corretta e puntuale, mentre la versione PDF produrrà una risposta approssimativa, errata o accompagnata da caveat sulla difficoltà di leggere il documento. La differenza non è nel modello: è nel formato.
Il caso DOCX: meglio del PDF, ma non innocuo
Il formato Word (.docx) rappresenta un miglioramento sostanziale rispetto al PDF, perché al suo interno conserva una struttura logica: i paragrafi sono identificati come tali, i titoli hanno un livello gerarchico, le tabelle sono oggetti con righe e colonne esplicite. Il parser non deve ricostruire la struttura da indizi visivi: la trova già codificata nel file.
Tuttavia, i documenti Word prodotti nella pratica professionale portano con sé un carico di informazioni accessorie che può confondere l’estrazione. Le revisioni tracciate, i commenti nascosti, le intestazioni e i piè di pagina replicati su ogni foglio, le sezioni con formattazioni diverse, gli stili sovrapposti: tutto questo materiale viene estratto insieme al contenuto e finisce nella sequenza di token che il modello riceve. Un documento Word prodotto da un gestionale contabile può contenere, dietro una pagina apparentemente semplice, decine di tag XML di formattazione che occupano spazio nella finestra di contesto del modello senza apportare alcun valore informativo.
C’è poi una questione specifica dei documenti generati automaticamente dai software di Studio. Molti gestionali producono file .docx con strutture interne non standard: tabelle annidate, campi calcolati, riferimenti incrociati che, una volta estratti, producono testo frammentato e difficilmente interpretabile. Il professionista che carica un verbale assembleare prodotto dal proprio gestionale in un chatbot potrebbe non ottenere i risultati attesi non per un limite del modello, ma per la peculiarità del file che gli ha fornito.
Il caso XLSX: dati strutturati con insidie nascoste
I fogli di calcolo sono, per certi aspetti, il formato più pulito per i dati tabulari: righe, colonne, celle con contenuti definiti. Quando un modello riceve un foglio Excel correttamente estratto, dispone di una griglia ordinata su cui ragionare. Il problema è che la pratica professionale introduce nell’uso di Excel una serie di abitudini che il modello non sa gestire.
Le celle unite, diffusissime nei prospetti di bilancio e nelle relazioni di revisione, distruggono la logica riga-colonna: il parser non sa se la cella unita è un’intestazione di gruppo, un commento o un dato. Le formule non risolte vengono talvolta estratte come stringhe testuali (=SOMMA(B2:B15) invece del valore numerico), rendendo il contenuto inutilizzabile. I nomi di colonna distribuiti su più righe (prassi comune nei prospetti con intestazioni lunghe) producono tabelle in cui il modello non riesce a individuare dove finiscono le intestazioni e dove cominciano i dati. I fogli nascosti e le aree di stampa personalizzate possono portare a estrazioni parziali senza che l’utente se ne accorga.
Il caso Markdown: il formato nativo del pensiero dell’IA
Per comprendere perché il Markdown rappresenta il formato ottimale per l’interazione con un modello linguistico, occorre capire cos’è. Il Markdown è un linguaggio di marcatura leggero, inventato nel 2004 da John Gruber, il cui principio fondamentale è: un documento deve essere leggibile dall’essere umano nella sua forma grezza, senza bisogno di rendering. I titoli si indicano con il simbolo #, i sottotitoli con ##, gli elenchi con il trattino -, le tabelle con il carattere |, il grassetto con due asterischi **parola**. Nessun metadato nascosto, nessuna informazione di layout, nessuna formattazione proprietaria.
Questa pulizia strutturale produce tre effetti concreti quando il documento viene elaborato da un modello linguistico.
Primo: fedeltà totale nella conversione. Non esiste catena di conversione. Il Markdown è già testo strutturato. Il modello riceve esattamente ciò che il documento contiene, nella gerarchia in cui è stato organizzato. Nessun parser deve interpretare, ricostruire o indovinare. Il rischio di perdita informativa è prossimo allo zero.
Secondo: rapporto segnale/rumore massimo. In un file Markdown, ogni carattere è contenuto o struttura. Non ci sono tag di formattazione, metadati nascosti, stili sovrapposti. A parità di contenuto informativo, un file Markdown produce significativamente meno token di un DOCX estratto, il che significa: più spazio nella finestra di contesto del modello per l’informazione che conta, meno spazio sprecato in rumore.
Terzo: struttura semantica esplicita. Un titolo marcato con ## è inequivocabilmente un titolo di secondo livello. Un elenco marcato con – è inequivocabilmente un elenco. Una tabella marcata con | è inequivocabilmente una tabella con le sue colonne. Il modello non deve dedurre la struttura: la riceve dichiarata. Questo riduce l’ambiguità e migliora la precisione delle risposte, soprattutto nelle interrogazioni su documenti complessi.
Esiste infine un aspetto che merita attenzione specifica. I modelli linguistici di ultima generazione sono stati addestrati su enormi quantità di testo proveniente dal web e una porzione significativa di quel testo era scritta in Markdown. La documentazione tecnica su GitHub, i file README dei progetti software, i contenuti delle piattaforme di knowledge management: tutto in Markdown. Ciò significa che il modello ha una familiarità nativa con le convenzioni Markdown, riconosce la struttura, ne rispetta la gerarchia, sa produrre output in Markdown quando gli viene chiesto. È il formato su cui il modello, letteralmente, è cresciuto.
I formati a confronto: una tabella comparativa
Per orientare le scelte operative dello Studio, è utile un confronto sistematico tra i formati documentali più diffusi nella pratica professionale, valutati sotto il profilo della compatibilità con i sistemi di intelligenza artificiale.
| Formato | Fedeltà strutturale | Gestione tabelle | Rumore (metadati) | Compatibilità RAG | Effort conversione |
| PDF nativo | Bassa (ricostruzione da coordinate) | Critica (griglia non esplicita) | Medio (font, posizione) | Bassa | Elevato |
| PDF scansionato | Molto bassa (OCR necessario) | Molto critica | Alto (artefatti OCR) | Molto bassa | Molto elevato |
| DOCX | Media (struttura logica presente) | Buona (oggetti espliciti) | Alto (stili, revisioni, XML) | Media | Medio |
| XLSX | Medio-alta (griglia esplicita) | Buona se ben formato | Basso | Medio-alta per dati tab. | Basso-medio |
| TXT | Nessuna (testo piatto) | Inesistente | Nullo | Bassa (no struttura) | Nullo |
| HTML | Alta (tag semantici) | Buona (<table>) | Medio (CSS, script) | Alta | Medio |
| Markdown | Molto alta (struttura esplicita) | Buona (sintassi |) | Nullo | Ottimale | Da medio a basso |
Raccomandazione operativa:
Per l’archivio documentale destinato all’interrogazione tramite IA o all’indicizzazione in un sistema RAG, il Markdown rappresenta il formato di riferimento.
Per i documenti destinati alla stampa, alla firma o al deposito presso terzi, il PDF resta necessario.
Le due esigenze non sono in contraddizione: si conserva il PDF come formato di deposito e si produce una versione Markdown come formato di lavoro per l’IA. Il costo aggiuntivo della doppia produzione è modesto e si riduce rapidamente con l’adozione di strumenti e procedure standardizzate.
Cosa sono i token e perché il formato influenza costi e capacità
Per comprendere pienamente l’impatto operativo di quanto descritto, è necessario un breve approfondimento su una nozione tecnica che il professionista dovrebbe padroneggiare: il concetto di token.
Un token è l’unità elementare di testo che il modello linguistico elabora. Non corrisponde esattamente a una parola: in italiano, una parola comune come “commercialista” viene scomposta in due o tre token, mentre una parola breve come “fisco” ne occupa uno. Come ordine di grandezza approssimativo, in un testo italiano un token corrisponde mediamente a circa quattro caratteri.
I token hanno due implicazioni dirette per il professionista.
Implicazione economica. I servizi di intelligenza artificiale commerciali fatturano per token elaborati, sia in ingresso sia in uscita. Un documento che, a causa del formato, produce il 40 per cento di token in più rispetto al suo contenuto effettivo genera un costo proporzionalmente superiore senza alcun beneficio informativo. Su uno Studio che elabora centinaia di documenti al mese attraverso un’API, la differenza diventa economicamente significativa.
Implicazione sulla capacità. Ogni modello linguistico ha una finestra di contesto, il numero massimo di token che può elaborare in una singola operazione. Se una parte di quella finestra è occupata da rumore di formattazione, resta meno spazio per il contenuto effettivo del documento e per la risposta del modello. In uno scenario RAG, dove il sistema deve inserire nella finestra sia la domanda dell’utente sia i frammenti documentali recuperati, ogni token sprecato riduce la quantità di contesto utile che il modello può considerare.
Esempio concreto: un parere di 5 pagine in formato Word, estratto con il parser standard, può produrre circa 3.500 token. Lo stesso contenuto informativo, convertito in Markdown pulito, ne produce circa 2.200. La differenza di 1.300 token è interamente rumore di formattazione. Moltiplicata per i documenti di un intero archivio di Studio, la differenza si traduce in centinaia di migliaia di token risparmiati ossia, in un sistema RAG, in uno spazio aggiuntivo significativo per il contenuto che conta.
Quattro scenari operativi per lo Studio
Per tradurre questi principi in azioni concrete, si illustrano quattro scenari operativi con indicazione delle procedure e degli strumenti da adottare.
Scenario 1 – Convertire i modelli di parere da Word a Markdown
I modelli di parere, le bozze di consulenza e i template di Studio sono tipicamente conservati in formato Word. Convertirli in Markdown significa disporre di una versione immediatamente utilizzabile con qualsiasi strumento di IA senza perdita di struttura. La conversione può essere effettuata con lo strumento open source Pandoc, disponibile per tutti i sistemi operativi.
Procedura operativa – Conversione DOCX → Markdown con Pandoc
Da terminale (Mac/Linux/Windows):
pandoc parere_template.docx -t markdown -o parere_template.md –wrap=none
Il flag –wrap=none evita l’interruzione automatica delle righe.
Verificare il file .md risultante: le intestazioni devono essere marcate con #, le tabelle con |, gli elenchi con -. Correggere manualmente eventuali artefatti (immagini non convertite, formattazioni complesse).
Tempo stimato per un documento di 10 pagine: 5-10 minuti tra conversione e pulizia.
Scenario 2 – Pre-trattare un bilancio in PDF per il sistema RAG
Un bilancio depositato in formato PDF contiene informazioni preziose, stato patrimoniale, conto economico, nota integrativa, ma in un formato che l’IA legge male. Il pre-trattamento consiste nell’estrazione strutturata del contenuto e nella sua conversione in un formato ad alta fedeltà prima dell’indicizzazione nel sistema RAG.
Procedura operativa – Pre-trattamento bilancio PDF
Fase 1: estrarre il testo con uno strumento di parsing avanzato.
Strumenti consigliati: PyMuPDF (pymupdf4llm) per Python, che produce direttamente output in Markdown; in alternativa, marker o docling di IBM per documenti complessi con tabelle.
Fase 2: verificare manualmente le tabelle di stato patrimoniale e conto economico, che sono i punti più critici della conversione. Controllare che le colonne siano allineate correttamente e che i totali corrispondano.
Fase 3: arricchire il file Markdown con metadati utili all’interrogazione: denominazione della società, esercizio di riferimento, data di deposito. Inserirli come intestazione del file.
Fase 4: indicizzare il file nel sistema RAG.
Tempo stimato per un bilancio di 30 pagine: 30-45 minuti per la prima volta, 10-15 per i successivi una volta consolidata la procedura.
Scenario 3 – Strutturare le carte di lavoro di revisione in Markdown
Le carte di lavoro sono il terreno su cui la scelta del formato produce l’impatto più rilevante. Una carta di lavoro in Word o in Excel, caricata in un sistema RAG, viene indicizzata con tutti i limiti di formato descritti. La stessa carta di lavoro redatta nativamente in Markdown è immediatamente disponibile per l’interrogazione, con struttura preservata e rapporto segnale/rumore ottimale. Lo sforzo di adattamento è circoscritto: non si tratta di cambiare il modo di lavorare, ma di adottare per le carte di lavoro un formato che, per lo più, si limita a utilizzare il cancelletto per i titoli e il trattino per gli elenchi.
Esempio operativo – Carta di lavoro in Markdown
# Carta di lavoro: test di cut-off vendite
## Cliente: [denominazione] | Esercizio: 2025 | Revisore: [nome]
## Obiettivo Verificare che i ricavi siano registrati nel corretto esercizio di competenza.
## Procedura
– Selezionato campione di [n] fatture emesse negli ultimi 5 giorni lavorativi dell’esercizio e nei primi 5 del successivo
– Criterio di selezione: [casuale / per importo / stratificato]
– Per ciascuna fattura verificato:
(1) data DDT,
(2) data registrazione,
(3) coerenza temporale
## Risultanze
| N. fattura | Data DDT | Data registrazione | Esito | |—|—|—|—| | 1234 | 28/12/2025 | 28/12/2025 | Conforme | | 1235 | 30/12/2025 | 03/01/2026 | Anomalia: registrazione esercizio successivo |
## Conclusione
Rilevata [n] anomalia su [n] elementi testati. Impatto stimato: [importo].
Procedura di risposta: [descrizione].
Scenario 4 – Costruire un archivio normativo in Markdown
Le circolari dello Studio, le note operative, le schede di sintesi normativa che il professionista produce abitualmente sono materiale di altissimo valore per un sistema RAG. Redigere questi documenti direttamente in Markdown, anziché in Word, significa renderli immediatamente indicizzabili senza alcuna fase di conversione. Molti editor di testo oggi supportano nativamente il Markdown, tra i più utilizzati: Obsidian, Typora, Visual Studio Code con le estensioni appropriate e la curva di apprendimento per la sintassi base è nell’ordine di una o due ore.
Esempio operativo – circolare di Studio in Markdown
“# circolare di Studio n. 12/2026 ## Oggetto: Nuove aliquote IRPEF – impatto su persone fisiche ## Data: 15 marzo 2026 | Redattore: [nome socio] ## Sintesi La Legge di Bilancio 2026 ha modificato le aliquote IRPEF con effetto dal 1° gennaio 2026. Le principali novità riguardano: [elenco sintetico]. ## Analisi dettagliata ### Fascia di reddito fino a 28.000 euro [Testo dell’analisi] ### Fascia di reddito da 28.001 a 50.000 euro [Testo dell’analisi] ## Implicazioni operative per i clienti dello Studio – Clienti con reddito prevalente da lavoro autonomo: [indicazioni] – Clienti con redditi da partecipazione: [indicazioni] ## Azioni richieste – Ricalcolo acconti 2026 entro il [data] – Comunicazione ai clienti della fascia impattata entro il [data]”
Una regola semplice per il professionista
Al termine di questa analisi, che ha toccato aspetti tecnici non banali, è opportuno condensare il messaggio in una regola operativa che il professionista possa portare con sé.
La regola è questa: ogni documento destinato ad essere elaborato dall’intelligenza artificiale dovrebbe essere disponibile in Markdown. Non necessariamente al posto del formato originale, ma accanto ad esso. Il PDF resta il formato di deposito e di scambio. Il Word resta il formato di redazione collaborativa. Ma il Markdown è il formato di lavoro per l’IA.
Chi costruisce un sistema RAG sul proprio archivio e lo alimenta con modelli locali otterrà risultati tanto migliori quanto più il materiale indicizzato è pulito, strutturato e privo di rumore. E il Markdown, fra tutti i formati disponibili, è quello che possiede queste tre qualità nella misura più alta.
Non si tratta di una rivoluzione nei processi dello Studio. Si tratta di un’abitudine nuova, che si acquisisce in poco tempo e che produce effetti cumulativi nel tempo. Ogni documento redatto o convertito in Markdown è un tassello che si aggiunge all’infrastruttura digitale della propria conoscenza professionale. Chi comincia oggi, tra un anno disporrà di un archivio strutturato, interrogabile, efficiente. Chi continuerà a conservare tutto in PDF e Word, tra un anno avrà lo stesso archivio opaco di sempre solo con un chatbot in più che fa fatica a leggerlo.
La qualità dell’intelligenza artificiale, nel lavoro dello Studio, non si misura dal modello che si sceglie. Si misura da come si preparano i documenti che gli si danno in pasto.
Il contenuto di questa newsletter è strettamente riservato e destinato esclusivamente ai destinatari autorizzati.
È espressamente vietata la condivisione totale o parziale di questa comunicazione su qualsiasi piattaforma pubblica o privata, inclusi (ma non limitati a):
• Gruppi e canali Telegram
• Chat di gruppo o broadcast su WhatsApp
• Post o storie su Facebook, Instagram, X (Twitter), LinkedIn, o altri social network.
Ogni violazione di questa norma potrà comportare l’esclusione immediata dalla lista dei destinatari e, nei casi più gravi, azioni legali.
Grazie per il rispetto delle regole e per contribuire a mantenere la riservatezza delle informazioni condivise.