Validazione dei dati prodotto: IA dove serve, regole altrove

I dati prodotto sono un caso d’uso interessante per l’IA aziendale, perché gli input sono disordinati e l’output desiderato appare strutturato. Ma un modello capace di leggere un documento o scrivere una descrizione non dovrebbe decidere se un record è conforme. Separiamo l’interpretazione probabilistica dal controllo deterministico: i modelli estraggono e formulano; regole tracciabili validano e decidono.

I dati prodotto sono un sistema di controllo, non un compito di scrittura

Un record prodotto collega evidenze del fornitore, requisiti commerciali, obblighi legali, specifiche di canale e dati anagrafici interni. Un attributo può influire su ricerca, logistica, imposte, verifiche di sicurezza, imballaggio o aspettative dei clienti. Una modifica apparentemente minore può propagarsi in molti sistemi a valle.

Per questo «generare i contenuti prodotto» è il perimetro sbagliato: la generazione è soltanto un’attività. Il vero flusso riceve evidenze, identifica entità e attributi, applica regole operative, instrada eccezioni, registra approvazioni e pubblica una versione autorizzata. L’affidabilità dipende dall’intera catena.

Partiamo quindi da due categorie di lavoro:

Interpretazione: leggere documenti variabili, immagini o testo libero; ricondurre termini non familiari a un concetto noto; redigere una descrizione concisa.
Controllo: verificare campi obbligatori, tipi di dati, valori consentiti, unità, dipendenze fra campi, requisiti delle evidenze, autorizzazioni e stato di pubblicazione.

L’interpretazione è probabilistica e beneficia dei modelli. Il controllo dovrebbe essere deterministico ovunque sia possibile esprimere la regola operativa. Riunire entrambi in un prompt rende l’output difficile da sottoporre a verifica, testare e contestare.

Definire il record canonico prima di aggiungere l’IA

Il modello canonico dei prodotti richiede identificativi stabili, campi tipizzati e responsabilità esplicite. Per ogni attributo documentiamo definizione, unità, cardinalità, fonti consentite, evidenze richieste, ambito di mercato o canale e autorizzazione ad approvare modifiche.

Le evidenze grezze restano immutabili. Conserviamo i valori candidati estratti separatamente da quelli approvati, per impedire che un valore generato dal modello diventi silenziosamente un fatto e permettere ai revisori di confrontarlo con la fonte. Un record minimo di tracciabilità comprende:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Il record in produzione contiene soltanto valori che hanno superato le regole applicabili e il percorso di approvazione. È coerente con l’architettura di un catalogo B2B con pagine di certificazione: le affermazioni devono restare collegate alle evidenze, anziché essere trattate come testi promozionali intercambiabili.

Dove i modelli creano valore

I modelli sono utili nelle parti del flusso di lavoro in cui gli input variano.

Estrarre candidati da evidenze non strutturate

Moduli dei fornitori, schede tecniche, etichette e immagini esprimono spesso lo stesso attributo con impaginazioni o formulazioni diverse. Un modello può individuare valori plausibili, normalizzare il testo circostante e restituire un candidato strutturato con un riferimento all’evidenza. Il contratto dell’output deve richiedere null quando mancano evidenze: tirare a indovinare non significa completare il lavoro.

Per i compiti di analisi delle immagini, il sistema deve conservare la regione dell’immagine o la pagina che sostiene l’estrazione. Per il testo, deve conservare un breve passaggio della fonte o una coordinata. Il grado di confidenza è utile per instradare il lavoro, ma non è un’evidenza e non deve mai sostituire il riferimento alla fonte.

Mappare il linguaggio su un vocabolario controllato

Un termine della fonte può non corrispondere esattamente alla tassonomia dell’organizzazione. Un modello può proporre il concetto più vicino del vocabolario controllato e spiegare la corrispondenza. L’accettazione finale resta affidata a una regola o a un revisore autorizzato. Se la tassonomia dispone di una tabella esatta dei sinonimi, si deve prima eseguire la corrispondenza deterministica; il modello gestisce ciò che resta irrisolto.

Formulare testi per il cliente

I modelli possono redigere titoli, punti elenco, riepiloghi o traduzioni a partire da attributi approvati. Il prompt deve attingere soltanto al record approvato e indicare chiaramente le istruzioni stilistiche facoltative. Il testo generato passa poi attraverso regole su lunghezza, affermazioni vietate, precisazioni obbligatorie, terminologia e valori privi di riscontro.

Non chiediamo al modello se il proprio testo è conforme: significherebbe affidare alla stessa componente probabilistica i ruoli di autore e giudice.

