Dall’analisi video agli allenamenti strutturati

L’ultimo passaggio è stato il più divertente.

Ho caricato un video di una mia nuotata in piscina, con riprese dalla superficie e sott’acqua frontali.

Claude non guarda il video in movimento come faremmo noi, ma ne ha estratto i fotogrammi e li ha analizzati uno per uno.

Il responso è stato onesto e utile.

Tra le cose positive: recupero del braccio con gomito alto e ritmo regolare.

Da migliorare:

  • una trazione spesso a braccio teso, che spinge l’acqua verso il fondo invece che indietro;
  • braccia che in allungo escono dalla linea delle spalle, probabilmente durante la respirazione;
  • molta aria all’entrata della mano;
  • la testa a tratti un po’ alta.

Claude ha anche indicato con chiarezza i limiti dell’analisi: risoluzione bassa e nessuna ripresa laterale, quindi niente giudizio sulla gambata.

Il tutto è finito in un documento Word con i fotogrammi commentati.

Poi siamo passati alla programmazione della settimana:

Scarico il lunedì, soglia il venerdì, aerobico lungo la domenica.

Ogni seduta include esercizi mirati ai difetti emersi dal video, come il remate, il nuoto a pugni chiusi, il braccio singolo e il catch-up con entrata sulla linea della spalla.

Le andature sono calcolate sul mio passo di soglia, circa 1:58 ogni 100 metri.

La parte che mi è piaciuta di più è stata la discussione.

Ho chiesto più volume: 2.000, 2.500 e 2.800 metri.

Poi ho chiesto perché alcune ripetute fossero in zona B2 e non B1.

Claude mi ha spiegato il ragionamento, cioè attivazione prima della serie centrale e richiamo di velocità a fine seduta, ma mi ha anche detto che B1 era una scelta altrettanto valida e più prudente.

Abbiamo cambiato, e alla fine ho avuto tre documenti Word, uno per seduta, da stampare e portare a bordo vasca.

Non è un sostituto di un allenatore in carne e ossa che ti guarda dal bordo, ma come strumento per ragionare sui propri dati e tenere il filo della programmazione funziona davvero bene.

Claude legge i miei allenamenti

Con il server MCP attivo, il collegamento tra Claude e intervals.icu è diventato reale.

Ho creato un Progetto su Claude dedicato al nuoto, che ho chiamato “AI-nuoto”, e ci ho caricato come riferimento lo storico delle mie sedute esportato da Final Surge, con la mia struttura abituale: sedute A, B e C e zone di intensità da A1 a C3.

La prova del nove è stata la domanda più semplice: “vedi i miei allenamenti?”.

Claude ha interrogato intervals.icu e in pochi secondi mi ha restituito il riepilogo delle ultime due settimane: le nuotate in piscina con il passo medio su 100 metri, le uscite in acque libere, le camminate, lo yoga, e l’andamento di fitness e fatica.

La cosa interessante non è tanto l’elenco, che vedo anche su intervals.icu, quanto la lettura.

Claude ha notato per esempio che in una sessione in mare avevo tenuto lo stesso passo della piscina, un buon segnale visto che in acque libere non ci sono virate e spinte dal muro.

Ha anche calcolato che il carico era moderato e che la mia forma era leggermente positiva, cioè ero riposato.

Da qui in poi i dati non sono più solo numeri da guardare: diventano la base per ragionare sulla programmazione.

Creare un server MCP per intervals.icu

Avere i dati su intervals.icu è utile, ma volevo fare un passo in più.

Poterli discutere con Claude, l’assistente di intelligenza artificiale di Anthropic, come farei con un allenatore.

Il problema è che un assistente AI, da solo, non ha accesso ai miei dati.

Qui entra in gioco MCP.

MCP, cioè Model Context Protocol, è uno standard aperto che permette di collegare un assistente AI a strumenti e servizi esterni. Un “server MCP” è un piccolo programma che fa da ponte.

Da un lato parla con il servizio (in questo caso intervals.icu), dall’altro espone a Claude una serie di strumenti, come “leggi le attività”, “leggi i dati di benessere” o “aggiungi un evento al calendario”.

Per intervals.icu esiste un server MCP open source.

La configurazione ha richiesto questi passaggi:

  1. Installare i requisiti sul computer [Python e il gestore di pacchetti indicato nella documentazione del progetto].
  2. Scaricare il progetto e creare un file di configurazione con due dati: la chiave API personale, che si genera nelle impostazioni per sviluppatori di intervals.icu, e l’ID atleta.
  3. Registrare il server nella configurazione di Claude Desktop, così che Claude lo avvii e lo possa usare.

