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

When discussing enterprise AI adoption, people tend to ask first: "Which model should we choose? ChatGPT, Claude, or build our own?" But after years of talking with enterprises, we've often found that the first real question isn't about model rankings — it's something more fundamental and more easily overlooked: Where exactly is the company's data? Who knows what it means? And can it be organized in a trustworthy way so that different departments and different tools can reuse it?

Many enterprises aren't actually short on data. Quite the opposite — there's so much data that every department has its own version. There's one copy in the ERP, one in the POS system, one in the e-commerce backend, and another Excel file sent over by a sales colleague; HR, customer service, inventory, and accounting each maintain their own familiar spreadsheets. When it's time to make a report, people first have to gather all the files together, then manually clean up the columns, remove subtotal rows, cross-check codes, and confirm date formats — only then can they start actually answering business questions. The data already exists, yet a huge amount of manual labor is still needed to translate it into something machines can understand and colleagues can trust.

This gap isn't just something we've observed in individual client cases. Statistics related to Salesforce's "State of Marketing" report indicate that 84% of surveyed marketers use first-party data, but only 31% are fully satisfied with their ability to integrate data across sources. These two figures are interesting when placed side by side: enterprises increasingly recognize how important their data is, yet many teams still can't organize data scattered across different places into a consistent, usable whole. 1

A 2026 PwC survey of 767 U.S. operations and supply chain executives reveals a similar reality. 89% of respondents said their technology investments have not fully delivered the expected results; 87% noted that poor data quality has hampered the ability of digital initiatives to create value. This isn't saying every company's data is a mess — it's a reminder that if you buy new systems and set up AI accounts without simultaneously addressing data quality, system integration, and workflow design, investment won't automatically translate into results. 2

So, starting last year, we began investing our skills in a task that may not sound glamorous but is actually critical: helping AI assist enterprises in cleaning and organizing their data. A year later, with the product gradually maturing, we launched AotterClam AI. This isn't about building yet another chat window — it's about helping enterprises organize data scattered across legacy systems, reports, and files into a data foundation that can be governed, kept up to date, and used by downstream AI and BI tools.

Why does talking about AI so often end up stuck on Excel?

Aotter has spent over a decade doing data-related work, and we're familiar with the daily realities of data engineering and data governance. People outside the company may know us starting from AotterGirls, but Aotter's journey — from creative tools and content products, into data advertising and first-party data applications, and now into enterprise AI — has always revolved around the same core issue: how to shorten the time it takes for information to become value. Having worked with user behavior data for a long time in media and ad tech, we know that collecting data is only the beginning. The real difficulty lies in organizing it, defining it, managing permissions and use cases, and being able to keep it updated going forward. 10 11

Discussions about first-party data used to center mainly on marketing and advertising, but they're now increasingly central to core enterprise operations. It's not just about member or transaction data that brands collect directly — it also includes orders, inventory, customer service interactions, and service records accumulated through legitimate, reasonable business relationships. Whether this data can be properly harnessed determines whether an enterprise can build analytical capability within its own operational context, rather than relying every time on vague answers provided by external platforms.

This trend isn't complete just by slapping the label "first-party" on things. eMarketer, citing a 2024 survey, notes that in one survey of B2B marketers, 67% listed data compliance and accuracy as important priorities; another global survey of marketers found that 84% said they use customer, first-party, and transactional data to understand their audiences. These figures reflect specific survey populations and the market conditions at the time — they don't mean every company already has mature data governance capabilities. But they clearly show that enterprises are increasingly concerned not just with whether data can be used, but whether the way it's used is compliant and accurate. 3

We also want to specifically point out that first-party data doesn't mean "data we obtained ourselves can be used however we like." Where the data came from, what was disclosed at the time of collection, what uses are permitted, who can view it, how long it's retained, and whether it can be linked with other sources — all of this must be clearly governed. Truly valuable first-party data is a data asset accumulated through legal and transparent relationships that the organization can continuously manage — not over-collection or unlimited tracking under a different name.

