Architettura di un sistema AI per la pubblicazione automatica sui social

Generare un testo con l'intelligenza artificiale è relativamente semplice.

Trasformarlo in un contenuto coerente con l'identità di un'organizzazione, adattarlo ai diversi canali, convertirlo in immagini e video e pubblicarlo senza interventi manuali richiede invece un sistema progettato con attenzione.

Per Fundacja Moje Podl@sie abbiamo sviluppato un'automazione capace di gestire l'intero processo di creazione e distribuzione dei contenuti social: dalla scelta del formato alla generazione delle grafiche, fino alla preparazione dei materiali destinati a LinkedIn, Facebook, Instagram e YouTube.

Lo stack, in breve: Make orchestra il flusso, un modello veloce come Groq genera i testi strutturati, un renderer serverless su Vercel (Satori + resvg-wasm) produce le grafiche e FFmpeg compone i video.

Il cuore del progetto non è un singolo modello AI.

È il software costruito intorno al modello per rendere il risultato utilizzabile, riconoscibile e compatibile con le diverse piattaforme.

La sfida: non bastava generare un post

La fondazione aveva bisogno di comunicare con maggiore continuità senza dover preparare manualmente ogni contenuto.

Il processo tradizionale richiedeva diversi passaggi:

• scegliere l'argomento;
• scrivere il testo;
• decidere se utilizzare un post singolo o un carosello;
• dividere il contenuto nelle varie slide;
• preparare le grafiche;
• adattare i file ai requisiti dei social;
• creare un formato video per YouTube;
• programmare la pubblicazione.

Automatizzare soltanto la scrittura avrebbe risolto una parte limitata del problema.

Un testo, da solo, non è ancora un contenuto pronto per essere pubblicato. Deve avere una struttura adeguata, rispettare l'identità visiva della fondazione e arrivare alle piattaforme nel formato corretto.

Per questo abbiamo sviluppato un renderer serverless su misura: un servizio capace di ricevere il contenuto prodotto dall'AI e trasformarlo in immagini brandizzate pronte per la distribuzione.

Come funziona: la pipeline da Groq a Satori, fino alla pubblicazione

Il processo parte dalla generazione del contenuto.

Il modello linguistico (Groq) analizza l'argomento e restituisce una struttura che comprende titolo, testo, didascalia, hashtag e formato consigliato.

In base alla complessità del tema può scegliere tra:

• un post singolo, adatto a un messaggio breve e immediato;
• un carosello, utile quando il contenuto deve essere suddiviso in più punti.

Questa scelta non viene lasciata alla fase grafica. È già presente nella struttura generata dall'AI e viene interpretata dal software.

L'automazione coordina poi i vari componenti, prepara le immagini, converte i formati necessari e invia i contenuti ai moduli di pubblicazione.

Il risultato è un flusso unico nel quale testo, design e distribuzione vengono gestiti in modo coordinato.

Un'architettura divisa in responsabilità precise

Per evitare che un unico componente dovesse gestire contemporaneamente logica, impaginazione e distribuzione, abbiamo separato il renderer in più endpoint.

Ogni parte del sistema ha una funzione specifica.

Il primo endpoint interpreta il contenuto e costruisce la sequenza delle slide.

Il secondo genera materialmente le immagini.

Un terzo componente utilizza le grafiche prodotte per creare un video destinato a YouTube.

Questa separazione rende il sistema più semplice da controllare e consente di modificare una parte senza dover riscrivere l'intero flusso.

L'output strutturato: dal JSON di Groq alle slide

L'endpoint dedicato alla composizione riceve il JSON generato dal modello (Groq).

Il suo compito è comprendere quale formato è stato scelto e trasformare la risposta in una struttura pronta per essere renderizzata.

Quando il formato richiesto è un carosello, il sistema costruisce:

• una copertina;
• una slide per ciascun punto (in genere dalle 5 alle 7 in totale);
• una slide conclusiva con invito all'azione.

Quando il contenuto non richiede più passaggi, viene generata una singola card.

