Automatizzare le news AI con n8n: da fonti sparse a un flusso editoriale controllato

Restare aggiornati sull'intelligenza artificiale sembra semplice solo in teoria. Ogni giorno escono nuovi modelli, paper, release note, benchmark, framework, annunci di prodotto, dataset, demo e discussioni tecniche. Il problema non e' trovare informazioni: il problema e' non affogare nel rumore.

Per questo, nel progetto contenuti di SynapseSoftware.cloud, ho sviluppato la prima parte del workflow n8n AI News Daily Curation. L'obiettivo non e' pubblicare automaticamente qualsiasi cosa venga trovata online, ma creare un flusso editoriale controllato, capace di raccogliere segnali da fonti diverse, normalizzarli, prepararli come bozze e mantenerli in revisione prima della pubblicazione.

Mi interessa molto questo progetto perche' unisce diverse aree che considero centrali nel mio percorso: automazione, data pipeline, integrazione API, backend, qualita' dei dati, revisione umana e pubblicazione su un CMS reale.

Il problema: troppe fonti, poco contesto

Le notizie sull'AI arrivano da canali molto diversi. Alcune sono release ufficiali, altre sono paper accademici, altre ancora sono articoli giornalistici, changelog di prodotto o aggiornamenti pubblicati dagli stessi laboratori di ricerca.

Una singola fonte non basta. Se guardo solo un sito, rischio di vedere una parte troppo stretta del panorama. Se guardo tutto manualmente, invece, il processo diventa dispersivo e poco ripetibile. Il punto non e' sostituire la lettura, ma costruire un sistema che aiuti a scegliere cosa leggere, cosa salvare e cosa trasformare in contenuto.

Il workflow e' nato da questa esigenza concreta: raccogliere aggiornamenti da piu' sorgenti, dare una struttura comune ai dati e creare un passaggio ordinato verso la sezione news del sito. Nella prima versione ho lavorato soprattutto sulla pipeline minima: lettura della fonte, normalizzazione, filtro dei contenuti recenti o importanti, classificazione, sintesi editoriale e preparazione del payload per il backend.

Le fonti del workflow

Il flusso non nasce per dipendere da una sola fonte. La prima versione e' stata sviluppata partendo da OpenAI News come ramo di test, per validare campi, normalizzazione, deduplica e passaggi AI su pochi item. Da quella base l'idea e' integrare progressivamente canali diversi, ognuno con un ruolo specifico.

Tra le fonti considerate ci sono OpenAI e le OpenAI Release Notes, utili per seguire modelli, API, funzionalita' e cambiamenti di piattaforma. A queste si aggiungono Google e DeepMind, arXiv per AI, machine learning e NLP, Hugging Face Hub per modelli e dataset, Papers with Code per collegare paper, codice e benchmark, TechCrunch AI e VentureBeat AI per il contesto piu' giornalistico e di mercato.

Nel percorso di evoluzione del workflow sto considerando anche sorgenti come Perplexity Changelog, Anthropic Newsroom, Mistral News, GLM e DeepSeek, per intercettare aggiornamenti dai principali attori che stanno evolvendo rapidamente nel panorama dei modelli generativi.

Questa lista e' volutamente ampia, ma il workflow non deve diventare una macchina che accumula tutto. Una pipeline utile non e' quella che prende piu' dati possibile: e' quella che porta avanti i dati giusti, nel formato giusto, con abbastanza contesto per decidere.

Perche' n8n

Ho scelto n8n perche' e' molto adatto a orchestrare processi composti da passaggi eterogenei: chiamate HTTP, parsing, trasformazioni, filtri, condizioni, notifiche, chiamate API e integrazioni con servizi esterni.

In un workflow come questo, n8n funziona bene come livello di orchestrazione. Non voglio mettere tutta la logica in un unico script monolitico; preferisco separare i passaggi: recupero delle fonti, normalizzazione, deduplica, classificazione, preparazione della bozza e invio al backend.

Il vantaggio e' che ogni nodo del flusso racconta un pezzo del processo. Se una fonte cambia formato, posso intervenire su quel ramo. Se voglio aggiungere un controllo, posso inserirlo in un punto preciso. Se voglio disattivare temporaneamente una sorgente, posso farlo senza riscrivere tutto.

Dal dato grezzo alla bozza

Il primo passaggio del workflow e' raccogliere dati grezzi: titolo, URL, data, fonte, eventuale descrizione, categoria iniziale e metadati disponibili. Ogni sorgente espone informazioni diverse, quindi il lavoro vero e' portare tutto verso una struttura comune.

Una news proveniente da un changelog non ha la stessa forma di un paper arXiv. Un articolo TechCrunch ha un taglio diverso da una release ufficiale di Anthropic o Mistral. Hugging Face Hub puo' indicare modelli, dataset o trend di community. Papers with Code aggiunge il legame tra paper, implementazioni e risultati.

Per questo la normalizzazione e' una parte importante. Nel ramo iniziale ho portato gli item verso una struttura comune con campi come source_name, source_url, title_raw, summary_raw, published_at, feed_type, dedupe_key e flag di validazione. Questo rende il dato piu' semplice da filtrare, classificare e trasformare in contenuto editoriale.

Il risultato ideale non e' una news gia' pubblicata, ma una bozza pulita. Una bozza abbastanza strutturata da essere valutata rapidamente, modificata se necessario e approvata solo quando ha senso per il sito.

Revisione umana prima della pubblicazione

La parte piu' importante del workflow e' proprio questa: il sistema non deve pubblicare in automatico senza controllo. L'automazione serve a ridurre lavoro ripetitivo, non a togliere responsabilita' editoriale.

