Quando l’AI incontra i dati reali: da Garmin e Strava al mio coach AI

A questo punto AI-nuoto sapeva perfettamente cosa era stato programmato.

Ma non necessariamente cosa avevo fatto, ed è una differenza enorme.

Final Surge può dirmi che il 6 agosto erano previsti determinati metri e determinati lavori.

Ma se quel giorno ho nuotato 3.500 metri, oppure ne ho fatti 2.000, oppure non sono proprio entrato in acqua, un coach intelligente dovrebbe saperlo.

Nasce così una distinzione fondamentale del progetto:

PLANNED ≠ COMPLETED

Non volevo che AI-nuoto vedesse un allenamento nel calendario e concludesse automaticamente che fosse stato eseguito.

Serviva quindi un’altra fonte dati, ed entra in gioco Strava.

Il Garmin registra praticamente ogni mio allenamento.

La strada ideale sarebbe quindi:

Garmin → AI

ma l’accesso diretto ai dati Garmin tramite le API ufficiali non è la soluzione più semplice per un piccolo progetto personale.

Fortunatamente nel mio ecosistema esiste già un ottimo ponte, Strava !!!

Garmin Connect sincronizza automaticamente le attività con Strava. Strava dispone inoltre di API che permettono, previa autorizzazione OAuth, di interrogare le attività dell’atleta.

A questo punto il nerd ha definitivamente preso il sopravvento sul vacanziere.

Ho creato una piccola applicazione Strava chiamata, naturalmente, AI-nuoto.

Poi ho configurato una Action nel mio GPT utilizzando OAuth e le API Strava, inizialmente esclusivamente in lettura (Nessuna possibilità di modificare o pubblicare attività).

Solo leggere ciò che serve al coach

Le prime operazioni sono volutamente semplici:

  • getAuthenticatedAthlete
  • getRecentActivities
  • getActivityDetails

Dopo qualche passaggio tra Client ID, Client Secret, callback URL e OAuth, è arrivato il momento del test.

AI-nuoto ha interrogato e Strava ha risposto recuperando realmente le mie attività recenti, riconoscendo tra queste i miei allenamenti di nuoto.

A quel punto il progetto ha cambiato natura:  Planned + Completed.

AI-nuoto dispone di due prospettive differenti.

Da una parte: Final Surge → cosa era previsto

Dall’altra: Garmin → Strava → cosa è realmente successo

E in mezzo: Profilo atleta → chi sta facendo quegli allenamenti

L’AI può quindi iniziare a ragionare su qualcosa di molto più interessante:

Previsto → Eseguito → Differenza → Decisione successiva

L’architettura concettuale è diventata:

Final Surge → Planned

Knowledge Base

Garmin → Garmin Connect → Strava API → Completed

AI-nuoto

Profilo atleta → Context

Analisi → prossimo allenamento

Ed è qui che, secondo me, l’AI applicata allo sport comincia davvero a diventare interessante dato che l’obiettivo del progetto non è costruire una macchina che dica: “Oggi fai 10×100 A2 recupero 15 secondi” (un normale LLM può già generare qualcosa del genere in pochi secondi).

Quello che sto cercando di costruire è un sistema capace di rispondere prima ad altre domande:

  1. Cosa ho fatto nelle ultime settimane?
  2. Cosa era previsto?
  3. Cosa ho realmente completato?
  4. Qual è stata la progressione?
  5. Quali stimoli ho già ricevuto?
  6. Qual è il mio obiettivo attuale?

E soltanto dopo:

  • Cosa avrebbe senso fare adesso?

È una differenza sostanziale.

L’AI non diventa interessante quando genera più velocemente una scheda.

Diventa interessante quando dispone del contesto necessario per prendere una decisione migliore.

Il vero progetto è trasformare dati in contesto

Alla fine dei miei primi due giorni di ferie mi sono reso conto che AI-nuoto è in realtà un piccolo laboratorio su qualcosa di molto più grande.

