Per anni “AI nell’enterprise” ha voluto dire una cosa precisa: un chatbot per un caso specifico. Un dipartimento sceglie il suo problema, un fornitore costruisce la soluzione, sei mesi dopo la cosa funziona — più o meno. Per il dipartimento successivo si ricomincia da capo.

PaLoMa è nata perché un cliente ci ha chiesto esattamente questo. Un anno dopo ci eravamo accorti che la risposta più corretta non era un chatbot — era un prodotto.

Questo è il racconto onesto di come ci siamo arrivati.

Il setup: un cliente automotive grande

Il cliente è un’azienda automotive di dimensioni grandi, con cui FITEC lavorava da tempo su altri perimetri. Non un primo contatto, non un POC speculativo. Una conversazione partita perché loro avevano già visto in pratica come lavoriamo.

La richiesta iniziale era specifica: un assistente AI per supportare il lavoro su una determinata area tecnica. Non un esperimento — qualcosa da mettere in produzione su utenti reali, presto.

Tre cose che abbiamo capito nella prima settimana

Quando si scava sotto la superficie di una richiesta come questa in un’azienda grande, emergono in fretta tre vincoli che non si possono ignorare.

Compliance e residenza dei dati. I dati tecnici di un’azienda automotive non possono uscire dal perimetro aziendale. Una soluzione che gira su un servizio terzo con i tuoi dati in transito altrove è semplicemente esclusa — non per paranoia ma per policy.

Vincolo al singolo modello. Legarsi a un unico provider LLM è una decisione strategica più grande di quanto sembri. Il modello migliore oggi non è quello di sei mesi fa, e con ogni probabilità non è quello di sei mesi prossimi. Inoltre, alcuni casi d’uso vogliono un modello locale per latenza o privacy, altri un modello hostato sul tenant cliente, altri ancora un foundation model premium su una pipeline cloud. Un singolo modello blocca tutte queste scelte.

Frammentazione interna. In un’azienda di queste dimensioni esistono decine di Business Unit, ognuna con la propria documentazione, i suoi sistemi e — soprattutto — il suo lessico tecnico. Costruire un assistente per una di queste BU significa costruire qualcosa che farà fatica a uscire da quel perimetro.

A questo punto la domanda non era più “come costruiamo questo chatbot”. Era: “ha senso costruire un chatbot per un caso, sapendo che fra sei mesi saremo di nuovo qui per la BU successiva, con un nuovo set di documenti e un nuovo set di sistemi?”

La decisione: un prodotto, non un chatbot

La risposta è stata costruire un prodotto pensato per essere parametrizzato. Lo stesso strumento, configurato diversamente, deve funzionare per BU diverse — con doc diversa, sistemi diversi, modelli diversi.

Detto così sembra ovvio. In pratica significa che ogni decisione di design deve essere presa per riusabilità, non per il caso specifico davanti agli occhi. È più lento, è più impegnativo, e introduce un sacco di problemi che un chatbot one-off non ha. Ma costruire un chatbot per ogni BU è una promessa che non si può mantenere — almeno non con il margine commerciale che un cliente sano pretende.

Nel mercato di allora c’era poco a coprire questi tre vincoli insieme. Microsoft Copilot — che era già un riferimento — aveva problemi importanti su segregazione dati e ACL multi-utente nello scenario enterprise reale. Gli altri tool consumer-grade non si avvicinavano nemmeno. Costruire era l’unica strada.

Sfida 1: la terminologia tecnica di nicchia

Il primo muro è arrivato presto. I modelli foundation sono potentissimi su lessico generale, mediocri su lessico tecnico verticale. In un’area dell’automotive con dieci anni di terminologia interna, il modello base falliva in modo subdolo: non sbagliava con confidenza, sbagliava sembrando di aver capito.

La soluzione che ha funzionato non è stata fine-tuning. È stata l’introduzione di documenti di supporto creati ad hoc — glossari, mapping di sinonimi, descrizioni esplicite di termini interni — che il sistema RAG fa attraversare prima di rispondere. Non è romanticamente intelligente, ma è chirurgico ed è verificabile: chi mantiene il glossario controlla cosa il modello “sa”.

Questa è una lezione importante per chiunque costruisca AI su un dominio tecnico verticale: la parte difficile non è il modello, è capire dove il delta linguistico fra il pubblico generale e il tuo dominio causa errori, e colmarlo deliberatamente.

Sfida 2: i dati frammentati

Il secondo muro era architetturale. La conoscenza dell’azienda non viveva in un posto solo — viveva spalmata su sistemi diversi che non si parlavano fra loro. Una risposta utile richiedeva interpolare informazioni da fonti eterogenee.

Inizialmente abbiamo usato il function calling — la modalità classica con cui un LLM può chiamare strumenti esterni. Funziona, ma scala male quando ogni nuovo sistema richiede di rivedere prompt, schema e gestione errori. Più crescevano le integrazioni, più il codice attorno diventava ingombrante.

Il passaggio a MCP (Model Context Protocol) ha cambiato la fisionomia del progetto. MCP standardizza il modo in cui i tool sono esposti al modello: ogni sistema diventa un server MCP, ogni nuova integrazione è una somma di tool dichiarati, non una riscrittura. La superficie esposta cresce per addizione, non per refactoring.

