L’AI in azienda non è una licenza: è un’infrastruttura da governare

La domanda sbagliata è: “quale AI compriamo?”. La domanda giusta è: “quale pezzo del nostro sistema informativo stiamo lasciando leggere, riassumere, modificare o automatizzare?”. Per molte PMI italiane l’AI sta entrando con la stessa leggerezza con cui, anni fa, sono entrati i primi SaaS: una carta di credito, un reparto che prova, un fornitore che promette produttività, qualche file caricato “tanto per vedere”. Poi ci si accorge che non era un tool: era un nuovo strato di accesso ai dati aziendali.

Questo non significa frenare. Significa comprare meglio. L’AI utile non è quella che risponde in modo brillante in demo, ma quella che lavora dentro un perimetro chiaro: dati selezionati, identità controllate, log leggibili, costi prevedibili, possibilità di cambiare modello senza rifare tutto. A una PMI non serve un laboratorio di ricerca. Serve trattare l’AI come un’infrastruttura critica leggera: piccola, governata, verificabile.

Se l’AI viene acquistata come semplice licenza aggiuntiva della suite già in casa, la governance resta in mano al fornitore. Se invece viene inserita come componente architetturale, l’azienda conserva spazio di manovra: può scegliere dove stanno i dati, quale modello usare, quali documenti indicizzare, quali funzioni abilitare, chi chiamare quando qualcosa non torna. È qui che si decide la sovranità tecnologica reale, non nelle slide.

1. La demo non misura il rischio: misura solo la seduzione

Le demo di AI sono quasi sempre convincenti. Un documento lungo diventa una sintesi. Una tabella viene spiegata in linguaggio naturale. Una mail scomoda viene riscritta con tono cortese. Il problema è che una demo mostra il comportamento del modello, non il comportamento del sistema aziendale in cui quel modello finirà.

In una PMI il rischio raramente nasce dal modello in sé. Nasce dal collegamento tra modello e repository documentali, posta, CRM, gestionale, ticketing, file server e identità degli utenti. Un assistente collegato male può rendere visibili informazioni che erano già accessibili, ma di fatto nascoste dal disordine. Può anche accelerare errori banali: incollare dati personali in un servizio non governato, generare offerte su listini obsoleti, rispondere ai clienti con documentazione interna non approvata.

Il GDPR non parla di chatbot aziendali, ma i principi dell’articolo 5 restano molto concreti: minimizzazione, limitazione della finalità, esattezza, integrità e riservatezza. Se un sistema AI indicizza tutto “perché così poi trova tutto”, sta già andando nella direzione opposta alla minimizzazione. Se usa documenti non aggiornati senza distinguerli da quelli approvati, crea un problema di esattezza. Se non si capisce chi ha interrogato cosa, manca un pezzo di responsabilità.

Il punto non è trasformare ogni sperimentazione in un progetto infinito. È evitare che la prova gratuita diventi architettura di fatto. Prima di collegare un assistente ai dati aziendali, anche solo per un pilota, vanno decise tre cose: a quali dati accede l’AI, chi può usarla e dove restano le tracce delle interrogazioni e delle risposte. Senza questi tre elementi non si sta facendo innovazione agile: si sta solo spostando il rischio in un punto dove sarà più difficile vederlo.

2. Il modello conta meno della pipeline dei dati

Nel dibattito pubblico si parla quasi sempre di modelli: quale è più potente, quale costa meno, quale scrive meglio codice, quale ragiona meglio in italiano. Domande legittime, ma secondarie per la maggior parte delle PMI. In un contesto aziendale normale il vantaggio non nasce dal modello “più intelligente” in assoluto. Nasce dal fatto che il modello riceva i dati giusti, nella forma giusta, con i permessi giusti.

Per questo la parte decisiva è la pipeline: raccolta dei documenti, pulizia, classificazione, indicizzazione, aggiornamento, esclusione dei contenuti sensibili, gestione delle versioni. Un’AI collegata a un archivio sporco produce risposte sporche con grande sicurezza linguistica. Non inventa per malizia: spesso trova materiale vecchio, duplicato o non approvato e lo presenta come se fosse attuale.

