Is Your Company's Data Ready for AI? An Honest Checklist

Every enterprise AI conversation eventually hits the same wall. The demo was impressive. The vendor was convincing. The board is asking. And then someone in the room says the quiet part: we don't even know where half our data is.

That instinct is right more often than it is wrong. Across the enterprise AI work we see, the data foundation stalls far more initiatives than the model ever does; the model was rarely the real bottleneck. Yet the usual response is worse than the problem itself: a data-cleanup program that runs for quarters, spends serious money, and postpones AI indefinitely while chasing a perfection that never arrives.

There is a better question than "is our data clean?" It is "is our data ready?" Those are not the same thing. This article is a checklist for answering the second question honestly, about your own company, this week.

What does "ready" actually mean?

Readiness is not perfection. A company whose data is scattered, partially duplicated, and imperfectly clean can still be genuinely ready for AI, provided it knows three things: where the data lives, who owns it, and which of it can be trusted.

The reverse is also true. A company with a modern warehouse and a dashboard on every wall can be deeply unready, because nobody can say which of three revenue numbers is the real one, or who has the authority to decide.

An AI system answering business questions does not need every field to be correct. It needs to know which fields to use, which to ignore, and what the words in them mean. That is a knowledge problem before it is a cleanliness problem, and knowledge problems are much faster to fix. For the mechanics of how AI actually consumes enterprise data, read what an AI intelligence layer is; here, the short version suffices: AI answers are only as good as the mapped, governed data behind them.

What are the four dimensions of readiness?

Readiness breaks into four dimensions. Score yourself on each. The questions are designed to be answerable in a meeting, not a project.

1. Accessibility: can the data be reached at all?

The first dimension is brutally practical: can a system, not a person, get to the data?

• For each core system (ERP, CRM, POS, HRIS), is there any machine-readable way in: an API, a database connection, even a scheduled export? Or does data leave it only through a human downloading a file?
• How many of your critical numbers exist only inside one person's laptop or inbox?
• If a system's vendor disappeared tomorrow, could you still get your own data out?

A "no" here is not fatal, but it is the first thing to fix, because everything else depends on it.

2. Quality: can the data be trusted?

Quality matters, but ask about it precisely, not vaguely.

• For your five most-used reports, do you know roughly how wrong they are? "Sales data is 95% complete but region tagging is unreliable" is a ready answer. "Our data is messy" is not. It is an unexamined one.
• When two systems disagree on the same figure, is there a known rule for which one wins?
• Are the errors you know about concentrated (one bad field, one bad branch) or diffuse?

Notice what these questions do not ask: whether the data is clean. They ask whether the shape of the dirt is known. Known dirt can be worked around; unknown dirt poisons everything.

3. Governance: who owns what?

Ownership is the dimension most companies skip and most AI projects die on.

• For each core dataset, can you name one accountable person, not a committee, a person?
• Who decides who may see what? If a sales agent and a CFO ask the same question, should they get the same answer, and is that written down anywhere?
• When a definition changes (a new region split, a new discount policy), is there a path by which every downstream report learns about it?

Governance sounds bureaucratic. In practice it is the opposite of bureaucracy: it is the thing that lets you stop debating numbers in meetings.

4. Context and definitions: do the words mean one thing?

The quietest killer. Every company runs on words ("active customer," "net revenue," "on-time delivery"), and in most companies those words mean different things in different departments. Agreeing on one written meaning for each is the beginning of a semantic layer: the shared vocabulary that lets a machine resolve a business question the same way twice.

• Pick your three most important metrics. Would finance, sales, and operations write down the same formula for each?
• Do your systems use codes (CUST_TYP_3, amt_net_2) that only two veterans can decode?
• If those two veterans resigned this month, what fraction of your reporting logic walks out the door with them?

AI makes this dimension urgent in a way it never was before, because an AI system will answer confidently using some definition, and if your company has four, it will pick one. This is also why turning plain-English questions into SQL is only as reliable as the definitions underneath it. Agents scoped to a department, the way department-scoped AI agents work, only behave correctly when the definitions they inherit are explicit.

