Domanda Scomoda: Ha Ancora Senso Affidare i Nostri Dati a Sistemi che Non Controlliamo?

La domanda provocatoria

Ha ancora senso fornire dati aziendali a sistemi AI che non controlliamo?

Per anni abbiamo accettato servizi cloud potenti in cambio dei nostri dati.
Ma l’intelligenza artificiale cambia questo equilibrio perché non si limita a processare dati ma genera conoscenza.

Gli investimenti necessari

Adottare un’architettura AI controllata richiede alcuni investimenti:

  • Infrastruttura containerizzata o Kubernetes
  • Data architecture e vector database
  • Integrazione tramite API o MCP
  • Governance e controllo del dato

Competenze necessarie

Le competenze richieste includono:

  • Data engineering
  • AI engineering
  • DevOps o platform engineering
  • Data governance

Il vero valore è avere una visione architetturale chiara.

Conclusione

Nel prossimo futuro l’intelligenza artificiale diventerà l’interfaccia principale con la conoscenza aziendale.

La domanda quindi non sarà solo se utilizzare l’AI, ma chi controlla l’accesso ai dati e il processo di generazione della conoscenza.

LLM, RAG e Data Sovereignty: costruire una piattaforma AI sui propri dati

Nel mio laboratorio ho implementato una piattaforma AI locale composta da:

  • Ollama per eseguire modelli LLM localmente
  • Qdrant come vector database per gli embeddings
  • OpenWebUI come interfaccia utente
  • Kubernetes per l’orchestrazione dei servizi
  • I modelli utilizzati includono Qwen2.5 e nomic‑embed‑text

Vector database e embeddings

Quando documenti o knowledge base vengono caricati nel sistema, il modello di embedding trasforma il testo in vettori numerici.

Questi vettori vengono salvati in Qdrant e permettono ricerche semantiche molto veloci all’interno dei dati aziendali.

Retrieval Augmented Generation

Quando l’utente pone una domanda:

  1. Il sistema cerca documenti rilevanti nel vector database
  2. I documenti vengono inseriti nel contesto
  3. Il modello genera la risposta

Questo approccio è noto come RAG (Retrieval Augmented Generation) e permette di utilizzare modelli generici su conoscenza aziendale specifica.

Questa architettura dimostra come sia possibile costruire sistemi di intelligenza artificiale avanzati mantenendo il controllo completo dei propri dati.

LLM, vector database e RAG permettono di sfruttare la potenza dei modelli generativi senza dover spostare informazioni sensibili fuori dal dominio aziendale.

In questo scenario l’AI non è più solo uno strumento potente, ma un’infrastruttura che può essere progettata secondo i principi di sicurezza, integrazione e sovranità del dato.

Ed è proprio qui che architetture aperte e protocolli come MCP diventano fondamentali: non solo per collegare modelli e dati, ma per farlo senza rinunciare al controllo di ciò che rappresenta il vero valore dell’azienda — le sue informazioni.

Generare allenamenti di nuoto con un LLM locale

Generare allenamenti di nuoto con un LLM locale: dalla knowledge base alla pianificazione settimanale

Nel precedente articolo abbiamo visto come costruire un sistema RAG (Retrieval Augmented Generation) nel nostro laboratorio Kubernetes utilizzando:

  • Ollama come motore LLM locale
  • Qdrant come database vettoriale
  • OpenWebUI come interfaccia per l’interazione con il modello

In quella fase l’obiettivo era permettere al modello di rispondere a domande utilizzando una knowledge base specifica.

Il passo successivo è stato molto più interessante: utilizzare lo stesso sistema per generare allenamenti di nuoto realistici, basati su allenamenti realmente utilizzati durante la stagione.

Dalla conoscenza alla generazione di allenamenti

Un modello linguistico può generare contenuti plausibili, ma senza un contesto specifico tende a produrre risultati generici.

Per ottenere allenamenti realistici abbiamo costruito una knowledge base composta da sedute reali di allenamento, strutturate secondo il modello CSS (Critical Swim Speed).

