Costruire MIA #1: le fondamenta, prima delle funzioni

Qualche settimana fa abbiamo raccontato la visione di MIA: un direttore operativo AI che aggrega i dati sparsi di un’azienda e ogni mattina dice all’imprenditore cosa conta davvero. Quell’articolo raccontava dove vogliamo arrivare.

Questo apre una serie diversa. Ogni due settimane racconteremo come la stiamo costruendo: le scelte fatte, le alternative scartate, i vincoli che abbiamo accettato e — soprattutto — cosa ancora non funziona.

Il motivo è semplice. Del lancio di un prodotto AI si vede sempre la demo perfetta e quasi mai il percorso. Ma se un giorno chiederai a MIA di leggere i tuoi contratti e i cedolini dei tuoi dipendenti, hai il diritto di sapere come è stata costruita.

Ogni puntata avrà lo stesso schema: cosa volevamo ottenere, cosa abbiamo trovato, la scelta fatta, cosa non funziona ancora.

Si parte da un fatto poco spettacolare: le prime settimane di lavoro su MIA non hanno prodotto nemmeno una funzionalità.

Cosa volevamo ottenere

La tentazione era forte: partire dal CEO Daily Briefing, la funzione più raccontabile del prodotto. In pochi giorni si mette in piedi un prototipo che legge una casella Gmail, la dà in pasto a un modello e genera un riassunto mattutino. Fa impressione in una demo.

Ma sarebbe stato esattamente questo: un prototipo. E i prototipi, sui dati sensibili, non si trasformano in prodotti — si buttano.

Perché MIA tratta cedolini, contratti, dati del personale, flussi finanziari. E alcune decisioni — dove vivono quei dati, chi può leggerli, dove gira l’elaborazione AI che li attraversa — non si cambiano dopo. O meglio: si cambiano riscrivendo tutto.

Così abbiamo definito una Fase 0 che non produce niente di visibile: multitenancy, identità e accessi, sicurezza, pipeline di integrazione continua. Fondamenta.

Cosa abbiamo trovato

Il problema non era tecnico. Era di sequenza e di disciplina.

Quando lavori su un progetto ambizioso, la pressione a “intanto partiamo, poi sistemiamo” è costante. E ogni scelta presa “per intanto” diventa un debito che si paga con gli interessi tre mesi dopo.

Ci siamo dati una regola: nessuna decisione strutturale presa implicitamente. Ogni scelta che vincola il futuro finisce in un documento formale — un ADR, Architecture Decision Record — con quattro sezioni obbligatorie: contesto, decisione presa, alternative considerate e perché sono state scartate, conseguenze incluse quelle negative.

È l’ultima parte a fare la differenza. Scrivere perché una scelta è buona è facile. Scrivere per iscritto cosa ci costerà obbliga a guardarla in faccia prima di firmarla.

Ne sono usciti quattro documenti: tre decisioni già approvate e una ancora in valutazione. Eccole, in italiano comprensibile.

Le scelte che abbiamo fatto

1. Ogni azienda vive in uno spazio separato

Ci sono tre modi di tenere separati i dati di aziende diverse sullo stesso sistema.

Il primo è un database per ogni cliente: isolamento massimo, ma un costo di gestione che diventa insostenibile oltre una manciata di clienti.

Il secondo è una struttura condivisa con regole di accesso riga per riga: efficiente, denso, ma l’isolamento dipende interamente dalla correttezza di quelle regole. Un errore in una singola condizione, e i dati di un’azienda diventano visibili a un’altra.

Il terzo — quello che abbiamo scelto — è uno schema dedicato per ogni azienda all’interno dello stesso database. La separazione è strutturale, non affidata a un controllo applicativo che qualcuno potrebbe dimenticare di scrivere.

La conseguenza più concreta riguarda un diritto che di solito è un incubo tecnico: il diritto all’oblio. Con questa architettura non è un progetto, è un’operazione. Si elimina lo schema di quel cliente e i suoi dati non ci sono più — senza dover ripulire venti tabelle sperando di non aver dimenticato niente. Lo stesso vale per backup e ripristino di un singolo cliente.

Il prezzo che paghiamo: ogni aggiornamento della struttura dati va applicato azienda per azienda, il che richiede uno strumento dedicato. L’abbiamo messo in conto.

2. L’elaborazione AI non esce dall’Europa

Questo è il punto più spesso trascurato nelle architetture AI, e vale la pena spiegarlo bene.