Abbiamo già moltissimi dati personali e professionali distribuiti in applicazioni differenti, il problema è che ogni componente conosce soltanto un pezzo della storia.

L’AI può diventare lo strato capace di collegare questi pezzi

Nel mio piccolo esperimento:

  • Final Surge conosce il programma.
  • Garmin conosce il gesto eseguito.
  • Strava rende accessibile l’attività.
  • La Knowledge conserva la storia.
  • Il profilo fornisce il contesto.
  • L’AI mette tutto in relazione.

La sequenza che mi interessa è quindi:

DATA → KNOWLEDGE → CONTEXT → DECISION

E probabilmente è questo l’aspetto che continuerò a esplorare.

Perché, da nerd appassionato di tecnologia e di lunghe nuotate in acque libere, c’è qualcosa di particolarmente affascinante nell’idea che anni di vasche, chilometri, test, gare e allenamenti non rimangano semplicemente righe archiviate dentro qualche applicazione.

Possono diventare memoria utilizzabile.

E una memoria utilizzabile può diventare contesto e il contesto diventa analisi.

E l’analisi, può aiutarmi a fare una cosa molto semplice:

Nuotare meglio e più veloce!


Nei prossimi articoli: Garmin, Strava e AI: come trasformare i dati reali dell’allenamento in informazioni utilizzabili da un agente AI.

Qui entreremo più nel tecnico: API, OAuth, GPT Actions, Planned vs Completed e architettura dell’integrazione, senza perdere di vista la domanda fondamentale: quali dati servono davvero a un’AI per capire come ci stiamo allenando?

Dal diario di allenamento a un coach AI personale

Sottotitolo: Come trasformare anni di allenamenti, dati e passione per il nuoto in un agente AI capace di conoscere la mia storia sportiva

I primi due giorni di ferie, normalmente, dovrebbero servire a staccare.

Nel mio caso è successo più o meno il contrario.

Da buon nerd, appassionato di tecnologia e grande cultore del nuoto in acque libere, mi sono posto una domanda che, come spesso accade, sembrava innocua:

“E se mi costruissi un agente AI che conosce davvero il mio modo di allenarmi?”

Non un chatbot al quale chiedere genericamente “fammi un allenamento di nuoto da 3.000 metri”. Quello è relativamente semplice.

Volevo qualcosa di diverso.

  1. Un agente che conoscesse anni di allenamenti, sapesse come sono strutturate le mie Sedute A e B, riconoscesse A1, A2, B1, B2, C1, pull, pinne, boccaglio, remate e lavori di sensibilità.
  2. Un sistema che conoscesse i miei riferimenti prestativi, sapesse distinguere ciò che avrei dovuto fare da ciò che ho realmente fatto e, soprattutto, utilizzasse tutto questo contesto prima di suggerirmi cosa fare dopo.

Così sono iniziati i miei primi due giorni di ferie.

E naturalmente sono finiti con Final Surge, Garmin, Strava, API, OAuth, Knowledge Base e un agente AI.

Forse la definizione di ferie per un nerd è leggermente diversa.

Il problema non sono i dati. È riuscire a usarli !

Come molti sportivi che utilizzano tecnologia durante gli allenamenti, negli anni ho accumulato una quantità notevole di informazioni.

  • Gli allenamenti programmati sono in Final Surge.
  • L’orologio Garmin registra ciò che faccio realmente.
  • Garmin Connect raccoglie le attività. Strava ne riceve una copia.

Il risultato è che possiedo moltissimi dati, ma possedere dati non significa necessariamente possedere conoscenza.

Se voglio sapere cosa ho fatto ieri, è semplice.

Se invece voglio rispondere a domande come:

  • Come sono cambiate le mie Sedute A negli ultimi sei mesi?
  • Quali esercizi tecnici ho utilizzato maggiormente?
  • Quanto lavoro A2 sto facendo?
  • L’allenamento che dovrei fare domani è coerente con le ultime settimane?

