LaCulturaDelDato #198

Dati & algoritmi attraverso i nostri 5 sensi

For my English speaking friends, click here for the translated version

Ciao,

sono Stefano Gatti e questo è il centonovantottesimo numero della newsletter LaCulturaDelDato: dati & algoritmi attraverso i nostri 5 sensi. Le regole che ci siamo dati per questo viaggio le puoi trovare qui.

Ecco i cinque spunti del centonovantottesimo numero:

👃Investimenti in ambito dati e algoritmi. Start-up del mese Novembre 2025: Parallel.ai

Anche questo mese… la bolla dell’AI scoppia il prossimo mese 🙂.

Umorismo a parte, anche il solito puntuale e preciso report mensile di Crunchbase segnala un novembre con quasi 40 miliardi di dollari investiti nel VC mondiale, con numeri importanti sul late stage e con una dominanza statunitense sempre più marcata: quasi il 70% dell’intero investito. I valori si mantengono superiori rispetto alla media post-Covid. Anche nel mio personale database vedo una stabilità mese su mese in termini di volumi, con un numero di deal leggermente inferiore.

La startup del mese è Parallel.ai.
Parallel è una delle nuove infrastrutture chiave dell’era “agentica”: non è un altro chatbot, ma il livello che permette alle AI di usare il web come un vero sistema distribuito, leggendo, filtrando e strutturando informazioni in tempo quasi reale. Dietro c’è Parallel Web Systems, fondata nel 2023 a Palo Alto da Parag Agrawal, ex CEO di Twitter, che dopo l’uscita burrascosa dal social ha passato mesi a studiare paper prima di costruire il primo team di circa 25 persone. Oggi la società ha raccolto prima 30 milioni di dollari nel 2024 da Khosla Ventures, First Round, Index e altri fondi, poi un round Series A da 100 milioni a novembre 2025, guidato da Kleiner Perkins e Index, per una valutazione di 740 milioni.

Parallel non fa un motore di ricerca “per umani”, ma API di ricerca pensate per agenti AI: Search, Task, Extract, FindAll, Monitor, Chat. Queste API permettono di chiedere “dammi la mappa del mercato dei semiconduttori” o “estrai e confronta tutte le clausole di non competition di queste aziende” e ottenere direttamente un dataset strutturato, non una pagina di link. Nei benchmark indipendenti di deep web research, come BrowseComp di OpenAI e DeepResearch Bench, il loro motore Ultra8x supera sia i migliori modelli generalisti (compreso GPT-5) sia i punteggi umani su compiti complessi, e oggi alimenta già milioni di task di ricerca quotidiani per startup e grandi aziende.

Il nuovo round da 100 milioni serve a tre cose: scalare l’infrastruttura, espandere la base clienti enterprise e negoziare accordi economici con i detentori di contenuti online. Parallel vuole essere “il web per il secondo utente”, dove il secondo utente sono le AI, e sta lavorando a un meccanismo di mercato che incentivi editori e piattaforme a lasciare i contenuti accessibili agli agenti, invece di chiuderli dietro paywall o blocchi anti-scraping, preservando allo stesso tempo diritti e monetizzazione di chi produce informazione. È una posizione delicata, perché si colloca esattamente nel punto di frizione tra l’esigenza delle AI di vedere il web e l’esigenza dei publisher di non regalare il proprio patrimonio informativo.

Ci sono almeno quattro motivi per cui dovresti seguire l’evoluzione dell’azienda o valutarne l’uso, se stai facendo progettazione di servizi che usano l’AI in azienda:
Il primo è architetturale: se stai progettando piattaforme di AI interna, RAG o agenti multi-step, il “web layer” diventa un componente esplicito, con requisiti di qualità, latenza, explainability e compliance, non un accessorio del modello.
Il secondo è di governance: chi controlla il layer che decide quali fonti vedere, come valutarle, come attribuire le citazioni, diventa un nuovo gatekeeper dell’accesso ai dati pubblici.
Il terzo è competitivo: chi integra presto infrastrutture di questo tipo può costruire agenti che non solo rispondono, ma monitorano, sorvegliano, scattano in automatico quando qualcosa cambia nel contesto esterno.
Infine, per chi lavora in data engineering e data science, Parallel è un promemoria concreto che il lavoro sui dati non finirà con i database aziendali: dovremo progettare anche “pipeline dal web agli agenti”, con la stessa cura con cui ieri e oggi abbiamo costruito lakehouse.

