Company brain: dare all'azienda una memoria che l'AI sa leggere
Il collo di bottiglia dell'AI in azienda non è il modello: è che la tua azienda non ha mai messo per iscritto quello che sa. Il company brain è la memoria aziendale scritta perché gli agenti la leggano prima di produrre qualsiasi cosa. Come è nato il nostro da quattro copie divergenti della stessa identità di marca, come si costruisce partendo dagli artefatti che hai già, e da dove parte una PMI.
Gaetano Castaldo
Il collo di bottiglia dell'AI in azienda non è il modello. È che la tua azienda non ha mai messo per iscritto quello che sa.
Ogni sessione con un assistente AI parte da zero. Il modello non sa a chi vendi, a che prezzo, con quali regole, cosa avete già provato e perché non ha funzionato. Quindi risponde con la media di internet: plausibile, ordinata, inutilizzabile. E la reazione istintiva è dare la colpa allo strumento, quando il problema è che nessuno gli ha detto dove si trova.
Il company brain è la risposta a questo.
In breve: un company brain è la fonte unica di conoscenza di un'azienda, scritta in un formato che gli assistenti AI leggono prima di produrre qualsiasi cosa: chi sei, cosa vendi, a chi, con quali regole. Non è documentazione da consultare, è il contesto che rende specifico ogni output invece che generico.
Ti racconto come è nato il nostro, cosa ci ha insegnato, e come si costruisce senza scrivere un solo documento a freddo.
Perché l'AI risponde in modo generico alla tua azienda
Prendi una richiesta banale: "scrivimi la mail di follow-up per questo cliente". Senza contesto, l'assistente non sa che dai del tu, che non usi certe parole, che quel cliente è già stato in trattativa due anni fa, che il tuo posizionamento non è il prezzo. Produce una mail corretta e anonima, che tu riscrivi da capo. Hai risparmiato zero.
Il punto è che quella conoscenza esiste, solo che vive in tre posti dove nessun agente la vede: la tua testa, le mail, e file sparsi che nessuno apre da mesi. Finché resta lì, ogni sessione AI riparte dalla media del mondo invece che dalla tua azienda.
Come sono nate quattro versioni diverse della stessa identità di marca
Il nostro brain non nasce da una strategia. Nasce da un problema che mi si è presentato addosso.
La nostra identità di marca era finita, copiata, dentro quattro repository diversi: il sito, due prodotti, un progetto cliente. Nessuno l'aveva duplicata di proposito. Era stata copiata una volta per comodità, poi corretta solo dove serviva in quel momento. Il risultato, dopo qualche mese, erano quattro versioni che stavano divergendo: quattro tono di voce leggermente diversi, quattro liste di regole non del tutto uguali. Quattro agenti che lavoravano bene, ognuno secondo un brand un po' suo.
Lo stesso identico meccanismo lo vedo in ogni PMI, senza AI di mezzo: il listino aggiornato che sta nel foglio del commerciale e non in quello dell'amministrazione, la procedura di installazione che il tecnico anziano fa a modo suo, il contratto tipo che esiste in tre versioni e nessuno sa quale sia buona.
Il 28 luglio 2026 abbiamo fuso le quattro copie in una sola e stabilito un criterio, che poi è l'unica regola che serve davvero ricordare: se una cosa serve a un solo progetto resta lì, se serve all'azienda va nel brain.
Cos'è un company brain e in cosa è diverso da un wiki aziendale
Un wiki è scritto per le persone e viene letto quando qualcuno si ricorda che esiste. Un company brain è scritto perché venga letto da chi lavora, umano o agente, prima di ogni output. È la differenza tra un archivio e uno strumento.
| Wiki aziendale | File di progetto (CLAUDE.md) | Company brain | |
|---|---|---|---|
| A cosa serve | consultare quando serve | far lavorare bene su un progetto | far lavorare bene tutta l'azienda |
| Chi lo legge | le persone, raramente | l'agente su quel repository | agenti, skill, automazioni e persone |
| Cosa contiene | tutto quello che è stato scritto | stack, file critici, convenzioni | fatti, decisioni, playbook aziendali |
| Quando si aggiorna | quando qualcuno se ne ricorda | quando cambia il progetto | a ogni correzione di un output |
| Come invecchia | male e in silenzio | con il progetto | ha una data di verifica per file |
La regola per decidere dove mettere una cosa è una sola: se serve a un solo progetto resta lì, se serve all'azienda va nel brain.
La struttura che regge nel tempo tiene separati tre generi di conoscenza, che non si mescolano mai:
- I fatti dicono cosa è vero adesso: chi siamo, cosa vendiamo, a chi, a quanto. Sono mutabili e vanno tenuti freschi.
- Le decisioni dicono perché abbiamo scelto così, con la data. Non si riscrivono mai: se una decisione cambia, se ne scrive una nuova che supera la precedente.
- I playbook dicono come si fa una cosa: una proposta, l'avvio di un progetto, la gestione di un incidente.
Mescolare i tre generi è il modo esatto in cui una base di conoscenza marcisce. Se dentro il documento dei prezzi c'è anche la storia di come ci siete arrivati e mezza procedura commerciale, nessuno lo aggiornerà mai, perché aggiornarlo significa rimettere in discussione tutto il resto.
Come si costruisce senza scrivere documenti a freddo
Questa è la parte che di solito blocca tutti: l'idea di doversi fermare tre settimane a documentare l'azienda. Non serve, e sarebbe pure la strada peggiore.
Il nostro brain è stato inizializzato raccogliendo quello che già esisteva: 22 proposte reali del 2025 e 2026, e 63 articoli pubblicati. Sei mesi di proposte dicono della tua clientela ideale molto più di qualsiasi riunione dedicata: mostrano a chi hai venduto davvero, cosa ti ha chiesto, cosa hai accettato di fare e cosa hai rifiutato. Gli articoli pubblicati sono l'unico posto dove il tuo modo di scrivere esiste su larga scala, quindi sono il materiale con cui si insegna a un agente a scrivere come te invece di descrivergli il tono a parole.
La conoscenza della tua azienda esiste già. Sta dentro gli artefatti che hai prodotto: preventivi, contratti, mail di risposta a un cliente difficile, il verbale di quella riunione in cui avete deciso di non fare più una certa cosa. Il lavoro non è scrivere, è estrarre.
Una accortezza che ci ha salvato: ogni voce dedotta dallo storico e non dichiarata da una persona è marcata come ipotesi, non come verità. Un fatto derivato da tre proposte simili è una probabilità, non una regola aziendale, e va confermato da chi decide.
Come si organizza perché l'AI non si perda dentro
Qui c'è il vincolo tecnico che cambia tutto il progetto: il contesto di un modello è limitato e costoso. Caricare l'intera conoscenza aziendale a ogni sessione non solo è impossibile, è controproducente. Più materiale metti all'inizio, prima la sessione degrada.
Non è un'impressione. Il 14 luglio 2025 Chroma ha pubblicato uno studio su 18 modelli, tra cui Claude 4, GPT-4.1 e Gemini 2.5, che misura il fenomeno: le prestazioni calano al crescere della lunghezza dell'input anche su compiti semplici, e il calo comincia molto prima del limite dichiarato dal modello (Context Rot: How Increasing Input Tokens Impacts LLM Performance, Hong, Troynikov e Huber). Tradotto per chi decide: un assistente a cui dai tutto diventa peggiore di uno a cui dai la cosa giusta.
La soluzione che usiamo è organizzare la conoscenza in anelli:
- Anello 0: un solo file, sempre in contesto. Dieci righe su chi siamo, le regole non negoziabili e la mappa di dove sta tutto il resto. Ogni riga qui costa a ogni sessione di ogni agente, quindi si difende come uno spazio prezioso.
- Anello 1: file che si caricano su richiesta, in base al tipo di lavoro. I prezzi si caricano quando si fa una proposta, la strategia editoriale quando si scrive un articolo. Mai insieme.
- Anello 2: materiale che non entra mai in contesto e si cerca solo quando serve.
A tenere in piedi il meccanismo c'è un file di routing che dichiara, per ogni documento, quando va caricato. Un agente decide cosa leggere consultando quel contratto, non frugando a caso nelle cartelle.
È l'evoluzione naturale del ragionamento che avevo già fatto sul file di istruzioni di un singolo progetto, di cui ho scritto nella guida completa al CLAUDE.md. Lì il problema era un progetto, qui è l'azienda intera: la stessa conoscenza serviva a quattro repository e agli agenti di automazione, che non la vedevano. Se stai partendo adesso con questi strumenti, il quadro d'insieme è nella guida a Claude Code.
Il company brain è un metodo nuovo o poggia su pratiche esistenti?
Questa è la domanda che farei io, al posto tuo. Rispondo senza girarci intorno: non abbiamo inventato quasi niente. Il company brain è la composizione di pattern che esistono da anni, alcuni da decenni, applicati a un uso che finora quasi nessuno faceva.
| Pezzo del modello | Da dove viene, e di che natura è | Cosa succede se lo togli |
|---|---|---|
| Far uscire la conoscenza dalle teste e renderla esplicita | Nonaka e Takeuchi, The Knowledge-Creating Company, 1995. Teoria organizzativa: la conoscenza esiste in due stati, tacito ed esplicito, e il valore si crea nel passaggio dal primo al secondo | Il brain diventa un archivio di documenti già scritti. Il sapere che conta, quello che sta solo nella testa del titolare, non entra mai |
| Le decisioni con la data, mai riscritte | gli Architecture Decision Records di Michael Nygard, 2011. Pattern di documentazione: si registra la scelta, il contesto in cui è stata presa e le conseguenze | Resta il cosa senza il perché. Ogni sei mesi si rifà la stessa discussione, e nessuno ricorda perché quel cliente era stato rifiutato |
| Un fatto, un posto solo | il principio DRY (Hunt e Thomas, The Pragmatic Programmer, 1999). Principio di ingegneria: ogni informazione ha una sola rappresentazione autorevole | Torni al punto di partenza: le quattro copie che divergono. È il pezzo che risolve il problema da cui siamo partiti |
| Fatti, decisioni e playbook che non si mescolano | Diátaxis di Daniele Procida, 2020. Tassonomia: bisogni diversi vogliono documenti di natura diversa, tenerli insieme li rovina entrambi | Il file dei prezzi si riempie di storia e di procedura, diventa pesante da aggiornare, e smette di essere aggiornato |
| Conoscenza versionata, con validatori che bloccano prima del commit | docs-as-code. Pratica di ingegneria: la documentazione vive nello stesso flusso del codice, con storico e revisione | Nessuno sa chi ha cambiato cosa e quando. Un errore si scopre in riunione invece che in una riga di diff |
| Dare al modello la tua conoscenza invece di ri-addestrarlo | RAG, Lewis et al., NeurIPS 2020. Architettura tecnica: memoria esterna consultata al momento della risposta, non incorporata nel modello | "AI su misura" torna a significare addestrare un modello: costi e competenze fuori portata per una PMI, per un risultato che invecchia subito |
| Caricare solo il pezzo che serve, e non tutto | i limiti misurati del contesto lungo, lo studio Chroma qui sopra. Evidenza sperimentale, non opinione | Un unico file gigante che peggiora le risposte invece di migliorarle. È il motivo per cui esistono gli anelli |
| Contesto leggibile dalle macchine, pubblicato sul sito | la proposta llms.txt di Jeremy Howard, Answer.AI, settembre 2024. Formato proposto, non standard adottato | Perdi poco: è il pezzo più debole della lista, e lo dichiaro. Costa un'ora e forse serve |
Il nostro contributo originale è uno solo, e lo rivendico per quello che è: aver applicato questa roba alla conoscenza commerciale di una PMI, non alla documentazione tecnica di un prodotto software. Prezzi, cliente ideale, obiezioni di vendita, motivi per cui un lavoro è stato rifiutato. È il materiale che di solito non viene scritto da nessuna parte, ed è esattamente quello che serve a un agente per smettere di rispondere come la media di internet.
Cosa è dimostrato e cosa è ancora sperimentale
Preferisco dirtelo io prima che te lo chieda tu.
Cosa è verificabile, perché sono numeri del nostro repository, non stime:
- 88 file e 69.557 parole di conoscenza aziendale, in 50 commit dal 28 luglio 2026
- il file sempre in contesto tenuto a 85 righe: 2 file caricati sempre, 24 su richiesta, 14 mai
- 6 decisioni datate, 7 playbook, 7 esempi canonici
- costruito estraendo da 22 proposte reali e 63 articoli già pubblicati, non scrivendo documenti nuovi
Cosa non è dimostrato, e sarebbe scorretto vendertelo come tale:
- la forma consolidata ha pochi mesi. Il modo di lavorare è più vecchio (viene dalla modularizzazione delle istruzioni di progetto, di cui scrivevo ad aprile), ma il brain come lo descrivo qui è recente
- il campione è una azienda sola, la nostra. Nessun gruppo di controllo, nessuna misura prima e dopo con un cronometro. La stima sui tempi che trovi qui sotto è esperienza sul campo, non un esperimento
- la proposta llms.txt non è uno standard adottato: nessun fornitore di AI ha confermato ufficialmente di consumarla. Noi la pubblichiamo perché costa poco, non perché sia provata
- non sappiamo ancora come regge su un'azienda di trenta persone con cinque reparti. Su una struttura piccola e su progetti clienti sì, funziona
Aggiornerò questo articolo con i numeri man mano che arrivano. Se lo stai leggendo tra sei mesi e la sezione è identica, quello è un segnale.
E c'è un modo solo per rendere un metodo davvero verificabile: farlo guardare. Da oggi lo scheletro del nostro company brain è pubblico su GitHub, con licenza MIT (company-brain-template): la struttura delle cartelle, il file sempre in contesto, il contratto di routing, la separazione dei tre generi e i validatori, senza un solo dato riservato dentro. Così invece di fidarti di questo articolo puoi aprire i file, criticarli e usarli.
Quanto costa tenerlo aggiornato
Poco, se l'aggiornamento è dentro il lavoro invece che accanto al lavoro. Da noi funziona su tre livelli.
Automatico: indici rigenerati, controllo di freschezza sui file scaduti, validatori che bloccano prima del salvataggio le violazioni delle regole di scrittura. Proposto: a fine sessione un controllo segnala le correzioni emerse e chiede se vanno registrate. Esplicito: un comando che cattura un fatto nuovo nel file giusto, senza doversi ricordare dove sta.
La regola culturale conta più degli strumenti: ogni correzione che fai a un output di un agente è un fatto che manca nel brain, e si registra subito, non "dopo". Se correggi tre volte la stessa cosa, il problema non è l'agente.
E ogni file di fatti ha una data di verifica. Scaduta quella data, il contenuto torna a essere un'ipotesi da verificare, non una verità su cui costruire una proposta.
Stima dal campo: su un progetto strutturato così, la parte di sessione spesa a ricostruire il contesto passa da un quarto d'ora abbondante a zero, e un nuovo collaboratore arriva al primo output utilizzabile in giorni invece che in settimane.
Chi lo legge, oltre a te
Questo è il punto che di solito convince i titolari più della parte tecnica. Il brain non serve solo agli agenti: lo leggono i collaboratori, e diventa l'archivio ragionato dell'azienda. Quando entra una persona nuova, non deve stare tre mesi appesa a te per capire come si scrive una proposta, chi è un cliente buono e perché due anni fa avete smesso di prendere certi lavori.
Una avvertenza importante: prezzi, marginalità e informazioni sui clienti sono materiale riservato e non finiscono mai in contenuti pubblici o in documenti che escono dall'azienda. E il brain non contiene mai credenziali: descrive dove stanno i segreti, non cosa sono.
Da dove parte una PMI che vuole la propria memoria aziendale
Non da un progetto di knowledge management. Da tre artefatti.
Prendi la migliore proposta che hai vinto, il tuo contratto tipo e le ultime dieci mail con cui hai risposto a un cliente in trattativa. Estrai da lì tre file: cosa vendiamo davvero, a chi lo vendiamo, come lo raccontiamo. Sono le prime venti righe del tuo anello 0, e già da sole cambiano la qualità di ogni output AI che produci.
Poi si aggiunge un fatto alla volta, quando emerge, e non prima. La disciplina di mappare i processi prima di automatizzarli vale identica qui: la memoria aziendale si costruisce sul lavoro che fai, non in una stanza separata.
Il percorso completo, con i comandi e le decisioni da prendere, sta nella guida pratica per costruire un company brain.
Se preferisci non partire dal foglio bianco, parti dallo scheletro open source: premi Use this template e ti ritrovi un repository tuo, con la struttura già impostata e i validatori dentro. Da quel punto il tuo lavoro è solo riempirlo con quello che sai. Crealo privato: conterrà prezzi e clienti.
Se vuoi capire come applicarlo alla tua azienda, è esattamente quello che facciamo nei servizi di AI e automazione per le PMI.
Domande frequenti sul company brain
Quanto tempo serve per costruirlo? Le prime venti righe utili si scrivono in mezza giornata, partendo dai tre artefatti di sopra. Il lavoro non è scrivere documenti nuovi, è estrarre i fatti da quelli che esistono già. Poi si aggiunge un fatto alla volta, quando emerge.
Serve avere sviluppatori interni? No. Un company brain è fatto di file di testo organizzati con un criterio, non di software da installare. Serve competenza tecnica per collegarlo agli agenti e ai flussi di automazione, ma la parte che conta davvero, decidere cosa è vero e chi lo conferma, è lavoro di chi guida l'azienda.
Che differenza c'è tra il company brain e il file di istruzioni di un progetto? Il file di progetto contiene stack, file critici e convenzioni di quel codice. Il brain contiene la conoscenza dell'azienda, che serve a tutti i progetti insieme. Il criterio di smistamento è quello della tabella qui sopra.
Esiste un template open source da cui partire? Sì, è pubblico su GitHub con licenza MIT: company-brain-template. Contiene struttura delle cartelle, file sempre in contesto, contratto di routing, separazione dei tre generi e validatori, senza un solo dato riservato.
I prezzi e i dati dei clienti sono al sicuro? Solo se lo decidi in modo esplicito. I file riservati si marcano come tali e non finiscono mai in contenuti pubblici o in documenti che escono dall'azienda. E il brain non contiene mai credenziali: descrive dove stanno i segreti, non cosa sono.
Come capisco se sta funzionando? Chiedi a un assistente AI di scrivere qualcosa che richiede di conoscere la tua azienda, senza dargli nessuna istruzione aggiuntiva. Se l'output è usabile al primo tentativo, funziona. Se devi correggerlo, quella correzione è il prossimo fatto da registrare.
La tua azienda sta usando l'AI e i risultati sono generici? Ogni collaboratore chiede a te le stesse cose da anni?
Nel pre-assessment gratuito guardiamo insieme dove vive oggi la conoscenza della tua azienda, quali artefatti hai già che valgono come materia prima, e costruiamo il primo anello della tua memoria aziendale. Senza fermare il lavoro per documentare.
Tags
Founder & CEO · Castaldo Solutions
Sono un consulente di trasformazione digitale con esperienza enterprise. Aiuto le PMI italiane ad adottare AI, CRM e architetture IT con risultati misurabili in 90 giorni.