The checklist at a glance

To turn the table into a score, rate each dimension 2 (a confident written answer), 1 (partly known), or 0 (nobody can say). A total of 6–8 means you can start a scoped AI project now and fix quality in flight. A 3–5 means you are close, with one or two dimensions to shore up first. Below 3, the honest move is to map before you build. The four scores matter more than the sum, though: a company that lands 2 on accessibility and context but 0 on quality is in better shape than the reverse, because known gaps are workable and unmapped ground is not. That asymmetry brings us to the two most counterintuitive points on the list.

Aren't our spreadsheets a problem?

Probably not the problem you think. Spreadsheets are not a disqualifier for AI. Undocumented spreadsheets are.

A spreadsheet whose owner is known, whose columns humans can understand, and whose role in the business is mapped — "this is where the commercial team reconciles distributor claims before they enter the ERP" — is usable data. It can be connected, read, and reasoned about. That reconciliation file is exactly the kind of source an FMCG distribution agent reads from once it is documented rather than buried.

Contrast that with a warehouse of two hundred tables, half abandoned by a consultant three years ago, none documented, with nobody able to say which one is the source of truth for customers. That warehouse is more modern and less ready.

A mapped spreadsheet beats an unmapped warehouse. Every time.

The lesson is not "keep everything in spreadsheets." It is that readiness lives in the map, not in the technology. The work of getting there has a name and a shape of its own, covered in moving from spreadsheet chaos to governed data. Companies that skip the mapping and jump straight to tooling — often via a RAG or fine-tuning project — rediscover this the expensive way.

What should we fix first?

If the four dimensions all need work (and in most companies they do), the order matters. Fix access and definitions before quality.

The reasoning is practical. A quality program pointed at data you cannot access and have not defined cleans the wrong things to the wrong standard: months polishing a table that turns out to be nobody's source of truth, using a definition of "customer" that sales never agreed to.

Reverse the order and quality work becomes cheap and targeted. Once systems are reachable and definitions are written down, discrepancies surface on their own: you can see that the ERP and the CRM disagree about 3% of customers, and you know exactly which field, which branch, which period. Quality stops being a program and becomes a punch list.

There is a morale reason too. Access and definitions produce visible wins in weeks; quality programs, in quarters — if ever. Early wins are what keep the initiative funded.

How do you find out where you stand?

The default corporate answer is a data audit committee: representatives from every department, a long questionnaire, monthly meetings, a report in two quarters. Thorough in form, slow in fact, and usually stale before it is presented.

A structured diagnostic is the better instrument. Instead of asking every department to self-report everything, it walks a fixed protocol: inventory the systems, trace the critical data flows, name the owners, test the definitions against real questions. Because the protocol is fixed, it takes days, not quarters. And because it sits outside internal politics, it can say what a committee cannot: "this dataset has no owner," or "these two departments define revenue differently and neither will yield."

The output that matters is not a maturity score. It is a specific, written answer to the four dimensions above: here is where your data lives, here is who owns it, here is what can be trusted, here is what your words mean — and here is what to fix, in what order.

Where Nalar fits

Nalar is an AI intelligence layer for Indonesian enterprises: it connects the systems a company already runs — ERP, CRM, databases, spreadsheets — models how the business operates, and serves answers through department-scoped agents, dashboards, and WhatsApp. Everything in this article is the groundwork that makes that layer trustworthy, which is why we built the diagnostic before anything else.

That diagnostic is BARI: a structured AI-readiness assessment that reviews your systems, data flows, ownership, and definitions, and produces a written PDF report — including an honest "not yet ready" verdict when that is the truth, with the specific gaps that earn it. If you want to see what the destination looks like first, the interactive demo shows the working dashboard across six Indonesian industry archetypes. Start with whichever answers your bigger question — but start with the map, not the cleanup.