Qui il tema della sovranità diventa pratico. Se l’intera pipeline è nascosta dentro una piattaforma proprietaria, l’azienda vede l’interfaccia ma non governa il processo. Può funzionare benissimo, fino al momento in cui serve cambiare modello, spostare i dati, ricostruire l’indice, dimostrare quali fonti sono state usate o escludere una famiglia di documenti. A quel punto il costo di uscita diventa il vero prezzo della soluzione.

Un’architettura più sana separa almeno quattro livelli: repository dei dati, motore di indicizzazione, modello linguistico, interfaccia utente. Non serve farlo in modo accademico. Anche una PMI può ottenere questa separazione con strumenti gestiti da un provider europeo o da un system integrator italiano, usando componenti già maturi. L’obiettivo non è inseguire l’open source per ideologia, ma evitare che documenti, embedding, prompt, log e policy finiscano tutti nello stesso recinto contrattuale senza una via d’uscita chiara.

C’è poi un tema economico spesso sottovalutato. Le piattaforme AI si pagano in modi diversi: licenze per utente, consumo a token, capacità riservata, moduli aggiuntivi per sicurezza e governance. Una demo su dieci utenti costa poco. Un uso quotidiano su vendite, amministrazione e supporto può diventare una voce ricorrente importante, soprattutto se ogni interrogazione coinvolge documenti lunghi o flussi automatizzati. Anche qui la pipeline conta: ridurre i documenti inutili, usare indici mirati e scegliere modelli diversi per compiti diversi taglia i costi senza ridurre la qualità.

3. Prima delle policy servono tre confini tecnici

Molte aziende partono scrivendo una policy sull’uso dell’AI. È utile, ma non basta. Una policy che dice “non caricare dati riservati” funziona solo se l’utente sa riconoscere quei dati, se ha alternative aziendali comode e se il sistema impedisce gli errori più gravi. Altrimenti è un cartello appeso sopra una porta sempre aperta.

I confini tecnici da impostare subito sono pochi, ma devono essere reali.

• Confine dei dati: l’AI accede solo a repository selezionati, con esclusione esplicita di HR, legale, finanza straordinaria, segreti industriali e archivi personali non governati. Dove servono dati personali, valgono i criteri di minimizzazione dell’articolo 5 e le misure di sicurezza adeguate previste dall’articolo 32 del GDPR.
• Confine delle identità: ogni utente accede con account aziendale, autenticazione forte dove opportuna, gruppi coerenti e privilegi minimi. Gli account condivisi sono veleno: impediscono audit, responsabilità e revoca puntuale.
• Confine delle azioni: una cosa è far generare una bozza, un’altra è permettere all’AI di inviare mail, aggiornare ticket, creare ordini o modificare record del CRM. Le azioni operative richiedono approvazioni, limiti e log più severi.

Questa è la differenza tra un chatbot e un componente aziendale. Il chatbot risponde; il componente aziendale opera dentro un perimetro. Se il perimetro non è definito, l’AI tende ad allargarsi perché è comoda: prima scrive testi, poi legge cartelle condivise, poi suggerisce risposte ai clienti, poi entra nel gestionale tramite integrazioni. Non c’è nulla di male, purché ogni passaggio sia deciso e non subìto.

L’AI Act ha introdotto l’obbligo di alfabetizzazione sull’AI (“AI literacy”) all’articolo 4: chi usa o fornisce sistemi AI deve garantire un livello sufficiente di competenza al personale coinvolto. Per una PMI questo non significa corsi teorici su reti neurali e transformer. Significa formare le persone sui casi d’uso approvati, sui dati da non inserire, sui limiti delle risposte generate e su come segnalare risultati sbagliati o pericolosi.

Ma la formazione senza controlli tecnici non basta, e i controlli senza formazione producono aggiramenti. La combinazione corretta è più semplice di quanto sembri: accesso aziendale approvato, casi d’uso chiari, log consultabili, referenti interni, supporto di un integratore che sappia tradurre le regole in configurazioni e non in documenti decorativi.

4. Il contratto deve dire cosa succede a prompt, log ed embedding