🖐️Tecnologia (data engineering). MCP e A2A: i protocolli che stanno ridisegnando l’architettura degli agenti

Mentre tutti parlano di “AI agentica” come se fosse una cosa scontata, pochi si stanno rendendo conto che, dietro gli agenti che funzionano davvero, ci sono due protocolli infrastrutturali che stanno emergendo come standard de facto: MCP (Model Context Protocol) proposto da Anthropic e A2A (Agent-to-Agent) proposto da Google.
MCP, lanciato a novembre 2024, risolve un problema fondamentale: come connettere in modo standardizzato i modelli linguistici a tool esterni, database, API e sistemi enterprise, senza dover riscrivere integrazioni custom per ogni caso d’uso. Viene spesso descritto come una porta USB-C per le applicazioni di AI, perché definisce un modo unico per scambiare richieste e risultati con qualsiasi sorgente esterna.
A2A, annunciato a metà 2025, affronta invece il tema della comunicazione tra agenti diversi, definendo come scoprire quali agenti esistono, quali capacità offrono, come affidare loro un task e come ricevere lo stato di avanzamento.
MCP standardizza l’accesso a strumenti e sorgenti dati: “come un agente chiede un report al CRM, legge un file o chiama un’API esterna”. A2A standardizza la collaborazione: “come un agente di customer care passa il caso a un agente analitico, che a sua volta coinvolge un agente di fatturazione, ciascuno con i propri strumenti e regole interne”. In molte architetture emergenti, un agente riceve la richiesta dell’utente, usa MCP per accedere a dati e applicazioni enterprise e poi usa A2A per delegare parti del lavoro ad altri agenti specializzati, magari appartenenti ad altre business unit o addirittura ad altre aziende.

La sinergia è evidente: MCP dà agli agenti “le mani” per interagire col mondo, A2A dà loro “la voce” per collaborare.
Non sto dicendo che questi protocolli siano già maturi o universalmente adottati. Sono ancora in fase sperimentale, con implementazioni parziali e casi d’uso limitati. Ma la direzione è chiara: verso un’architettura modulare in cui agenti specializzati comunicano via protocolli standard, esattamente come è accaduto con HTTP per il web.
Se vuoi capire davvero come funzionano e come implementarli, ti consiglio questo ottimo corso pratico su YouTube che sto seguendo e che sto trovando molto utile per entrare nel dettaglio operativo. Anche solo le prime due lezioni (meno di 30 minuti in tutto) ti forniscono le informazioni basilari per capire questi nuovi pattern architetturali.

Oggi parliamo ancora di API REST e webhook quando immaginiamo l’integrazione tra sistemi. Domani potrebbe essere normale esporre non solo endpoint, ma interi agenti aziendali accessibili via A2A, che a loro volta useranno MCP per parlare con dati e applicazioni interne. È plausibile che MCP e A2A diventino lo strato di interoperabilità sopra le API tradizionali: le API resteranno il modo in cui i sistemi espongono funzionalità, mentre i protocolli per agenti definiranno come orchestrare quelle funzionalità in flussi complessi, con più autonomia e più contesto.
Resta da vedere se vincerà un unico standard o se avremo, come sul web, un piccolo numero di protocolli dominanti, con gateway e bridge tra loro. Ma chi inizia oggi a progettare agenti, pensando già in termini di MCP e A2A, si sta abituando a ragionare non più per singola integrazione punto-punto, bensì per “tessuto connettivo” fra agenti, strumenti e organizzazioni. E questo, per la prossima generazione di applicazioni AI, potrebbe fare la differenza.

