Tempo di lettura: 20 minuti
Indice dei contenuti
C’è un momento, quando lavori con i progetti AI, in cui ti sembra #fattobene caricare tutto e di più nella AI Knowledge Base.
Prompt vecchi, prompt nuovi, documenti strategici, bozze operative, note sparse, checklist tecniche, file commerciali, vecchie istruzioni, nuove istruzioni, PDF dimenticati, pezzi di workflow, appunti di una call fatta tre mesi prima. Tutto dentro. Così la AI “sa”.
In teoria sembra sensato. In pratica, spesso, è il modo più rapido per trasformare una AI Knowledge Base in una soffitta digitale uscita da un format televisivo tipo: “Sepolti in casa”.
Una soffitta piena di cose utili, per carità. Ma anche di scatoloni senza etichetta, doppioni, vecchie versioni, oggetti che non servono più e documenti che dicono la stessa cosa in modi diversi. Oppure, peggio, che dicono cose diverse, fingendo di essere ancora tutti validi.
Il risultato è abbastanza prevedibile: il modello non lavora meglio perché ha più materiale. Lavora peggio perché riceve più rumore informativo.
La cosa interessante è che questo errore non nasce dalla superficialità. Nasce spesso dall’intenzione opposta: voler essere precisi, completi, organizzati. Solo che, a un certo punto, completezza e confusione iniziano ad assomigliarsi troppo.
Me ne sono accorto lavorando su un progetto reale, non facendo teoria da lavagna motivazionale con pennarello scarico 😁. Il punto era semplice: rendere più efficace un progetto AI usato per gestire contenuti, SEO tecnica, workflow editoriali, documentazione interna e procedure operative.
All’inizio la tentazione era aggiungere. Poi è arrivata la parte più utile: togliere. Come dicono quelli bravi: Less Is More. E un motivo ci sarà se viene ripetuto sempre alle conventions e ai workshop!?! O no?
Non cancellare conoscenza, ma distinguere. Non impoverire il progetto, ma alleggerirlo. Non ridurre l’intelligenza, ma ridurre l’attrito.
Perché una buona AI Knowledge Base non è quella che contiene più file. È quella che contiene i file giusti, scritti bene, aggiornati, non ridondanti e organizzati secondo una logica chiara.
Quando la documentazione diventa rumore
La documentazione è una cosa bellissima. Almeno finché documenta.
Il problema comincia quando diventa un deposito da format televisivo “Sepolti vivi”. E il deposito, nei progetti AI, è una bestia subdola: non fa rumore, non protesta, non ti chiede manutenzione. Sta lì. Tu continui a caricare file e lui continua ad ingrandirsi. Insomma, diventa un moloch.
Un vecchio master prompt resta accanto alle nuove istruzioni. Una procedura superata resta accanto al workflow aggiornato. Un documento nato come esperimento resta nella stessa Knowledge Base di un file operativo. Una checklist preparatoria continua a parlare come se fosse ancora il riferimento principale.
Per un essere umano esperto, forse, il contesto storico è leggibile. Ed è questo che ancora oggi distingue il discernimento umano dalla fredda macchina. Altrimenti andremmo tutti a casa. Vedi il file, capisci che è vecchio, lo relativizzi. Per un modello AI, invece, quel materiale può diventare contesto attivo. E se il contesto attivo contiene versioni diverse della stessa regola, la risposta rischia di perdere precisione.
È un problema molto simile a quello che accade con la cannibalizzazione SEO.
Due contenuti competono per lo stesso intento, confondono la lettura del sito e indeboliscono la chiarezza complessiva. Nella AI Knowledge Base succede qualcosa di analogo: due documenti spiegano lo stesso workflow, ma con priorità, tono o dettagli diversi. Il modello pesca, combina, media.
E la media, in questi casi, non è equilibrio. È nebbia.
Il punto non è avere pochi file per principio. Il punto è evitare file che non hanno più una funzione chiara.
Una Knowledge Base può anche essere ampia, se ogni documento ha un ruolo preciso. Ma quando i file iniziano a sovrapporsi senza gerarchia, la documentazione smette di aiutare e comincia a interferire.
A quel punto il problema non è più “manca contesto”.
Il problema è: ce n’è troppo, non è ordinato e nessuno ha detto al modello dove pescare.
Il paradosso dei progetti AI: più file, meno chiarezza
Il paradosso è questo: nei progetti AI, spesso aggiungiamo documenti per aumentare la precisione, ma otteniamo l’effetto contrario.
Succede perché confondiamo due cose diverse: quantità di materiale e qualità del contesto.
Un progetto AI non ragiona come un archivista umano che conosce la storia dei file, sa quale documento è nato prima, quale è stato superato, quale era solo una bozza e quale invece è la procedura definitiva. Il modello legge quello che trova, valuta le informazioni disponibili e prova a costruire una risposta coerente.
Se però la AI Knowledge Base contiene dieci documenti simili, con regole parzialmente sovrapposte, versioni diverse dello stesso workflow e istruzioni non più aggiornate, la coerenza diventa fragile.
Non perché la AI sia “stupida”. Perché la base informativa è ambigua.
Nei progetti AI questo si vede in piccoli segnali: risposte che cambiano tono senza motivo. Output che mescolano vecchie regole e nuove preferenze. Documenti finali formalmente corretti, ma leggermente fuori fuoco. Raccomandazioni che non sono sbagliate, ma nemmeno davvero allineate.
Quel tipo di risposta che leggi e pensi: “Sì, ci siamo quasi, ma non è esattamente quello che avevo chiesto”.
Il problema, spesso, non è il prompt del momento. È il retrobottega.
Se il retrobottega è pieno di scaffali storti, etichette vecchie e scatole duplicate, anche il commesso più volenteroso farà fatica a trovare subito il pezzo giusto. Magari lo trova, ma prima passa da tre cassetti sbagliati. E qualche volta ti porta una vite quasi compatibile.
Nel lavoro con la AI, quel “quasi” pesa.
Pesa nei testi, perché il tono si sporca. Pesa nella SEO tecnica, perché una priorità può essere interpretata male. Pesa nella documentazione interna, perché un workflow vecchio può tornare a galla.
Una AI Knowledge Base non dovrebbe essere pensata come una cartella condivisa. Dovrebbe essere pensata come una piccola architettura decisionale.
Non tutto deve stare dentro. Non tutto deve avere lo stesso peso. Non tutto deve restare attivo per sempre.
Pochi documenti, ma scritti bene
La soluzione non è avere una AI Knowledge Base minuscola. La soluzione è avere una Knowledge Base progettata per priorità.
Pochi file, se scritti male, restano pochi file scritti male. Non fanno miracoli. Non diventano improvvisamente strategici solo perché sono snelli. La leggerezza, da sola, non basta.
Il punto è un altro: ogni documento deve avere una funzione riconoscibile.
Un file può servire a definire le istruzioni generali del progetto. Un altro può descrivere il modello operativo. Un altro ancora può contenere un workflow editoriale. Poi ci possono essere documenti specialistici, asset di brand, template commerciali, riferimenti di stile.
Ma ogni file dovrebbe rispondere a una domanda precisa:
Perché esiste questo documento?
Se la risposta è vaga, il documento probabilmente sta solo occupando spazio cognitivo.
Nel lavoro sul mio progetto interno, la svolta è arrivata quando ho smesso di ragionare per accumulo e ho iniziato a ragionare per gerarchia. Non “che cosa posso caricare ancora?”, ma “che cosa deve guidare davvero il progetto?”.
Da lì è nata una struttura molto più semplice:
- istruzioni compatte;
- modello operativo;
- workflow fondativi;
- workflow specialistici;
- asset sorgente separati;
- archivio storico fuori dalla knowledge attiva.
Niente di esoterico. Niente formula magica. Solo ordine.
Le istruzioni generali devono essere brevi, perché hanno il compito di orientare il comportamento complessivo. Non possono diventare un romanzo ottocentesco russo con dentro ogni dettaglio possibile. Se diventano troppo lunghe, perdono forza. Se cercano di dire tutto, finiscono per non dare priorità a nulla.
I workflow, invece, possono essere più pratici. Devono spiegare quando usarli, quali input servono, quali output produrre, quali errori evitare, quale checklist seguire.
Gli asset sorgente sono un’altra cosa ancora: palette, dati aziendali, intestazioni, FAQ, template, loghi. Sono utili, ma non devono guidare da soli il comportamento del progetto.
Una palette non è una strategia.
Un template non è un metodo.
Una FAQ commerciale non deve sovrascrivere un workflow editoriale.
Quando i file hanno ruoli diversi, il modello trova meglio il contesto. Quando i file sono tutti sullo stesso piano, il modello deve indovinare. E quando deve indovinare troppo, prima o poi produce una risposta che sembra corretta, ma non è davvero centrata.
La domanda più sana da farsi, davanti a un nuovo file, non è “può tornare utile?”. Quasi tutto può tornare utile, in astratto. Anche un cavo SCART nel 2026 può avere il suo momento di gloria, se trovi il videoregistratore giusto.
La domanda vera è:
Questo documento deve stare nella knowledge attiva?
Se aggiunge una procedura nuova, sì.
Se chiarisce una regola esistente, forse.
Se duplica qualcosa che c’è già, no: va integrato nel documento giusto.
Se racconta la storia del progetto, ma non serve più a guidarlo, va archiviato.
L’archivio non è una punizione. È igiene informativa.
Istruzioni compatte, workflow fondativi, asset separati
Una buona AI Knowledge Base dovrebbe avere pochi livelli, ma ben distinti.
Il primo livello sono le istruzioni compatte. Servono a dire al progetto chi è, come deve ragionare, quali principi deve rispettare, quali errori deve evitare. Sono la bussola. Non devono contenere ogni dettaglio operativo, perché una bussola non è una carta topografica.
Le istruzioni compatte devono rispondere a domande essenziali:
- qual è il ruolo del progetto?
- quale tono deve usare?
- quali regole non deve violare?
- quali workflow deve scegliere in base al task?
- quali limiti deve rispettare?
Il secondo livello sono i workflow fondativi.
Qui non si definisce più soltanto l’identità del progetto. Si spiega come lavorare.
Un workflow editoriale, ad esempio, deve dire come partire da una main keyword, come costruire la struttura, come gestire H1, slug, excerpt, meta title, meta description, immagini, schema markup e controllo finale.
Un workflow tecnico deve spiegare come diagnosticare un problema, distinguere causa e sintomo, assegnare priorità, proporre un fix e verificare il risultato.
I workflow fondativi sono il sistema operativo del progetto. Non devono essere poetici. Devono essere utili.
Il terzo livello sono i workflow specialistici.
Sono documenti più verticali: metadata e schema, link building, hosting, infrastruttura, branding, commerciale, local SEO, reportistica. Servono quando un task richiede regole più precise, ma non devono sovrascrivere il modello generale. Devono integrarlo.
Il quarto livello sono gli asset sorgente.
Qui stanno palette, dati aziendali, intestazioni, FAQ, modelli, template, specifiche. Sono materiali da consultare quando servono, non istruzioni comportamentali complete.
Poi c’è l’archivio.
L’archivio è il posto dove mettere i documenti che hanno valore storico, ma non devono più guidare il progetto: vecchi prompt, versioni precedenti, guide preparatorie, bozze di sistema, file superati.
Tenerli fuori dalla knowledge attiva non significa buttarli. Significa evitare che continuino a parlare quando non devono più farlo.
La differenza non è solo quantitativa. È strutturale.
Meno file non vuol dire meno conoscenza. Vuol dire meno interferenza.
E in un sistema che genera risposte partendo dal contesto disponibile, meno interferenza è spesso il primo passo per ottenere output più precisi, più coerenti e più vicini al metodo che vogliamo davvero applicare.
La Information Architecture vale anche per la AI
Chi lavora con la SEO lo sa bene: l’ordine non è un vezzo. È una condizione di leggibilità.
Un sito con pagine duplicate, categorie sovrapposte, URL incoerenti, contenuti vecchi lasciati a marcire e link interni messi a sentimento diventa difficile da interpretare. Per gli utenti, per i motori di ricerca, per chi deve mantenerlo.
Una AI Knowledge Base funziona in modo diverso da un sito web, ovviamente. Non ha breadcrumbs, menu di navigazione o sitemap XML. Però il principio di fondo è molto simile: se l’architettura informativa è confusa, anche l’interpretazione peggiora.
La Information Architecture non riguarda solo dove mettiamo le pagine. Riguarda come organizziamo il significato.
E nei progetti AI il significato non sta solo nel singolo prompt. Sta nel rapporto tra istruzioni, file, workflow, asset, esempi, vecchie versioni e regole operative. Se quel rapporto è disordinato, il modello deve compensare. E quando un modello compensa troppo, il risultato diventa meno affidabile.
Per questo trovo riduttivo parlare solo di prompt engineering.
Il prompt è importante, certo. È il punto di contatto più immediato. Ma un buon prompt lanciato dentro una AI Knowledge Base confusa è come una query ben formulata dentro un sito con architettura disastrosa: qualcosa viene fuori, ma non necessariamente quello che dovrebbe.
La qualità della risposta dipende anche dal sistema che sta dietro.
Questo sistema dovrebbe avere alcune caratteristiche semplici:
- una gerarchia chiara;
- documenti non ridondanti;
- versioni aggiornate;
- ruoli distinti per ogni file;
- regole globali separate dalle procedure operative;
- asset separati dai workflow;
- archivio storico fuori dal contesto attivo.
Sono principi molto vicini alla buona SEO tecnica e alla buona content strategy. Non perché la AI sia un motore di ricerca, ma perché entrambi i mondi hanno un problema comune: devono interpretare informazioni organizzate da esseri umani, spesso con più entusiasmo che metodo.
Il punto non è trasformare ogni progetto AI in un manuale ISO con timbro, revisione e ufficio qualità. Sarebbe un altro tipo di incubo, solo più ordinato.
Il punto è dare alla AI una struttura abbastanza chiara da non costringerla ogni volta a ricostruire il senso del progetto da frammenti sparsi.
In altre parole: non basta chiedersi che cosa il modello deve sapere.
Bisogna chiedersi anche in quale ordine, con quale peso e da quale documento deve saperlo.
Questa è Information Architecture applicata alla AI.
Non ha il fascino modaiolo del prompt perfetto. Non produce screenshot virali. Non promette di farti risparmiare dieci ore al giorno mentre bevi tè matcha guardando il tramonto.
Però funziona.
E, soprattutto, rende il lavoro più controllabile. Che, per chi usa la AI in modo professionale, vale molto più dell’ennesima scorciatoia luccicante.
Nota terminologica sulle abbreviazioni AI e IA, con riferimento all’Intelligenza Artificiale
Una nota terminologica: uso AI per indicare Artificial Intelligence e IA per indicare Information Architecture. In italiano si trova spesso “IA” per Intelligenza Artificiale, ma spesso crea una sovrapposizione inutile. Visto che parliamo proprio di architettura informativa applicata ai progetti AI, distinguere le due sigle aiuta a non fare confusione.
Che cosa ho imparato ripulendo un progetto reale
La lezione più utile è arrivata quando ho smesso di chiedermi come rendere il progetto più ricco e ho iniziato a chiedermi come renderlo più leggibile.
Non per me. Per la AI.
Un progetto può contenere ottimi documenti e funzionare male lo stesso. Può avere istruzioni accurate, workflow intelligenti, appunti validi, file tecnici pieni di informazioni utili. Ma se tutto convive senza una gerarchia, il valore dei singoli pezzi non basta.
È come avere una libreria piena di buoni libri, ma senza scaffali, categorie, ordine alfabetico o memoria di dove hai messo le cose. Il problema non è la qualità dei libri. Il problema è il recupero.
Nel caso specifico, la pulizia è partita da una domanda molto semplice:
Quali documenti devono guidare davvero il progetto ogni giorno?
Da lì la selezione è diventata più facile.
Alcuni file erano fondamentali. Dovevano restare attivi. Altri erano utili, ma ridondanti. Andavano fusi dentro documenti più solidi. Altri ancora avevano valore storico, ma non operativo. Andavano archiviati. Alcuni erano semplicemente fuori fuoco rispetto al progetto principale.
La vera svolta è stata smettere di trattare tutti i file come “conoscenza”. È come fare pulizia dentro ai cassetti di casa.
Non tutto ciò che contiene informazioni utili è knowledge attiva. Certe cose sono archivio. Certe sono fonti. Certe sono template. Certe sono procedure. Certe sono residui di lavorazione.
Il modello, però, non sempre può intuire questa differenza se noi non gliela rendiamo esplicita.
Per questo una AI Knowledge Base ben fatta non è solo una raccolta di file. È una struttura di responsabilità.
Le istruzioni compatte orientano.
Il modello operativo decide il routing.
I workflow spiegano come lavorare.
Gli asset forniscono dati specifici.
L’archivio resta fuori dal contesto attivo.
Questa separazione sembra amministrativa, ma in realtà è cognitiva. Serve a ridurre il numero di interpretazioni possibili. E quando riduci le interpretazioni possibili, migliori la qualità degli output.
Non perché il modello diventi più intelligente. Perché lo metti in condizione di lavorare con meno ambiguità.
La seconda cosa che ho imparato è che i doppioni sono più pericolosi dei vuoti.
Un’informazione mancante, spesso, emerge subito. Te ne accorgi perché la risposta è incompleta. Un doppione contraddittorio, invece, è più subdolo. Produce risposte plausibili, ma leggermente sbagliate.
È il tipo di errore più fastidioso, perché non esplode. Si insinua. Come lo sporco tra le fughe delle mattonelle della doccia. E Dio sa quanto è fastidioso sistemarle 😁.
Una vecchia regola di tono, un template superato, un workflow precedente, una checklist non aggiornata: ognuno di questi file può sembrare innocuo. Ma se resta attivo accanto alla versione nuova, crea una piccola interferenza.
E tante piccole interferenze fanno rumore.
Alla fine, il progetto ha iniziato a funzionare meglio, non quando abbiamo aggiunto nuove istruzioni, ma quando abbiamo tolto quelle che non servivano più. Non quando abbiamo caricato altri documenti, ma quando abbiamo dato ai documenti rimasti un ruolo più chiaro.
Ed è una lezione molto poco spettacolare, quindi probabilmente vera.
La AI lavora meglio quando non deve fare l’archeologo, il bibliotecario, il detective e il consulente nello stesso momento.
A volte, per migliorare un progetto, non serve aggiungere potenza.
Serve togliere polvere.
Chiosa: meno knowledge, più conoscenza
La tentazione di caricare tutto dentro un progetto AI è comprensibile. Sembra un gesto di prudenza. Sembra dire: “più contesto gli do, meglio lavorerà”.
Ma non sempre il contesto migliora perché aumenta.
A volte migliora perché viene scelto.
Una AI Knowledge Base efficace non è una raccolta onnivora di documenti. È una piccola architettura informativa costruita con attenzione. Deve sapere che cosa è fondativo, che cosa è operativo, che cosa è specialistico, che cosa è solo un asset e che cosa appartiene ormai alla storia del progetto.
La differenza è sottile, ma decisiva.
Più file possono dare l’illusione di più controllo. Pochi file ben progettati danno invece una cosa più utile: coerenza. E la coerenza, nei sistemi AI, pesa moltissimo. Pesa nel tono, nelle scelte operative, nelle priorità, nella capacità di produrre risposte che non siano solo formalmente buone, ma davvero allineate al metodo.
In fondo, lavorare su una AI Knowledge Base significa fare lo stesso lavoro che facciamo quando mettiamo ordine in un sito, in una documentazione tecnica o in una strategia editoriale: separare, nominare, gerarchizzare, aggiornare, archiviare.
Non è un lavoro appariscente. Non è la parte che finisce nelle demo spettacolari. Non è la promessa miracolosa da post social con sfondo sfumato e freccine verso l’alto.
È lavoro di struttura.
E il lavoro di struttura, quando è fatto bene, non si vede subito. Si sente dopo. Nella qualità delle risposte. Nella riduzione delle correzioni. Nella stabilità del tono. Nel fatto che il modello smette di sembrare un assistente brillante, ma un po’ distratto, e inizia a comportarsi come uno strumento più affidabile.
Questo non significa che una Knowledge Base debba essere povera. Significa che deve essere governata.
Perché il problema non è avere molti documenti. Il problema è avere molti documenti senza una ragione chiara per cui debbano restare attivi.
Alla fine, la regola che mi porto a casa è semplice:
ogni file deve meritarsi il proprio posto nella knowledge attiva.
Se guida il progetto, resta.
Se aiuta un workflow, resta.
Se contiene dati utili, resta come asset.
Se duplica, si fonde.
Se è vecchio, si archivia.
Se confonde, esce.
La conoscenza non coincide con l’accumulo. Anzi, spesso comincia proprio quando smettiamo di accumulare e iniziamo a dare forma.
Vale per i siti. Vale per gli archivi. Vale per le aziende. Vale anche per la AI.
Meno soffitta, più architettura.
Meno rumore, più metodo.
Meno knowledge caricata a peso, più conoscenza davvero utilizzabile.
FAQ – AI Knowledge Base e manutenzione dei progetti AI
Che cosa significa AI Knowledge Base?
Per AI Knowledge Base intendo l’insieme di documenti, istruzioni, workflow, asset e riferimenti che un progetto AI usa come contesto stabile. Non è una semplice cartella di file: è una base informativa che dovrebbe guidare risposte, tono, metodo e priorità operative.
Perché troppi file possono peggiorare un progetto AI?
Troppi file possono peggiorare un progetto AI quando sono ridondanti, superati o privi di gerarchia. Il problema non è la quantità in sé, ma il rumore: documenti simili o contraddittori possono generare risposte plausibili, ma non davvero allineate.
Qual è la struttura migliore per una AI Knowledge Base?
Una buona struttura distingue istruzioni compatte, modello operativo, workflow fondativi, workflow specialistici, asset sorgente e archivio. Ogni documento dovrebbe avere un ruolo chiaro e un motivo concreto per restare nella knowledge attiva.
Che differenza c’è tra istruzioni, workflow e asset?
Le istruzioni orientano il comportamento generale del progetto. I workflow spiegano come eseguire un’attività specifica. Gli asset sono materiali di supporto: dati aziendali, palette, template, FAQ, esempi, riferimenti visuali o documentali.
Perché in questo articolo uso AI e non IA per Intelligenza Artificiale?
Uso AI per Artificial Intelligence e IA per Information Architecture. È una scelta intenzionale: in italiano “IA” viene spesso usato per indicare l’Intelligenza Artificiale, ma in questo articolo parliamo anche di architettura informativa. Usare la stessa sigla per due concetti diversi avrebbe creato rumore, proprio mentre stiamo parlando di come ridurlo.
Che cosa va archiviato fuori dalla knowledge attiva?
Vanno archiviati i vecchi prompt, le versioni superate, le bozze preparatorie, le checklist non più valide e i documenti che hanno valore storico, ma non devono più guidare il progetto. Archiviare non significa cancellare: significa togliere rumore dal contesto operativo.
Una AI Knowledge Base piccola è sempre meglio?
No. Una AI Knowledge Base piccola non è automaticamente migliore. Se è vaga o scritta male, resta inefficace. La dimensione giusta dipende dal progetto. Il punto è avere documenti chiari, aggiornati, non ridondanti e organizzati secondo una gerarchia leggibile.
Ogni quanto andrebbe rivista una AI Knowledge Base?
Dipende dall’intensità del progetto, ma una revisione periodica è necessaria. Ogni volta che cambiano metodo, workflow, tono o asset fondamentali, conviene controllare se ci sono file da aggiornare, fondere o archiviare.
Altri percorsi nerd da fabri.news
Quattro articoli tra AI, scrittura digitale, prompt e lavoro autonomo ragionato.
- Letterly App, quando la voce diventa un prompt — Come trasformare note vocali e pensiero parlato in prompt utili, flussi di lavoro e contenuti strutturati.
- Markdown for Agents, SEO e AI Visibility — Un approfondimento sul Markdown come formato chiaro, portabile e leggibile anche per agenti AI e sistemi di retrieval.
- Dentro l’intelligenza artificiale, cosa direbbe oggi Pier Paolo Pasolini — Una riflessione culturale su AI, coscienza critica e sguardo laterale dentro il nostro presente tecnologico.
- Il dodecalogo del freelancer, la mia vision — Dodici punti per leggere il lavoro autonomo non come improvvisazione, ma come disciplina, postura e visione.