Antes de “meterle IA” a un negocio, conviene responder: ¿los datos están listos para decir la verdad? Si el stock miente, el modelo también. Si el CRM tiene tres teléfonos distintos para la misma persona, el asistente alucinará con estilo.
Este artículo cubre pipelines de datos auditables para ecommerce, ERP y pasarelas de pago — sin prometer milagros, con métricas de negocio y privacidad desde el diseño.
Orden recomendado
- Pregunta de negocio (“bajar tickets de soporte”, “priorizar leads”).
- Fuente de verdad (ERP, ecommerce, CRM).
- Calidad y PII.
- Versionado de datasets / exports.
- Modelo o RAG pequeño y medible.
- Producto (API, panel, automatización) + feedback humano.
Checklist de calidad
- Duplicados y claves naturales (¿qué identifica un cliente?).
- Nulos “silenciosos” (0 vs vacío vs
NULL). - Unidades y monedas (USD/PAB, impuestos).
- Drift: el catálogo de hace seis meses no es el de hoy.
- Estados de pago alineados con la pasarela, no con lo que el front mostró.
- Zonas horarias consistentes en timestamps de pedido y webhook.
Patrón con Laravel como fuente
- Definir el evento o entidad (pedido, lead, ticket) y su contrato JSON/SQL.
- Exponer lectura controlada por API o réplica de solo lectura.
- Jobs/colas para exports e ingesta (idempotentes).
- Tablas o archivos versionados con fecha + git SHA del transform.
- Métricas de frescura: “¿cuándo llegó el último pedido al warehouse?”.
WordPress / WooCommerce como fuente
- Pedidos + line items + meta: documentar qué meta keys importan.
- Usuarios/clientes: deduplicar por email con reglas explícitas.
- Multisite: decidir si el análisis es por sitio o consolidado.
- Contenido para RAG: páginas publicadas, slug estable, HTML limpio.
- Evitar scrapear el front: REST/export/SQL con usuario de solo lectura.
Privacidad
- Minimizar columnas (“¿hace falta la cédula para este informe?”).
- Separar ambientes; no copiar producción entera a un laptop.
- Enmascarar o hashear cuando baste.
- Retención definida para logs con PII.
- Acceso por rol — también en el dashboard.
RAG pragmático
Cuando el caso es documentación interna, FAQs o catálogo, un RAG bien acotado suele rendir más que un fine-tune caro:
- Fragmentar documentos con metadatos (fuente, fecha, idioma).
- Guardar embeddings versionados.
- Citar siempre la fuente al usuario interno.
- Medir: % de respuestas con cita válida, escalados a humano.
- Reindexar cuando cambia el catálogo o las políticas.
Errores frecuentes
- Entrenar sobre pedidos de prueba mezclados con reales.
- Usar el total del carrito del front como “ground truth” de revenue.
- Dashboards sin fecha de corte ni definición de “pedido cancelado”.
- RAG sin cita: el usuario interno copia la alucinación al cliente.
- Jobs de sync que fallan en silencio.
Conecta con datos para IA, integraciones y auditoría de seguridad .