Once we move into the context of enterprise AI, the data bottleneck shows up in very practical ways. Many companies' core systems have been running for years. ERP, POS, warehouse, or order systems may each have their own databases, but there's no suitable API connecting the systems — or even if an API exists, the company lacks the budget, permissions, or dedicated staff to properly connect it. In practice, the most commonly used external output is still Excel or CSV: a weekly sales export, a daily emailed report, or month-end merging of spreadsheets from different departments by a colleague.

Data shouldn't be considered worthless just because it's delivered in Excel format. These spreadsheets often carry years of operational experience — it's just that the table design was originally meant to serve people, not data pipelines. The first row might be a merged-cell title, with actual column headers only appearing in the second row; a single column might contain dates, text, and notes all mixed together; a single sheet might blend line items, subtotals, totals, and remarks. Different departments might even use different names for the same field, or use the same name to mean different things.

For example, "amount" might mean the pre-tax amount, the tax-included amount, the net amount after deducting discounts, or simply the total order amount before refunds are deducted. Tables may all label a column "amount," but summing them up can lead to completely different operational conclusions. Similarly, a row might represent an entire order, or it might represent a single product line item within an order. If the system doesn't understand the granularity of the data, and the order total gets copied into every product row, total revenue can easily be double-counted. These aren't minor glitches caused by AI not being smart enough — they're root causes of errors that can occur in any report or model whenever business definitions haven't been clearly written down.

Since last year, we've been exploring many Generative BI, data lakehouse, and semantic layer solutions. These tools can help enterprises query, analyze, and present data, but most usage scenarios generally assume the data has already been cleaned and placed into an analyzable database or data warehouse. In other words, they're very good at handling "data that's already ready" — they don't necessarily solve the upfront work of inventorying data, cleaning fields, defining rules, establishing relationships, and scheduling updates.

This is a common sequencing problem in enterprise adoption: everyone rushes to see AI question-answering before the data has even been prepared. In reality, data is scattered across systems, attachments, and various versions of spreadsheets, so an implementation project first has to spend time locating data, asking people questions, confirming fields, and then figuring out how to get it all into the same analyzable environment. Traditional approaches often require consultants and system integration teams to inventory data case by case, investing weeks or even longer before a first usable data warehouse can be established. This doesn't mean consultants or SIs have no value — it's that enterprises often need to complete a lengthy round of data engineering before they can even start discussing what AI can do for the business.

Local surveys in Taiwan make this problem even more concrete. The 2025 Manufacturing AI Adoption Survey by the Institute for Information Industry's Digital Transformation Research Institute and the AI Foundation examined traditional manufacturing and ICT industries separately. The report found that among traditional manufacturing respondents, 35.8% had adopted information systems such as ERP or MES, while the rate of cross-system API integration was only 13.2%; 22.7% of traditional manufacturing respondents had reached the AI validation or scaling stage, lower than the 39.1% figure for the ICT industry. This study's sample size is limited — 53 traditional manufacturing companies and 74 ICT companies respectively — so it shouldn't be directly extrapolated as a precise census of Taiwan's entire industry. But it clearly illustrates a structural gap: having systems doesn't mean the systems can talk to each other; having data doesn't mean the data is ready to support AI. 4

When enterprises come to us to discuss data cleaning, a common answer we hear is: "First find someone to extract the data, do ETL, clean it up, and then load it into the warehouse." ETL — extract, transform, load — is indeed a core part of data engineering. However, if every type of report requires a custom-built processing program from scratch, any change in data format requires a rewrite, and bringing in new staff means they have to relearn all the past rules — implementation costs are very hard to bring down. What enterprises need isn't to pretend data cleaning is simple, but to turn the large volume of repetitive, describable, verifiable steps into reusable rules.