Nel software tradizionale il contratto parla di licenze, supporto, disponibilità e trattamento dei dati. Nell’AI bisogna leggere anche ciò che spesso resta in seconda pagina: come vengono trattati prompt, file caricati, output, log, dati di telemetria, embedding e contenuti usati per migliorare il servizio. È qui che una PMI scopre se sta comprando uno strumento o consegnando un pezzo della propria memoria aziendale.

Il GDPR offre già una base solida. Se il fornitore tratta dati personali per conto dell’azienda, l’articolo 28 richiede un contratto che disciplini il trattamento: oggetto, durata, natura, finalità, categorie di dati, obblighi e diritti del titolare. Nel caso dell’AI queste voci non possono restare generiche. Un conto è usare un servizio per correggere testi non riservati, un altro è collegarlo alla posta, al CRM o a documenti che contengono dati di clienti, dipendenti e fornitori.

Bisogna chiedere nero su bianco almeno quattro risposte. I dati inseriti vengono usati per addestrare o migliorare modelli generali? Dove sono conservati prompt e file caricati? Per quanto tempo restano i log? Quali subfornitori intervengono nel trattamento? Non sono domande ostili: sono domande normali per chi deve difendere continuità, riservatezza e controllo dei propri processi.

Attenzione anche agli embedding, spesso assenti dalle discussioni commerciali. Sono rappresentazioni vettoriali dei contenuti, usate per cercare documenti semanticamente simili. Non sono il documento originale, ma possono incorporare informazioni rilevanti sul contenuto. Trattarli come materiale innocuo è superficiale: devono avere una collocazione, una policy di cancellazione e una strategia di portabilità. Se si cambia fornitore, l’azienda deve sapere se può rigenerarli, esportarli o eliminarli in modo verificabile.

Qui i system integrator italiani possono fare la differenza. Non perché siano magicamente migliori dei grandi vendor, ma perché possono sedersi con amministrazione, commerciale, produzione e IT, guardare i flussi reali e scrivere una configurazione sostenibile. Una PMI non ha bisogno di un documento di novanta pagine sulla governance dell’AI. Ha bisogno di clausole comprensibili, di un’architettura leggibile e di qualcuno che risponda al telefono quando un reparto chiede: “possiamo caricare questi contratti nel sistema?“.

5. Suite integrata o architettura indipendente: non è una questione di fede

C’è una tentazione forte: attivare l’AI della suite già in uso. È comoda, veloce, integrata con posta, documenti e calendario. Per molte PMI può essere una scelta sensata, soprattutto se il perimetro informativo è già dentro quell’ecosistema e se le funzioni richieste sono produttività personale, riassunti, bozze, ricerca documentale interna. Demonizzare questa opzione sarebbe poco serio.

Il problema nasce quando la scelta viene presa solo perché “è già lì”. L’integrazione è un vantaggio, ma anche un acceleratore di dipendenza. Più l’assistente entra nei flussi quotidiani, più diventa difficile cambiare piattaforma. Non contano solo le licenze: contano abitudini, prompt salvati, automazioni, connettori, logiche di classificazione, indici documentali, formazione del personale. Il lock-in raramente arriva con un annuncio: si accumula per comodità.

L’alternativa non è costruire tutto in casa. Un’architettura indipendente può essere piccola: un ambiente controllato presso un provider europeo, un motore RAG per interrogare documenti selezionati, uno o più modelli intercambiabili, un’interfaccia aziendale semplice, l’integrazione con l’identità esistente e un logging centralizzato. Così la PMI mantiene la possibilità di usare modelli diversi: uno economico per classificare ticket, uno più capace per analizzare documenti complessi, uno locale o dedicato per i dati più sensibili.

La scelta corretta dipende dal caso d’uso. Per la produttività individuale e i documenti a basso rischio, la suite integrata può vincere per semplicità. Per knowledge base tecnica, offerte commerciali, documentazione di prodotto, manualistica, supporto clienti e processi con dati sensibili conviene valutare un perimetro più governato. Non è una gara tra grandi cloud e cloud indipendente: è una questione di reversibilità.

Il criterio pratico è semplice. Se domani il prezzo raddoppia, se cambiano le condizioni contrattuali, se un cliente chiede dove passano i dati, se un audit chiede evidenze, l’azienda riesce a rispondere senza panico? Se la risposta è no, l’AI non è stata comprata: è stata subita.

