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

From the data warehouse upward: only then can AI enter daily work

Getting data organized doesn't mean enterprise transformation is complete. It's more like laying a solid foundation that lets downstream data analytics, BI dashboards, natural language Q&A, and AI agents have a reliable data source to work from. If the data foundation lacks permissions, versioning, and definitions, the AI layer on top is likely just to produce seemingly complete but actually inconsistently-defined answers faster.

McKinsey's 2026 "State of AI" survey shows that nearly 90% of respondents say their organization regularly uses AI in at least one business function, and 44% say AI has been scaled at the enterprise level, up from 38% the previous year. But "being used" doesn't equal "fully delivering measurable financial returns": 37% of respondents said AI has made a positive contribution to enterprise EBIT, roughly similar to the previous year; about 6% are classified as AI high performers. These figures are worth pausing on: the scope of AI usage is expanding, but that doesn't mean every pilot has translated into measurable operational value. 7

Another McKinsey analysis points out that workflow redesign is one of the factors correlated with whether surveyed organizations see an EBIT impact from generative AI; among respondents using generative AI, 21% said their organization has fundamentally redesigned at least part of its workflows. This is a correlational observation from the survey — it doesn't mean that changing processes will definitely increase profitability, nor is it a causal guarantee for every company. But it shows us that enterprises shouldn't just bolt AI onto old processes; instead, they should ask: which decisions, handoffs, waiting periods, or repetitive organizing tasks could be redesigned? 8

For many enterprises, once data is loaded into the warehouse, the first actionable change isn't necessarily a fully automated AI agent — it's shortening the time it takes to get an answer. Where colleagues used to spend hours every month merging ERP, warehouse, and sales reports, that fixed process can now be automated first, letting managers ask about inventory turnover, channel sales, or product changes in natural language. The next step is to connect these query results to restocking, customer service, or budgeting processes, so data doesn't just sit on a dashboard but becomes the basis for actual action.

BusinessNext's 2026 report on Aotter and AotterClam AI describes the data engineering problem using the scenario of enterprises organizing monthly performance, accounting, and inventory data, and also reports on how a traditional enterprise, after considering rebuilding its ERP, instead chose to examine the reports output by its legacy systems and build a separate data warehouse. This is an individual company's case and shouldn't be directly generalized to mean every enterprise doesn't need to replace its ERP; but it points to an often-overlooked option: if a legacy system still supports core operations, an enterprise can first improve how data is used across systems before evaluating whether a full replacement is needed. 9

Data governance isn't about locking data away — it's about letting data be used within the right boundaries

Whether a data warehouse is queryable is only part of governance. True governance also includes the source and purpose of data, data quality, field definitions, retention periods, sensitivity, permissions, audit logs, exception handling, and accountability. If data can't be used at all, it can't create value; but if everyone and every model can see all data without restriction, that's equally not mature governance.

Taiwan's "Artificial Intelligence Basic Act" passed its third reading in the Legislative Yuan on December 23, 2025. The seven principles compiled by the Ministry of Digital Affairs include sustainable development and well-being, human autonomy, privacy protection and data governance, cybersecurity and safety, transparency and explainability, fairness and non-discrimination, and accountability. These principles place data governance within the basic framework of AI development, and also remind enterprises that adopting AI involves not just model capability, but also how data is obtained, who is responsible for it, how it's disclosed, and how issues are traced when something goes wrong. 12

The EU AI Act takes a risk-tiered approach rather than applying identical requirements to every AI use case. For certain high-risk systems, the relevant rules cover aspects such as dataset quality, risk management, activity logging, documentation, human oversight, robustness, and cybersecurity; the EU's official timeline has also been subsequently adjusted, with rules for some high-risk use cases postponed to take effect starting in 2027. Enterprises should therefore confirm applicable obligations based on their target markets, actual use cases, and data types, rather than oversimplifying the "EU AI Act" into a single checklist that every internal AI tool must follow. 13

When planning data governance, we bring the discussion back to daily operations. Who can view sales data? Does customer service data contain personal information? Can managers download query results? When using external AI models, which fields get sent out? How long are original files retained? If a colleague leaves or changes roles, when are their permissions revoked? After data is corrected, how do old reports and model answers get updated? These questions may seem less glamorous than "how smart is the model," but they determine whether an enterprise can confidently put AI into its workflows.

The AI Foundation's 2025 expert interviews on data governance also point out that data governance needs to start from strategy and use cases — it can't be left solely to the IT department to define fields and install tools. Business leaders best understand which decisions the data needs to support, while the data team can translate definitions into standards, quality checks, and data lineage; the two need to take joint responsibility. The governance capabilities raised in the interviews — data being discoverable, accessible under proper authorization, debuggable, and deployable into real processes — align well with the need for enterprises to move data from merely "stored" to "usable." 6

To turn governance into executable work, enterprises can create a concise data contract for each important dataset. The contract doesn't need to be a thick rulebook, but it should at least list the source system, data owner, purpose of use, the granularity each record represents, update frequency, required fields, allowed values, quality thresholds, and who should be notified when data anomalies occur. When a new Excel format or field version arrives, the team can then judge whether this is normal evolution or a major change requiring import to be paused.

For example, if a store's daily sales report is committed to being updated by 9am every day, the enterprise should define how late counts as an anomaly, which missing stores should trigger an early warning, and how much difference in amount compared to the previous day requires reconciliation. For product inventory, checks could be set up for negative inventory, unmatched product codes, and unreasonable single-day jumps. These thresholds aren't meant to treat every special case as an error — they're meant to let the responsible person know which discrepancies can be automatically accepted and which must be clarified first, preventing data quality issues from only being discovered at month-end.

Permissions should also be broken down by task, not just split into "administrator" and "regular user." A finance manager might need to see company-wide aggregated revenue, a store manager might only need to see their own store, and an analyst might be able to use de-identified customer segmentation data without needing access to phone numbers or addresses. If role-based permissions can be granular down to the dataset, field, or row level, different job functions can be given the minimum data necessary to complete their work. For sensitive fields, masking, pseudonymization, or aggregated queries can also be considered to reduce the direct identification risk if data is leaked.

Operation logs should likewise be designed to be useful. Simply recording "this person used the system" isn't enough to trace problems; enterprises may also need to know which original dataset was processed, which rule version was applied, which rows were quarantined, who approved a rerun, and ultimately which reports or queries were affected. When AI participates in Q&A, it's also necessary to confirm whether query content, model source, the scope of returned data, and download behavior are retained according to policy. Audit logs themselves may also contain sensitive information, so just because they're used to protect data doesn't mean the permissions and retention period of the logs themselves can be overlooked.

Finally, enterprises should fold data retention, deletion, and correction into the same lifecycle. When personal data has exceeded its necessary retention period, when a customer requests deletion, or when an upstream system corrects a transaction record, how should the raw layer, cleaned data, aggregate tables, and already-scheduled reports be synchronized? When should data in backups be rotated out? Must historical reports be retained by law? These questions are best confirmed with legal, security, and business owners before implementation. A data warehouse can integrate data together; a governance system has to ensure the integrated data continues to be used according to enterprise rules.