Un’avvertenza: la chiave API dà accesso ai propri dati, quindi va trattata come una password e non va mai condivisa o pubblicata.

Garmin e intervals.icu: far parlare l’orologio con la piattaforma di analisi

Da qualche tempo registro tutto con il mio Garmin fenix 7

Nuoto in piscina, acque libere, bici, camminate e perfino le sessioni di yoga.

Garmin Connect è comodo per avere un colpo d’occhio, ma quando si vuole capire davvero come sta andando l’allenamento serve qualcosa di più.

Per questo ho scelto intervals.icu, una piattaforma di analisi molto apprezzata da ciclisti, triatleti e nuotatori, che calcola carico di allenamento, fitness, fatica e forma nel tempo.

Il collegamento è semplice.

Dalle impostazioni di intervals.icu si apre la sezione delle connessioni, si sceglie Garmin Connect e si autorizza l’accesso con le proprie credenziali Garmin.

Da quel momento ogni attività registrata con l’orologio arriva automaticamente su intervals.icu pochi minuti dopo la sincronizzazione con il telefono. Vengono inoltre importati i dati di benessere, come frequenza a riposo, sonno e peso.

Il vantaggio è immediato.

Per ogni nuotata intervals.icu mostra distanza, passo, frequenza cardiaca, carico e il suo contributo alla curva di fitness.

Guardando le ultime settimane posso capire se sto accumulando fatica o se sono fresco, e tutto senza inserire un solo dato a mano.

Questo è il primo mattone. Nel prossimo articolo racconto come ho dato a un’intelligenza artificiale la possibilità di leggere questi dati.

Notate che in questa modalità non serve utilizzare strava.

Se i dati diventano la memoria dell’AI, chi protegge la memoria?

Dopo aver collegato un agente AI ai miei dati, la domanda successiva è inevitabile: chi sa quali dati sta usando, dove si trovano e se dovrebbero essere accessibili?

Nel precedente articolo sono arrivato a una conclusione apparentemente semplice:

il vero valore di un agente AI non è soltanto nel modello, ma nei dati e nel contesto che gli mettiamo a disposizione.

Nel mio piccolo progetto AI-nuoto il rischio è relativamente limitato. Ho una Knowledge con gli allenamenti, un profilo atleta e un collegamento a Strava.

Ma proviamo a spostare lo stesso concetto in un’azienda.

Improvvisamente non stiamo più parlando di vasche, CSS e chilometri.

Stiamo parlando di documenti, database, email, contratti, informazioni personali, proprietà intellettuale e dati regolamentati.

E la domanda cambia completamente.

Se un agente AI può accedere ai dati aziendali, siamo sicuri di sapere a quali dati sta accedendo?

Prima di proteggere un dato bisogna sapere che esiste e qui emerge uno dei problemi che considero più interessanti nell’adozione dell’AI.

Un’organizzazione può avere petabyte di informazioni distribuite tra cloud, SaaS, file server, object storage e database.

Prima ancora di parlare di AI dobbiamo essere in grado di rispondere ad alcune domande:

  • Dove sono i miei dati?
  • Quali sono sensibili?
  • Chi può accedervi?
  • Quali vengono utilizzati dall’AI?
  • Esistono copie che non dovrebbero essere accessibili?

È qui che entra in gioco il concetto di Data Security Posture Management e, più in generale, di governance dei dati.

Ed è qui che diventa interessante Securiti AI.

Dalla Data Protection alla Data Intelligence

Securiti AI lavora proprio sul problema della conoscenza e della governance dei dati: scoperta, classificazione, privacy, accesso e controllo delle informazioni.

Il concetto che trovo particolarmente interessante è semplice:

non posso proteggere correttamente ciò che non conosco.

E con l’AI questo principio diventa ancora più importante.

Perché ora non sono soltanto gli utenti e le applicazioni tradizionali ad accedere ai dati.

Abbiamo LLM, RAG, copiloti e agenti che utilizzano quelle informazioni per costruire risposte e prendere decisioni.

La superficie da governare cambia!

Discover → Understand → Govern → Protect → Recover

Il percorso che vedo è questo:

  • DISCOVER
    Sapere quali dati possediamo e dove si trovano.
  • UNDERSTAND
    Comprenderne contenuto, sensibilità e relazioni.
  • GOVERN
    Definire chi e cosa può utilizzarli, compresi sistemi AI e agenti.
  • PROTECT
    Proteggerli da perdita, compromissione e accessi non autorizzati.
  • RECOVER
    Essere in grado di ripristinarli quando qualcosa va storto.

Ed è proprio nell’ultimo passaggio che Data Security e Data Resilience si incontrano.