Dove devono decidere le regole

Le regole sono appropriate quando una condizione di errore può essere espressa e testata. Le categorie tipiche comprendono:

Tipo di regola	Controllo di esempio
Presenza	Attributo obbligatorio compilato per questa classe di prodotti
Tipo e formato	Valore interpretabile secondo il tipo e la codifica dichiarati
Intervallo	Valore numerico nell’intervallo autorizzato
Enumerazione	Valore appartenente al vocabolario controllato corrente
Unità	Unità consentita e conversione senza perdita di informazione o approvata
Dipendenze fra campi	Campo dipendente presente quando si applica il valore che lo rende necessario
Evidenza	Affermazione sostenuta da un documento fonte ammissibile e aggiornato
Coerenza	Quantità per confezione, dimensioni e totali derivati riconciliati
Ambito	Valore valido per lingua, mercato e canale di destinazione
Autorità	Soggetto autorizzato ad approvare o pubblicare questo campo

Ogni regola richiede identificativo, versione, responsabile, gravità e messaggio leggibile. Il messaggio conta: «validazione fallita» genera un ticket di assistenza; «la quantità netta richiede un’unità approvata e un riferimento alla fonte» genera un compito di correzione.

Questa separazione rende più sicura anche l’automazione tramite flat file su più destinazioni: la formattazione specifica della destinazione può cambiare senza indebolire le regole di validazione canoniche.

I controlli devono essere eseguiti all’acquisizione, dopo l’estrazione, dopo le modifiche umane, prima dell’esportazione e prima della pubblicazione. Interfaccia, pipeline batch e API devono usare lo stesso servizio di validazione versionato. Duplicare la logica fra sistemi crea esiti contraddittori.

Un flusso di lavoro di riferimento

Implementiamo il processo come una serie di transizioni di stato esplicite:

Acquisire: registrare file di origine, checksum, provenienza e data e ora di ricezione.
Preelaborare: classificare i documenti e associarli a possibili identità prodotto.
Estrarre: usare prima parser deterministici, poi modelli per i campi irrisolti.
Normalizzare: convertire formati e unità senza cambiare il significato semantico.
Validare: eseguire l’insieme applicabile di regole versionate.
Revisionare: inviare soltanto le eccezioni o le modifiche ad alto rischio a una persona autorizzata.
Approvare: registrare valore accettato, evidenze e identità di chi approva.
Pubblicare: scrivere su ogni destinazione attraverso un adattatore controllato.
Osservare: acquisire rifiuti a valle, correzioni e segnali sui risultati.

Ogni transizione produce un evento. Il registro permette di rieseguire il processo: quando cambia una tassonomia o una regola, si possono individuare e rivalidare i record interessati senza estrarre di nuovo tutto.

Lo stesso principio vale per le varianti linguistiche. Un’architettura e-commerce multilingue ben progettata tratta la traduzione come output derivato e versionato, mantenendo condivisi fatti approvati ed evidenze.

Il flusso evita anche un approccio costoso: inviare ogni campo al modello più grande disponibile. Identificativi esatti, date, unità note e codici enumerati devono seguire percorsi deterministici. I modelli sono riservati ai campi ambigui: si riducono costi e latenza e si rende più significativa la valutazione dei modelli sui campi rimanenti.

Il grado di confidenza instrada il lavoro, non certifica la verità

I punteggi di confidenza vengono spesso fraintesi. Un valore alto non prova che la fonte sia corretta, aggiornata o autorizzata: descrive soltanto la valutazione del modello secondo un metodo specifico.

Usiamo il grado di confidenza insieme al rischio e agli esiti delle regole per scegliere un percorso. Un candidato a basso rischio, con evidenze dirette e tutti i controlli superati, può entrare in una coda di revisione leggera. Un’affermazione soggetta a regolamentazione o commercialmente sensibile può richiedere approvazione umana indipendentemente dal grado di confidenza. La mancanza di evidenze comporta astensione, non una soglia più bassa.

Le soglie vanno calibrate su dati rappresentativi per attributo e tipo di documento. Una soglia globale nasconde grandi differenze: estrarre un identificativo standard non equivale a interpretare un’affermazione relativa al materiale. Tracciamo precisione, recall, astensione e decisioni dei revisori che modificano l’esito per ciascun segmento significativo.

Le eccezioni fanno parte del prodotto

I cataloghi reali contengono pacchetti di prodotti, articoli sostitutivi, varianti regionali, record storici e documenti dei fornitori in conflitto. Un sistema progettato soltanto per il percorso senza intoppi crea lavoro manuale in punti non osservabili.