So we began asking a seemingly simple question: even though Excel formats vary endlessly, are there still some stable "atoms" of data processing that can be clearly described? How should a sheet be read, which rows should be excluded, what type should each field be converted to, how do you identify a single record, how do you establish a relationship with another table, and how should things be updated when new files arrive? These tasks don't naturally become risk-free just because AI is added, but they can be broken down into definitions, rules, validation, and execution — rather than always relying on some colleague remembering "that's roughly how we used to do it."

After months of research, we organized the recurring processing patterns found in data science and data engineering into a declarative syntax. "Declarative" means clearly writing out the goals and rules — for example: "this column represents the order date," "subtotal rows should be excluded from the line-item detail," "a record is identified by order ID plus item ID," "amount is calculated as the net value after deducting discounts" — rather than leaving behind a manual process that's hard for anyone else to pick up. AI can first analyze an Excel file it's never seen before and propose an initial understanding of the columns, formats, and relationships; a person familiar with the business then reviews and corrects it, and the approved definitions are saved and handed off to a fixed process for handling future files.

Incoming data doesn't have to rely solely on colleagues manually uploading files. If an enterprise's existing ERP can regularly export reports, it can continue using its existing schedule to send Excel or CSV files; if the system has an API, direct integration is also possible. Once an exported file arrives, the system cleans, validates, updates, and loads it into the warehouse according to the approved definitions. According to AotterClam AI's official product documentation, currently listed methods include Excel and CSV file import, API and scheduled synchronization, and automatic processing of report email attachments; the actual available sources, formats, and deployment methods still need to be confirmed case by case according to each enterprise's environment. 5

The core idea behind this design isn't to have AI permanently replace human judgment — it's to put AI's best use at "helping to understand unorganized data and propose candidate rules"; to put business confirmation at "determining the meaning of fields and metrics"; and to hand fixed rules off to a reproducible data pipeline for execution. Done this way, data engineering won't lose stability from having to re-invoke the model and re-guess every time data is imported, and business staff won't need to re-explain the entire table's background every time they run a query.

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.

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.

Deployment methods, model selection, and implementation recommendations

Different enterprises have different requirements for data retention and model services. Some can use managed services in a public cloud environment, while others must keep everything in an enterprise private cloud, VPC, or on-premises data center. AotterClam AI's official documentation lists enterprise private cloud and on-premises deployment options, and explains that it supports configurable roles and permissions, operation logging, and offers different approaches such as local inference or connecting to external AI models. 5

When discussing "data doesn't leave the country" or "data doesn't leave the company," we recommend breaking that statement down into concrete data paths to verify. Where is the database itself located? Which region are backups and logs stored in? Where does model inference actually run? When a user asks a question, which fields, summaries, or query results does the system send to the model? Can support staff access the data? Who are the service provider's subprocessors? Simply answering "we're running it on-premises" isn't enough, because an enterprise system typically also includes backups, monitoring, updates, external models, and operational access channels.

Similarly, BYOK (Bring Your Own Key) generally refers to enterprises supplying their own API keys for model services; BYOAI is often used to describe enterprises choosing or bringing their own AI models and services. These are ways of adopting models and managing costs — they don't automatically mean data is protected, nor do they mean a personal ChatGPT or Claude subscription automatically includes enterprise API access. Whether a connection is actually possible, how billing works, whether data is used for model training, and how long logs are retained should all be confirmed according to the model provider's terms of service and the enterprise's deployment configuration.

MCP allows AI tools to connect to data services in a standardized way, but MCP itself is not a privacy protection protocol, nor does it automatically determine how much data should be exposed. Enterprises need to define the scope of data available for querying, field masking, role-based permissions, query logging, and policies on the use of external models. If a user only needs product inventory and sales trends, the system shouldn't expose customer phone numbers or addresses to the model just because they happen to live in the same database.