Perché conoscere perfettamente i propri dati non basta se, dopo un ransomware o un errore, non siamo in grado di recuperarli.

Allo stesso modo, avere un backup perfetto non risolve tutto se non sappiamo quali dati stiamo proteggendo e quanto sono importanti.

L’AI ha bisogno di dati.

I dati hanno bisogno di governance.

Il mio piccolo AI-nuoto mi ha insegnato qualcosa di molto semplice.

Più dati fornisco all’agente, più le sue risposte possono diventare contestualizzate.

Ma aumentando l’accesso ai dati aumenta anche la responsabilità di sapere cosa gli sto permettendo di vedere.

In azienda questo diventa un problema di:

Governance. Security. Privacy. Identity. Data Protection. Resilience.

E probabilmente il futuro della Data Protection non sarà soltanto:

“Posso recuperare questo dato?”

ma anche:

“So che questo dato esiste, so cosa contiene, so chi lo utilizza, so quale AI può accedervi e, se viene compromesso, quanto velocemente posso renderlo nuovamente disponibile?”

A quel punto entrano inevitabilmente in gioco anche RPO e RTO.

Ed è qui che la conversazione sull’AI smette di essere soltanto una conversazione sui modelli.

Diventa una conversazione sui dati e soprattutto, sulla loro resilienza.

Non voglio un’AI che mi scriva allenamenti. Voglio un’AI che capisca come mi sto allenando

Dal semplice generatore di schede a un coach digitale che utilizza storico, dati reali e contesto prima di suggerire cosa fare

Dopo aver costruito AI-nuoto e averlo collegato ai miei allenamenti reali attraverso Strava, mi sono posto una domanda.

Che cosa ho costruito realmente?

  • Un sistema capace di generare allenamenti?
  • Sì, ma questa è probabilmente la parte meno interessante.
  • Oggi posso aprire qualsiasi AI generativa e scrivere:
  • “Preparami un allenamento di nuoto da 3.000 metri per migliorare la capacità aerobica.”

In pochi secondi otterrò una scheda apparentemente credibile.

Ma quella scheda potrebbe essere adatta a me, a un altro nuotatore o praticamente a chiunque.

Il problema non è quindi generare un allenamento, il problema è generare l’allenamento giusto in quel momento.

Prima di decidere bisogna conoscere!

Un allenatore, prima di assegnare una seduta, dispone di informazioni.

Conosce l’atleta, sa cosa ha fatto nei giorni precedenti, conosce gli obiettivi e sa se si sta avvicinando una gara.

Un LLM utilizzato senza contesto non possiede nulla di tutto questo.

È qui che il progetto AI-nuoto ha iniziato ad assumere per me un significato differente.

Il sistema dispone ora di tre elementi.

  1. La storia: più di 200 allenamenti provenienti da Final Surge costituiscono la sua Knowledge.
  2. L’atleta: un profilo contiene riferimenti prestativi, CSS, obiettivi e caratteristiche dell’allenamento.
  3. La realtà: attraverso Strava può verificare gli allenamenti effettivamente eseguiti.

A questo punto la domanda può cambiare completamente.

Non più: “Fammi 3.000 metri.”

Ma: “Considerando quello che avrei dovuto fare, quello che ho realmente fatto e la mia progressione recente, cosa avrebbe senso fare domani?”

Questa è la domanda che mi interessa !

Planned e Completed raccontano due storie diverse

Durante la costruzione di AI-nuoto è emerso un concetto apparentemente banale ma fondamentale:

PLANNED ≠ COMPLETED

Il programma racconta ciò che avrebbe dovuto succedere, il dispositivo racconta ciò che è successo realmente.

Se Final Surge prevede 3.000 metri ma su Strava non esiste alcuna attività, AI-nuoto non deve concludere che io abbia nuotato 3.000 metri.

Se erano previsti 2.800 metri e Garmin ne registra 3.200, anche questa differenza è informazione.

E se negli ultimi giorni ho accumulato più volume del previsto, la seduta successiva potrebbe meritare una valutazione diversa.

È qui che il dato smette di essere semplicemente un numero.

Diventa contesto.

Dal dato alla decisione

L’architettura che si è creata può essere riassunta in quattro parole:

DATA → KNOWLEDGE → CONTEXT → DECISION

  • Data è il dato grezzo: metri, durata, frequenza cardiaca, data dell’attività.
  • Knowledge è la storia: allenamenti, struttura delle sedute, progressioni, esercizi.
  • Context è la situazione attuale: cosa ho fatto recentemente, quale obiettivo sto perseguendo, quanto manca alla prossima gara.
  • Decision è ciò che viene dopo.