Ovviamente, per ogni cliente costruiamo integrazioni custom su richiesta — non un connector generico magico. La differenza è che ora la complessità sta nei singoli server MCP, non in un blob monolitico al centro.

Una decisione tecnica che abbiamo dovuto correggere

Non tutto ha funzionato al primo tentativo. Vale la pena raccontare un caso in cui ci siamo dovuti fermare e cambiare rotta.

Avevamo integrato il sistema di ticketing aziendale con l’idea di estrarre pattern di risoluzione dai ticket chiusi. L’intuizione era: ci sono anni di problem-solving documentato lì dentro, usiamolo come knowledge base.

Il problema è emerso presto. I commenti di chiusura dei ticket non erano esaustivi — spesso una riga, “risolto”, o un riferimento implicito a una conversazione fuori dal sistema. Il segnale era troppo rumoroso per estrarre pattern affidabili.

Abbiamo cambiato approccio: invece di cercare di ricostruire knowledge dai ticket, ci siamo focalizzati sulla reportistica giornaliera del sistema. Lì il dato era strutturato, esaustivo, recente. L’utilità è arrivata da un angolo diverso da quello che avevamo immaginato.

La lezione è semplice e difficile da accettare: la qualità del dato a monte determina tutto. Quando capisci che la fonte è povera, non insistere a estrarne valore — riconfigura il caso d’uso intorno a una fonte ricca.

Il momento in cui abbiamo capito che ce l’avevamo fatta

C’è stato un punto preciso in cui il progetto ha smesso di essere “una cosa che stiamo provando” ed è diventato uno strumento nel flusso quotidiano. È successo quando abbiamo integrato sistemi diversi — non uno, più contemporaneamente — e gli utenti hanno iniziato a chiedere spontaneamente funzioni che non erano nella roadmap.

Non aspettavano il prossimo rilascio. Ce le proponevano: “se aggiungete X, posso fare anche Y”. È il segno più affidabile di product-market fit che esista in un contesto enterprise: smette di essere il tuo prodotto e diventa il loro strumento.

Uno dei casi d’uso che ha generato più valore — più di quanto ci aspettassimo — è stata l’interrogazione della documentazione tecnica con gestione delle immagini. La possibilità di mostrare contesto visivo nelle risposte ha avuto un impatto sproporzionato rispetto alla complessità implementativa. PaLoMa oggi digerisce praticamente tutti i tipi documentali dell’azienda — manuali, specifiche, presentazioni, immagini di componenti — con un’eccezione esplicita: i disegni tecnici CAD veri e propri, che restano per ora fuori dal perimetro.

Governance: accessi via SSO

C’è un dettaglio che spesso passa inosservato nei demo ma fa la differenza in produzione. Gli accessi a PaLoMa sono gestiti dall’admin del cliente sulla base dell’SSO aziendale esistente — non duplichiamo identity, non gestiamo password, non creiamo un secondo perimetro autorizzativo.

In pratica: ogni utente vede solo quello che il suo profilo SSO gli permette di vedere. Quando un fornitore consumer-grade ti racconta che “supporta SSO” e poi scopri che la segregazione del contenuto è gestita con tag e regole approssimate, hai capito questo può creare una falla nel sistema.

L’effetto a catena

L’utilità del prodotto si è diffusa internamente in un modo che non avevamo pianificato. L’interesse si è esteso ad altre Business Unit della stessa azienda — non per push commerciale nostro, ma per passaparola interno.

Questo è successo perché il prodotto funzionava per il caso d’uso originale, ma — e qui torna la decisione iniziale — era stato pensato per essere riconfigurabile. La BU successiva non aspettava un progetto di sei mesi: aspettava un’ingestion di documenti diversi e un set di integrazioni nuove. Il valore unitario per BU aggiuntiva è crollato.

Cosa rifaremmo, cosa cambieremmo

Rifaremmo la stessa scelta strategica: partire da un’esigenza vera di un cliente vero. Costruire un prodotto enterprise in laboratorio porta a soluzioni eleganti in cerca di un problema. Costruirlo dentro un caso reale, con la pressione di mettere qualcosa in produzione, forza a scartare tutto quello che non serve davvero — e a trovare, quasi per caso, le cose che servono ma non avevi pensato.

Cambieremmo il nostro posizionamento online. Su quasi tutte le killer feature enterprise — segregazione utenti reale, multi-LLM, MCP custom, governance, ingestion multimodale, no-code admin — siamo al pari o avanti rispetto a tool molto più visibili. Però non se ne stanno accorgendo i potenziali clienti, perché lato comunicazione abbiamo sottoinvestito. Stiamo recuperando.

Il consiglio per chiunque voglia partire con un progetto AI enterprise simile: parti da un’esigenza reale, non da una visione di prodotto. Semplifica i processi interni e l’apprendimento prima del modello. L’LLM è la parte facile — il fitting sul tessuto aziendale, sulla terminologia, sui permessi, sulla documentazione che hai davvero, è il lavoro vero.

PaLoMa esiste perché un cliente ci ha chiesto di costruire un chatbot ma ha poi avuto la vision di considerare il prodotto più completo e flessibile.