If your most important AI provider tripled its prices tomorrow, could your organisation move elsewhere without losing the knowledge, workflows and productivity it had spent years building? The answer reveals something that ownership of data alone cannot tell you: how much control your company retains over the capabilities that make it competitive.
In last week’s Episode 190 of the AI After Work (AIAW) Podcast, Daniel Lundin , Managing Director at inorigo , joined Henrik Göthberg for a conversation that began with Europe’s dependence on global AI providers and reached into a more uncomfortable question: have enterprises already outsourced so much of their business understanding that they risk automating what they no longer fully understand? As agents take on more work, companies can become faster at producing results while becoming less able to explain, reproduce or improve the decisions behind them.
That tension has consequences for every leader investing in enterprise AI, because the choices that deliver immediate productivity also determine where knowledge accumulates and who can use it next. Understanding those choices opens a practical route towards greater independence, better decisions and innovation that builds on what the organisation learns, with seven recommendations for turning that ambition into everyday practice.
The sovereignty question inside the enterprise
Europe’s debate about AI sovereignty often begins with infrastructure, moving between data centres, semiconductors, energy, cloud services and foundation models. These dependencies deserve attention because access to technology can be shaped by commercial decisions, geopolitical tensions and constraints beyond an individual organisation’s influence. However, the same debate becomes more immediate when directed towards the enterprise itself, where control can erode through ordinary procurement, architecture and management decisions.
An organisation may own its data, operate within European infrastructure and still depend heavily on external parties to understand how its business works. Its critical operating rules may be scattered across applications, custom code, supplier configurations and the memories of experienced employees, while its formal process documentation captures only a simplified version of reality. Under those conditions, ownership of information provides limited assurance that the company could reproduce an important capability or adapt it independently.
This is the central insight running through the discussion: sovereignty depends partly on the practical ability to understand, maintain and develop the mechanisms through which an organisation creates value. The question therefore reaches beyond the location of a server or the nationality of a supplier to the ownership of business meaning, decision context and accumulated experience. 
AI makes that distinction consequential because organisations are beginning to delegate activities that involve interpretation and judgement. When those activities become embedded in systems that the enterprise cannot adequately explain or reconstruct, productivity gains can coexist with a weakening of internal capability. The strategic challenge is to benefit from external intelligence while ensuring that the organisation’s own understanding continues to grow.
The gradual outsourcing of business understanding
For years, enterprise technology decisions have been guided by a reasonable distinction between core business and supporting activities. Companies should concentrate on what makes them competitive, while purchasing standard services where specialised providers offer greater efficiency. The difficulty arises when a technology treated as support contains the operational logic through which the company actually competes.
A manufacturing process can depend on design rules, material substitutions, scheduling exceptions and customer commitments that have evolved over decades. Once those rules are implemented in software, they may become difficult to distinguish from the surrounding technical complexity, particularly after the original specialists leave. A subsequent modernisation programme can then classify the implementation as a maintenance burden without fully recognising the capability it preserves.
One example in the conversation concerned an unnamed company able to deliver a previously unproduced item within 24 hours of an order, using a design-automation process built on years of accumulated experience. Replacing that implementation with a standard solution appeared attractive from a maintenance perspective, yet the decision also raised the possibility of losing valuable operational knowledge. The relevant comparison was therefore between two ways of sustaining a distinctive capability, rather than simply between old and new software.
This is where business understanding becomes a strategic asset in its own right. An organisation needs enough internal competence to identify which parts of an implementation represent unnecessary complexity and which express valuable differentiation, even if an external partner continues to build and operate the technology. Without that distinction, standardisation can quietly remove the practices that made the business unusually effective.
The same problem becomes more difficult when AI is layered over systems whose logic is already poorly understood. Automation can make existing dependencies faster and more productive while leaving the enterprise less able to question them, creating a situation in which apparent technological progress masks a growing distance between the organisation and its own operating knowledge.
Why the recipe matters as much as the result
A company’s completed work provides only a partial record of its capability. A design drawing preserves the selected configuration, a transaction records an agreed price and a report captures a measured outcome, yet none necessarily explains the alternatives considered or the conditions that made the final choice appropriate. Reproducing competent performance requires access to some of that missing context.
This distinction challenges a common assumption in enterprise AI: that large volumes of historical output will adequately explain how the business should act. An archive of engineering drawings can reveal recurring patterns, but a reliable design decision may also depend on production constraints, available materials, supplier qualifications and the reasons previous alternatives were rejected. Those conditions can change, making a historically successful answer unsuitable for a superficially similar problem.
The knowledge worth retaining therefore includes the connection between evidence, assumptions, constraints, decisions and outcomes. A supplier selected during a capacity shortage may be inappropriate when availability improves, while a product configuration approved in one market may require different treatment elsewhere. Removing those relationships can make information easier to store while making it harder to apply responsibly.
This does not mean preserving every conversation or asking AI systems to produce lengthy explanations for every action. The useful goal is a verifiable business record that captures enough context for another qualified person or system to assess the decision later, with detail proportionate to its importance. Generated explanations require particular care because a plausible account of a decision is not proof of how a model reached it.
The novelty here lies in extending sovereignty from information ownership to the retention of learning. If an organisation continually supplies its knowledge to agents but fails to retain the resulting insights, validated rules and operational discoveries in an accessible form, it can increase throughput without strengthening its own foundations. Over time, the ability to produce the next result may depend increasingly on an environment whose workings remain outside its practical control.
Shared data does not automatically create shared meaning
Bringing information together has long been a central ambition of enterprise data programmes, yet consolidation alone cannot resolve the differences in meaning that arise across business functions. Engineering, sales, finance and service can refer to the same product while making decisions about different aspects of it, each requiring information suited to a particular purpose.
The discussion illustrated this through product managers who initially claimed ownership of product data across the enterprise. When discrepancies appeared between websites and business systems, responsibility narrowed towards the product-lifecycle management application, leaving other representations with web or sales teams. The ownership statement sounded comprehensive, while the operational mandate covered only part of the problem.
There are two distinct challenges within that example, and both matter for AI. Some discrepancies are errors that require correction, while others reflect legitimate differences between markets, contractual arrangements, versions or effective dates. Governance needs to identify which situation applies and establish who can resolve it, rather than assuming that a single owner and universal definition will settle every question.
A useful enterprise knowledge model therefore needs relationships between contexts, including shared identifiers, explicit mappings and rules governing where particular definitions apply. A sellable configuration, an engineering assembly and a service entitlement may be related without being interchangeable, while a change to one can affect the others in ways that require review.
Knowledge graphs and semantic models offer ways to express such relationships, although their value depends on the quality and governance of the information represented. Microsoft Research’s GraphRAG work illustrates how extracted entities, relationships and community summaries can help answer questions across document collections, including questions that simple similarity-based retrieval handles poorly. Its findings support the value of structured relationships for particular retrieval problems, while leaving enterprises responsible for establishing whether extracted claims are accurate and authoritative. [1]
Likewise, the W3C’s Shapes Constraint Language provides a mechanism for checking RDF graphs against declared constraints, making some expectations testable rather than leaving them entirely implicit. These tools contribute to a broader discipline of preserving meaning, but the business still has to determine which meanings, relationships and constraints are appropriate. [2]
A living enterprise model built through work
The ambition of a living enterprise model is compelling because it promises a representation that people and agents can use to understand processes, dependencies and responsibilities together. Historically, however, comprehensive modelling has often involved lengthy workshops and extensive agreement before useful results become available, creating a risk that the organisation changes faster than its model can be maintained.
The discussion proposed a more evolutionary approach, captured in the principle “feedback first, schema second.” Operational activity provides evidence from which the model develops, while the emerging structure helps organise and reuse what the enterprise learns. The sequence changes from attempting to define everything in advance towards developing a useful representation through repeated interaction with real work.
That approach still requires judgement about evidence. A meeting transcript can contain an approved decision, an abandoned proposal or an individual misunderstanding, and automated extraction can fail to distinguish among them. Feeding more material into a model does not automatically make it more reliable, so source attribution, review and clear distinctions between proposed and accepted knowledge remain essential.
The practical unit of progress is a workflow or bounded problem whose value can be observed. A representation of a supply-chain decision, product-change process or service activity can become useful without describing the entire enterprise, provided it is designed to connect with adjacent activities. Related models can then be combined as their shared entities and dependencies become clearer.
This creates a necessary relationship between enterprise direction and local delivery. Teams need room to discover the structure that actual work requires, while leadership must establish enough common expectations for their discoveries to fit together. Asking every team to solve only its immediate problem produces disconnected solutions, while asking it to model the whole enterprise places an unreasonable burden on local delivery.
A useful test is whether the evolving model helps answer consequential questions that were previously difficult to resolve. Understanding which customers depend on a constrained component or which commercial commitments are affected by a design change gives the model operational relevance, turning enterprise knowledge into something maintained through use rather than preserved as a periodically updated documentation exercise.
Freedom to choose requires the ability to change
Technological independence cannot reasonably mean eliminating every external dependency, particularly across an AI value chain that spans energy, equipment, software and specialist expertise. Enterprises need to decide which dependencies they can accept, which capabilities require stronger control and what circumstances would justify changing the arrangement.
The practical test is what happens when a supplier changes prices, alters a service or becomes unsuitable for a critical activity. If the company can export its records but cannot reproduce the workflow without rebuilding years of hidden logic, its freedom remains constrained. Portability must therefore include attention to operating rules, evaluation methods, configurations and the expertise required to use them.
The EU Data Act provides relevant context through requirements intended to facilitate switching between data-processing services, including cloud and edge services. The European Commission’s explanation describes interface and export provisions as well as limits concerning provider intellectual property and trade secrets, illustrating how contractual and technical measures can support customer choice. Those measures cannot, by themselves, supply the internal understanding needed to reconstruct a business capability. [3]
External engineers can either deepen a dependency or help reduce it, depending on how the relationship is organised. When specialists work alongside internal employees and transfer design knowledge, they can strengthen the enterprise’s ability to maintain and question the system. When the result is delivered without sufficient access to the relevant knowledge, the organisation may acquire a powerful capability whose continued operation depends on retaining the same external team.
Model gateways offer another expression of deliberate choice by allowing different requests to be directed towards different models. Their usefulness nevertheless depends on evaluation, because changing a model can alter reliability, tool use and task performance even when the interface remains similar. The strategic asset is the demonstrated ability to change an important component while preserving acceptable business outcomes.
Agents expose the limits of existing management
Agents bring the ownership problem into organisational design because software that retrieves information and takes action needs a clear relationship with responsibility and authority. A growing collection of individually created agents can otherwise reproduce the fragmentation familiar from uncontrolled spreadsheets, with the additional complication that some systems can affect activities beyond their creators’ immediate work.
An unnamed enterprise in the discussion was described as having more agents than employees, an anecdotal observation that raised useful questions about onboarding, supervision and retirement. The issue is whether the organisation knows which systems are acting, what mandates they have and how their behaviour is evaluated, rather than whether a particular ratio of agents to people is desirable.
Leadership can make this difficult by simultaneously demanding rapid productivity improvements and stronger control without explaining how employees should navigate the trade-offs. Those tensions require operational decisions about permissions, approval thresholds, escalation and ownership, supported by teams with enough domain and technical understanding to apply them.
NIST’s AI Risk Management Framework offers a complementary reference through its emphasis on system inventories, clear accountability, ongoing monitoring, feedback and safe decommissioning. These responsibilities extend across the lifecycle, reinforcing the need to manage an agent after its initial deployment and to revisit the arrangement when its purpose or environment changes. [4]
The organisational implications extend beyond adding a governance checklist to existing delivery. Someone must connect local learning with wider strategy, reconcile conflicts between functions and ensure that a successful optimisation in one area does not damage another. As information processing becomes easier to automate, these responsibilities for coordination, judgement and organisational learning become increasingly significant.
Seven recommendations for enterprise leaders
1. Identify the capabilities whose logic must remain accessible. Select a small number of business-critical processes and establish whether internal teams can explain their rules, exceptions and dependencies, using gaps in that understanding to guide knowledge recovery before major automation or replacement decisions.
2. Retain decision context within important workflows. Capture the evidence, constraints, approvals and outcomes needed to reassess consequential decisions, making the record accessible beyond an individual employee or agent platform while keeping the effort proportionate to the business risk.
3. Govern relationships between business meanings. Distinguish legitimate contextual differences from errors, and establish shared identifiers, mappings and escalation responsibilities so that teams and agents can determine which representation applies to the decision they are making.
4. Build the enterprise model through bounded delivery. Start with a workflow that has a clear operational purpose, validate its representation through use and preserve the connections needed for adjacent teams to build upon it within an agreed enterprise direction.
5. Test supplier dependence through realistic change scenarios. Examine whether the organisation could maintain an important capability after a service change or substantial price increase, and use contracts, knowledge transfer and migration exercises to address the most consequential weaknesses.
6. Give consequential agents accountable human ownership. Define their purpose, permitted actions, approval requirements and operating limits, with monitoring and retirement arrangements that reflect the consequences of their activity rather than the ease with which they were created.
7. Measure the reusable knowledge produced by delivery. Evaluate immediate results alongside demonstrated reductions in effort, uncertainty or risk for subsequent work, ensuring that investments in common knowledge earn support through observed reuse rather than promises of future scale.
The economics of retaining what you learn
The discussion’s final contribution was to connect these practical choices with the economics of innovation, particularly the difference between improving one activity and increasing the enterprise’s ability to improve the next. A project can deliver a worthwhile local outcome while leaving little reusable knowledge behind, forcing future teams to repeat discovery, integration and validation work.
Traditional business cases can make that repetition difficult to see because they evaluate each initiative within its own boundaries. Preserving shared definitions or documenting reusable decision logic can appear as additional cost, even when those activities reduce the cost and uncertainty of later projects. An enterprise can therefore optimise each investment individually while repeatedly paying to rediscover how its own business works.
The alternative requires evidence that learning carries forward. A reusable component creates value when another team can apply it more effectively than starting again, while a shared model earns its place when it helps identify dependencies or prevents avoidable mistakes. Compounding benefits remain an ambition to test, with measures such as reuse, reduced discovery effort and improved decision quality helping determine whether they are occurring.
That learning must include organisational incentives as well as technical relationships. One example concerned a move towards a product-as-a-service model that encountered resistance from functions rewarded for existing service and spare-parts revenue, revealing how a promising innovation can conflict with the measures governing everyday behaviour. An enterprise model becomes more useful when it helps expose such tensions early enough to address them.
The larger conclusion is that sovereignty develops through a repeated practice of understanding the business, making deliberate choices and retaining the learning created through change. Enterprises that strengthen those habits gain more than negotiating power with suppliers, because they also become better able to adapt their own capabilities when markets, technologies and priorities shift.
Access to powerful AI will remain important, but the lasting advantage may belong to organisations that can explain what they know, apply it responsibly and carry it into the next stage of their development. Control over the knowledge behind the system gives technological choice its practical meaning.
This article was enhanced with the help of AI tools, drawing on the podcast transcript and complementary online research. To go deeper into the source material, I encourage you to listen to the full episode and make your own insights.
See and listen to the entire episode here.
Research references
[1] Microsoft Research, “GraphRAG: New tool for complex data discovery now on GitHub.”
[2] World Wide Web Consortium, “Shapes Constraint Language (SHACL).”
[3] European Commission, “Data Act explained.”
[4] NIST, “AI RMF Core.”
