Errores de datos que hacen fallar proyectos de IA en empresas peruanas

Primero identifica qué decisión salió mal

Si el ERP registra cajas y el Excel de promociones usa unidades, el asistente puede calcular un total coherente con datos incompatibles. Pregunta: ¿a qué cliente se cotizó, qué producto, bajo qué condiciones y con información de qué momento? Así distingues un error del origen, una transformación incorrecta y una interpretación del asistente. NIST propone gestionar riesgos durante el ciclo del sistema, incluida su evaluación [1].

ERP, CRM y Excel no siempre hablan del mismo cliente

No unas clientes solo por razón social ni productos por descripción. Mantén equivalencias ERP/CRM revisadas, con origen y responsable. SUNAT describe el RUC como un identificador único de once dígitos [7]. Guardar RUC, códigos de cliente y SKU como texto es una recomendación técnica: evita recortes y conversiones innecesarias. Un formato aceptable o un nombre coincidente no prueba identidad comercial ni validez fiscal. El cotejo aplicable requiere un procedimiento separado y autorizado.

Conserva el valor original y la regla aplicada cuando normalices un campo. Para fechas e importes, acuerda formato, separadores y zona horaria. TRY_CONVERT de SQL Server puede devolver NULL si falla una conversión; algunas conversiones expresamente prohibidas generan error [2]. No conviertas un fallo en cero ni lo presentes como un dato confirmado.

Cuatro errores en un distribuidor ilustrativo

Imagina un distribuidor con ventas en Lima y Arequipa: ERP para pedidos e inventario, CRM para contactos y Excel para promociones. Un vendedor pide una propuesta de reposición. Estos registros muestran qué revisar antes de responder:

Seguir el recorrido de la propuesta

El recorrido propuesto es origen → zona de preparación → equivalencias y transformación → consulta autorizada → borrador comercial → revisión humana. Cada propuesta conserva identificadores, versión del precio, momento del stock y condiciones utilizadas. La persona que revisa ve evidencia suficiente para corregirla, sin recibir información de otros clientes. Si un contrato está incompleto o un precio no puede verificarse, el asistente pide una aclaración o deriva el caso; no rellena el vacío con una condición inventada.

Asignar un responsable comercial para condiciones, otro para datos maestros y otro para operación es una propuesta organizativa. Debe adaptarse al tamaño del equipo. La corrección está demostrada cuando el mismo caso vuelve a ejecutarse y produce el cliente, producto y total esperados, no cuando alguien modifica manualmente la respuesta final.

Una respuesta convincente no concede permisos

El sistema de destino debe decidir qué usuario puede consultar precios, contactos o contratos. Una cuenta usada para preparar propuestas no debería poder borrar clientes o cambiar condiciones libremente. OWASP recomienda limitar funciones y permisos, además de aprobación humana para acciones de alto impacto [3]. Las instrucciones dentro de un archivo no autorizan ampliar ese acceso.

Evitar doble escritura y cerrar el ciclo

Si CRM y ERP crean el pedido por separado, un reintento puede producir dos ventas. Define qué sistema confirma la operación y una clave de negocio estable para reconocer solicitudes repetidas. Compara identificadores, estados, conteos y totales por moneda entre propuesta, pedido y resultado del ERP. Ante un estado incierto, consulta y concilia antes de reenviar; un timeout puede ocurrir después de que el sistema registre el pedido.

Clasifica las correcciones humanas: identidad, precio, stock, documento o interpretación. Convierte cada error relevante en un caso de prueba y ajusta su causa. Esa retroalimentación mejora datos y reglas; decide por separado qué observaciones pueden utilizarse para evaluar o entrenar un modelo.

Qué comprobar antes de ampliar el piloto

• Propuestas aceptadas tras revisión, separando las que necesitaron corrección.
• Errores de identidad, moneda, unidad y precio sobre casos evaluados.
• Consultas con información vencida y casos derivados correctamente a una persona.
• Pedidos duplicados y diferencias de reconciliación pendientes.
• Tiempo y costo total hasta una propuesta aceptada, incluyendo revisión y retrabajo.

Dova documenta Mappings para diseñar transformaciones, Sessions para configurar ejecución y Workflows para organizarlas [5]. Monitor ayuda a seguir tareas y relacionar errores con Mapping, Session y worker [6]. Evalúa los conectores y las transformaciones disponibles para tus sistemas, y acuerda qué equipo implementará la validación de negocio y la conciliación. Comprueba el resultado de cada integración y conserva las excepciones que requieren intervención.