Your data is the advantage: why your company needs an owned digital layer

Most companies do not have a shortage of data. They have the same data in five places, with a slightly different meaning in each one.

The customer sits in CRM, the order in ERP, the proposal in a PDF, an important note in an email, and the only genuinely current status in a spreadsheet owned by the person who has held that process together for years. When management asks how much this customer has actually paid us this year, the answer requires three systems and one employee who knows which field can be trusted.

This is not only a small company problem. The tenth edition of the MuleSoft Connectivity Benchmark, a survey of 1,050 IT leaders in organisations with at least 1,000 employees, reports an average of 897 applications per organisation, of which only 29% are connected. Ninety percent of respondents say that data silos create business problems inside the company.

This article goes deep on one layer. I mapped the full set of company layers in How I would build a company today that does not need an army of administrative staff. Here the subject is data alone: who owns it and where the truth lives.

AI is only as reliable as the infrastructure beneath it

A model can summarise, classify or propose a next action extremely well. But if two systems hold a different price, a conflicting order status or a duplicate customer, AI cannot determine which record is authoritative. It will use the one it is handed, or the one that sounds more convincing. Neither is a decision criterion.

The NIST AI Risk Management Framework 1.0 from January 2023 places the Valid & Reliable characteristic, meaning validity and reliability, beneath the other characteristics of trustworthy AI, and adds that trustworthiness is only as strong as its weakest characteristics. A model built on data you do not trust yourself is a generator of faster mistakes.

The business therefore needs to define a source of truth for its key entities: customer, product, price, order, invoice, availability, user and permissions. It is an agreement about which system is authoritative for a given field, and where everyone else only reads it from. Not a technology, a decision.

That this is not a marginal topic is shown by the Salesforce State of Data and Analytics research, collected in the summer of 2025 and published in November 2025: 84% of leaders responsible for data and analytics say their data strategy needs a complete rebuild. They estimate that 19% of company data sits in silos or is otherwise unusable, and that 26% is untrustworthy.

What a source of truth decision looks like

Four questions have to be answered for every entity. Which system owns it? Who may write to it, and through which interface? What is its single identifier across systems? And what does reconciliation look like when two records diverge?

It sounds trivial, yet it tends to be the hardest hour of the project. A worked example: three people own the price and each of them is right in their own context, sales has an exception, the online shop has a price list and accounting has whatever went out on the invoice. If that conversation does not happen around a table, the integration will settle it later. Randomly and badly.

Regulation is pushing in the same direction. Article 10 of the EU AI Act requires datasets for high-risk systems to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. Without alarmism: it applies only from 2 December 2027, or from 2 August 2028 depending on the type of system, and most corporate deployments will not fall under high risk.

A shared data model simplifies the entire ecosystem

When the customer has one identifier, the order has a clear lifecycle and every system knows where to read the price or availability from, integrations become substantially simpler. A lead arrives from the website, is created in CRM, enriched, assigned to a salesperson and later connected to a proposal, an order and an invoice without anyone retyping the same thing four times.

The economics here are ordinary arithmetic, not a research finding. If you connect every system to every other one, five systems mean ten links and ten systems mean forty-five. Every link is code that somebody wrote, somebody maintains and that will break one day. With a shared vocabulary and shared identifiers, adding a tool is one connection, not another nine.

Zhamak Dehghani, in her text on data mesh published in May 2019 on martinfowler.com, named the failure modes of centralised data platforms: the ability to process and harmonise all data in one place declines as both sources and consumers grow, and splitting the platform by technical steps instead of business domains creates tight coupling in which a new requirement demands changes across the entire pipeline. The most usable part is her bar for “data as a product”: a dataset should be discoverable, addressable, trustworthy and secure.

A vendor will usually not say the uncomfortable part: most mid-sized companies do not need a data mesh, it is a concept for organisations with several data teams. A smaller company gets most of the value from three cheap steps. One properly configured CRM as the owner of the customer. One documented identifier. One export that can be run at any time.

One digital layer can serve customers, teams and AI

A well-designed data and API layer, meaning the interface through which systems hand data to each other under agreed rules, can serve a customer portal, an internal dashboard, pricing, reporting, website personalisation and an AI assistant at the same time. The company does not have to build a new island every time.

The test is simple. Take one business rule, for example the discount calculation for a long-standing customer, and count how many places it is written in today. If it is in five, every change is five changes and five opportunities for the versions to drift apart. If it is in one, a new channel is not a project but a screen. That is why it pays to treat the company as one product rather than as departments sending files to each other.

Security belongs in the architecture

Not every user and not every AI process needs access to everything. Sensitive data should be separated, access logged and flows designed so that it is possible to explain afterwards who accessed what and why.