Il componente prepara anche le informazioni che servono alle piattaforme: titolo, caption, hashtag, testo completo e URL delle immagini nei diversi formati.

Non crea direttamente i file grafici. Costruisce invece gli indirizzi che richiamano il renderer, così ogni URL restituisce già l'immagine corrispondente.

Questo permette all'automazione di passare i file ai canali social senza doverli salvare, rinominare o convertire manualmente.

Gestire gli output imperfetti dell'intelligenza artificiale

Un modello linguistico non restituisce sempre una struttura perfettamente conforme alle specifiche.

Può aggiungere un blocco Markdown, inserire una frase prima del JSON o produrre un carattere in eccesso.

In una dimostrazione questo può sembrare un dettaglio. In un sistema automatico può interrompere l'intero processo.

Per questo abbiamo inserito un parser tollerante, progettato per correggere alcuni degli errori più comuni prima che il contenuto venga elaborato.

Il parser può, ad esempio:

• rimuovere i delimitatori Markdown;
• isolare il JSON dal testo circostante;
• gestire caratteri aggiunti accidentalmente;
• recuperare una struttura valida quando l'output non è perfettamente pulito.

L'obiettivo non è accettare qualsiasi risposta, ma impedire che piccole imprecisioni formali blocchino un flusso altrimenti corretto.

È uno degli aspetti meno visibili del progetto, ma anche uno dei più importanti per il suo funzionamento quotidiano.

Dal testo all'immagine con Satori e resvg-wasm, senza browser

La generazione delle grafiche è affidata a un secondo endpoint.

Il renderer riceve i contenuti della card, li inserisce nel template e restituisce direttamente un'immagine.

Per costruirlo abbiamo scelto un approccio basato su Satori e resvg-wasm.

Satori trasforma il layout in un file SVG. Successivamente, resvg-wasm converte il vettore in un'immagine PNG o JPEG.

Questo significa che il sistema non deve avviare Chromium, utilizzare un browser headless o catturare lo screenshot di una pagina web.

Il rendering avviene direttamente sul server.

Questa scelta riduce il numero di dipendenze necessarie e rende il processo adatto a un ambiente serverless come Vercel.

Il template viene generato inizialmente in formato vettoriale, quindi il testo mantiene una buona nitidezza anche quando l'immagine viene prodotta a una risoluzione più alta.

Un'identità visiva integrata nel codice

Le grafiche non vengono generate partendo da un modello visivo differente ogni volta.

Il design della fondazione è stato trasformato in un sistema di template riutilizzabili.

La combinazione principale utilizza:

• uno sfondo scuro;
• il rosso come colore di accento;
• una tipografia leggibile;
• elementi monospace per rafforzare il carattere tecnologico;
• una struttura coerente tra copertine, punti e call to action.

Ogni tipologia di slide ha una funzione precisa.

La cover introduce l'argomento.

Le slide centrali evidenziano i singoli concetti attraverso numerazione, titolo e testo.

La slide conclusiva chiude il racconto e indirizza l'utente verso l'azione successiva.

Sono state inoltre predisposte più varianti grafiche, così il sistema può mantenere coerenza senza produrre necessariamente una composizione identica per ogni contenuto.

Il design, in questo caso, non viene applicato dopo la generazione. Fa parte dell'architettura del software.

Il problema dei caratteri polacchi

Uno dei dettagli tecnici più delicati ha riguardato i font.

I contenuti della fondazione includono caratteri polacchi come ą, ę, ł, ń e ś.

Non tutti i file di un font contengono l'intero insieme di caratteri. Le versioni destinate all'alfabeto latino di base possono non includere correttamente le estensioni necessarie per il polacco.

Per evitare simboli mancanti o sostituzioni errate, il renderer carica separatamente le varianti latin e latin-ext.

Le due versioni vengono registrate con nomi distinti, così il motore di rendering può utilizzarle entrambe senza trattarle come duplicati.

Abbiamo aggiunto anche un meccanismo di nuovo tentativo per il caricamento dei font dal CDN, riducendo la possibilità che un problema temporaneo della rete produca una grafica incompleta.

