Copilot BI per direzione (NL2SQL governato) — caso tipo

Scenario caso tipo: la direzione vuole interrogare KPI in italiano senza aprire il database a query arbitrarie generate da un LLM. Purple AI propone un copilot con template SQL approvati, permessi per ruolo, audit e export verso Excel o BI esistenti — tema centrale anche nel post blog sulla governance NL2SQL.

Contesto dati

Spesso i dati esistono in SQL Server, PostgreSQL o in viste curate dal reparto IT. Il rischio è che un modello generi SQL non valido, eccessivamente costoso o che esponga colonne riservate. La soluzione non è “disabilitare l’AI” ma circoscrivere lo spazio delle query a percorsi noti, versionati e testati in CI.

Problema

Il CFO o i responsabili di linea perdono tempo in richieste al BI; il BI è congestionato. Una chat generica non conosce i vostri ruoli, le maschere di row-level security né i vincoli di performance. Serve un assistente che traduca domande in selezione di template o parametrizzazioni sicure, non in testo SQL libero.

Approccio

Mappiamo le domande frequenti a query parametrizzate; il modello classifica l’intento e propone i parametri mancanti (periodo, business unit, valuta). JWT o equivalente portano i ruoli fino al layer query. Ogni esecuzione produce log con hash della richiesta e tempo di esecuzione. Report schedulati riusano gli stessi template per coerenza tra ciò che chiedete in chat e ciò che arriva via email.

Collegamento con il portfolio del gruppo

Piattaforme dati, integrazioni gestionali e progetti storici sono documentati sul portfolio dell’hub software. Il copilot AI si innesta su quell’ecosistema quando le API e le viste sono già mature.

Rischi mitigati

SQL injection via LLM, leakage di colonne sensibili, query full-scan su tabelle enormi. Mitigazione: allowlist, timeout, limite righe, spiegazioni testuali solo dopo esecuzione riuscita su dati già filtrati per ruolo.

Metodo Purple AI sul caso

Questa scheda è un caso tipo descritto in forma aggregata: non sostituisce una proposta commerciale né un contratto. Purple AI è il marchio del verticale intelligenza artificiale di Purple AI S.r.l., parte di Purple Holding S.r.l. Il percorso che proponiamo unisce discovery, proof of concept realistico, hardening e messa in produzione con osservabilità. Evitiamo demo isolate che non reggono policy di sicurezza o audit interni.

Prerequisiti organizzativi

Serve un referente business, un referente IT o sicurezza e — dove presenti — un DPO o ufficio compliance. Definiamo insieme cosa può uscire dal perimetro rete, quali log conservare e chi può approvare modifiche a corpus, template SQL o agenti. Per integrazioni gestionali e progetti non esclusivamente AI il contesto completo del gruppo resta sull’hub software di Purple Holding.

Architettura di riferimento

Tipicamente combiniamo servizi gestiti per STT/TTS o LLM, backend .NET o stack concordato, database relazionale e — se serve memoria semantica — PostgreSQL con pgvector. L’edge o il client leggero gestisce sessione, wake word opzionale e fallback quando la rete non è disponibile. Ogni componente ha owner, versione e piano di aggiornamento quando i vendor deprecano API o modelli.

Sicurezza, privacy e residenza dati

Audio, testo e metadati transitano con TLS; dove richiesto evitiamo di persistere registrazioni integrali. Ruoli e segregazione dati sono progettati prima del go-live, non come patch. Allineiamo il trattamento a policy aziendali e — se applicabile — a requisiti di settore. Per domande ricorrenti su cloud, log LLM e GDPR vedi anche la FAQ.

Metriche e acceptance

Definiamo soglie su latenza percepita, tasso di conferma utente dopo TTS, errori di intent e costo medio per sessione. Il business valida su campioni reali o semi-realistici prima di firmare il go-live. Se le metriche non si raggiungono, documentiamo gap (rumore ambientale, lessico, connettività) e pianifichiamo iterazione o riduzione perimetro.

Manutenzione e roadmap

Dopo il rilascio offriamo monitoraggio, ticket e release notes quando cambiano modelli o corpus. Pianifichiamo con voi aggiornamenti stagionali del lessico, nuove integrazioni tool e regression test automatici dove ha senso. Per pacchetti e audit visitate shop o contatti.

Limiti e responsabilità

I sistemi descritti non sostituiscono procedure di sicurezza sul lavoro, pareri legali o decisioni umane dove la legge richiede supervisione. Non garantiamo disponibilità continua dei provider terzi; mitighiamo con fallback e comunicazione trasparente degli SLA concordati. Per approfondimenti tecnici analoghi consultate i casi studio e il blog.

Collegamenti utili

Servizi · Portfolio · Ricerca & laboratorio · Chi siamo

Proof of concept e transizione a produzione

Il POC deve usare gli stessi confini di rete, ruoli e logging che prevedete in produzione, altrimenti i numeri saranno fuorvianti. Fissiamo una durata massima dello sprint sperimentale, criteri di successo misurabili e una decisione esplicita go/no-go. In caso positivo, pianifichiamo hardening: backup, monitoraggio, allarmi su errori ripetuti, procedure di rollback modello o corpus. In caso negativo, documentiamo cosa manca (dati, connettività, ownership) così potete riprendere il tema con budget e stakeholder allineati.

Formazione utenti e change management

Strumenti vocali e copilot cambiano abitudini: servono brevi guide, video e sessioni sul campo. Raccogliamo feedback strutturato nelle prime settimane e aggiorniamo lessico, prompt di sistema o messaggi TTS per ridurre frustrazioni. Il reparto IT riceve runbook su come sospendere una funzionalità, ruotare chiavi API o isolare un nodo difettoso senza spegnere tutto il magazzino o tutta la direzione.

Conformità e fornitori terzi

Elenco fornitori, sottoprocessori e regioni di processing va tenuto allineato a quanto dichiarate in privacy e contratti. Quando un vendor modifica termini o modelli, valutiamo impatto su qualità e costi e comunichiamo opzioni al cliente. Non nascondiamo dipendenze critiche: preferiamo roadmap condivise e piani B documentati piuttosto che sorprese a produzione avviata.

Scalabilità e costi operativi

Progettiamo batch dove possibile (embedding, report) e caching dove la freschezza dei dati lo consente. Monitoriamo costo per richiesta o per ora di utilizzo voce così il business non riceve bollette impreviste. Se il carico cresce, verticalizziamo prima ottimizzando retrieval e template, poi scalando infrastruttura, evitando di “alzare solo il tier del modello” come unica leva.

Test, osservabilità e incident response

Prevediamo test automatici su intent critici, contratti API tra servizi e traccia distribuita per capire dove nasce un errore (STT, LLM, DB). In incident response definiamo chi può disattivare una funzionalità, come comunicare agli utenti e come conservare log per post-mortem senza violare minimizzazione dati. Questa disciplina vale per voce, copilot e RAG allo stesso modo: l’AI in produzione è un servizio IT come gli altri.