When Enterprises Adopt AI, the First Hurdle Isn't the Model—It's the Data Scattered Across Excel Files

Six product features we care about most

1. Deterministic: understand once, then process according to approved rules

The first time it encounters an unfamiliar table, AI can help identify possible header rows, column names, date formats, total rows, and data granularity. Rather than treating its guesses as official fact, it first proposes a definition that can be reviewed. Once the user confirms "what each row represents," "which column is the actual amount," and "which rows should be excluded from analysis," the system saves these determinations as formal rules.

The next time a file in the same format arrives, the data pipeline executes according to the already-approved definitions, without needing to consume model resources again to guess the purpose of every field. This is the core of "deterministic": not treating every cleanup as a brand-new conversation, but turning steps that have already passed business review into a repeatable procedure.

But deterministic doesn't mean errors never happen. A data source might change format, a vendor might rename a field, or even different departments exporting from the same system might produce different formats. When fixed rules encounter incompatible changes, the correct response isn't to force bad data into the warehouse — it's to detect the structural change, pause or quarantine the affected data, and ask a person to confirm. Stability comes from clear rules and change management, not from claiming that "AI learns it once and never needs to be checked again."

2. Replayable: can be rerun without inflating numbers through resends

Enterprise data import almost always runs into resends. A report sent by mistake and resent, the same file uploaded twice, a scheduled job interrupted and re-run, or accounting correcting last month's records at month-end — all of these are everyday scenarios. If the system simply appends whatever it receives each time to the end of the data table, rerunning it even once could cause revenue, order count, or inventory levels to inexplicably double.

So the system needs to know what conditions identify the same piece of business data. It might be order ID plus item line number, or it might require combining store code, transaction date, and a serial number. This identification method should be determined by the enterprise's business definitions — it can't rely solely on filename or row number as a permanent unique key. When the same record appears again, the system needs to be able to update the existing data according to the rules, or identify it as a duplicate — rather than blindly accumulating it.

Replayability also gives corrections a formal process. Suppose we discover that a date was previously read as text, a discount field was mistakenly left out, or product line items in the same order were incorrectly summed — as long as the original file, the versioned processing definitions, and execution logs are preserved, we can fix the rule first and then reprocess the affected period. This makes data results traceable and gives enterprises the ability to answer "where did this number come from" and "which version of the rules produced this report."

It's worth noting that replayability isn't a reason to keep all original files forever. Whether the raw data contains personal information, how the retention period should be set, who has the right to rerun processes, and whether old versions should be deleted or masked — all of this must be incorporated into the enterprise's existing data policies. Rerunnability solves the problem of technical recoverability; it doesn't automatically fulfill a company's data retention and personal data management responsibilities.

3. Reviewable: how AI understands data can be inspected and corrected by people

A great deal of data cleaning knowledge exists only in the heads of senior colleagues. People know "those two rows at the top of the report should be excluded," know that a field labeled "status" actually refers to shipping status, and know which set of codes needs to be used to match up two lists. In the short term, asking that colleague is the fastest solution; in the long term, if this critical knowledge is never documented, it disappears with staff handovers, organizational changes, or departures.

Reviewable means laying out AI's understanding of the data for inspection: how fields are named, what type each field is, whether each row represents an order or an order line item, which fields can be summed, which data should be excluded, and how different sources connect. Business staff can add domain knowledge, data staff can verify technical settings, and managers can confirm whether metric definitions align with how the business talks about them. This isn't about adding extra approval steps — it's about turning data rules that previously only existed through word of mouth into assets the organization can maintain together.

Reviewability should also include change history. When a field definition changes from "sales amount" to "net sales amount after deducting refunds," the enterprise needs to know who made the change and when, which dashboards are affected, and whether old reports are still using the old definition. Data definitions aren't built once and set in stone forever — they evolve along with business processes, product forms, and regulatory requirements. Trackable version management can prevent the same name from representing different numbers in different departments.

4. Validatable: data passes checks before flowing into analytics and AI Q&A

Automation shouldn't just mean errors happen faster. Missing fields, date formats that don't match expectations, product codes that don't correspond to any product, or order totals that diverge significantly from the sum of line items — these problems should all be flagged before data enters the analytics layer.