È un esempio di come un requisito linguistico possa diventare una decisione architetturale.

Icone vettoriali senza dipendenze esterne

Il sistema comprende una libreria di icone duotone associate a temi come tecnologia, sicurezza, educazione, rete, ambiente e collaborazione.

L'AI può selezionare l'icona più adatta attraverso un campo dedicato.

Le icone sono integrate direttamente nel progetto come SVG inline.

Non è quindi necessario richiamare un servizio esterno o scaricare un file durante il rendering.

Questo riduce le richieste di rete e limita il rischio che una risorsa non disponibile comprometta l'immagine.

L'icona rimane comunque opzionale: quando non è presente, il layout mantiene la propria struttura senza lasciare spazi vuoti o produrre errori.

PNG, JPEG e requisiti differenti

Le piattaforme social non gestiscono sempre i file nello stesso modo.

Per LinkedIn e Facebook il sistema può utilizzare le immagini PNG prodotte dal renderer.

Per Instagram viene generata anche una versione JPEG, necessaria per rispettare i requisiti del relativo flusso di pubblicazione.

Entrambe le versioni derivano dallo stesso template e dallo stesso contenuto. Non è quindi necessario duplicare la composizione o eseguire conversioni esterne.

Il formato viene selezionato tramite un parametro dell'endpoint e l'immagine viene restituita direttamente con il tipo MIME corretto.

Il renderer applica inoltre una cache di 24 ore, evitando di ricostruire inutilmente la stessa grafica quando l'URL viene richiesto più volte.

Dalle slide al video 1080×1080 con FFmpeg

Il progetto comprende anche un endpoint dedicato alla generazione video.

Le card prodotte dal renderer vengono raccolte e trasformate in una sequenza attraverso FFmpeg.

Il sistema unisce le card in un video quadrato 1080×1080, aggiunge una traccia musicale e crea un contenuto pronto per il canale YouTube della fondazione.

In questo modo lo stesso contenuto può essere adattato a un formato differente senza dover ricostruire manualmente il materiale.

Le immagini rimangono la fonte visiva principale, mentre il componente video si occupa della loro composizione temporale e dell'audio.

Questo approccio permette di riutilizzare lo stesso nucleo editoriale su più canali mantenendo una continuità grafica.

Perché un'architettura serverless

Il renderer è stato distribuito su Vercel utilizzando un runtime Node.js e includendo il modulo WebAssembly necessario per la rasterizzazione.

La scelta serverless è coerente con il volume previsto dal progetto.

