Enterprise AI Data Access: Make Legacy Data Usable
Learn why legacy data blocks enterprise AI, how access layers can help, and how to evaluate security, context, cost, and real-world value before you scale.
Enterprise AI Needs More Than Better Models: It Needs Access to Business Data
Companies are putting AI assistants and agents into real work, but many still can't give them a full picture of how the business actually runs. Key information lives in older ERP systems, mainframes, dealership platforms, claims software, and other apps built for employees - not for modern AI tools. The data might be visible on a screen, but getting it out reliably via an API or standard export can be surprisingly hard.
That mismatch can turn an AI pilot from a promising idea into a polished demo that only knows part of the story. Traditional integration helps, but it usually connects specific systems and specific fields. It doesn't automatically recover every record, business rule, and exception an employee can see. And replacing the underlying software is often too slow and risky to treat as the solution - especially if you need value before a multi-year modernization project finishes.
This article focuses on the access problem, what newer approaches claim to change, and how to judge them without accepting a vendor pitch as proof. You'll get a practical framework for picking use cases, testing data quality and controls, and deciding whether an access layer can deliver enough value to scale.
Why enterprise data access is now an AI bottleneck
Enterprise software piles up over time. A company might have a modern cloud data warehouse sitting next to an ERP installed decades ago, a regional system acquired during a merger, and custom apps that only a few people still know how to use. Connecting some of those systems doesn't automatically make all of their information usable.
A lot of integration tools were built around one idea: expose a set of fields through an API, move them to another system, and repeat the pattern for the next use case. That works when the source system offers the needed data and you understand its structure. It breaks down when an API exposes only a subset, reports impose limits, or the meaning of a field depends on local business knowledge.
AI raises the stakes of those gaps. A dashboard can be designed around known metrics and known limitations. But an agent asked to investigate a late shipment, reconcile a claim, or explain a warranty balance may need to join information across multiple systems - and deal with exceptions along the way. If it can only see one convenient slice, it may respond confidently while still being incomplete or wrong.
The costs aren't always dramatic. No one ends up in the news because an AI assistant had missing fields. But they add up: specialists map undocumented fields, analysts download reports and reconcile them in spreadsheets, and engineers build one-off pipelines. Each project becomes another dependency to maintain. And when the original subject-matter expert leaves, the practical meaning of codes and processes can disappear with them.
In an interview about Unfold, CEO Ran Cherniavsky described it as a mismatch between traditional integration and what AI needs. Integration connects systems through exposed interfaces; AI needs access to relevant information - and the context that makes it interpretable. That's a fair diagnosis, but it's not the same as proof that every access product can solve the problem safely and completely.
There's also security to consider. A system that's poorly documented and rarely inspected can be hard to govern, but making its data more accessible doesn't magically make it safer. Access has to be deliberate, logged, and restricted to a real purpose. The real requirement isn't "more data for AI." It's reliable, permission-aware access to the right data, with enough context to use it correctly.
What changes when AI can read legacy systems
A new group of access tools is trying to work with the interfaces employees already use, instead of waiting for every legacy app to grow a complete API. Depending on the system, those interfaces can be a user interface, a report, a file export, or even a command line. The point is to retrieve information without replacing the source application and without kicking off a major migration right away.
Unfold, for example, says it maps a system's data and business meaning, then builds a deterministic, read-only collector that relies on the system's existing permissions. The company also says onboarding can take up to 14 days, including for older environments such as AS/400 systems. Those are vendor claims, not universal benchmarks - the actual timeline will depend on system complexity, access rights, data quality, and your security requirements.
It also helps to separate extraction from interpretation. A value like "03" might be meaningless unless you know whether it's an order status, a payment condition, or a local exception. The same business entity can carry different identifiers across different applications. So an access layer needs to capture more than raw tables. It should document what objects mean, how they relate, where values came from, and what transformations were applied.
A common model can help downstream systems compare records consistently. For instance, a customer might be recorded under one identifier in an ERP and another in a CRM, but mapped to a shared enterprise entity. Still, normalization isn't the same as truth. If source records conflict, no schema can decide which one is authoritative without agreed business rules - and someone accountable for those rules.
Access products can sit upstream of analytics platforms such as Snowflake or Databricks, or they can feed data directly into an AI application. They may complement existing warehouses rather than replace them: the warehouse still stores and serves data, while an access layer tries to retrieve information that existing pipelines don't reach. Some tools also offer query-time access, which can reduce data movement - but it changes latency, availability, and control questions.
Here's the practical test: it's not whether a tool can connect to an old interface during a demo. It's whether it can retrieve the right records consistently, preserve the source permissions, explain lineage, handle changes to the interface, and fail safely. If a screen a human can read is the starting point, that's a possible path - not a guarantee of production-grade data access.
Where better access can create business value
The best use cases start with a specific workflow that's blocked by unavailable or fragmented information. "Make our data AI-ready" is hard to measure. "Give claims staff a grounded view of policy, payment, and case data without manually reconciling three systems" is clear enough to test.
Take a multi-location retailer trying to detect suspicious transactions across countries. Point-of-sale records may sit in older systems that don't feed the company's analytics environment completely. Exposing those records could improve coverage, but the team still has to check regional data rules, agree on what counts as suspicious, and track false positives. The value isn't just "we connected the data." It's a better control with operational consequences they can live with.
Insurance shows a similar pattern. If staff or contractors have to map claims-system fields by hand before engineers can build a pipeline, automating discovery can cut preparation time. That's only useful if the mapping is accurate enough for the business decision. A fast pipeline that silently misreads claim status can cost more than the manual work it replaced.
In a dealership group, an owner might want to ask how long warranty payments have stayed outstanding, using parts, service, and warranty records. An assistant can make that question easier to answer, but the result depends on definitions: when does an amount become owed, how do partial payments work, and which system wins when records disagree? Those rules need to be explicit before you trust "conversational" access.
Measure value across three dimensions:
- Time: How long does it take to access the information today, and how much of that delay does the new approach remove?
- Cost: Which recurring consultant, analyst, or engineering work actually goes away, instead of shifting to a different team?
- Outcome: Does broader access enable a decision or control that was previously impractical - and can you measure the impact?
And don't forget the costs that are easy to miss: security review, ongoing monitoring, integration maintenance, user training, plus the human effort required to resolve ambiguous or conflicting records. If a pilot saves a few days but adds a new operational dependency, it may not scale economically.
Often the real goal isn't just answering questions - it's completing workflows across systems. That's a step up in risk. A summarizing assistant can be reviewed before action, but an agent that changes a claim, issues a refund, or updates inventory creates direct consequences. Start with read-only retrieval, build confidence in reliability, and add actions only when permissions, approvals, and rollback procedures are clear.
How to evaluate and roll out an access layer
Treat access as a product capability with a defined business owner, not as an open-ended data project. A rollout usually makes more sense in stages.
-
Choose a blocked decision or workflow
Write down the exact question or task AI can't handle today. Identify who does the work, which systems are involved, what decision is being made, and what happens when the answer is wrong. Start bounded - prefer a specific workflow over a broad "enterprise assistant."
-
Trace the data and its meaning
For every required field, document where it comes from, who owns it, how it's defined, how often it updates, and how it relates to other records. Ask experienced users how exceptions work; formal documentation may miss what actually happens in practice. If two systems disagree, decide who gets the final say before the AI application is built.
-
Set the access and safety boundary
Decide whether the solution will copy data, query in place, or use a mix of both. Define who can access it, how permissions flow, what gets logged, and how sensitive data is handled. Use read-only access for early tests whenever possible. In the UK and EU contexts, check obligations under GDPR and relevant sector rules; in the US, account for state, federal, and industry-specific requirements.
-
Test against real questions and known answers
Build a test set from real questions from real users, including edge cases and ambiguous phrasing. Compare AI responses to answers verified by someone who knows the domain. Track missing records, incorrect joins, stale data, unsupported claims, latency, and access-control failures. Don't measure success only by how plausible the answer sounds.
-
Expand only after operational proof
Set explicit scaling criteria: what thresholds for result quality, cost, and security must be met. Assign owners for connector maintenance, schema changes, incident response, and business-rule updates. If the first use case meets your criteria, reuse the foundation where systems and governance are genuinely similar. Don't assume that one successful connector means every other application will be straightforward.
When you compare approaches, ask vendors to demonstrate on your actual system and a representative workflow. Request evidence for the claims that matter: how long setup took in a comparable environment, how permissions are enforced, what happens when the UI changes, how lineage is exposed, and what audit records are available. Also clarify whether data stays in the source systems or is copied, and who's responsible if a source system produces misleading or incomplete records.
The trade-off is pretty clear. A new access layer may reduce reliance on brittle one-off integrations and avoid an immediate system replacement. In return, you get another component you have to secure, monitor, and maintain. You may also inherit limitations from the source interface - if a screen hides records or a report caps results, the access method can mirror that. Compare the ongoing cost and risk against API work, manual processing, or modernization, not against an imaginary zero-cost alternative.
Key takeaways
- AI pilots often stall because core operational data is incomplete or lacks business context, not because the model needs another prompt.
- Traditional APIs and pipelines still fit many cases; a new access layer is most useful when important systems are only partially reachable.
- Extraction, normalization, and business interpretation are different problems. Validate all three against real records and real workflows.
- Start with a measurable, read-only use case. Add agent actions only after accuracy, permissions, and human oversight are proven.
- Evaluate total operating cost and security responsibilities, not just setup speed or the promise of avoiding modernization.
Conclusion
Enterprise AI depends on more than model quality. It needs dependable access to operational data and the business knowledge required to interpret it. For organizations running critical workflows on older or closed systems, an access layer can help close the gap without making system replacement a prerequisite.
But access isn't the same as accuracy, context, or governance. Start with one workflow where you can measure today's limitations and outcomes. Test the actual data, permissions, and failure modes, then compare ongoing operating burden with your alternatives. Scale only when the evidence shows the system is useful, safe, and genuinely more effective or cheaper than the process it replaces.