Molti prodotti dichiarano che i dati risiedono in Europa, e per database e archivio documentale è vero. Poi però, quando quel contratto va analizzato, il suo testo viene inviato a un’API di elaborazione che sta altrove. È a tutti gli effetti un trasferimento di dati fuori dall’UE, solo meno visibile.

La nostra decisione: tutta l’elaborazione AI avviene su endpoint in region europea, coperti da un accordo sul trattamento dei dati con clausola esplicita di no-retention e no-training. I dati dei clienti non vengono conservati dal fornitore, né usati per addestrare modelli. Per i clienti che lo richiedono resta l’opzione di modelli ospitati su infrastruttura dedicata, sempre in UE.

Il costo: il catalogo di modelli disponibili in Europa è più ristretto di quello globale. È un prezzo che abbiamo accettato consapevolmente.

3. Gli agenti non sanno quale AI stanno usando

Gli agenti di MIA non chiamano direttamente un fornitore di modelli. Dichiarano il tipo di compito che devono svolgere, e un componente interno — un gateway — decide quale modello usare.

Tre ragioni.

La prima è l’indipendenza: se un fornitore raddoppia i prezzi, cambia i termini o ha un disservizio, cambiamo backend modificando una configurazione, non riscrivendo il prodotto.

La seconda è il costo. Usare il modello più potente disponibile per estrarre una data da un’email è uno spreco. Compiti diversi meritano modelli diversi, e il gateway permette di instradarli senza che gli agenti debbano saperne nulla.

La terza è la flessibilità sulla conformità: clienti diversi possono avere requisiti diversi, gestibili per singolo cliente invece che a livello di prodotto.

Il costo: è un componente in più da costruire, testare e mantenere, e l’astrazione rinuncia ad alcune funzioni specifiche dei singoli fornitori.

4. (in valutazione) Far girare tutto dentro l’azienda del cliente

Questa quarta decisione è ancora una proposta, non una scelta definitiva — e la raccontiamo proprio per questo.

Alcune PMI, tipicamente in settori regolamentati, non affideranno mai i propri dati a un’infrastruttura condivisa, per quanto conforme. La loro richiesta è netta: tutto sul mio server, elaborazione AI compresa.

Tecnicamente il gateway del punto precedente rende la cosa possibile senza mantenere due prodotti diversi: passare da un modello gestito a uno che gira in casa del cliente diventa una questione di configurazione, non di riscrittura.

Resta però una proposta perché comporta requisiti hardware a carico del cliente, un pacchetto di installazione dedicato e un modello commerciale diverso da quello in abbonamento. Vogliamo verificarla su un caso reale prima di dichiararla supportata.

Il database c’è. Il prodotto no.

Insieme alle decisioni abbiamo scritto la struttura dati: le entità e le relazioni che formeranno il grafo della conoscenza aziendale, i documenti e i loro frammenti indicizzati per la ricerca semantica, fatture, dipendenti, promemoria con escalation, conversazioni.

È l’ossatura su cui poggerà tutto il resto. Ma è, appunto, un’ossatura.

Cosa non funziona ancora

La parte più importante di questo diario, e quella che ripeteremo ogni volta.

• Non c’è un’interfaccia. Non c’è niente da mostrare su uno schermo.
• Non c’è nessun collegamento attivo. Gmail, calendario e documenti sono progettati, non collegati.
• Il CEO Daily Briefing non esiste. È la Fase 1, deve ancora iniziare.
• La modalità completamente interna all’azienda del cliente è una proposta architetturale, non una modalità supportata.
• La stessa Fase 0 non è chiusa: la struttura del progetto e le decisioni ci sono, la gestione di identità e accessi e l’attivazione automatica di un nuovo cliente no.

La priorità è un MVP solido — il CEO Daily Briefing — da validare con poche aziende pilota prima di allargare. Non diamo una data di rilascio: la comunicheremo quando avremo il primo pilota attivo, non prima. Nel frattempo l’avanzamento è qui, ogni due settimane.

Nella prossima puntata

Perché abbiamo scelto proprio il CEO Daily Briefing come prima funzione da costruire — e quali altre, apparentemente più utili, abbiamo messo da parte.

---

Vuoi seguire lo sviluppo di MIA, o essere tra le aziende pilota che la proveranno per prime? Contattaci: raccontaci come sono organizzati oggi i dati della tua azienda.