6. Un percorso di 60 giorni per partire senza restare intrappolati

Una PMI non può permettersi un programma pluriennale prima di usare l’AI. Ma può permettersi due mesi fatti bene. Sessanta giorni bastano per passare dalla curiosità disordinata a un primo servizio AI aziendale utile, senza trasformare la governance in burocrazia.

Fase 1 — scegliere un caso d’uso ristretto. Non “l’AI per tutta l’azienda”, ma qualcosa di concreto: ricerca nella documentazione tecnica, supporto alla stesura delle offerte, classificazione dei ticket, sintesi di procedure interne, assistenza al customer care su procedure approvate. Il caso d’uso deve avere un proprietario di processo, un set di documenti definito e un modo per misurare se funziona. Se non si misura nulla, vince sempre la demo più brillante.

Fase 2 — costruire il perimetro dati. Si selezionano le fonti, si eliminano i duplicati, si marcano i documenti obsoleti, si escludono le aree sensibili, si decide chi vede cosa. Questa fase è meno affascinante della scelta del modello, ma produce più valore. Spesso fa emergere problemi che l’azienda aveva già: cartelle senza proprietario, versioni multiple dello stesso listino, procedure vecchie ancora accessibili, permessi ereditati da anni.

Fase 3 — definire contratto e logging. Anche in un pilota deve essere chiaro dove vanno i dati, se vengono usati per l’addestramento, quali subfornitori sono coinvolti, come si cancellano contenuti e indici, chi vede i log. Non serve complicare tutto: basta non lasciare queste risposte alla buona fede commerciale. Il principio di protezione dei dati fin dalla progettazione (articolo 25 del GDPR) non è un vezzo da grande azienda: è una buona regola anche per chi ha cinquanta dipendenti.

Fase 4 — mettere lo strumento in mano a pochi utenti reali. Non solo IT e direzione, ma persone che conoscono il lavoro quotidiano. Devono provare, segnalare errori, indicare documenti mancanti, misurare i tempi risparmiati e i casi in cui l’AI risponde male. La qualità di un sistema AI si vede nel ciclo di correzione: quanto velocemente si migliora la base documentale, si restringe un permesso, si cambia il prompt di sistema, si sostituisce un modello.

Alla fine dei sessanta giorni l’azienda dovrebbe avere un risultato concreto: un caso d’uso funzionante, un perimetro dati noto, un contratto letto, log attivi, costi osservati e una decisione informata su estensione o stop. Molto più utile di un piano strategico sull’AI scritto prima di aver toccato i problemi veri.

7. L’AI conviene quando aumenta il controllo, non quando lo riduce

La promessa dell’AI è la produttività. Ma in azienda la produttività che riduce il controllo prima o poi presenta il conto. Si guadagna mezz’ora su una bozza e si perde una giornata per capire dove è finito un documento. Si velocizza il supporto clienti e si rischia di dare risposte basate su procedure vecchie. Si abilita un assistente per tutti e ci si accorge che i permessi interni erano un colabrodo.

La buona notizia è che non serve scegliere tra entusiasmo e paura. Esiste una via pratica: partire piccoli, separare i componenti, governare i dati, leggere i contratti, mantenere la portabilità. È un lavoro alla portata delle PMI italiane, soprattutto se accompagnato da fornitori che non vendono solo licenze, ma capacità operativa. Il mercato nazionale ha system integrator e provider abbastanza vicini da capire vincoli, budget e urgenze di chi non ha un ufficio compliance da venti persone.

La frase da portare al prossimo incontro con un fornitore è semplice: “prima del modello, vediamo l’architettura”. Dove stanno i dati. Come si cancellano. Chi accede. Quali log restano. Quanto costa uscire. Cosa succede se si cambia modello. Se queste domande rovinano la magia della presentazione, era la presentazione il problema.

L’AI aziendale non va trattata come una moda da adottare prima dei concorrenti, ma come un nuovo livello dell’infrastruttura informativa. Chi lo capisce adesso non sarà più lento: sarà più libero di scegliere, correggere, negoziare e crescere, senza scoprire troppo tardi che la vera intelligenza era finita nel contratto del fornitore.