Validación de datos de producto: IA donde hace falta, reglas en el resto

Los datos de producto son un caso de uso atractivo para la IA empresarial porque las entradas son desordenadas y la salida deseada parece estructurada. Pero un modelo capaz de leer un documento o redactar una descripción no debería decidir si un registro cumple los requisitos. Separamos la interpretación probabilística del control determinista: los modelos extraen y formulan; las reglas trazables validan y deciden.

Los datos de producto son un sistema de control, no una tarea de redacción

Un registro de producto conecta evidencia del proveedor, requisitos comerciales, obligaciones legales, especificaciones de canal y datos maestros internos. Un atributo puede afectar las búsquedas, la logística, los impuestos, la revisión de seguridad, el embalaje o las expectativas del cliente. Un cambio aparentemente menor puede propagarse a muchos sistemas posteriores.

Por eso, «generar el contenido del producto» define mal el alcance del sistema: la generación es solo una actividad. El flujo real recibe evidencia, identifica entidades y atributos, aplica políticas, encamina excepciones, registra aprobaciones y publica una versión autorizada. La fiabilidad depende de toda la cadena.

Empezamos, por tanto, con dos categorías de trabajo:

Interpretación: leer documentos variables, imágenes o texto libre; relacionar lenguaje desconocido con un concepto conocido; redactar una descripción concisa.
Control: comprobar campos obligatorios, tipos de datos, valores permitidos, unidades, dependencias entre campos, requisitos de evidencia, permisos y estado de publicación.

La interpretación es probabilística y se beneficia de los modelos. El control debe ser determinista siempre que la política pueda expresarse. Combinar ambos en un único prompt dificulta auditar, probar e impugnar la salida.

Definir el registro canónico antes de añadir IA

El modelo canónico de producto necesita identificadores estables, campos tipados y responsables explícitos. Para cada atributo documentamos su definición, unidad, cardinalidad, fuentes permitidas, evidencia requerida, ámbito de mercado o canal y autoridad para aprobar cambios.

La evidencia original permanece inmutable. Almacenamos los candidatos extraídos por separado de los valores aprobados, para evitar que un valor generado se convierta silenciosamente en un hecho y permitir al revisor compararlo con su fuente. Un registro mínimo de linaje incluye:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

El registro de producción contiene únicamente valores que han superado las reglas y la vía de aprobación correspondientes. Esto coincide con la arquitectura de un catálogo B2B con páginas de certificación: las afirmaciones deben permanecer conectadas a la evidencia, en lugar de tratarse como textos de marketing intercambiables.

Dónde aportan valor los modelos

Los modelos son útiles en las partes variables del flujo.

Extraer candidatos de evidencia no estructurada

Los formularios de proveedores, las fichas técnicas, las etiquetas y las imágenes suelen expresar un mismo atributo con diseños o palabras distintos. Un modelo puede localizar valores probables, normalizar el texto que los rodea y devolver un candidato estructurado con una referencia a la evidencia. El contrato de salida debe exigir null cuando falte evidencia: adivinar no equivale a completar.

En tareas de visión, el sistema debe conservar la región de imagen o página que respalda la extracción; para texto, un fragmento breve de origen o una coordenada. La confianza ayuda a encaminar el trabajo, pero no es evidencia y nunca debe sustituir la referencia a la fuente.

Relacionar lenguaje con un vocabulario controlado

Un término de origen puede no coincidir exactamente con la taxonomía de la organización. El modelo puede proponer el concepto controlado más cercano y explicar la correspondencia. La aceptación final sigue dependiendo de una regla o de un revisor autorizado. Si la taxonomía tiene una tabla exacta de sinónimos, primero debe aplicarse la correspondencia determinista; el modelo trata lo que quede sin resolver.

Formular texto dirigido al cliente

Los modelos pueden redactar títulos, viñetas, resúmenes o traducciones a partir de atributos aprobados. El prompt debe usar solo el registro aprobado e identificar claramente las instrucciones opcionales de estilo. Después, el texto generado pasa por reglas de longitud, afirmaciones prohibidas, matices obligatorios, terminología y valores sin respaldo.

No se pide al modelo que evalúe su propio cumplimiento: eso convertiría al mismo componente probabilístico en autor y juez.

Dónde deben decidir las reglas