Ogni allenamento è stato inserito nella libreria come documento indipendente, ad esempio:

  • workout_week24_sessionA.txt
  • workout_week24_sessionB.txt
  • workout_week24_sessionC.txt

Ogni file segue una struttura coerente:

  • WARMUP
  • SENSITIVITY
  • TECHNIQUE
  • ACTIVATION
  • MAIN SET
  • COOLDOWN

Questo approccio permette al sistema RAG di recuperare esempi reali e fornire al modello pattern di allenamento realistici.

Il ruolo della knowledge base

La knowledge base contiene tre tipi di informazioni:

1. Regole del metodo di allenamento

Un documento descrive il metodo utilizzato per costruire le sedute.

Ad esempio: coach_training_rules.txt

In questo file sono definite:

  • le zone di allenamento (A1, A2, B1, B2, C1, C2)
  • la struttura delle sedute
  • il ruolo dei drill tecnici
  • l’utilizzo degli attrezzi (pinne, pull buoy, palette, snorkel)

Questo documento permette al modello di comprendere la logica dell’allenatore, non solo copiare esempi.

2. Allenamenti reali

La libreria contiene numerose sedute distribuite su diverse settimane.

Ad esempio: week21, week22, week23, week24, week25, week26, week27, week28

Ogni settimana include più sessioni di allenamento.

Questo consente al modello di osservare:

  • progressioni di carico
  • variazioni di intensità
  • alternanza tra tecnica e lavoro aerobico
  • uso delle diverse zone di allenamento

3. Regole di generazione

Un ulteriore documento definisce alcune regole utili per generare allenamenti coerenti:

  • distanza totale tipica (2000–2800 m)
  • utilizzo delle zone CSS
  • presenza obbligatoria delle sezioni della seduta
  • uso di set concreti con distanze e recuperi

4. Generazione di nuovi allenamenti

Una volta popolata la knowledge base, il sistema è in grado di generare nuovi allenamenti utilizzando i pattern presenti negli esempi.

Un esempio di richiesta può essere: (prompt)

Generate a 2500m swim workout using CSS zones
similar to the sessions in the knowledge base.

Il sistema RAG recupera i documenti più rilevanti dalla libreria e li utilizza come contesto per il modello.

Il risultato è una seduta strutturata, ad esempio:

WARMUP
200 freestyle
100 pullSENSITIVITY
2x(30″ sculling + 50 freestyle)ACTIVATION
4×50 (1 A2 + 1 B1)MAIN SET 2x
150 A2
150 B1
2×100 A1 pullCOOLDOWN
200 easy swim

Il vantaggio principale è che il modello non inventa un allenamento casuale, ma utilizza pattern già presenti nella libreria.

Verso la pianificazione settimanale

Una volta che il sistema è in grado di generare singole sedute, il passo successivo è generare una settimana completa di allenamento.

Ad esempio:

Generate week 29 swim training
3 sessions
based on weeks 21–28 patterns

In questo caso il modello utilizza le settimane precedenti per creare una nuova settimana coerente con il metodo di allenamento.

Questo permette di utilizzare il sistema come assistente per la pianificazione degli allenamenti.

Nel prossimo articolo vedremo i passaggi all’interno di webui per realizzare il progetto swimming-training

MCP: Il Ponte tra LLM e Sistemi Aziendali

Cos’e’ un MCP

Il Model Context Protocol (MCP) nasce per permettere ai modelli AI di accedere a sistemi aziendali senza dover trasferire i dati su piattaforme esterne.

L’ MCP permette ai modelli di interagire con:

  • Servizi
  • Database
  • API
  • Applicazioni
  • Repository documentali

E’ il layer standardizzato tra LLM e i dati aziendali che siano strutturati o meno.

Sovranità del dato

La sovranità del dato non è solo una questione geografica.

Riguarda tre aspetti fondamentali:

  • Controllo: chi può accedere ai dati
  • Tracciabilità: sapere come vengono utilizzati
  • Governance: decidere dove vengono processati