la situazione cambia!

I dati ci sono, ma sono distribuiti in sistemi diversi e soprattutto manca qualcosa che li metta in relazione.

Ed è qui che l’AI diventa interessante.

Primo passo: Dare una memoria al coach

La prima operazione è stata recuperare lo storico da Final Surge.

L’obiettivo non era semplicemente esportare dei PDF e caricarli dentro un GPT. Volevo trasformare quello storico in una Knowledge Base utilizzabile dall’agente.

Ho quindi estratto esclusivamente gli allenamenti di nuoto, identificati dalle mie classiche voci Seduta A, Seduta B, ecc., eliminando tutto ciò che non era pertinente.

Il risultato è stato un archivio strutturato di 221 allenamenti, dal quale l’AI può recuperare una determinata seduta, confrontare periodi differenti e riconoscere progressioni ed elementi ricorrenti.

Questo cambia radicalmente il tipo di domanda che posso fare.

Non più: “Creami un allenamento da 3.000 metri.”

Ma: “Analizza le ultime tre Sedute A e proponimi la successiva, mantenendo una progressione coerente.”

Sono due richieste apparentemente simili, ma concettualmente molto diverse.

Nel primo caso l’AI genera, nel secondo deve prima recuperare, comprendere e contestualizzare.

Ma, una Knowledge Base non basta

A quel punto è emerso un secondo problema.

L’agente conosceva gli allenamenti, ma non conosceva abbastanza bene l’atleta.

Ho quindi creato un secondo elemento: il Profilo Atleta.

Qui sono raccolti i riferimenti utili per interpretare lo storico:

Età, disciplina prevalente, frequenza degli allenamenti, piscina e acque libere, obiettivi e alcuni riferimenti prestativi.

Per esempio:

200 m → 3:45
400 m → 7:42
1.000 m → 19:22
CSS storico → circa 1:58/100 m

Con una regola fondamentale: un dato storico non deve essere considerato automaticamente un dato attuale.

Se domani effettuo un nuovo test, il sistema deve utilizzare il nuovo valore senza perdere quello precedente, perché proprio il confronto nel tempo permette di capire l’evoluzione.

A questo punto iniziava a delinearsi una struttura interessante:

  • Knowledge → cosa ho fatto nel tempo
  • Profilo → chi sono e quali sono i miei riferimenti
  • Conversazione → qual è la mia situazione oggi

Poi arriva il problema dei 3.000 metri.

Chi prepara allenamenti di nuoto probabilmente sorriderà.

Chiedere a un’AI: “Preparami una seduta esattamente da 3.000 metri”, può produrre una bellissima scheda che termina con:

TOTALE: 3.000 m

Peccato che, facendo i conti, magari siano 2.850.

Un piccolo dettaglio: quando sei in acqua e scopri che il totale scritto in fondo alla scheda è più ottimista della matematica.

Per questo nelle Instructions di AI-nuoto ho inserito una regola quasi ossessiva:

il totale non si dichiara, si calcola.

Ogni blocco deve essere calcolato, le moltiplicazioni delle serie devono essere considerate e alla fine tutto deve essere sommato nuovamente.

Durante il collaudo ho quindi chiesto all’agente di analizzare le ultime tre Sedute A e crearne una nuova esattamente da 3.000 metri.

Il risultato finale è stato:

Riscaldamento: 600 m
Esercizi: 400 m
Attivazione: 400 m
Lavoro: 1.200 m
Defaticamento: 400 m

Totale:

3.000 m.

Questa volta anche secondo la matematica.

Può sembrare una banalità, ma è un esempio molto concreto di un principio importante quando costruiamo sistemi AI: non basta fornire informazioni al modello. Dobbiamo anche definire le regole con cui deve utilizzarle.

Ma….  mancava ancora metà della storia.

Nel prossimo articolo vedremo cosa serve

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.