This is not an opinion, it is a standard. NIST Special Publication 800-207 on zero trust architecture, from August 2020, states in the third of its seven tenets that access is granted on a per-session basis and with the least privileges needed to complete the task. The seventh tenet asks organisations to collect as much information as possible about the state of assets, network and communications, and to use it to improve their security posture. Logging is therefore not a nuisance, it is an input into decision making.

With AI it is additionally sensible to minimise which data the model receives at all. More context does not automatically mean a better system. The OWASP Top 10 for LLM Applications 2025 places sensitive information disclosure in second place and recommends data sanitisation, strict access controls following least privilege, and quite literally restricting the model’s access to external data sources. The data minimisation principle in Article 5 of the GDPR points the same way: data should be adequate, relevant and limited to what is necessary.

The sixth risk on the same list, Excessive Agency, describes what emerges from fast pilots: the agent is given more functions, permissions and freedom than the task requires. Limit extensions and their permissions to the necessary minimum. Require human approval for high-impact actions. Enforce authorisation in downstream systems, not in the model. The model is not a security boundary, the model is a client.

The Cost of a Data Breach Report 2025, conducted by Ponemon Institute and sponsored by IBM on a sample of 600 organisations, shows the same. Thirteen percent of them reported a breach of their AI models or applications, and of those 13%, not of all companies, 97% said they had no AI access controls in place. One in five organisations reported a breach caused by shadow AI, and companies with a high level of it had average costs USD 670,000 higher than companies with a low level or none, against a global average of USD 4.44 million.

Shadow AI does not arise out of malice. It arises when the official route to data is slow and someone finds a faster one. Bans do not work, a better official route does.

When an owned data layer is not worth it

An owned data layer is an investment with fixed overhead that not every company needs. My working rule, an experience-based estimate rather than a research finding: if one system writes a given entity and the others read from it, there is nothing to build, only something to write down. If two systems write it and a person occasionally resolves the difference by hand, a native integration or a no-code automation is enough. An owned layer starts to make sense only when three or more systems write the same entity, and when the company has a process that cannot be bought ready-made because it is its competitive advantage.

The cheaper routes are worth trying first. Retire one of the duplicate tools. Switch on the native integration you have already paid for in the licence. Build a read-only reporting layer instead of two-way synchronisation, because most management questions are reads, not writes. Fewer moving parts tends to be a better solution than smarter synchronisation, which is the subject of the whole article Your company does not need more software. It needs less chaos.

Models will change. The owned digital layer remains

Today’s best AI model does not have to be the best one in two years. A SaaS vendor can change pricing, the API or its product strategy. A company that owns its data model, its integration logic and its interfaces can swap services without breaking the whole process. That is the only negotiating position against a vendor that works even without a lawyer.

Regulation has helped here. The European Data Act, Regulation (EU) 2023/2854, entered into force on 11 January 2024 and applies from 12 September 2025. According to the European Commission, it creates a framework that allows customers to port data and switch cloud providers, and prohibits unfair contractual terms that prevent data sharing. The contract gives you the right to leave. The architecture decides how much leaving will cost.

The practical ownership test is worth asking of every new tool before signing. If we switched it off tomorrow, how long would it take to get the data out in a usable structure? The answer that it can be exported to CSV is not enough. The question is whether the export preserves the relations between records, the history of changes, the attachments and the identifiers. A tool that returns data without its relations is not returning your data.

From that follows the dividing line. It is worth owning the data model, the identifiers, the business rules, the integration logic and the interfaces. Rent almost everything else: email, accounting, storage, the warehouse, the payment gateway and the models themselves. Nobody sensible builds their own CRM from scratch today, or writes their own language model. The goal is not to own software, but to own the truth that the software processes.

The advantage in AI will not belong to the company with the largest number of subscriptions, but to the company that knows where its data is, what it means and how safely it flows through its processes.

A data layer cannot be ordered as a line item on a price list. It can first be diagnosed: map the entities, the owners, the flows and the places where the truth diverges. Only from such a map is it possible to say whether the company needs a project, a single integration, or just one retired tool and one written agreement. The order matters more than the budget: process first, then removing what is unnecessary, and technology last.

Key takeaways

• Before you buy another model or another tool, write down on one page which system owns the customer, the product, the price, the order and the invoice. If the team cannot agree within an hour, you have just found the real project.
• With every new tool, ask before signing how you will get the data out, complete with its relations and history. The Data Act gives you the right to leave, your architecture sets the price of leaving.
• Give an AI process only the data it needs for its task, and enforce authorisation in the target systems, not in the model. Keep a human in the loop for high-impact actions.
• If one or two systems write the same entity, do not build your own layer. Document the ownership and switch on the native integration.
• Do not measure success by the number of integrations, but by how long it takes the company to answer a commercially important question with confidence, without having to ask one particular person.