Your AI is only as good as your data: why integration comes first

Almost every stalled AI pilot we get called into looks the same from the inside. The model was fine. The demo worked on the sample extract. Then someone pointed it at production and the answers stopped matching what the business knew to be true, because the customer record in the CRM disagreed with the one in the finance system, the product catalogue had been exported to a spreadsheet eight months ago, and nobody could say which of the two addresses on file was current.

That is a data problem wearing a model costume. This post is part of our AI-Ready Data and Integration series, and it covers the part that has to happen before any of the interesting work: getting a trustworthy view of your own operations into a form a machine can read.

Why software engineering got there first

AI uptake has run far ahead in software engineering compared with other business functions, as The Economist set out in August. The usual explanation is that developers are early adopters. A better one is that code is already in the shape AI needs. It is text, it is versioned, every change has an author and a timestamp, and there is exactly one repository that counts as the truth. A coding agent never has to work out which branch is the real one.

Now look at the data behind a typical Australian mid-market operation. Customer records in a CRM, billing in an ERP, service history in a ticketing system, a warehouse that only some reports use, and a set of spreadsheets that hold the rules nobody wrote down. No timestamps you would trust. No agreed precedence. An AI project starting there is being asked to do the reconciliation work first and the clever work second, with no tools for the first job.

What AI-ready actually requires

Three things, and none of them are model choices.

A master view. One place that resolves customers, products, transactions and the events connecting them into single records, with the source of every field recorded. Not a copy of each system side by side, which is what most “data lakes” turn out to be, but a resolved view where the question “how many active customers do we have” has one answer.

Freshness guarantees you can state in numbers. For each entity, how old can this be before it is wrong to act on it? Contact details might tolerate a day. Stock levels might tolerate five minutes. Write the number down per entity, measure it in production, and alarm on it. This matters more than which model you pick, because the model contributes nothing current by itself. A public tracker of 20 models across eight labs shows median release age measured in weeks and training cutoffs months behind release, and only half of those models publish a cutoff at all. Everything the model knows about your customers arrives at query time from your systems, or it does not arrive.

A conflict rule. When two systems disagree, one of them wins, and the rule is written down before the disagreement happens. This is the part organisations skip. It is also the part that decides whether anyone trusts the output six months in.

An architecture that survives contact with production

This is the shape we build, and it is the shape Centazio, our open-source integration platform, is designed around.

• Read functions per source system, each one responsible for pulling changes and nothing else. They write raw payloads to staging, unmodified, with the retrieval time recorded.
• Promote functions that map staged payloads into core entities. Mapping rules live here, in code, under version control.
• An entity mapping store that holds the relationship between external identifiers and internal core identifiers, so the same customer arriving from three systems resolves to one record and you can always trace back which system contributed which field.
• Write functions that push core state back out to the systems that need it, closing the loop rather than leaving the master view as a read-only reporting artefact.
• Checkpoints and operational state per function, so a failed run resumes from where it stopped instead of reprocessing everything.

Conflict resolution sits in the promote step and should be boring and explicit:

// Billing owns the legal entity name and ABN.
// CRM owns contact details, but only if its record is fresher than billing's.
// Anything older than the freshness budget is not promoted at all; it raises an alert.
var name    = billing.LegalName ?? crm.TradingName;
var email   = Fresher(crm.UpdatedUtc, billing.UpdatedUtc) ? crm.Email : billing.Email;
var stale   = UtcNow - Newest(crm, billing) > budgets.Contact; // 24h
if (stale) alerts.Raise(ConflictAlert.StaleEntity, coreId);

Five lines of deterministic code replace an assumption the model would otherwise have to guess at. That is the argument the author of CodeIO made in September about AI-assisted development: supply deterministic, verifiable inputs and you get measurably better output than letting the model infer context. The same principle holds at the data layer. Every fact you can resolve before the prompt is a fact the model cannot get wrong.

Contradiction is the normal case

There is now open-source tooling whose entire premise is that AI sessions silently contradict earlier state unless one authoritative record exists. Engineers building agent infrastructure are separating persistent memory from durable execution for the same reason: the record of what is true has to be managed separately from whatever the agent is doing this minute. When practitioners build guardrails against a failure, that failure is the default behaviour, not an edge case.

Meanwhile the market’s instinct is to add more surfaces. September brought another wave of tooling to connect agents to WhatsApp. Every new channel is another place a customer can state a fact and another version of that fact to reconcile. Adding channels before you have decided which system wins multiplies the contradictions.

The stakes rise when the AI starts acting

An AI that drafts a summary and gets it wrong wastes a few minutes. An AI that has authority to transact does something to the world. The Atlantic wrote in September about handing a personal assistant a credit card, and the point generalises to any agent with write access to your systems: bad underlying data now produces a wrong action, an incorrect invoice or a refund to the wrong account.

Source-of-truth governance is also a security control. Lakera’s public agent-breaker exercises demonstrate agents being subverted through the content they ingest. If your agent reads free-text fields that anyone outside the organisation can write into, those fields are an input channel for instructions, and they need the same treatment as any other untrusted input. Under the Australian Privacy Principles you also need to know which system holds the authoritative copy of personal information before you can answer a correction request, which is a good reason to sort this out regardless of AI.

In administrative health settings, the same architecture applies to referrals, bookings and billing reconciliation. Any output that touches clinical judgement needs a named clinician signing off inside the workflow, designed in from the start, with the AI restricted to assembling and presenting the record.

A readiness checklist before you fund anything

Ask your team these questions. Written answers, not verbal ones.

1. For customers, products and each other core entity, which system is authoritative, and where is that written down?
2. When two systems disagree on a field, what is the resolution rule and who approved it?
3. What is the freshness budget for each entity, in minutes or hours, and do we measure the actual lag today?
4. Can we trace any field in a report back to the system and the record it came from?
5. How many customer records exist in more than one system with no link between the copies?
6. If the AI writes back to a source system, what is the rollback path when it writes something wrong?
7. Which free-text fields does the AI read, and who can write into them from outside the organisation?

An initiative that cannot answer one to three should fund integration work first. The AI project does not disappear; it starts three months later with a foundation, and it usually gets cheaper because the prompt no longer has to compensate for missing context.

What it costs

Integration is unglamorous and it is usually the larger half of a first AI project’s budget. Connecting two systems properly, with mapping, conflict rules, monitoring and a replay path for failures, takes weeks rather than days, and legacy systems with poor APIs take longer. We built Centazio and released it as open source because we were rewriting the same staging, checkpointing and entity-mapping machinery on every engagement, and that machinery is not where the value sits.

The payoff is that the work is reusable. A master view built for a customer service assistant also serves the next forecasting model, the reporting rebuild and the system you replace in two years. Model choice is a decision you will revisit every few months as the tracker above keeps ticking over. The data foundation is the part you build once.

PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.