Cuando una empresa mexicana quiere “meter IA” al pipeline comercial, a la cadena de suministro o al servicio, casi siempre choca con lo mismo: el ERP dice una cosa, el CRM otra y el data warehouse llega tarde o incompleto. El problema no es solo técnico. Es de acuerdo entre sistemas y equipos sobre qué significa un cliente, un pedido, un inventario o un ticket.
Sin ese acuerdo —un contrato de datos— cualquier copiloto, scoring o automatización termina entrenado con versiones contradictorias de la realidad. Este artículo propone un enfoque práctico B2B para LatAm: integrar lo suficiente para que la IA produzca evidencia de negocio, sin montar un programa de integración de dos años.
Si ya revisaste el checklist de datos listos para IA, aquí bajamos al siguiente nivel: cómo conectar ERP, CRM y warehouse con contratos claros y un diseño API-first que un piloto pueda sostener.
Qué es un contrato de datos (y por qué importa más que el conector)
Un contrato de datos es un acuerdo explícito entre el productor y el consumidor de información: qué campos se entregan, con qué semántica, en qué frecuencia, con qué calidad mínima y qué pasa cuando el dato falla. No es un diagrama de arquitectura colgado en Confluence. Es un artefacto operativo que ingeniería, analítica y negocio pueden leer en una página.
En la práctica mexicana, “integrar SAP/Oracle/NetSuite con Salesforce/HubSpot y el warehouse” suele traducirse en hojas de cálculo de mapeo eternas, jobs frágiles y nadie dueño del significado de cliente activo. El conector (middleware, iPaaS, script) es solo el tubo. El contrato es lo que viaja por el tubo.
Para IA, el contrato es crítico porque el modelo no “entiende el negocio”: consume lo que le das. Si el CRM marca oportunidad ganada y el ERP aún no facturó, tu scoring de pipeline miente. Si el warehouse refresca cada noche y el copiloto responde en tiempo real, estás tomando decisiones con datos de ayer vestidos de inteligencia.
El error típico: el proyecto de integración infinito
El patrón clásico en medianas y grandes empresas de México y LatAm:
- Se abre un RFP de “plataforma de integración”.
- Se intenta sincronizar todo el maestro de clientes, productos, precios e historial.
- Legal y seguridad bloquean el alcance; TI pide seis meses más.
- El caso de uso de IA se diluye o se queda en demo con CSV exportado a mano.
La salida no es abandonar la integración. Es acotar el contrato al caso de uso. Un piloto de priorización de leads no necesita el catálogo completo de materiales. Un asistente de seguimiento postventa no necesita el mayor libro de contabilidad. Empieza por el mínimo conjunto de entidades que mueven el KPI del piloto.
API-first: diseñar para el copiloto, no solo para el reporte
Muchas integraciones nacieron para BI: ETL nocturno, tablas anchas, latencia alta. La IA conversacional y los agentes operativos piden otra cosa: lecturas confiables on-demand, escrituras controladas y trazabilidad.
Un enfoque API-first útil en este contexto implica:
- Contratos versionados (v1, v1.1) en lugar de “el job de anoche”.
- Semántica estable: un campo
customer_idsignifica lo mismo en CRM, ERP y warehouse. - SLAs de frescura: cuántos minutos/horas puede tener el dato para ese caso de uso.
- Errores observables: códigos, colas de reintento y alerta cuando el contrato se rompe.
No hace falta reescribir el ERP. Sí hace falta una capa (API gateway, servicio de dominio o vistas/contratos en el warehouse) que exponga lo que el copiloto puede consumir sin romper sistemas core.
Un contrato mínimo viable entre ERP y CRM
Para un piloto típico (scoring comercial, forecasts ligeros, asistente de account manager), define al menos estas entidades con dueño y reglas:
1) Identidad de cliente / cuenta
Quién es la fuente de verdad del ID canónico. Regla de matching (RFC, razón social, email dominio). Qué hacer con duplicados. Sin esto, la IA “multiplica” clientes y tus métricas de conversión se rompen.
2) Oportunidad vs. pedido / factura
Cuándo una oportunidad del CRM se considera real en el ERP. Campos mínimos: monto, moneda, etapa, fecha prometida, estatus de facturación. El contrato debe decir si el copiloto puede afirmar “cerrado” solo con CRM o necesita confirmación ERP.
3) Producto / SKU / servicio
Catálogo reducido al subset del piloto. Alias y unidades. Evita sincronizar 40,000 SKUs “por si acaso”.
4) Eventos de interacción
Llamadas, tickets, visitas, emails relevantes. Frecuencia y retención. Aquí suele estar el oro para modelos de churn o next-best-action, y también el riesgo de privacidad.
Cada entidad lleva: productor, consumidor(es), schema, frecuencia, calidad mínima (completitud, unicidad), y dueño de negocio. Si no cabe en una página, el alcance del piloto está inflado.
Warehouse: el tercer actor, no el basurero
El data warehouse (o lakehouse) no debería ser el lugar donde “ya unimos todo y vemos qué sale”. Para IA útil, el warehouse debe materializar vistas contractuales: tablas o datasets que cumplen el contrato del caso de uso, con tests de calidad y timestamp de frescura.
Una regla práctica: el copiloto o el job de entrenamiento no leen tablas crudas de staging. Leen el dataset publicado (customer_360_piloto_v1) con documentación de campos y un test que falla el pipeline si se rompe el contrato. Eso convierte “datos listos” en algo verificable, no en una promesa de la presentación.
Cómo ejecutar en 30–45 días sin teatro
Un plan realista para equipos de innovación + TI en México:
- Semana 1: elige un KPI y una sola decisión asistida (ej. priorizar 50 cuentas/semana). Lista entidades mínimas. Nombra dueños ERP, CRM y datos.
- Semana 2: escribe el contrato en una página + schema. Acuerda IDs canónicos y regla de matching. Identifica gaps de calidad (no los “arregles todos”: marca los bloqueantes).
- Semana 3: implementa la integración delgado: API o sync solo de esos campos. Publica dataset v1 en warehouse con tests básicos (nulos, duplicados, frescura).
- Semana 4–5: conecta el piloto de IA a v1. Mide línea base vs. asistido. Registra fallas de datos como incidentes del contrato, no como “la IA no sirve”.
- Semana 6 (opcional): versión v1.1 solo si el KPI lo exige. Congela alcance nuevo hasta tener evidencia.
Este ritmo encaja con un piloto de IA en 30 días: la integración deja de ser el monolito que retrasa todo y se vuelve un entregable semanal medible.
Gobierno ligero: quién firma el contrato
Sin burocracia de comité eterno, alguien debe poder decir “esto rompe el contrato”:
- Dueño de dominio (negocio): semántica (qué es un cliente activo).
- Dueño técnico de integración: pipeline, versionado, alertas.
- Consumidor IA / analítica: valida que el dataset sirve al modelo y al KPI.
Un cambio de campo en el ERP que silencie el CRM sin aviso es un incidente de producción, igual que una caída de API. Trátalo así y dejas de vivir de exports manuales el viernes a las 6.
Señales de que vas bien (y de que estás fingiendo integración)
Vas bien cuando: el copiloto cita un ID que existe en ERP y CRM; la frescura del dato está en un dashboard; un campo nuevo exige bump de versión; el piloto tiene evidencia de KPI sin “limpiar Excel a mano”.
Estás fingiendo cuando: cada demo usa un CSV distinto; nadie sabe qué sistema gana en conflicto; el warehouse tiene 12 tablas “cliente_*”; el proyecto de integración no tiene fecha de dataset v1.
Conclusión: la IA no arregla silos; los contratos sí los hacen manejables
En empresas mexicanas el cuello de botella de la IA rara vez es “falta de modelo”. Es la imposibilidad de confiar en una versión compartida del cliente, del pedido y del evento. Los contratos de datos entre ERP, CRM y warehouse —delgados, versionados, con dueño y SLA de frescura— son la base práctica para que un copiloto o un scoring dejen de ser teatro y pasen a mover el P&L.
No necesitas el landscape perfecto. Necesitas un contrato v1 lo bastante bueno para aprender en producción controlada, y la disciplina de no ampliarlo hasta tener evidencia.
Si tu equipo está atorado entre silos y un RFP de integración eterna, en NextWave AI te ayudamos a definir el contrato mínimo, la capa API-first y el piloto con métricas claras. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.
Add comment