Ed è proprio quest’ultimo passaggio quello più delicato.

Perché un’AI può avere accesso a migliaia di dati senza necessariamente prendere una buona decisione.

La qualità non dipende soltanto dalla quantità di informazioni disponibili, ma dalla capacità di metterle in relazione.

Un esempio concreto

Immaginiamo che nel calendario sia prevista una Seduta A da 3.000 metri; AI-nuoto potrebbe limitarsi a recuperarla dalla Knowledge, ma ora può fare qualcosa in più.

  • Può verificare su Strava se l’allenamento precedente è stato realmente effettuato.
  • Può confrontare distanza programmata e distanza eseguita.
  • Può guardare la progressione delle ultime Sedute A.
  • Può considerare i miei riferimenti prestativi.

E solo successivamente proporre una nuova seduta.

Il risultato finale può essere ancora un banalissimo:

Seduta A – 3.000 m

Ma ciò che cambia completamente è il processo che ha portato a quei 3.000 metri.

Ed è proprio questo che distingue, secondo me, un generatore da un agente.

Il ruolo dell’essere umano non scompare

C’è però un punto sul quale non vorrei creare equivoci.

Non penso che un progetto del genere elimini il ruolo dell’allenatore.

Al contrario, un coach vede cose che i dati spesso non raccontano.

Può osservare la tecnica, conoscere lo stato mentale dell’atleta, capire quando una giornata semplicemente non gira.

Anche il più sofisticato sistema di raccolta dati può sapere che ho completato 3.000 metri.

Non necessariamente sa come mi sono sentito mentre li facevo.

Ed ecco un altro pezzo interessante del progetto.

Il dato quantitativo deve incontrare quello qualitativo.

Dopo un allenamento potrei semplicemente dire ad AI-nuoto:

“Allenamento completato. Buone sensazioni fino ai 2.000 metri, poi ho iniziato a perdere qualità nella presa. Fatica 7/10.”

Poche parole.

Ma quelle poche parole possono dare un significato completamente diverso ai numeri registrati dall’orologio.

Il prossimo livello (capire cosa succede dentro l’allenamento)

Per ora ho volutamente mantenuto l’integrazione semplice; AI-nuoto recupera le attività da Strava e può confrontare programmato ed eseguito.

Ma esiste un livello successivo.

Gli stream permettono di analizzare l’andamento dei dati durante l’attività: tempo, distanza, frequenza cardiaca e altre informazioni disponibili.

A quel punto le domande potrebbero diventare:

  • La frequenza cardiaca è rimasta stabile?
  • Quando è iniziato il calo?
  • L’ultima parte è stata più impegnativa della prima?

Nel nuoto esiste però un’ulteriore difficoltà: Garmin possiede informazioni molto specifiche — vasche, bracciate, SWOLF, ripetute — che non necessariamente vengono esposte integralmente attraverso Strava.

Probabilmente sarà una delle prossime cose da esplorare.

Del resto sono un nerd in ferie 🙂

Qualcosa dovrò pur fare.

Un piccolo Digital Twin sportivo?

Spingendo un po’ più avanti il ragionamento, quello che sto costruendo assomiglia vagamente a un piccolo Digital Twin dell’atleta.

Non nel significato industriale rigoroso del termine, naturalmente.

Ma il concetto è interessante.

Esiste una rappresentazione digitale che conosce parte della mia storia sportiva, alcuni parametri prestativi, gli allenamenti programmati e quelli realmente eseguiti.

E questa rappresentazione viene aggiornata progressivamente.

Ogni nuovo allenamento aggiunge informazione, ogni nuovo test modifica i riferimenti, ogni gara aggiunge un nuovo punto alla storia.

L’AI non deve quindi “ricominciare da zero” ogni volta che le faccio una domanda. Ha una memoria sulla quale ragionare.

Ed è qui che l’AI diventa interessante

La cosa che più mi affascina di questo piccolo progetto non riguarda, in realtà, il nuoto.

Riguarda il modo in cui utilizzeremo l’intelligenza artificiale.

La prima fase dell’AI generativa è stata dominata dal prompt:

io chiedo → AI risponde.

La fase successiva potrebbe essere molto più interessante:

io chiedo → AI recupera il contesto → consulta i dati → utilizza la memoria → ragiona → risponde.

Il valore si sposta dal semplice modello alla combinazione tra modello, dati e contesto.

Nel mio caso tutto questo serve a decidere se domani devo fare 2.800 o 3.000 metri.

Non cambierò il mondo.

Ma probabilmente entrerò in piscina con un allenamento un po’ più ragionato.

E, per un appassionato di nuoto in acque libere e tecnologia, è già un ottimo risultato.