When implementing, we recommend starting with a clearly defined business question, rather than promising upfront that "all data will be AI-enabled." Enterprises can start by choosing a scenario with a steady workload, accessible data sources, and genuine management interest — for example, monthly sales aggregation, store inventory analysis, supplier lead-time tracking, or customer service issue classification. Clearly defining the target question first makes it possible to determine which data needs to be connected, which fields matter, and what the validation method should be.

Next, inventory the two or three most critical source documents or system outputs. Identify each dataset's owner, update frequency, field definitions, retention rules, primary key, and known exceptions. This step doesn't require replacing every system right away — first confirm whether existing data can be exported on a schedule, whether permissions allow the system to read it, and whether the data can be processed within the enterprise's designated environment. If data can currently only be sent manually, first lock down the sending method, file naming, and receiving rules, so the process is stable before expanding.

Then, work with the business side to define the criteria for a "correct answer." If the goal is monthly net sales, you need to at least specify how cancelled orders, refunds, discounts, tax, and shipping time are calculated; if the goal is inventory turnover, you need to agree on how beginning inventory, ending inventory, in-transit goods, and out-of-stock days are handled. You can pick real cases from the most recent three months and compare them line by line against existing manual reports, to identify exactly where the discrepancies lie in the rules — don't just test against one tidy sample file.

Only after that should validation and expansion be scheduled. Test common files, but also deliberately test error files, renamed fields, a sudden increase in null values, resent duplicate files, historical data backfills, and the addition of new codes. Once these pass, begin scheduled updates, and set up anomaly notifications, version retention, and a manual exception-handling process. When a second source is added, the enterprise can observe whether the data relationships remain stable before deciding whether to bring in a third department.

Success metrics should also be defined before starting. You can track things like how many hours colleagues spend each month organizing data, the time needed from asking a question to getting a trustworthy answer, the frequency of manual rework or reconciliation discrepancies, how many days managers wait for a report before making a decision, or changes in specific inventory and customer service metrics. If you only count how many times AI Q&A was used, it's easy to mistake "people tried it out" for "the business process actually improved." Only when an enterprise can clearly articulate the before-and-after difference can it know whether the next budget should go toward data quality, process automation, or more complex model applications.

Another observation from PwC's 2026 survey is worth incorporating into implementation strategy: among surveyed operations executives, 89% believe actionable data is more important than pursuing fully complete data, and 73% believe data doesn't need to be perfect to create value. This doesn't mean data errors can be ignored — it means enterprises don't have to wait until all data is "100% clean" before starting. A more practical approach is to first improve the quality of key fields for one high-value scenario, while continuing to improve the rest of the data, and use clear validation and risk tiering to hold the line. 2

Where AotterClam AI fits: make the data usable first, then choose the AI you want to use

AotterClam AI's starting point is that enterprises don't necessarily need to rebuild their entire ERP in a short period of time, nor do they need to first move all their data to an unfamiliar new system before starting data applications. Based on our current product design, AI helps understand sources like Excel and CSV and generates reviewable organization definitions; data is then validated, organized, and loaded into the warehouse according to fixed rules, after which the enterprise can use permission management, audit logging, BI dashboards, and AI Q&A features. Deployment and model options are then discussed according to the enterprise's cloud, VPC, or on-premises requirements. 5

The difference between this approach and an AI-ERP shouldn't be oversimplified into "which one is definitely better." An AI-ERP is suitable for enterprises that happen to be ready to replace their core operating system and want to redesign both process and data standards together; but if a legacy ERP still supports a large amount of daily operations, a full replacement might involve data migration, process overhaul, staff training, external system integration, and downtime risk. A data governance platform like AotterClam AI can instead first process the data already being output by different sources, allowing an enterprise to gain cross-system analytical capability while keeping its core systems intact. This is one path to reducing part of the migration cost — it doesn't mean every company should never replace its ERP.

