AI per content ecommerce: catalog enrichment, palette colori, video, voice

L’AI applicata al content ecommerce è la categoria su cui ricevo più domande, e quella dove vedo più sprechi. Tra “AI agent che gestisce tutto il catalogo” e “AI che scrive le descrizioni Shopify” passa lavoro reale che nessuno racconta: gateway, versionamento prompt, scelta modelli per fascia di costo, criteri di accettazione misurabili. Questo articolo descrive i pattern AI per content che ho portato in produzione su un catalogo moda/footwear, dove valgono la pena, dove no, e come si misura la differenza.

Quattro layer di AI nel content ecommerce

Quando parliamo di “AI per il catalogo” stiamo in realtà parlando di quattro layer molto diversi, che hanno economie e rischi diversi.

Layer testo: enrichment schede prodotto. Descrizioni, titoli, bullet feature, traduzioni. Layer più maturo e facile da industrializzare. Il pattern che uso è tool-calling: il modello chiama tool tipizzati (set_title, set_description, add_feature) che validano formato e regole di brand. Niente Markdown rotto, niente lunghezze fuori limite Shopify.

Layer visione: estrazione di metadati dalle immagini. Il caso più utile che ho implementato è l’estrazione automatica di palette colori da foto prodotto, con nomi in italiano e codici HEX. Non è glamour ma è il tipo di metadato che alimenta filtri, badge “disponibile in X colori”, merchandising automatico. Estrazione automatica, validazione contro una palette di brand, fallback umano per le immagini in cui il modello esita.

Layer audio: TTS multilingua. Voice-over generati per video shorts, content social, o audio guides di catalogo. ElevenLabs Multilingual v2 produce italiano broadcast-quality che fino a un anno fa richiedeva uno speaker professionista. Output MP3 salvato su storage, link riusabile in tutta la pipeline di produzione video.

Layer immagine/video: generazione e enhance. Stage virtuale di prodotti, enhance di foto esistenti, generazione di immagini lifestyle, generazione video clip cinematici. È il layer più costoso, con il margine di errore più alto, e quello dove è più facile produrre output non utilizzabili.

Il pattern che funziona: gateway + tool-calling + versioning

Il singolo decision che ha più impatto sui progetti AI content che vedo è non chiamare i modelli direttamente dal front-end o dagli scenari Make. Tra l’app e il modello deve esserci un gateway, e nel gateway devono vivere tre cose: routing tra provider, tool-calling tipizzato, e una libreria di prompt versionati.

Il routing serve perché nessun modello vince su tutto. Per descrizioni prodotto in italiano uso un LLM diverso da quello per palette colori. Il gateway astrae la scelta: l’app chiede “arricchisci questo prodotto”, il gateway decide quale modello chiamare in base a costo, latency e qualità storica.

Il tool-calling tipizzato serve perché senza, l’AI scrive testo che qualcuno deve parsare. Con tool-calling il modello chiama set_title("...") e tu ricevi struttura validata. Sembra dettaglio finché non lavori senza.

Il versioning prompt — una “AI Library” con master editor — serve perché i prompt cambiano: nuovo modello, nuova regola di tono di un brand, nuovo edge case. Senza versionamento, perdi traccia di “perché due settimane fa la qualità era migliore”. Con versionamento (numero, autore, diff, tag rollback) ogni cambio è auditable.

Esempio concreto: palette colori italiani

Il caso che porto sempre è l’estrazione palette su un catalogo moda. Ogni prodotto ha tra una e cinque foto. Per ogni foto vuoi estrarre i tre-cinque colori dominanti, con un nome in italiano comprensibile al cliente (“verde salvia”, non “#8FA882”) e un codice HEX preciso per il front-end.

L’approccio naive — un’unica chiamata a un Vision LLM che restituisce tutto — funziona, ma costa, e il modello si inventa nomi colore che cambiano fra una chiamata e l’altra (“verde militare” oggi, “verde army” domani). Il pattern che ho messo in produzione:

1. Estrazione HEX con algoritmo deterministico (clustering colori sulla foto, niente AI). Veloce, gratis, riproducibile.
2. Naming italiano con una map “quick lookup” su circa 200 colori canonici. Il 95% dei colori cade qui.
3. Fallback AI sul 5% rimanente, con un prompt molto stretto che riceve il HEX e una lista di nomi consentiti, e deve scegliere il più vicino.
4. Traduzione IT to EN con la stessa logica: una map per i casi comuni (“verde salvia” to “sage green”) e fallback AI per i nuovi.

Il risultato è che il 99% delle palette è generato senza chiamare un LLM. Solo il residuo problematico paga il costo AI, e quel residuo è anche quello dove la qualità AI è più visibile.

Quando l’AI immagine vale la pena, quando no

L’AI image (stage, enhance, generation) è il layer più affascinante e quello con il ROI più volatile. La domanda da farsi è: il costo unitario per immagine accettabile è inferiore al costo del processo manuale che sostituisce?

Per enhance di foto già esistenti (upscaling, color correction, light cleanup) il calcolo è quasi sempre positivo: il costo per immagine è di pochi centesimi, e sostituisce minuti di Photoshop. Da introdurre subito.

Per stage virtuale — adattare la stessa foto prodotto a contesti diversi (esempio: stessa sedia in tre mood ambientali) — il calcolo dipende dal numero di mercati. Se hai un mercato unico, il manuale spesso vince. Se hai cinque mercati e mille SKU, il break-even arriva presto.

Per generazione lifestyle ex novo sono molto cauto. La qualità è migliorata enormemente ma la consistenza brand è ancora difficile. Il caso d’uso che vedo funzionare è A/B test e moodboard, non hero asset.

Per video AI la situazione è la stessa moltiplicata per dieci. Funziona per content social ad alto volume e basso impegno per asset, dove l’esperimento costa poco. Non funziona ancora per video brand-hero che richiedono perfezione.

Come misurare il ROI

Una metrica che funziona, che ho calcolato in più progetti: per il layer testo (enrichment + traduzioni), un catalogo di 2.000 SKU con descrizioni in tre lingue richiede tradizionalmente circa 300 ore di copywriting. Con il pattern gateway + tool-calling + revisione umana selettiva (il copywriter umano interviene solo sulle schede sopra una soglia di valore o sotto una soglia di confidenza dell’AI), le ore scendono a circa 60: il 70-80% del tempo recuperato.

Il numero da non guardare da solo è il “tempo risparmiato”. Il numero da guardare in coppia è il “tasso di accettazione delle schede generate” — quante schede passano la review senza modifiche significative. Sotto il 75%, la pipeline non sta producendo valore reale, sta solo spostando lavoro dalla scrittura alla correzione. Sopra l’85%, il sistema sta funzionando come deve.

L’errore comune

Il singolo errore che vedo più spesso è “compriamo licenze di un tool AI per il catalogo e vediamo che succede”. Senza gateway, senza versioning, senza criteri di accettazione misurabili, senza fallback umano sui casi a bassa confidenza, sei nella terra di nessuno. Spendi soldi, produci output di qualità variabile, e dopo tre mesi nessuno sa dire se il sistema sta aiutando o no.

Il pattern alternativo — gateway proprietario su Supabase edge functions, prompt versionati, tool-calling tipizzato, metriche di accettazione tracciate per ogni layer — costa di più all’inizio. Ripaga in trasparenza, governabilità e capacità di migliorare nel tempo. È la differenza tra “abbiamo AI nel catalogo” e “sappiamo cosa l’AI sta facendo, perché, e con che qualità”.