Piattaforma dati AI governata Vue

Digitool

Una piattaforma che raccoglie i dati marketing dei clienti di un’agenzia e li trasforma in analisi e report. Costruita da agenti AI dentro un recinto dove il database non si tocca senza approvazione umana.

Cliente / Progetto Progetto DSM
Settore MarTech / Analytics
Tipo Piattaforma SaaS multi-cliente
Stato In sviluppo attivo
9
migrazioni approvate una per una
0
modifiche al database senza approvazione umana
1
container isolato per cliente

I dati del cliente stanno in dieci piattaforme diverse.

Un’agenzia che gestisce campagne per più clienti vive dentro una dispersione strutturale: Meta da una parte, Google Ads dall’altra, analytics altrove, e-commerce da un’altra ancora. Ogni fine mese qualcuno rientra manualmente negli stessi pannelli, copia gli stessi numeri e ricompone lo stesso report.

Il costo non è solo il tempo speso. È che l’analisi arriva sempre in ritardo rispetto alla decisione, e che il cliente riceve numeri senza il ragionamento che li rende utili.

L’AI doveva costruire il sistema senza poterlo rompere.

Il vincolo che ha determinato tutta l’architettura non riguarda le funzionalità ma il metodo: volevamo che fossero degli agenti AI a scrivere materialmente il software, senza però concedere loro la possibilità di fare danni irreversibili. Su un sistema che maneggia i dati di più clienti, uno schema di database modificato di iniziativa è un incidente, non un contrattempo.

C’era poi un secondo vincolo, sull’AI dentro il prodotto: un’analisi sbagliata presentata con sicurezza è peggio di nessuna analisi, perché qualcuno ci prende una decisione sopra.

Un recinto, e dentro il recinto la velocità.

Abbiamo costruito un middleware che fa da sbarramento: l’AI non tocca il database, propone. Ogni modifica allo schema entra come proposta in stato sospeso e resta lì finché una persona non la approva. Solo all’approvazione diventa una migrazione numerata, viene applicata in transazione e i tipi del frontend vengono rigenerati leggendo il database vero.

Il flusso non torna mai indietro: il frontend non può precedere i tipi, i tipi non possono precedere l’approvazione umana. Al frontend è vietato ridefinire la forma dei dati per far compilare il codice, che è la scorciatoia da cui nascono i disallineamenti più costosi.

Sopra questa base vivono le funzionalità: gestione clienti, sincronizzazione dei dati dalle piattaforme pubblicitarie, un magazzino dati con granularità per audience, analisi per periodo, generazione assistita dei report e un portale per il cliente finale.

Il rituale del giorno zero, prima di ogni riga di codice.

Ogni progetto costruito con questo stampo parte da tre artefatti che l’umano approva prima che si scriva una funzionalità: la mappa del sistema (quali entità, quale ciclo di vita del business, quali regole non negoziabili), il contratto dati tradotto in schema, e la roadmap a fasi ordinata per dipendenze reali. Le viste si costruiscono dopo i dati che leggono, mai prima.

Sull’AI dentro il prodotto vale un playbook altrettanto rigido. La prima domanda è sempre se serva davvero un modello: calcoli, aggregazioni e regole restano codice deterministico, che costa zero per esecuzione e non sbaglia. Il modello interviene solo dove il codice non arriva, cioè linguaggio naturale, sintesi e classificazione ambigua.

Le chiamate al modello vivono solo nel middleware, mai nel browser. Il contesto è pre-digerito con query SQL invece che riversato a blocco. Ed è vietato il text-to-SQL libero in produzione: il modello sceglie quale funzione autorizzata chiamare, mentre le query restano parametrizzate nel codice. Il modello non tocca mai il database, né in sviluppo né a runtime.

Le tecnologie usate.

Vue Pinia PostgreSQL Fastify Docker Tailwind

Front-end Vue con stato centralizzato in Pinia, dove i componenti ricevono l’identificativo di un’entità e non una sua copia, così che più viste della stessa cosa restino allineate. Design system a token in Tailwind: per ricolorare l’applicazione su un cliente si cambiano i valori, non i componenti. Middleware Fastify, PostgreSQL come unica fonte di verità, un container isolato per cliente, consegna del codice tramite pull request con controlli automatici prima del commit.

Nove migrazioni, nessuna sorpresa.

Lo schema del database è cresciuto in nove passaggi, ognuno passato dalla stessa porta: proposta, approvazione, applicazione in transazione, rigenerazione dei tipi. La storia delle migrazioni si legge come un registro delle decisioni prese, e non esiste un solo cambiamento entrato di soppiatto.

Le chiamate al modello sono tracciate a database, quindi costi ed esiti sono verificabili invece che stimati. La piattaforma è in sviluppo attivo e cresce per fasi.

La velocità dell’AI vale solo se qualcuno tiene la porta.

Digitool è la risposta concreta all’obiezione più seria che si fa al vibe coding: se l’AI scrive in fretta, chi garantisce che non rompa niente? La risposta non è rallentare l’AI, è costruire il recinto giusto: approvazione umana sulle azioni irreversibili, una sola fonte di verità per i dati, controlli automatici prima di ogni consegna. Se stai valutando di far scrivere software a degli agenti su qualcosa che conta, è questa l’architettura che portiamo sul tavolo.

Domande frequenti su questo progetto

Che cos’è il middleware airgap?

È lo sbarramento tra l’AI e il database. L’agente non può eseguire modifiche allo schema: può solo proporle. La proposta resta sospesa finché una persona non l’approva, e solo allora diventa una migrazione applicata in transazione, con i tipi del frontend rigenerati dal database reale.

Perché non lasciare che l’AI modifichi il database direttamente?

Perché lo schema è la cosa più costosa da correggere a posteriori e gli errori non sono reversibili come una riga di codice. Con dati di più clienti in gioco, un’iniziativa autonoma sullo schema è un incidente. L’approvazione umana su ciò che è irreversibile è il minimo sindacale, non un eccesso di prudenza.

Il sistema usa l’AI per generare le query sui dati?

No, ed è una scelta deliberata. Il text-to-SQL libero in produzione produce numeri sbagliati presentati con sicurezza assoluta, e qualcuno ci decide sopra. Qui il modello sceglie quale funzione autorizzata chiamare, mentre le query restano parametrizzate nel codice: i dati che tornano sono esatti per costruzione.

Quando conviene usare un modello linguistico e quando no?

La regola che seguiamo è chiedersi prima se serva. Calcoli, aggregazioni, lookup e regole si risolvono con codice deterministico: costa zero per esecuzione e non sbaglia. Il modello si usa solo per ciò che il codice non sa fare, cioè linguaggio naturale, sintesi e classificazione ambigua.

Questo impianto si può riusare su altri progetti?

Sì, ed è già successo: lo stesso stampo (contratto dati, airgap, design system a token, controlli prima del commit) regge anche il nostro software di project management. È un modo di lavorare prima che un codice specifico, e si adatta a qualunque applicativo gestionale con dati che contano.

Vuoi far scrivere software all’AI senza perderne il controllo?

Parliamone
Architettura e governance prima del codice