Lee Siang Fong

Blog

Data Is the Foundation of Enterprise AI

Useful enterprise AI starts with reliable business data, context and access. A SenangAI perspective on turning scattered records into decisions you can trust.

An AI system can explain cash flow clearly and still give the wrong answer about your cash position. To answer that question, it needs the relevant bank balances, receipts, payments and timing, with enough context to interpret them correctly. Data is the foundation of enterprise AI, not a feature to connect after the main product is finished.

The model matters. So do reasoning, software design and the experience of using it. But when a business asks AI about its own operations, the answer must connect to what is actually happening inside that business.

What Western Digital’s argument means for business AI

In an article published on 28 October 2026, Western Digital sets out CEO Irving Tan’s view of AI as a data system. Its focus is the architecture needed to move, access, store and preserve data, with performance, capacity, reliability and economics considered together.

That is a storage company’s perspective on AI infrastructure. The useful question for a business owner is what happens further along that chain: once the data is available, can the AI use the right evidence to answer a business question?

A file being stored does not establish that it is current. A database connection does not establish that its records mean what the model assumes. Making data available is the beginning of the job.

A better model cannot supply a missing business record

There is a difference between understanding a concept and knowing the state of a company.

A model may explain credit limits, stock allocation or profit margins. It still needs the company’s records to establish whether a customer has exceeded a limit, whether stock is already committed, or whether a proposed discount leaves enough margin.

Consider a fictional distributor deciding whether to accept a large order. Its warehouse system shows stock on hand. Its sales system contains earlier orders. Finance has placed one customer on hold. A supplier’s revised delivery date is sitting in an email.

An answer based only on warehouse stock could look convincing and still miss the commitments that determine what the business can promise.

The missing work is connecting the relevant records, checking their timing and understanding the rules around them. A model upgrade may improve interpretation, but it cannot establish a fact contained in a record the system has never received.

An enterprise AI data foundation needs meaning

The phrase “connect your data” can hide several separate jobs.

Identity: Do two records refer to the same customer, supplier or product? Similar names may belong to different businesses. Different names may belong to the same one. Suspected matches need evidence and a way to resolve uncertainty.

Definitions: What does a field mean? Stock on hand may include reserved goods. Revenue may mean orders, invoices or recognised sales. A correct calculation against the wrong definition can still mislead the person using it.

Time: When was the record true, and when did the AI last receive it? Yesterday’s export may be suitable for a monthly review and unsuitable for committing today’s remaining stock.

Source: Where did the information come from, and which source governs this decision? Two departments can hold different figures for legitimate reasons. The system should expose the difference before treating one as authoritative.

Access: Who is allowed to use it? Bringing records together should preserve the restrictions around customer details, salaries, supplier costs and other sensitive information.

These are business decisions as well as technical ones. IT can connect a field called “available balance”. Finance still needs to explain what that balance includes and when it can be relied on.

Retrieval helps, but it needs its own checks

One common approach is retrieval-augmented generation, or RAG. It retrieves supporting information and supplies it to a language model when answering a question.

Microsoft’s documentation explains how this can bring private or updated information into an answer, support source citations and restrict retrieval according to user credentials. It also includes evaluation, monitoring, data lineage and access controls as parts of the wider system.

The practical lesson is that a search connection needs ongoing care. A refresh can fail. A document can be superseded. A relevant record can be missed. An answer can cite a real document while interpreting it incorrectly.

I would therefore test the retrieved evidence as well as the final response. Did the system find the records needed for the question? Were they current enough? Did the answer follow from them? Did it reveal anything the user was not allowed to see?

For more on how these approaches fit together, see my guide to RAG, AI agents and agentic RAG.

Start with imperfect data and a clear boundary

Treating data as fundamental does not mean postponing AI until every spreadsheet and system is perfectly organised.

Start with one question that matters. Identify the minimum evidence needed to answer it, the person responsible for each source, and the conditions under which the answer should be withheld or qualified.

For the distributor, that could mean checking stock, existing commitments and customer status before suggesting whether to accept an order. A missing supplier confirmation should remain a visible gap. It should not quietly become an assumed delivery date.

Then test ordinary cases alongside missing records, conflicting figures, delayed updates and denied access. A useful outcome may be a qualified answer that explains exactly what a person needs to check next.

NIST’s AI Risk Management Framework places validity and reliability in the context of intended use and describes ongoing testing and monitoring as ways to assess them. For a business, that means evaluating the actual decision being supported, rather than judging the system by how polished its demonstration sounds.

How this shapes our thinking about SenangAI

At Kognosys, our intended direction for SenangAI is to help businesses identify issues, investigate causes, assess risks and uncover opportunities across the information they are permitted to use.

That puts the relationship between records, business meaning and decisions at the centre of the design. The goal is for people to inspect the evidence behind an answer, understand what is uncertain and decide what should happen next.

This is broader than searching documents. A possible profit opportunity needs cost and sales context. A warning about overdue payment needs the relevant invoices, receipts and agreed terms. An explanation of an operational problem needs enough history to investigate causes without presenting a guess as a finding.

Those are design goals, and each deployment needs to demonstrate its data coverage, permissions, update behaviour and answer quality. Connecting a source is one milestone; showing that it supports a real decision is the more useful test.

When planning enterprise AI, ask which business question you want to answer and what evidence would make that answer dependable. That is a practical starting point for an enterprise AI roadmap.

The strength of an enterprise AI data foundation is visible in the decisions it can support, the limits it can explain and the gaps it helps the business resolve.

Quick answers

Why is data fundamental to enterprise AI?

Business-specific answers depend on relevant records, their meaning, timing and permitted use. A capable model still needs that evidence to answer questions about the company’s actual operations.

Must all our data be clean before we start?

No. Start with a bounded use case, identify the evidence it needs and make missing or conflicting information visible. Resolve the problems that materially affect that decision, then expand.

Does RAG guarantee an accurate answer?

No. It can supply relevant source information, but retrieval can miss evidence and the model can misinterpret it. Test both retrieval and the resulting answers against the intended business use.

Is storing all data in one place enough?

No. Storage is part of the foundation. The system also needs appropriate definitions, source history, update processes and access controls, whether the records remain distributed or are brought together.

Sources