Validación de datos de producto: IA donde hace falta, reglas en el resto
Los datos de producto parecen un caso ideal para IA: entradas desordenadas y una salida estructurada. Pero un modelo capaz de leer o redactar no debe decidir la conformidad. Separamos interpretación probabilística y control determinista: los modelos extraen y formulan; reglas trazables validan y deciden.
Los datos de producto son un sistema de control
Un registro conecta evidencia del proveedor, requisitos comerciales y legales, especificaciones de canal y datos maestros. Un atributo afecta búsqueda, logística, fiscalidad, seguridad o expectativas. El flujo correcto recibe evidencia, identifica entidades, aplica política, enruta excepciones, registra aprobaciones y publica una versión autorizada.
- Interpretación: leer documentos, imágenes o texto variable; mapear términos; redactar.
- Control: verificar campos, tipos, valores, unidades, dependencias, evidencia, derechos y estado.
Los modelos ayudan a interpretar. El control debe ser determinista cuando la política puede expresarse.
Definir el registro canónico antes de la IA
Necesitamos IDs estables, campos tipados y ownership. Por atributo definimos significado, unidad, cardinalidad, fuentes, evidencia, ámbito y autoridad. La evidencia bruta es inmutable y los candidatos no se mezclan con valores aprobados.
product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_statusComo en un catálogo B2B con páginas de certificación, cada claim permanece unido a su evidencia.
Dónde aportan valor los modelos
Extraer candidatos de evidencia no estructurada
Formularios, fichas, etiquetas e imágenes expresan atributos de formas distintas. El modelo devuelve candidato y referencia; sin evidencia debe devolver null. Se conserva región, página o fragmento. La confianza enruta trabajo, no sustituye evidencia.
Mapear lenguaje a vocabulario controlado
El modelo propone concepto y explicación; regla o revisor autorizado acepta. Los sinónimos exactos se resuelven primero de forma determinista.
Formular texto para clientes
Títulos, bullets, resúmenes y traducciones parten solo de atributos aprobados. Reglas comprueban longitud, claims prohibidos, calificadores, terminología y valores no sustentados. El modelo no juzga su propio texto.
Dónde deben decidir las reglas
| Tipo | Control de ejemplo |
|---|---|
| Presencia | Atributo obligatorio informado |
| Tipo y formato | Valor compatible con el tipo |
| Rango | Número dentro del intervalo |
| Enumeración | Valor en vocabulario vigente |
| Unidad | Unidad permitida y conversión aprobada |
| Entre campos | Campo dependiente presente |
| Evidencia | Claim con fuente válida y actual |
| Coherencia | Cantidades, medidas y totales cuadran |
| Ámbito | Válido para idioma, mercado y canal |
| Autoridad | Actor autorizado a publicar |
Cada regla tiene ID, versión, owner, severidad y mensaje legible. Ingesta, interfaz, batch, API y publicación usan el mismo servicio. La separación hace más segura la automatización flatfile multidestino: el formato cambia sin debilitar la política.
Un flujo de referencia
- Ingest: registrar archivos, checksums, origen y recepción.
- Preprocess: clasificar y asociar identidades.
- Extract: parsers primero; modelos para lo no resuelto.
- Normalise: convertir formatos y unidades sin alterar significado.
- Validate: ejecutar reglas versionadas.
- Review: llevar excepciones a personas autorizadas.
- Approve: registrar valor, evidencia e identidad.
- Publish: escribir mediante adaptadores controlados.
- Observe: capturar rechazos, correcciones y outcomes.
Cada transición genera un evento y permite revalidar. Una arquitectura de comercio multilingüe trata las traducciones como outputs derivados y versionados, compartiendo hechos y evidencia.
La confianza enruta; no concede verdad
Una confianza alta no demuestra corrección, vigencia ni autorización. Riesgo, reglas y confianza eligen ruta. Los claims sensibles requieren aprobación; sin evidencia hay abstención. Los umbrales se calibran por atributo y documento con precisión, recall, abstenciones y overrides.
Las excepciones forman parte del producto
Bundles, recambios, variantes, legacy y documentos contradictorios son normales. Cada excepción tiene código, severidad, owner, plazo y resolución. El revisor ve candidato, evidencia, reglas e impacto. Los overrides son explícitos y acotados; su repetición señala una política o taxonomía que corregir.
Medir desde la baseline hasta el outcome
Antes medimos completitud, validación al primer intento, ciclos, tiempo, rechazos y defectos graves. Los informes confidenciales usan Baseline = 100; los absolutos quedan autorizados internamente.
- exactitud y cobertura de evidencia por atributo;
- aprobación de reglas y abstención;
- overrides y correcciones humanas;
- edad de cola y tiempo hasta aprobación;
- rechazos y correcciones tras publicar;
- guardrails para errores graves.
Modelos, prompts, taxonomías y reglas se versionan por separado. Replays comparan nuevos aceptados y rechazados; un guardrail peor bloquea el release aunque suba el promedio.
Gobernar cambios como política
Las reglas requieren owner, motivo, fecha, pruebas y aprobación proporcional. Los modelos se prueban con casos etiquetados, adversariales y deficientes; campos desconocidos, tipos inválidos y evidencia ausente deben fallar de forma segura. Shadow mode, cohorte limitada y rollout gradual preceden la escala. El adaptador impone idempotencia, mínimo privilegio y rollback.
La división del trabajo que escala
No es «IA contra reglas». Los modelos convierten evidencia variable en candidatos y hechos aprobados en lenguaje; las reglas expresan política repetible; las personas resuelven ambigüedad y riesgo. Los eventos unen decisión, evidencia y versión. IA donde hace falta interpretar; reglas donde la organización sabe formular la decisión.