La fondazione pubblica con una frequenza programmata (un'esecuzione ogni due giorni), quindi non è necessario mantenere un server dedicato costantemente attivo.

Il sistema viene eseguito quando serve e può rimanere inattivo tra una pubblicazione e l'altra.

Un avvio a freddo di alcuni secondi non incide in modo significativo su un processo che opera in background e non richiede una risposta immediata all'utente.

Questa architettura mantiene l'infrastruttura relativamente semplice e adeguata all'utilizzo reale del progetto.

Non sarebbe automaticamente la scelta corretta per qualsiasi applicazione. In un sistema con rendering continuo o richieste in tempo reale, potrebbero essere necessarie decisioni differenti.

Perché un renderer su misura e non un tool pronto (Satori vs APITemplate vs Blotato)

Esistono servizi pronti per generare grafiche social da template, come APITemplate, o piattaforme che coprono anche video e pubblicazione, come Blotato. Sono ottimi per partire in fretta. Per un sistema che deve rappresentare l'identità di un'organizzazione ed essere riutilizzabile su più progetti, abbiamo però scelto un renderer proprietario basato su Satori.

La differenza, in sintesi:

Con un renderer proprietario il design diventa codice versionato: possiamo aggiungere una nuova organizzazione cambiando pochi token (logo, colori, font) senza ricostruire l'automazione, mantenere ogni grafica coerente al pixel e non dipendere dal catalogo di un fornitore. È la scelta giusta quando il sistema deve essere riutilizzabile, non un singolo esperimento.

Come l'automazione coordina il sistema

Il renderer non lavora da solo. Make coordina i passaggi tra il modello AI, il servizio grafico e le piattaforme di pubblicazione, facendo transitare le informazioni tra i componenti e attivando le operazioni nell'ordine previsto: il modello genera il contenuto, l'endpoint di composizione ne interpreta la struttura, il renderer produce le immagini, il componente video prepara il formato per YouTube e i moduli social ricevono testi e file già pronti.

L'autonomia del sistema dipende anche dalla gestione dei passaggi che normalmente richiederebbero intervento manuale. Nel nostro caso il sistema deve:

• interpretare l'output dell'AI;
• correggere alcune imperfezioni formali;
• scegliere la struttura grafica corretta;
• suddividere il contenuto nelle slide;
• applicare l'identità visiva;
• gestire i caratteri polacchi;
• produrre formati compatibili con i diversi canali;
• creare una versione video;
• consegnare i materiali ai moduli di pubblicazione.

La generazione del testo è quindi soltanto l'inizio. L'autonomia nasce dall'insieme delle regole, dei controlli e dei componenti che permettono al contenuto di attraversare l'intero processo senza essere ricostruito manualmente a ogni passaggio.

Intelligenza artificiale e progetti sociali

In un'organizzazione sociale, la tecnologia dovrebbe rimanere proporzionata alle esigenze operative.

Lo scopo di questo progetto non era aumentare il numero di strumenti utilizzati, ma ridurre il lavoro necessario per mantenere attiva la comunicazione digitale della fondazione.

La scelta di generare grafiche attraverso template controllati permette di mantenere un'identità riconoscibile.

La possibilità di pubblicare su più canali riduce la duplicazione delle attività.

La presenza di un sistema automatico consente inoltre di mantenere una frequenza più regolare senza richiedere la preparazione manuale di ogni singolo contenuto.

L'AI viene quindi utilizzata come componente di un processo editoriale più ampio, non come sostituto dell'identità o degli obiettivi della fondazione.

Il valore non è nel modello, ma nel sistema

Un modello linguistico può generare una headline, un testo o una lista di punti.

Non conosce però automaticamente il formato richiesto da Instagram, la struttura visiva di un carosello, i limiti di un titolo YouTube o il modo corretto di renderizzare i caratteri polacchi.

Questi aspetti devono essere tradotti in software.

È qui che un progetto passa dalla sperimentazione a uno strumento utilizzabile.

Il modello produce materia prima.

Il sistema la controlla, la organizza, la trasforma e la consegna nel formato corretto.

I numeri reali del sistema

In concreto, per Fundacja Moje Podl@sie il sistema produce:

• slide dei caroselli a 1080×1080 pixel, dalle 5 alle 7 per carosello;
• immagini in PNG per LinkedIn e Facebook, in JPEG per Instagram, dallo stesso template;
• un video quadrato 1080×1080 con traccia musicale per YouTube;
• una cache di 24 ore sul renderer, per non rigenerare la stessa grafica;
• un'esecuzione programmata ogni due giorni, a costo di pochi crediti Make.

Il risultato: da un processo interamente manuale a 15 contenuti al mese creati e pubblicati in autonomia su LinkedIn, Facebook, Instagram e YouTube.

In sintesi

Per Fundacja Moje Podl@sie abbiamo sviluppato un sistema che non si limita a generare contenuti.

L'automazione sceglie il formato, costruisce la sequenza delle slide, produce immagini brandizzate, prepara i file per le diverse piattaforme e crea una versione video destinata a YouTube.

Il renderer serverless realizzato su misura rappresenta il collegamento tra l'output testuale dell'AI e il contenuto finale.

È il componente che trasforma una risposta generata da un modello in un elemento visivo coerente con l'identità della fondazione e pronto per essere distribuito.

L'intelligenza artificiale avvia il processo.

Il software costruito intorno ad essa rende possibile tutto ciò che viene dopo.