We think of validation as a quality gate. Basic checks can confirm whether fields exist, whether types are correct, whether required fields have null values, and whether primary keys are duplicated. On top of that, business rules can be added — for example, a transaction date shouldn't be too far after the import date, a discount can't exceed the original amount, a cancelled order shouldn't be counted as valid revenue, or every store should have data every week. For financial or inventory data, reconciling against the original ERP's aggregate figures is also important — otherwise a file that looks correctly formatted might still be missing an entire batch of data due to some step in the transformation process.

Validation results don't need to be limited to just "pass" or "fail." If an error involves a high-risk field, such as transaction amount or personally identifiable information, the system can quarantine the data first and ask for human confirmation; if it's just a non-critical note field with a new format, it can flag a warning and continue processing other fields. Separating alert levels from business impact helps avoid the dilemma of either shutting everything down completely or ignoring every anomaly.

The AI Foundation's 2025 survey on Taiwan's industrial AI adoption, through expert interviews, discusses how data standards, data quality, and use cases must be considered together. Data isn't "governed" just by being stored — it also needs to be able to support real decisions, have a responsible owner, and be identified and corrected when it changes. 6

5. Evolvable: as new sources arrive, existing data can gradually grow new relationships

Enterprises don't need to wait until every department has completed a full data inventory before starting their first analytics project. Starting with only sales detail data, you can first answer "which products have been selling best recently"; once inventory data is added, you can see "which products' sales are increasing while their inventory is gradually running low"; once customer or membership data is connected, you have the opportunity to understand "what different customer segments purchase, and how long it takes them to reorder." The data model can expand step by step according to real needs, rather than requiring every source across the entire enterprise to be collected all at once at project kickoff.

However, adding new data doesn't just mean joining two tables together using text fields that look similar. Product names might have abbreviations, spaces, or old versus new naming; customer IDs in different systems might also be entirely independent. When establishing relationships, you need to confirm whether the identifier keys on both sides are stable, whether the relationship is one-to-many or many-to-many, whether historical records need to be preserved, and how unmatched items should be handled. If "Taipei Store" and "Taipei Branch" are mistakenly treated as two different stores, or two different customers with the same name are merged together, no amount of smooth AI interpretation afterward can fix the broken data model.

Another benefit of an evolvable model is that enterprises can treat every new data source as an opportunity to expand data value. When only monthly revenue was available, managers could only look at results; once promotional activity and inventory changes are added, they can compare inventory turnover and sales differences before and after a campaign; adding customer service feedback on top of that lets them trace the causes of returns for best-selling items. As relationships between data grow, old data can also answer more questions thanks to new context.

6. Query-ready: preserving business semantics while cleaning data

Removing blanks, standardizing dates, and fixing typos are only part of data organization. If, after loading into the warehouse, the system still doesn't know what "product," "order," or "customer" each refer to, doesn't know which column is the official revenue figure, and isn't clear on how two tables should connect, then AI Q&A will still have to re-guess every time — and might even make hard-to-detect mistakes in answers that look perfectly reasonable.

That's why we want to build a basic semantic layer alongside the data cleaning stage. The semantic layer translates data fields into the concepts the enterprise actually uses: what granularity a sale record represents, how net revenue is calculated, how refunds should be deducted, which product category coding is used, whether dates follow the transaction date or shipping date, and how different datasets relate to each other. The goal is to give BI tools or AI queries a clear business context to work from, instead of having to guess based on column names alone.

The same metric can also have different versions depending on context. The finance department might use revenue recognized by invoice as the standard; the operations team might look at sales based on shipped orders; the marketing department might want to see campaign conversion after excluding cancelled orders. These definitions don't necessarily need to be forced into a single unified answer — a more practical approach is to clearly document each metric's name, calculation method, applicable scenario, and responsible owner, and let the system know which definition to apply when a user asks a question.

Once data granularity, relationships, and metric calculation methods are clearly described, AI's job becomes more than just translating a Chinese-language question into a database query. It can also use the semantic layer to identify which kind of sales figure, which time period, which product dimension, and which data shouldn't be mixed together in a given question. Of course, the semantic layer still needs to be approved by business owners — it's not a magic module that can automatically derive all business logic from field names alone.