👂🏾Organizzazione e cultura dei dati e algoritmi nelle organizzazioni. Scrivere la strategia (sul serio): qualche consiglio di Will Larson

back to 77

In qualunque tipo di organizzazione tu lavori, se hai un ruolo di leadership, sicuramente ti sarà capitato almeno una volta nella vita che ti abbiano chiesto, o che tu abbia ritenuto opportuno, di definire una strategia in forma scritta su una determinata tematica. Sottolineo bene l’aggettivo «scritta» perché di strategie raccontate oralmente in meeting, soprattutto esterni e marketing driven, è pieno il mondo… ma quando si tratta di mettere nero su bianco e divulgarla, a tutti i livelli, all’interno della propria organizzazione… ecco, tutto diventa più difficile.

È forse per questo 🙂 che vi era piaciuto molto, più di tutti gli altri approfondimenti, nella newsletter 77, questo lungo articolo di uno dei miei autori preferiti di saggistica organizzativa tech, Will Larson, “Writing an engineering strategy”.
Ti confesso di averlo riletto almeno due volte dopo avertelo condiviso tre anni fa e ho trovato molto utili anche altri articoli che Larson pubblica periodicamente, insieme ad alcuni suoi libri decisamente interessanti.
In quel post di tre anni fa avevo commentato alcuni passaggi dell’articolo che mi erano piaciuti. Oggi ti condivido e traduco la definizione di strategia che Larson, derivandola da un altro esperto sul tema, Richard Rummelt, racconta nella prima parte dell’articolo. La trovo una delle migliori definizioni di cosa sia una buona strategia:

“Una strategia è composta da tre parti:
Diagnosi: una teoria che descrive la natura della sfida. Serve a identificare le cause radice in gioco; per esempio, «un elevato work in progress ci impedisce di completare i task, quindi a ogni sprint restiamo sempre più indietro» può essere una buona diagnosi.
Linee guida (guiding policies): gli approcci che adotterai per affrontare la sfida. In genere le linee guida corrispondono a compromessi, espliciti o impliciti. Per esempio, una linea guida potrebbe essere: «assumere solo per il team con l’urgenza maggiore, senza distribuire le nuove assunzioni su tutti i team». Se una linea guida non implica alcun compromesso, dovresti guardarla con sospetto (per esempio, «lavorare più duramente per riuscirci» non è davvero una linea guida).
Azioni coerenti: un insieme di azioni specifiche, orientate dalle linee guida, per affrontare la sfida. È la parte più importante, e anche la più interessante, perché chiarisce che una strategia ha senso solo se porta a un’azione allineata.”

E l’articolo contiene tanti altri spunti e suggerimenti utili. Buona lettura!

👀 Data Science. Dentro la “magia” del formato parquet: il formato ibrido spiegato bene e “praticamente”

Se sei un data scientist o hai maneggiato grossi moli di dati, ti sarà stato raccomandato da qualche machine learning engineer o data engineer di usare il formato dati parquet. E, effettivamente, nella maggior parte dei casi hai subìto, come me, il fascino e i vantaggi di questo consiglio senza capire fino in fondo il perché di questa magia.

La magia è svanita, nel mio caso, quando mi sono imbattuto (via Giuseppe Sollazzo) in questo bellissimo articolo del senior data engineer di Spotify, Kirill Bobrov, scritto con la collaborazione di un altro data engineer molto nerd, Vu Trinh. L’articolo spiega molto bene come il file Parquet sia un formato ibrido che utilizza il meglio dei due sistemi di memorizzazione dati più usati, cioè il classico riga per riga e il colonnare. E lo fa spiegandoti, passo passo, come i dati sono scritti in Parquet e come sono letti. Ti lascio qui una splendida immagine in cui spiegano il processo di scrittura in modo minuzioso, gradevole e visuale.