Las reglas son apropiadas cuando una condición de fallo puede expresarse y probarse. Algunas categorías habituales son:

Tipo de regla	Ejemplo de control
Presencia	El atributo obligatorio tiene un valor para esta clase de producto
Tipo y formato	El valor puede interpretarse conforme al tipo y la codificación declarados
Rango	El valor numérico está dentro de un intervalo autorizado
Enumeración	El valor pertenece al vocabulario controlado vigente
Unidad	La unidad está permitida y la conversión no pierde información o está aprobada
Entre campos	El campo dependiente está presente cuando se aplica un valor activador
Evidencia	La afirmación tiene un documento de origen admisible y vigente
Coherencia	La cantidad del paquete, las dimensiones y los totales derivados cuadran
Ámbito	El valor es válido para el idioma, el mercado y el canal de destino
Autoridad	El actor está autorizado a aprobar o publicar este campo

Cada regla necesita identificador, versión, responsable, gravedad y mensaje legible. El mensaje importa: «falló la validación» genera un ticket de soporte; «la cantidad neta requiere una unidad aprobada y una referencia de origen» genera una tarea de corrección.

Esta separación también hace más segura la automatización de archivos planos para múltiples destinos: el formato específico de cada destino puede cambiar sin debilitar la política de validación canónica.

Las reglas deben ejecutarse al recibir los datos, después de extraerlos, después de las ediciones humanas, antes de exportar y antes de publicar. La interfaz, el pipeline por lotes y la API deben usar el mismo servicio de validación versionado. Duplicar la lógica entre sistemas produce resultados contradictorios.

Un flujo de referencia

Implementamos el proceso mediante una serie de transiciones de estado explícitas:

Recepción: registrar archivos de origen, sumas de comprobación, procedencia y hora de recepción.
Preprocesamiento: clasificar documentos y asociarlos con posibles identidades de producto.
Extracción: usar primero analizadores deterministas y después modelos para los campos sin resolver.
Normalización: convertir formatos y unidades sin cambiar el significado.
Validación: ejecutar el conjunto de reglas versionadas aplicable.
Revisión: encaminar solo las excepciones o los cambios de alto riesgo a una persona autorizada.
Aprobación: registrar el valor aceptado, la evidencia y la identidad de quien aprueba.
Publicación: escribir mediante un adaptador controlado en cada destino.
Observación: capturar rechazos posteriores, correcciones y señales del resultado.

Cada transición genera un evento. El registro de eventos permite reproducir el proceso: cuando cambia una taxonomía o una regla, se identifican y revalidan los registros afectados sin extraer todo de nuevo.

El mismo principio se aplica a las variantes lingüísticas. Una arquitectura de comercio multilingüe disciplinada trata la traducción como una salida derivada y versionada, mientras los hechos aprobados y la evidencia siguen compartidos.

El flujo también evita enviar cada campo al modelo más grande disponible, un antipatrón costoso. Los identificadores exactos, las fechas, las unidades conocidas y los códigos enumerados deben seguir rutas deterministas. Los modelos se reservan para campos ambiguos, lo que reduce el costo y la latencia y hace más significativa su evaluación.

La confianza encamina el trabajo; no demuestra la verdad

Las puntuaciones de confianza suelen interpretarse mal. Una confianza alta no prueba que la fuente sea correcta, vigente o autorizada; solo describe la evaluación del modelo con un método concreto.

Usamos la confianza junto con el riesgo y los resultados de las reglas para seleccionar una ruta. Un candidato de bajo riesgo, con evidencia directa y todas las reglas superadas, puede entrar en una cola de revisión ligera. Una afirmación regulada o comercialmente sensible puede requerir aprobación humana sin importar la confianza. La falta de evidencia exige abstención, no un umbral menor.

Los umbrales deben calibrarse con datos representativos por atributo y tipo de documento. Uno global oculta diferencias importantes: extraer un identificador estándar no equivale a interpretar una afirmación sobre materiales. Seguimos la precisión, la exhaustividad, la abstención y las correcciones del revisor en cada segmento significativo.

Las excepciones forman parte del producto

Los catálogos reales contienen paquetes de productos, repuestos, variantes regionales, registros heredados y documentos contradictorios de proveedores. Diseñar solo para el recorrido sin incidencias crea trabajo manual en lugares invisibles.