In fact, not long ago, Aotter itself, during interviews at a traditional enterprise, discovered that directly rebuilding the ERP might disrupt processes that already deeply depended on the legacy system (since these were human-machine collaborative processes tightly bound to specific employees), and so began evaluating an alternative approach: building a data warehouse using existing reports. This case demonstrates the value of "first integrating the data already being output by the systems"; if a legacy system has already stopped being maintained, poses major security risks, or can no longer support core operations, rebuilding may still be the correct choice. What really should be compared is the overall transformation cost, operational risk, future maintainability, and expected benefits — not simply whether the product name contains the word "AI." 9

Aotter and Formosa Digital Intelligence Technology announced a partnership in 2026, which includes jointly developing enterprise-grade AI data governance products and services, with the hope of turning the digital transformation experience of traditional industries into solutions that can be offered to other enterprises. 14 Our view is straightforward: enterprises don't need to chase the AI wave by sending every piece of data to a model, nor do they need to wrap every question in a chat interface from the start. What matters more is first managing data into an understandable, traceable, updatable organizational asset, establishing clear permissions and use cases, and then choosing models, connecting tools, and adjusting processes according to real work needs. Models will change, APIs will change, prices will change — but an enterprise's understanding of its own products, customers, orders, and way of operating should remain within a data foundation the enterprise itself can manage.

AotterClam AI currently has very fast implementation examples among manufacturing, traditional industries, and any enterprise using similar systems to Digiwin ERP, traditional CRM, or CDP management platforms. Perhaps after talking with us, you'll find that you don't actually need to go through the trouble of digging everything up and rebuilding your systems to conveniently leapfrog ahead. Anyone with similar needs is welcome to fill out the form and get in touch with us. Implementation doesn't have to start with writing up a grand AI vision — it can start with a report that someone has to manually organize every month, a question that often goes unanswered, or a reconciliation process that's constantly repeated. Clearly defining the problem first, taking inventory of the data, and then jointly deciding which part is worth automating will get you much closer to real transformation than just buying a pile of tools first.

Lastly, let us introduce ourselves again: we are Aotter, the Aotter behind AotterGirls. Many people may first know us through our content brand, but Aotter has continuously built data and technology products all along — from app tools, content, and ad tech, to first-party data, data governance, and enterprise AI. For more than a decade, what we've cared about has always been how to turn knowledge, content, and data into usable value faster; now we're applying that experience to AotterClam AI, hoping to help enterprises gradually build data into their own capability, without needing an entire data engineering team from day one.

AI is hot, but data can't just chase the hype. Data needs someone to define it, someone to be responsible for it, and it needs to be able to be rerun, validated, and traced whenever rules change. When enterprises are willing to put in this seemingly unglamorous foundational work, AI has a chance to evolve from a one-off answer into a capability that can be built up over the long term.

Original by: Dr. Porkchop (Peng-han Su) (Aotter Co-founder and Deputy CEO) | Adapted by: Konois (Lun Hsieh) (Aotter Co-founder and CEO)

References

1. Salesforce Marketing Statistics: First-Party Data and Data Unification
2. PwC 2026 Digital Trends in Operations Survey
3. EMARKETER: 2025 Trend, B2B Firms Are Laser-Focused on First-Party Data
4. 2025 Manufacturing AI Adoption Survey Report
5. AotterClam AI Official Product Introduction
6. AI Foundation: Good data is what lets AI take root — the 1234 principles of data governance
7. McKinsey: The State of AI in 2026
8. McKinsey: The State of AI, How Organizations Are Rewiring to Capture Value
9. BusinessNext: More than just AotterGirls! Aotter builds AotterClam AI, targeting the B2B enterprise market with two core strengths
10. Aotter Official Company Introduction
11. AotterTrek Official Introduction: History of First-Party Data Development
12. Ministry of Digital Affairs: Legislative Yuan Passes Third Reading of the Artificial Intelligence Basic Act
13. European Commission: AI Act Regulatory Framework
14. Aotter: Announcement of Partnership Between Formosa Digital Intelligence Technology and Aotter