Ogni eccezione richiede codice del motivo, gravità, responsabile, scadenza e risoluzione consentita. I revisori devono vedere candidato, evidenze della fonte, regole non superate e impatto a valle in un’unica vista, e poter accettare, correggere, rifiutare o richiedere nuove evidenze senza modificare i dati grezzi.

Le deroghe devono essere esplicite e circoscritte: un revisore può derogare a un avviso per un prodotto e una destinazione, ma non disabilitare globalmente la regola sottostante. Deroghe ripetute segnalano che regola, tassonomia, processo della fonte o modello prodotto potrebbero richiedere una revisione.

I livelli di servizio devono riflettere il rischio aziendale, non l’ordine di arrivo: un campo promozionale facoltativo mancante e un attributo di sicurezza contraddittorio non appartengono alla stessa coda.

Misurare dal riferimento iniziale al risultato

Prima dell’automazione misuriamo completezza dei campi, validazione al primo passaggio, cicli di correzione, tempo di revisione, tasso di rifiuto a valle e tasso di difetti gravi. Per la reportistica interna riservata possiamo esprimere ogni serie come indice con Baseline = 100, mantenendo volumi assoluti e valori commerciali nell’ambiente autorizzato.

Dopo il rilascio separiamo qualità dell’estrazione e prestazioni operative: un’estrazione può essere tecnicamente corretta ma arrivare troppo tardi per la pubblicazione; un flusso può ridurre il tempo di revisione aumentando i difetti gravi. Il quadro delle metriche comprende quindi:

accuratezza dei candidati e copertura delle evidenze per attributo;
tassi di superamento delle regole e di astensione;
tassi di deroga e correzione da parte delle persone;
età della coda e tempo necessario per ottenere un record approvato;
rifiuti delle destinazioni e correzioni dopo la pubblicazione;
limiti di controllo per gli errori ad alta gravità.

Le modifiche a modelli, prompt, tassonomie e regole sono versionate indipendentemente. Gli insiemi di valutazione includono record comuni ed eccezioni note. Prima della distribuzione, rieseguiamo la versione proposta e confrontiamo sia i record appena accettati sia quelli appena rifiutati. Il rilascio viene bloccato se un limite di controllo peggiora oltre la tolleranza concordata, anche quando l’accuratezza media migliora.

Governare le modifiche come cambiamenti delle regole operative

Le regole codificano le politiche operative. Aggiornarle può cambiare quali prodotti sono pubblicabili, quali affermazioni sono consentite e quali team ricevono lavoro. Le modifiche richiedono quindi responsabile, motivazione, data di entrata in vigore, test e approvazione proporzionata all’impatto.

I cambiamenti dei modelli richiedono una disciplina simile, ma test diversi: valutiamo estrazione e formulazione su casi etichettati, inclusi input avversari e di bassa qualità. Testiamo anche il contratto dell’output strutturato: campi sconosciuti, tipi non validi ed evidenze mancanti devono causare un errore gestito in sicurezza.

La distribuzione deve essere graduale. La modalità ombra confronta il nuovo percorso senza modificare i record; segue un gruppo limitato e poi un’estensione più ampia se i limiti di controllo tengono. L’adattatore di scrittura impone idempotenza, privilegio minimo e rollback. Nessun modello riceve accesso diretto e illimitato al sistema di riferimento.

La divisione del lavoro che scala

L’architettura duratura non è «IA contro regole», ma una divisione deliberata del lavoro.

I modelli trasformano evidenze variabili in candidati e fatti approvati in linguaggio utile. Le regole esprimono politiche ripetibili. Le persone risolvono ambiguità, approvano modifiche ad alto impatto e migliorano le regole quando le eccezioni rivelano una lacuna. I registri degli eventi collegano ogni decisione alle evidenze e alla logica versionata.

Questo progetto è più facile da spiegare ai dirigenti, perché il rischio è circoscritto da azioni ed evidenze; più facile da costruire, perché le componenti hanno contratti verificabili; più facile da gestire, perché gli errori sono specifici: un’estrazione non ha rilevato un valore, una fonte era inammissibile, una regola ha rifiutato una combinazione o un revisore autorizzato ha derogato a un avviso.

I dati prodotto aziendali non saranno mai perfettamente puliti o uniformi, e non devono esserlo. Il sistema deve sapere cosa è osservato, cosa è dedotto, cosa è consentito e chi ha deciso. Usa l’IA dove serve davvero interpretare e le regole ovunque l’organizzazione sappia già esprimere la decisione.