Nel sito le news possono vivere in stati diversi: pending, published o rejected. Questo e' il punto in cui l'automazione incontra il backend FastAPI e Supabase. Il workflow prepara news con created_by: "n8n" e stato pending; poi l'area admin permette di rivederle, correggerle, approvarle o scartarle.

Questo modello mi piace perche' mantiene un confine chiaro: la macchina raccoglie, organizza e propone; la persona decide. E' un approccio molto piu' sano rispetto alla pubblicazione automatica completa, soprattutto su un tema veloce e delicato come l'intelligenza artificiale.

Architettura del flusso

Il workflow puo' essere letto come una piccola pipeline dati editoriale.

Il primo livello e' l'acquisizione: RSS, endpoint pubblici, changelog, pagine ufficiali e altre fonti leggibili. Il secondo livello e' la trasformazione: parsing, normalizzazione dei campi, pulizia del testo, riconoscimento della fonte, deduplica e filtro dei contenuti meno rilevanti. Il terzo livello e' la parte AI: classificazione della rilevanza e sintesi editoriale in italiano. Il quarto livello e' la preparazione del payload per il sito.

Infine c'e' l'integrazione con il sito. Il backend FastAPI espone gli endpoint per gestire le news, mentre Supabase conserva i record e applica le regole di pubblicazione. La parte pubblica mostra solo contenuti approvati, mentre l'admin vede anche cio' che e' in attesa di revisione. Durante lo sviluppo sono emersi anche problemi molto concreti, come il passaggio dal dominio pubblico protetto da Basic Auth alla rete Docker interna e la configurazione corretta del body JSON nella chiamata POST.

Questa separazione e' importante: n8n non deve diventare il database, il backend non deve diventare il motore di scraping, e il frontend non deve conoscere dettagli interni del processo. Ogni pezzo ha una responsabilita' chiara.

Cosa rende interessante questo progetto

La cosa interessante non e' soltanto "ho collegato n8n a delle fonti". La parte interessante e' costruire un processo che assomiglia a un vero sistema dati: input eterogenei, trasformazione, controllo qualita', stato, persistenza e pubblicazione.

Ogni fonte porta con se' problemi diversi. Alcune sono piu' strutturate, altre meno. Alcune pubblicano aggiornamenti frequenti, altre solo quando c'e' una release importante. Alcune hanno titoli chiari, altre richiedono piu' contesto per capire se valga la pena salvarle.

Questo obbliga a ragionare su temi molto concreti: come evito duplicati? Come riconosco fonti affidabili? Come distinguo una release tecnica da un articolo di commento? Come assegno una categoria? Come mantengo leggibile il flusso quando aggiungo nuove sorgenti?

Sono domande tipiche dei progetti di automazione e data engineering. Anche se il caso d'uso e' un flusso news, sotto ci sono pattern riutilizzabili: ingestion, enrichment, validation, routing, monitoring e human-in-the-loop.

Una pipeline in evoluzione

Il workflow non e' pensato come qualcosa di definitivo gia' dalla prima versione. La prima parte e' stata sviluppata per validare il processo: trigger, ramo OpenAI News, normalizzazione, filtro fresh/important, classificazione con Gemini dopo il blocco quota OpenAI, sintesi editoriale, parsing degli output, merge dei dati, preparazione del payload e login Supabase admin. Da li' preferisco procedere a iterazioni: prima poche fonti affidabili, poi nuove sorgenti, poi controlli migliori, poi eventuali classificazioni piu' intelligenti.

Questo approccio e' piu' realistico. Automatizzare tutto subito spesso produce sistemi fragili. Partire da un flusso semplice, osservarne gli errori e migliorarlo progressivamente permette invece di capire dove serve davvero complessita'.

In futuro potrei aggiungere scoring di rilevanza piu' raffinato, classificazione per tema, rilevamento duplicati piu' robusto, gestione degli errori fonte per fonte, mail di riepilogo per revisione, log piu' dettagliati e una dashboard per osservare quante news vengono raccolte, quante approvate e quante scartate.

Cosa sto imparando

Questo progetto mi sta insegnando una cosa semplice ma importante: una buona automazione non e' quella che elimina ogni passaggio umano, ma quella che porta la persona nel punto giusto del processo.

Se devo cercare manualmente tra dieci fonti ogni giorno, spreco tempo in attivita' ripetitive. Se pubblico tutto automaticamente, perdo controllo. Il punto di equilibrio e' usare n8n per raccogliere e preparare, FastAPI e Supabase per gestire dati e stati, e l'area admin per decidere cosa diventa contenuto pubblico.

In questo senso il workflow news e' perfettamente coerente con il sito: non e' solo una funzionalita' aggiunta, ma un esempio concreto di come penso l'automazione. Sistemi piccoli, leggibili, controllabili, capaci di ridurre rumore e trasformare informazioni sparse in qualcosa di utile.

Conclusione

Automatizzare le news AI non significa inseguire ogni aggiornamento in tempo reale. Significa costruire un processo che aiuti a osservare meglio, filtrare meglio e pubblicare con piu' ordine.

Il workflow n8n e' gia' stato avviato nella sua prima parte ed e' ancora in evoluzione, ma rappresenta bene la direzione che voglio dare a SynapseSoftware.cloud: un sito che non mostra soltanto contenuti, ma che sperimenta processi reali dietro quei contenuti. Una piccola pipeline editoriale, costruita con strumenti pragmatici, attenzione tecnica e revisione umana.