Data mistakes that derail AI projects in Peruvian businesses

First identify which decision went wrong

If the ERP records boxes and the promotions spreadsheet uses individual units, the assistant may calculate a total consistent with incompatible data. Ask: which customer received the quote, for which product, under which conditions and with information from what point in time? This distinguishes a source error, an incorrect transformation and an assistant interpretation. NIST proposes managing risks throughout the system lifecycle, including evaluation [1].

ERP, CRM and Excel may not refer to the same customer

Do not join customers solely by business name or products by description. Maintain reviewed ERP/CRM mappings, with a source and owner. SUNAT describes RUC as a unique eleven-digit identifier [7]. Storing RUC, customer codes and SKUs as text is a technical recommendation: avoid truncation and unnecessary conversions. An acceptable format or matching name does not prove business identity or fiscal validity. The applicable check requires a separate, authorized procedure.

Preserve the original value and applied rule when normalizing a field. Agree on formats, separators and time zones for dates and amounts. SQL Server's TRY_CONVERT may return NULL when conversion fails; some explicitly prohibited conversions raise an error [2]. Do not turn a failure into zero or present it as confirmed data.

Four mistakes at an illustrative distributor

Imagine a distributor selling in Lima and Arequipa: ERP for orders and inventory, CRM for contacts and Excel for promotions. A salesperson requests a replenishment proposal. These records show what to review before answering:

Follow the proposal's data journey

The proposed journey is source → preparation area → mappings and transformation → authorized query → commercial draft → human review. Each proposal retains identifiers, the price version, inventory timestamp and conditions used. The reviewer sees enough evidence to correct it without receiving other customers' information. If a contract is incomplete or a price cannot be verified, the assistant requests clarification or refers the case; it does not fill the gap with an invented condition.

Assigning one commercial owner for conditions, another for master data and another for operations is an organizational proposal. It should be adapted to the team's size. A correction is demonstrated when the same case runs again and produces the expected customer, product and total, not when someone manually changes the final answer.

A convincing answer does not grant permissions

The destination system must decide which user may query prices, contacts or contracts. An account used to prepare proposals should not be able to delete customers or freely change conditions. OWASP recommends limiting functionality and permissions, together with human approval for high-impact actions [3]. Instructions inside a file do not authorize broader access.

Avoid duplicate writes and close the loop

If CRM and ERP create the order independently, a retry may produce two sales. Define which system confirms the operation and a stable business key for recognizing repeated requests. Compare identifiers, states, counts and totals by currency across the proposal, order and ERP result. When state is uncertain, query and reconcile before resending; a timeout may occur after the system records the order.

Classify human corrections: identity, price, inventory, document or interpretation. Turn each significant error into a test case and address its cause. This feedback improves data and rules; decide separately which observations may be used to evaluate or train a model.

What to check before expanding the pilot

• Proposals accepted after review, separating those requiring correction.
• Identity, currency, unit and pricing errors across evaluated cases.
• Queries using outdated information and cases correctly referred to a person.
• Duplicate orders and outstanding reconciliation differences.
• Total time and cost to an accepted proposal, including review and rework.

Dova documents Mappings for designing transformations, Sessions for configuring execution and Workflows for organizing them [5]. Monitor helps track tasks and relate errors to a Mapping, Session and worker [6]. Evaluate the connectors and transformations available for your systems, and agree which team will implement business validation and reconciliation. Verify each integration's outcome and retain exceptions requiring intervention.