Un’architettura basata su LLM e MCP permette di mantenere questi elementi
perché i dati rimangono nei sistemi originali.

Integrazione SaaS e On‑Prem

Uno dei vantaggi principali di MCP è la facilità di integrazione.

Un MCP server può collegare l’AI a servizi SaaS come CRM, piattaforme di ticketing, document management e strumenti di collaboration.

Allo stesso tempo può accedere a sistemi on‑premise come database interni,
file system, sistemi legacy o piattaforme di monitoring.

Nel futuro dell’intelligenza artificiale la vera differenza non sarà la potenza del modello, ma la capacità di utilizzarlo senza rinunciare al controllo dei propri dati.

AI, LLM e Sovranità del Dato: Perché l’AI ha Bisogno dei Nostri Dati

Negli ultimi anni l’intelligenza artificiale, e in particolare i Large Language Models (LLM), hanno dimostrato una capacità straordinaria di analizzare informazioni, generare contenuti e supportare decisioni operative.

Tuttavia molte aziende si trovano di fronte a una domanda cruciale: come utilizzare l’intelligenza artificiale sui propri dati senza perderne il controllo?

La risposta non riguarda solo dove gira il modello (cloud o on‑prem), ma come il modello accede ai dati.
Ed è qui che entrano in gioco architetture moderne basate su LLM e Model Context Protocol (MCP).

Il vero valore dell’AI? I dati

Un LLM senza dati aziendali è poco più di un assistente generico.

Il valore reale nasce quando l’AI può accedere a documentazione tecnica, dati operativi, log di sistema, knowledge base, ticket di supporto e dati provenienti da applicazioni SaaS o repository on‑premise.

In questo scenario l’intelligenza artificiale diventa uno strumento di analisi e supporto decisionale reale, non solo un chatbot.

Ma questo introduce due problematiche fondamentali:

  • Integrare i dati in modo semplice
  • Non perdere il controllo del dato

Il problema dei modelli AI tradizionali

Molti servizi AI cloud funzionano in modo semplice:

  1. I dati vengono caricati sulla piattaforma
  2. Il modello li analizza
  3. Le informazioni vengono elaborate fuori dal dominio aziendale

Questo approccio presenta diversi limiti:

  • Problemi di compliance
  • Perdita di sovranità del dato
  • Difficoltà di integrazione con sistemi interni
  • Dipendenza dalla location del servizio

Il problema quindi non è solo dove gira l’AI, ma dove si trovano i dati e come vengono utilizzati.

Come funziona una query RAG

Con l’articolo di oggi chiudiamo il cerchio vedendo cosa accade quando l’utente pone una domanda:

Qual è il colore segreto del laboratorio AI?

il sistema esegue queste operazioni:

1️⃣ la domanda viene convertita in embedding
2️⃣ Qdrant cerca i vettori più simili
3️⃣ vengono recuperati i documenti rilevanti
4️⃣ il contesto viene inviato all’LLM
5️⃣ il modello genera la risposta

Flusso:

Domanda utente
|||

Embedding
|||

Qdrant search
|||

Documenti rilevanti
|||

LLM (Ollama)
|||

Risposta finale

Questo modello permette di ottenere risposte basate sui propri dati, non solo sulle conoscenze del modello.

Conclusioni

Con l’introduzione di Qdrant il laboratorio AI su Kubernetes diventa una vera piattaforma RAG completa.

L’architettura ora è composta da:

  • Ollama → esecuzione dei modelli LLM
  • Qdrant → database vettoriale
  • Open WebUI → gestione knowledge base e interfaccia utente

Questo stack consente di costruire rapidamente assistenti AI che rispondono utilizzando documentazione aziendale, manuali tecnici o dati proprietari.

Nel prossimo articolo vedremo come:

  • creare dataset strutturati
  • migliorare il chunking dei documenti
  • ottimizzare la qualità delle risposte del modello.

Nell’immagine in calce il riassunto di quello che è stato messo in esercizio nel laboratorio

Modello AI