Cada excepción necesita un código de motivo, gravedad, responsable, fecha límite y resolución permitida. Los revisores deben ver conjuntamente el candidato, la evidencia de origen, las reglas incumplidas y el impacto posterior. Deben poder aceptar, corregir, rechazar o pedir nueva evidencia sin editar los datos originales.

Las modificaciones excepcionales deben ser explícitas y acotadas: un revisor puede exceptuar una advertencia para un producto y destino, pero no desactivar la regla globalmente. Su repetición indica que quizá deban revisarse la regla, la taxonomía, el proceso de origen o el modelo de producto.

Los niveles de servicio deben responder al riesgo empresarial y no al orden de llegada. Un campo de marketing opcional ausente y un atributo de seguridad contradictorio no pertenecen a la misma cola.

Medir desde la línea de base hasta el resultado

Antes de automatizar, medimos la completitud de los campos, la validación al primer intento, los ciclos de corrección, el tiempo de revisión, la tasa de rechazo posterior y la de defectos graves. En informes internos confidenciales podemos expresar cada serie como un índice con Baseline = 100, manteniendo los volúmenes absolutos y los valores comerciales en el entorno autorizado.

Después de poner el sistema en producción, separamos la calidad de extracción del rendimiento operativo. Una extracción puede ser técnicamente correcta y llegar demasiado tarde para publicar. Un flujo puede reducir el tiempo de revisión y aumentar los defectos graves. Por eso el cuadro de indicadores incluye:

exactitud de los candidatos y cobertura de evidencia por atributo;
tasas de superación de las reglas y de abstención;
tasas de modificaciones excepcionales y correcciones humanas;
antigüedad de la cola y tiempo hasta obtener un registro aprobado;
rechazos en los destinos y correcciones posteriores a la publicación;
controles de protección frente a errores de gran gravedad.

Los cambios de modelos, prompts, taxonomías y reglas se versionan de forma independiente. Los conjuntos de evaluación incluyen registros habituales y excepciones conocidas. Antes del despliegue, reproducimos el proceso con la versión propuesta y comparamos los registros que pasan a aceptarse y los que pasan a rechazarse. Se bloquea una versión si un control de protección empeora más allá de la tolerancia acordada, aunque mejore la exactitud media.

Gestionar los cambios como cambios de política

Las reglas codifican políticas operativas. Actualizarlas puede cambiar qué productos se pueden publicar, qué afirmaciones se permiten y qué equipos reciben trabajo. Los cambios necesitan un responsable, justificación, fecha de entrada en vigor, pruebas y aprobación proporcional al impacto.

Los cambios de modelo exigen una disciplina similar, pero pruebas distintas. Evaluamos extracción y formulación con casos etiquetados, incluidas entradas adversariales y de baja calidad. También probamos el contrato de salida estructurada: campos desconocidos, tipos inválidos y evidencia ausente deben causar fallos seguros.

El despliegue debe ser gradual. El modo de evaluación en paralelo compara la nueva ruta sin modificar registros; después sigue una cohorte limitada y una ampliación si los controles se mantienen. El adaptador de escritura impone idempotencia, mínimo privilegio y reversión. Ningún modelo recibe acceso directo e irrestricto al sistema de registro de referencia.

La división del trabajo que permite escalar

La arquitectura duradera requiere una división deliberada del trabajo, no elegir entre «IA o reglas».

Los modelos convierten evidencia variable en candidatos y hechos aprobados en lenguaje útil. Las reglas expresan políticas repetibles. Las personas resuelven ambigüedades, aprueban cambios de gran impacto y mejoran las políticas cuando las excepciones revelan lagunas. Los registros de eventos vinculan cada decisión con la evidencia y la lógica versionada.

Este diseño es más fácil de explicar a los directivos porque el riesgo está acotado por la acción y la evidencia. Es más fácil de construir porque los componentes tienen contratos verificables, y de operar porque los fallos son concretos: una extracción omitió un valor, una fuente no era admisible, una regla rechazó una combinación o un revisor autorizado exceptuó una advertencia.

Los datos de producto empresariales nunca serán perfectamente limpios ni uniformes, y no necesitan serlo. El sistema debe saber qué se observa, qué se infiere, qué se permite y quién decidió. Utilice IA donde realmente se requiere interpretación y reglas donde la organización ya sabe formular la decisión.