«Peccato che nessuno riesca a trovarci niente.»
È una frase che mi è rimasta scolpita in testa dopo una riunione di qualche tempo fa.
Avevo davanti a me un documento aziendale di una ottantina di pagine. A guardarlo, un capolavoro: impaginazione perfetta, tabelle elaborate con celle artisticamente disposte, box in evidenza, palette colori aziendale impeccabile. Uno di quei manuali operativi in cui si vede subito che qualcuno ci ha speso intere giornate di lavoro.
Al cliente dissi, sinceramente, che era bellissimo. Poi ho aggiunto una richiesta apparentemente innocua:
«Ora prova a cercare la “procedura di validazione dei fornitori esteri” usando il cerca di Word».
Sono seguiti tre minuti di silenzio. Tentativi a vuoto, scroll frenetici, un pizzico di imbarazzo. Alla fine, l’informazione è saltata fuori solo perché l’autore si ricordava a memoria in quale capitolo l’aveva infilata.
In ThinSoft lavoriamo quotidianamente sui sistemi RAG (Retrieval-Augmented Generation) — quei motori di intelligenza artificiale che interrogano i documenti aziendali per estrarre informazioni puntuali e generare risposte affidabili.
Dopo aver analizzato oltre 10.000 documenti, posso dire con certezza che quando un utente si lamenta dicendo che «il chatbot aziendale non trova le cose» o «risponde a metà», la prima cosa che facciamo è verificare i nostri algoritmi. Ma tornando a ritroso fino alla sorgente, scopriamo quasi sempre la stessa verità:
Il problema era già lì. L’informazione esiste, ma è sepolta sotto la forma.
Abbiamo sviluppato una cultura in cui i documenti aziendali (procedure, policy, manuali tecnici, contratti) sono progettati per essere guardati, non per essere letti e interrogati.
I tre vizi capitali del layout “artistico”
Nel mondo enterprise si confonde spesso la veste grafica con l’usabilità. Ecco i casi più frequenti che riscontriamo sul campo:
1. Il caso delle tabelle “a mosaico”
Celle unite in verticale e in orizzontale per creare impaginazioni scenografiche, intestazioni su tre livelli, colori usati come unico codice di significato. Per chi le crea è tutto ovvio; per un collega che cerca un singolo parametro sotto stress (o per un algoritmo che deve serializzare righe e colonne), la tabella diventa un rebus indecifrabile.
2. Il caso dei falsi titoli
Scrivere una frase in corpo 18, in grassetto e in blu non significa creare un titolo. Per gli occhi umani sembra un’intestazione, ma per il software (Word, parser o screen reader) è solo un paragrafo con un font più grande. Risultato? Sommario automatico vuoto, mappa di navigazione inesistente, struttura semantica pari a zero.
3. La sindrome del “vedi sopra”
«Applicare la procedura descritta nella sezione precedente.»
Quale sezione? Se leggo un libro cartaceo da pagina 1 a pagina 100, forse lo capisco. Ma oggi nessuno lavora più così: arriviamo a una pagina tramite un link diretto, una ricerca interna o un chunk estratto da un LLM. In quel contesto isolato, “sopra” non esiste. Bastava scrivere: «Applicare la procedura di validazione documenti fiscali (sez. 3.2)». Cinque parole in più che salvano l’usabilità.
E con i PDF? Il paradosso del “disegno”
Qui la faccenda si fa ancora più interessante dal punto di vista ingegneristico.
Formati come Word, Markdown o HTML descrivono la struttura logica del testo: alberi gerarchici, titoli nativi (<h1>, <h2>), tabelle con righe e intestazioni definite.
Il PDF, per sua natura storica, non nasce per descrivere una struttura, ma per disegnare una pagina stampabile. Per un PDF, un titolo non è un’entità logica: è una sequenza di caratteri tracciata a coordinate X, Y con una dimensione Z.
I moderni sistemi di parsing e i modelli multimodali fanno miracoli nel dedurre la struttura visiva, ma stanno comunque cercando di “indovinare” a valle ciò che avremmo potuto rendere esplicito a monte. Se il PDF deriva da un file sorgente ben strutturato, il parser lavora con precisione chirurgica; se deriva da composizioni grafiche disordinate o scansioni, stiamo chiedendo alla macchina di fare l’archeologo.
Anche le immagini e i grafici devono “parlare”
Lo stesso principio si applica alle presentazioni e alla documentazione visiva. Con i modelli Vision di ultima generazione possiamo estrarre contesto da qualsiasi immagine, ma la chiarezza batte sempre la metafora.
Se in una slide inserisco la foto di un’alba per indicare “crescita economica”, l’occhio umano coglie l’allusione poetica, ma per un sistema informativo quell’immagine potrebbe significare mattina, sole, speranza, orizzonte.
Un grafico lineare o una freccia accompagnata dalla didascalia: «Trend di crescita ricavi Q1-Q4 2026» non lascia spazio ad ambiguità. La grafica deve rinforzare il dato, mai sostituirlo.
La checklist operativa per documenti che funzionano (per umani e AI)
Non serve iniziare a scrivere “per i robot”. Serve scrivere documenti che funzionino come veri strumenti di lavoro.
Ecco 5 regole d’oro da applicare subito in azienda:
| Buona Pratica | Cosa fare | Cosa evitare |
|---|---|---|
| Struttura gerarchica | Usa sempre gli Stili Titolo nativi (Titolo 1, 2, 3 in Word o #, ## in MD). | Aumentare solo corpo del testo e grassetto a mano. |
| Modularità | Un capitolo = un argomento ben definito. | Mischiare budget, audit e fornitori sotto la stessa voce generica. |
| Autosufficienza dei blocchi | Esplicita nomi, codici e riferimenti esatti di sezione. | Usare formule vaghe come “tale procedura”, “quanto sopra”, “vedi prima”. |
| Tabelle lineari | Intestazioni chiare su singola riga + dati coerenti per colonna. | Celle unite a blocchi, righe vuote decorative, label su più assi. |
| Acronimi definiti | Scrivi il termine per esteso alla prima occorrenza (es. Retrieval-Augmented Generation – RAG). | Dare per scontato che tutti i lettori conoscano il gergo interno. |
Il grande vantaggio nascosto: l’accessibilità reale
C’è una conseguenza virtuosa che abbiamo scoperto analizzando migliaia di file: le stesse identiche regole che rendono un documento digeribile per un’AI lo rendono pienamente accessibile alle persone con disabilità.
Un documento strutturato con titoli nativi, tabelle lineari e immagini con didascalia:
- È perfettamente navigabile da chi usa screen reader per disabilità visive;
- È fruibile su smartphone senza costringere a continui zoom e panning orizzontali;
- È comprensibile per persone con disabilità cognitive o neurodivergenze;
- Risolve il problema del collega che ha 60 secondi di tempo per trovare una risposta prima di entrare dal cliente.
Rendere esplicita la struttura non è una rinuncia all’estetica: è un salto di qualità funzionale.
Il test dei 60 secondi
Vuoi sapere se le procedure della tua azienda sono pronte per il futuro (e per i vostri collaboratori)?
Fate questo test: prendete un collega appena arrivato nel team, dategli il documento e chiedetegli:
«Trovami la procedura per [caso operativo specifico] usando solo la ricerca testuale o l’indice».
Se impiega più di 60 secondi o è costretto a leggersi 15 pagine di fila per orientarsi, il problema non è il nuovo arrivato.
E domani non sarà colpa del chatbot.
Un documento aziendale non è una brochure pubblicitaria: è un’infrastruttura di conoscenza.
Progettarlo bene a monte fa risparmiare centinaia di ore di lavoro a valle.
