Validazione dei dati prodotto: AI dove serve, regole altrove

I dati prodotto sono un caso d’uso attraente: gli input sono disordinati e l’output atteso sembra strutturato. Ma un modello capace di leggere o scrivere non deve decidere la conformità. Separiamo interpretazione probabilistica e controllo deterministico: i modelli estraggono e formulano; regole tracciabili validano e decidono.

I dati prodotto sono un sistema di controllo

Un record collega evidenze del fornitore, requisiti commerciali, obblighi legali, specifiche di canale e master data. Un attributo può influire su ricerca, logistica, tasse, sicurezza, packaging e aspettative. «Generare contenuti» è quindi il confine sbagliato: il workflow riceve prove, identifica entità, applica policy, instrada eccezioni, registra approvazioni e pubblica una versione autorizzata.

Interpretazione: leggere documenti, immagini e testo variabili; mappare termini; redigere.
Controllo: verificare campi, tipi, valori, unità, dipendenze, evidenze, diritti e stato.

I modelli aiutano l’interpretazione. Il controllo resta deterministico quando la policy può essere espressa. Riunire entrambi in un prompt rende difficili audit e test.

Definire il record canonico prima dell’AI

Il modello canonico richiede ID stabili, campi tipizzati e ownership. Per ogni attributo definiamo significato, unità, cardinalità, fonti, prove, ambito e autorità. Le evidenze grezze restano immutabili e i candidati separati dai valori approvati.

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Il record produttivo contiene solo valori approvati. Come in un catalogo B2B con pagine di certificazione, i claim restano legati alle evidenze.

Dove i modelli creano valore

Estrarre candidati da evidenze non strutturate

Moduli, schede, etichette e immagini esprimono lo stesso attributo in modi diversi. Il modello restituisce un candidato con riferimento; senza prova deve produrre null. Regione dell’immagine, pagina o passaggio restano disponibili. La confidence instrada il lavoro, non sostituisce l’evidenza.

Mappare il linguaggio su un vocabolario controllato

Il modello propone un concetto e spiega il mapping; regola o reviewer autorizzato accetta. Le corrispondenze esatte e i sinonimi deterministici vengono prima.

Formulare testi per il cliente

Titoli, bullet, sintesi e traduzioni derivano solo da attributi approvati. Regole verificano lunghezza, claim vietati, qualificatori, terminologia e valori non supportati. Il modello non giudica il proprio testo.

Dove devono decidere le regole

Tipo	Controllo di esempio
Presenza	Attributo obbligatorio compilato
Tipo e formato	Valore conforme al tipo
Intervallo	Numero nel range autorizzato
Enumerazione	Valore nel vocabolario corrente
Unità	Unità consentita e conversione approvata
Cross-field	Campo dipendente presente
Evidenza	Claim con fonte valida e attuale
Coerenza	Quantità, dimensioni e totali concordano
Ambito	Valore valido per lingua, mercato e canale
Autorità	Attore autorizzato a pubblicare

Ogni regola ha ID, versione, owner, severità e messaggio leggibile. Lo stesso servizio opera su ingestion, estrazione, modifica, export e pubblicazione. La separazione rende più sicura anche la flatfile automation su più destinazioni: il formato cambia senza indebolire la policy canonica.

Un workflow di riferimento

Ingest: registrare file, checksum, origine e ricezione.
Preprocess: classificare e associare identità prodotto.
Extract: parser prima, modelli sui campi irrisolti.
Normalise: convertire formati e unità senza cambiare significato.
Validate: eseguire regole versionate.
Review: inviare eccezioni e rischi a persone autorizzate.
Approve: registrare valore, prova e identità.
Publish: usare adapter controllati.
Observe: acquisire rifiuti, correzioni e outcome.

Ogni transizione produce un evento e abilita la rivalidazione. Lo stesso vale per le lingue: un’architettura commerce multilingue tratta le traduzioni come output derivati e versionati, mantenendo comuni fatti ed evidenze. ID, date, unità e codici seguono percorsi deterministici; i modelli gestiscono l’ambiguità.

La confidence instrada il lavoro, non certifica la verità

Una confidence alta non prova correttezza, attualità o autorità. Insieme a rischio e regole sceglie il percorso. Claim sensibili richiedono approvazione; prova mancante significa astensione. Le soglie sono calibrate per attributo e documento, misurando precision, recall, astensione e override per segmento.

Le eccezioni fanno parte del prodotto

Bundle, ricambi, varianti, record legacy e documenti discordanti sono normali. Ogni eccezione ha reason code, severità, owner, scadenza e risoluzione. Il reviewer vede candidato, prova, regole e impatto. Gli override sono espliciti e circoscritti; la ripetizione segnala policy o tassonomia da correggere. Le priorità seguono il rischio.

Misurare dalla baseline all’outcome

Prima dell’automazione misuriamo completezza, validazione al primo passaggio, correzioni, tempo, rifiuti e difetti gravi. I report riservati usano Baseline = 100; valori assoluti restano nell’ambiente autorizzato.

accuratezza dei candidati e copertura delle prove;
pass rate delle regole e astensione;
override e correzioni umane;
età della coda e tempo all’approvazione;
rifiuti e correzioni post-pubblicazione;
guardrail per errori gravi.

Modelli, prompt, tassonomie e regole sono versionati separatamente. I replay confrontano nuovi accettati e rifiutati; un guardrail deteriorato blocca il rilascio anche se la media migliora.

Governare i cambiamenti come policy

Le regole richiedono owner, motivazione, data, test e approvazione proporzionata. I modelli sono testati su casi etichettati, avversariali e degradati; campi sconosciuti, tipi errati o prove mancanti devono fallire in sicurezza. Shadow mode, coorte limitata e rollout graduale precedono la scala. L’adapter impone idempotenza, least privilege e rollback; nessun modello accede senza limiti al system of record.

La divisione del lavoro che scala

Non è «AI contro regole». I modelli trasformano evidenze variabili in candidati e fatti approvati in linguaggio; le regole esprimono policy ripetibile; le persone risolvono ambiguità e approvano rischi. Gli eventi collegano decisione, prova e versione. Il sistema deve distinguere ciò che è osservato, inferito e consentito e chi ha deciso. AI dove serve interpretare, regole dove la decisione è formulabile.