Your Company Doesn't Have an AI Problem. It Has a Data Problem.

Why most AI projects in LATAM companies fail before they start, and what data engineering work needs to happen first to make them succeed.

“We bought the AI module from our vendor and it doesn’t work.” We hear this in nearly every first meeting with a new client. And in 90% of cases, the problem isn’t the AI.

It’s what sits underneath the AI: the data infrastructure. The invisible, unglamorous layer that nobody mentions in sales demos but that ultimately decides whether a project succeeds or ends up archived.

Why Does AI Fail in Companies That “Already Have Data”?

The short answer: having data is not the same as having usable data.

A 150-person company in the healthcare sector might have millions of records spread across its HIS, billing system, patient CRM, and a Google Drive folder full of spreadsheets. That data exists. But it’s not integrated, it doesn’t share a common model, and nobody transforms it consistently before it gets used.

When that company buys an AI module — for demand forecasting, automated triage, anomaly detection in billing — the module receives that mix. And what it produces is garbage with a polished interface.

This isn’t a new technological problem. It’s a problem of order.

The Stack Nobody Talks About

When companies talk about “implementing AI,” the conversation almost always starts at the most visible layer: the model, the interface, the dashboard. But there are three layers underneath that have to work first:

1. Source integration Is your data in one accessible place, or spread across five systems that don’t talk to each other? The first data engineering task is connecting those sources and creating a consistent flow of information into a central repository — something as simple as a well-modeled PostgreSQL database can do the job.

2. Quality and cleansing Duplicates, empty fields, inconsistent formats, records with historical load errors. These problems don’t disappear on their own — they propagate upward and poison every analysis or model that consumes them. Cleansing isn’t a one-time step: it’s a process that needs to be automated and monitored continuously.

3. Modeling and transformation Raw data from an operational system doesn’t come in the format that analysis needs. A sale in the accounting system is a row with 30 technical fields. For it to be useful in a report or an AI model, it needs to be transformed: margins calculated, categories grouped, linked to the customer, correct date assigned. That’s data transformation, and it has to live in an automated pipeline — not a spreadsheet someone updates on Fridays.

A Real Case in Healthcare

A medical center with three locations in Colombia had been running a clinical management system (HIS) for two years. They had patient data, appointments, diagnoses, medications, and lab results. They wanted to build a predictive model to identify patients at risk of not completing chronic disease treatments.

They hired an AI vendor. Six months later, the project was stalled.

Our diagnosis when we arrived: the HIS was recording data, but each location had configured it differently. The “primary diagnosis” field had three different formats depending on the site. Forty percent of follow-up records had incorrect appointment dates — the system date was the administrative entry date, not the actual consultation date. And lab data lived in a separate system that had never been integrated with the HIS.

The AI model had no problem. The problem was that there was no way to build a coherent dataset from what existed.

What we did before revisiting predictions:

• Map all three sources (HIS × 3 configurations + lab system)
• Define a unified data model for patient, appointment, and result
• Build transformation pipelines that normalized and loaded data into a central repository
• Implement automatic validation rules to catch future inconsistencies

That work took eight weeks. Afterward, the predictive model was implemented in two weeks and worked from day one.

When Does This Apply — and When Doesn’t It?

This problem applies to companies that:

• Have more than one operational system generating data (HIS, ERP, CRM, billing, etc.)
• Have been running those systems for more than two years without any integration work
• Have teams that prepare reports manually by pulling from multiple sources
• Want to implement AI, advanced analytics, or automations on top of that data

When it doesn’t apply: if your company has a single well-structured data source and reports are already generated automatically, integration is probably not your bottleneck. In that case, going directly to the analytics or modeling layer makes sense.

How to Tell If This Is Your Problem

Three concrete symptoms that signal data infrastructure is the bottleneck:

1. Reports take more than 48 hours If producing a monthly close report requires someone to extract from multiple systems, paste into Excel, and run manual calculations, you have an integration problem. Not an analytics problem.

2. Numbers don’t match across systems The ERP says one thing, the CRM says another, billing says a third. If there are three versions of the same metric depending on where you pull it from, your data isn’t integrated or consistently modeled.

3. Your data team spends more time preparing than analyzing If 60–70% of your technical team’s time is “getting and cleaning data,” the problem is the layer below — not the team’s capabilities.

The Work That Comes First

Before evaluating any AI or advanced analytics solution, a set of questions needs to be answered:

• What are all the data sources we’re generating?
• Are they connected, or does each department have its own silo?
• Is there a centralized place where processed data lives?
• Who is responsible for the quality of that data?
• What business decisions need what data, and how often?

With those answers, you can design a data architecture that fits the company’s actual size and budget. There’s no universal solution: for an 80-person company, a PostgreSQL database with simple Python pipelines might be more than enough. For a 500-person company, incorporating dbt and a more robust data warehouse could make sense. The key is not to over-engineer or under-engineer.

What is universal: that work has to happen before talking about AI.

Actionable Takeaway

This week, ask your team one question: how long does the monthly close report take, and how many people touch it before it reaches you?

If the answer involves more than two people and more than two days, you have evidence that the data layer needs work. That’s your starting point — not the AI model.

---

Frequently Asked Questions

How long does it take to fix data integration problems?

It depends on the number of sources and the quality of existing data. In projects we’ve seen, the range goes from 6 weeks (company with 2 relatively clean sources) to 4–6 months (company with 5+ systems carrying years of dirty data). The important thing is that it’s a finite, plannable effort — not a bottomless pit.

Can we implement AI while fixing the data?

In some cases yes, if there’s already one clean data source that enables a focused use case. But it’s not a recommended general strategy — you risk building on unstable foundations and having to redo the work later.

Does this require replacing our current systems?

Almost never. The most common approach is to keep existing operational systems (HIS, ERP, CRM) in place and build an integration and transformation layer on top, without touching them. The systems keep working the same way; what changes is how data gets consolidated and processed for analysis.

Is open source enough for this?

Yes, for most companies between 50 and 500 employees. PostgreSQL, dbt, Airflow or n8n, and a visualization layer like Metabase or Superset cover 90% of use cases with no licensing cost and no vendor dependency.

Where do I start if I don’t know what I have?

With a diagnostic. Before designing solutions, you need to map the current state: what sources exist, how they’re connected, what decisions depend on that data, how reliable it is. With that in hand, priorities become obvious.