Ma nell’articolo gli autori ti forniscono tutte le informazioni utili per usare questo formato al meglio e capire quei rari casi in cui è meglio non usarlo. Per farti un esempio concreto, entrano nel dettaglio e ti suggeriscono, a seconda dei casi d’uso e della tipologia di dati, il tipo di metodologia di compressione dei dati da usare per essere più efficiente. Meraviglioso!

Se sei appassionato alle tematiche dell’uso e del trattamento dei dati al meglio, Kirill Bobrov e Vu Trinh vanno assolutamente seguiti, anche per la gradevolezza con cui riescono a scrivere di concetti complessi.

E a proposito di cose nerd, se sei un amante dell’ecosistema Python non puoi perderti i quasi 90 minuti di questo documentario su YouTube: “The Story of Python and how it took over the world | Python: The Documentary”. Oltre a sentire il racconto dalla voce del benevolo dittatore a vita potrai conoscere altri protagonisti di questa lunga storia :-)

👅Etica & regolamentazione & impatto sulla società. L’IA a scuola e all’università non è un “problema tecnico” … è un problema “debole”.

Quando parliamo di intelligenza artificiale nel settore educativo, spesso ci comportiamo come se fosse un problema tecnico: mancano le linee guida, servono strumenti migliori, manca la formazione, bisogna aggiornare i regolamenti. In realtà siamo davanti a quello che molti studiosi chiamano “problema debole” o , in inglese, “wicked problem”. Il termine viene dall’ingegneria sociale e indica problemi che non hanno formulazione univoca, non hanno un criterio di successo chiaro, non ammettono soluzioni vere o false ma solo migliori o peggiori, e sono unici: ciò che funziona in un contesto può fallire in un altro. Esempi classici: povertà, cambiamento climatico. Non esiste “la” soluzione, esistono compromessi e adattamenti continui. L’uso dell’IA in educazione rientra esattamente in questa categoria. Per alcuni il problema è prevenire che gli studenti imbroglino. Per altri è sfruttare i tutor IA per personalizzare l’apprendimento. Per i policy maker conta la scalabilità dei sistemi. Per i docenti pesano tempo, valutazione, responsabilità. Ogni scelta su come usare l’IA in aula ha effetti su equità, motivazione, ruoli, competenze future degli studenti.

L’approfondimento che ti consiglio oggi è un articolo recente di Nick Potkalitsky che descrive benissimo questa complessità parlando del “wicked problem of AI in education” e di come l’AI costringa scuola e università a ripensare le proprie fondamenta, non solo a “integrare un nuovo tool”. Lo fa commentando uno studio condotto da quattro ricercatori australiani su questo tema, anch’esso molto interessante e decisamente lungo, ma che nella sua parte finale sintetizza molto bene il miglior approccio da tenere in questa fase: “Le università che continuano a cercare l’inafferrabile “risposta giusta” all’uso della AI esauriranno i loro docenti e deluderanno i loro studenti. Quelle che accettano la natura complessa di questo problema possono costruire culture che supportano un giudizio professionale ponderato piuttosto che punire soluzioni imperfette.”

Se accettiamo che sia un problema debole, la domanda non diventa “AI sì o no in classe”, ma “quale uso vogliamo esplorare, con quali vincoli, con quali valori non negoziabili”. Questo sposta il focus da soluzioni standard a percorsi di sperimentazione consapevole. Piccoli piloti, ben progettati e misurati, contano più delle grandi strategie dichiarate a tavolino. Dal mio punto di vista, come docente di un corso sul decision making (con l’uso di dati) all’Università Cattolica, vorrei proprio muovermi in questa direzione. Sarà una sfida non semplice ma, come tutte le sfide dei problemi deboli, molto affascinante e più simile a un viaggio senza traguardo finale ma con infiniti traguardi “volanti”, per usare una metafora sportiva.

Se hai ulteriori suggerimenti e riflessioni sui temi di questo numero o per migliorare questa newsletter scrivimi (st.gatti@gmail.com) o commenta su substack.

Se ti è piaciuta e non sei ancora iscritto lascia la tua mail qui sotto e aiutami a diffonderla!

Alla prossima!