Study no. 3 · Sovereignty and asset data

Asset data: exit becomes free, the model stays captive

Nizar Younes Mqam ORCID 0009-0008-5549-7620

Study · 18 September 2026 · Cahiers de technopolitique, no. 3

From 12 January 2027, switching cloud provider will no longer incur any switching charges. In France, data transfer has already been free of charge since a ministerial order of 17 November 2025. What remains to be seen is what you take with you. Contracts promise a "reasonable and common format", that is to say, tables. What does not leave is the model: the functional hierarchy, the classifications, the rules. And the regulation that organises the exit excludes it in its very definition.

Exit becomes free, and France is ahead

Chapter VI of the European Data Act has applied since 12 September 2025. It is more ambitious than is often said. Its article 23 requires providers to remove "pre-commercial, commercial, technical, contractual and organisational obstacles" to a customer's departure, whether to another provider or to on-premises infrastructure. Its article 25 frames the timetable: a maximum notice period of two months, a transitional period of thirty calendar days during which the contract continues to apply, then a retrieval period of at least thirty days. And, in its paragraph 2 point (b), it obliges the provider to "support the customer's exit strategy", a wording that none of the earlier contracts examined here contains.

Article 29 sets the timetable for the money. Reduced charges may still be invoiced until 12 January 2027. From that date, any switching charge is prohibited. It is a date that a director of assets should have in their schedule, just like a contract renewal date.

France has moved ahead, and one must be precise about how it did so, because the opposite is often read. The SREN Act of 21 May 2024 does not prohibit egress fees. Its article 27 prohibits charging data transfer fees that exceed the costs borne by the provider and directly linked to the switch, and refers, for the ceiling, to an order of the minister responsible for digital affairs adopted on a proposal from ARCEP, the French telecoms regulator. This is cost-based pricing, not gratuity.

Gratuity came from the order. By its decision no. 2025-0340 of 20 February 2025, ARCEP proposed setting this ceiling at zero euros. The minister delegate for artificial intelligence and digital affairs followed it with an order of 17 November 2025, published on 30 November. On 2 July 2026, ARCEP completed the arrangement with two sets of guidelines, one on the costs attributable to switching charges other than data transfer, the other on multi-cloud.

This French lead is not theoretical, and it can be read in the providers' own terms. The IBM Cloud terms of use page, updated on 26 August 2026, contains two neighbouring paragraphs. Under the heading "EU Data Act", a European customer migrating its data "is entitled to reduced data egress charges". Under the heading "French SREN Law", a French customer "is not charged data egress charges". The same provider, the same page, two regimes. At this date, and at one of the largest operators in the world, the European regulation produces a discount. The French law produces a zero.

One could stop there and conclude that dependence is dissolving. That would be a misreading, and the rest of this study sets out to show why. What these texts make free is the movement of bytes. Not the return of what gives them meaning.

Four exclusions, all in the text

An asset register is not a list. It is a list plus an organisation: a functional hierarchy that says which equipment belongs to which system and which system to which installation, classifications that say what a pump is and what counts as a failure, attributes, units, criticality rules, thresholds. An operator takes ten or fifteen years to build this whole. It is this, and not the list of serial numbers, that makes it possible to decide what to replace and when.

The regulation organises the portability of data. It does not organise the portability of this organisation. And it says so, four times, in its own text.

First, the definition. Article 2, point 38 defines "exportable data" as the input and output data, including metadata, generated by the use of the service, "excluding any assets or data protected by intellectual property rights, or constituting a trade secret, of providers of data processing services or third parties". The exclusion is not a derogation added further on, nor an exception to be invoked. It is in the definition. What you are entitled to take with you is defined by subtracting what the provider claims.

Second, the clause. Article 25, paragraph 2, point (f) requires the contract to include "an exhaustive specification of categories of data specific to the internal functioning of the provider's data processing service that are to be exempted from the exportable data [...] where a risk of breach of trade secrets of the provider exists". The text thus requires the contract to list what you will not take with you. It is an obligation of transparency, which is better than silence, but it is an obligation of transparency about a deprivation.

Third, the guarantee stops at infrastructure. Article 30, paragraph 1, reserves functional equivalence, that is, the promise of finding elsewhere a service that does the same thing, to providers of "scalable and elastic computing resources limited to infrastructural elements such as servers, networks and the virtual resources [...], but that do not provide access to the operating services, software and applications". In other words, infrastructure alone. A computerised maintenance management system, an enterprise asset management system, a predictive maintenance platform fall under paragraph 2, which asks only for "open interfaces", and under paragraph 5, which asks only, in the absence of published common specifications, for an export "in a structured, commonly used and machine-readable format". A comma-separated values file meets this requirement.

Paragraph 6 of the same article adds that providers "shall not be required to develop new technologies or services, or disclose or transfer digital assets that are protected by intellectual property rights or that constitute a trade secret".

Fourth, custom-built services are exempted. Article 31, paragraph 1, sets aside the obligations of article 23 point (d), article 29 and article 30 paragraphs 1 and 3 for services "of which the majority of main features has been custom-built to accommodate the specific needs of an individual customer [...], and where those data processing services are not offered at broad commercial scale via the service catalogue of the provider of data processing services".

One must be honest about the scope of this last exclusion: a heavily configured software package deployment is not, in principle, a custom-built service in the catalogue sense. The regulation targets specific development, not configuration. But the boundary is defined nowhere, and the text leaves it to the provider to inform the customer, before signature, of the obligations that will not apply. A unilateral declaration, made at the moment when the customer has the least reason to pay attention to it.

The Commission knew, and legislated on the easy half

This split between infrastructure and software is not a drafting accident. It was documented, by the Commission itself, in the impact assessment accompanying the proposal for the regulation, in February 2022. The passage deserves to be read in full:

The absence of common standards is also a very relevant problem for the effective portability of data and for switchability between cloud and edge services. It is the most important technical cause of vendor lock-in in cloud and edge services, particularly as regards services that go beyond simple storage (PaaS/SaaS). Different data formats, data semantics or data architectures lead to different outcomes on the basis of the same data, and this prevents a specific application after switching from being maintained. While technical interoperability of simple storage (IaaS) cloud services may be easier in theory, at the SaaS level it forms a prohibitive obstacle.

So the Commission writes, in 2022, that the obstacle is prohibitive at the application level, and that it lies in data semantics and data architectures. Then the regulation, in 2023, reserves functional equivalence for infrastructure alone. The obstacle identified as the most important is the one the text does not address.

It will be objected that one had to start somewhere, and that article 30 paragraph 3 provides for what comes next: software providers will have to ensure compatibility with common specifications or harmonised standards, twelve months after their publication in a central Union repository. The mechanism exists. But it has not started to run.

The Commission's rolling plan for standardisation, in its 2025 edition, states that article 35 paragraph 8 "obliges the Commission to build this repository by means of implementing acts", and that "to prepare this repository, the Commission will launch a study", tasked with mapping the existing standards and specifications that could be included in it. That study delivered its results on 23 February 2026, and the page publishing them states that it aims to prepare "the first batch" of open specifications. As of 18 September 2026, I found no publication of the repository. I do not conclude that it does not exist; I say that I did not find it, and that the most recent official documents still describe it in the future tense.

As long as it is empty, paragraph 5 applies: a machine-readable export. Tables.

A note, in passing, on what was tried before. The same 2025 rolling plan recalls that the SWIPO codes of conduct, a self-regulatory scheme meant to organise portability and switching on a voluntary basis, "ultimately did not gain the desired market traction". Self-regulation was tried, and the Commission itself notes that it failed. It is an argument that it is fair to recall to those who propose returning to it.

What the contracts commit to returning

Let us move from the general text to actual commitments. IBM's cloud framework agreement, in its version published for IBM Cloud International B.V., reference Z126-6304-IBMCIBV_13_ZZ_08-2023, published on 7 December 2023, runs to seventeen pages. The article dealing with the fate of customer content is entitled, literally, "Removal of Content": removal, not return. It reads as follows:

IBM will return or remove Content from IBM computing resources upon the expiration or cancellation of the IBM Cloud Services [...] IBM may charge for certain activities performed at Client's request (such as delivering Content in a specific format).

And, in the provisions on termination:

Upon termination, IBM may assist Client in transitioning Content to an alternative technology for an additional charge and under separately agreed terms.

One must measure what these two sentences articulate. The return of the content is due, and free. The return of the content in a specified form is a chargeable service. Transition assistance is chargeable and, what is more, subject to terms that remain to be negotiated. Yet those terms are negotiated at the time of departure, that is, at the very moment when the customer has the least power: it has announced that it is leaving, it has nothing left to promise, and its schedule is already committed with the incoming provider.

A point of fairness, which matters. This document is dated August 2023 and published in December 2023, that is, before Chapter VI became applicable on 12 September 2025. The words "Data Act", "2023/2854", "portability" and "interoperability" appear nowhere in it, which is not a failing but a matter of date. What the clause documents is not an infringement; it is the state of contract practice just before the regulation came to apply to it. It serves here as a point of comparison, not as an accusation.

IBM's French cloud service description, reference i126-6605-28, published on 9 April 2024, adds an asymmetry of notice that says something about the structure of the relationship. IBM undertakes to give twelve months' notice before discontinuing an essential feature or introducing any non-backward-compatible change to an API, and twelve months before withdrawing a service. But the period falls to thirty days for a price increase or for a change to the service description itself, the very document that carries the exit terms, and to ninety days for an unfavourable change in service level. The text specifies that by continuing to use the Cloud Services after the notice period, the Customer accepts the changes (the document is in French; this is my rendering).

Twelve months for the technical interface, thirty days for the terms of exit, and silence counts as acceptance. The hierarchy of protections is explicit, and it does not place the exit at the top.

The same question put to three providers

Comparing contractual commitments is usually impossible, because each contract asks its own questions. There is one exception, and it is public. The British G-Cloud procurement framework, whose catalogue is published by the government, requires all suppliers to answer the same standardised questions, two of which concern us directly: "Data export approach" and "End-of-contract data extraction". The answers are public, dated, and binding on the supplier. Putting the same question to three publishers of asset management systems therefore becomes a reproducible exercise: any reader can redo the check.

Here are the three answers, as they stood on 18 September 2026.

IBM, Maximo Application Suite. End-of-contract data extraction: "IBM will return the Client Data within a reasonable period in a reasonable and common format upon receiving written instructions from the Client prior to termination or expiration." Data export approach: "Data can be exported from the solution as excel from tabular reports. Charts can be exported as pdf or images." Declared formats: comma-separated values, and XML.

Hexagon, Octave Attune EAM, formerly HxGN EAM. "Hexagon provide a full data set upon contract termination. The customer is responsible for extracting any interim data prior to contract termination. Additional cost options are available [...] for enhanced support in extracting the data." Formats: Excel, HTML, PDF, XML.

F0CUS Work and Asset Management. "At the end of the contract we would appoint a F0CUS developer to work on a full extraction of the customer's database and associated media. We would provide: A backup copy of the customer's F0CUS instance, provided as either a .bak file or a .bacpac file. [...]" And, in the description of the exit process: "Provide process charts and user manuals to new provider."

The result contradicts what one would expect, and that is what makes it interesting. It is not the largest publisher that delivers the most. The two global players deliver tables, one in a "reasonable and common format" whose definition remains in its hands, the other by charging for extraction assistance. The smallest of the three suppliers delivers the complete database and the process documentation, that is, the container, the content and the instructions for use.

Two conclusions can be drawn, and they must be kept apart. The first is technical: a database backup in a proprietary database management system format is no more portable than a comma-separated values file; it can only be used by someone able to rebuild the same schema. F0CUS's generosity is therefore not a universal solution. The second is structural, and it is the real lesson: the constraint is not technical, it is commercial. Nothing prevented the two large players from offering the same. The wider the installed base, the thinner the exit commitment.

A point of law, to be watched rather than settled. Extraction assistance charged as an additional option will have to be re-examined in the light of article 29 paragraph 1 of the regulation on 12 January 2027. I do not claim that it will be unlawful: the analysis depends on the contract concerned, on the exact characterisation of the service and on the regime applicable to the customer. I say that the date is known, that it is near, and that a buyer can use it in a negotiation right now.

The model is not a secret, and that is worse

It would be convenient to write here that publishers conceal the data model of their systems. That would be false, and verifiable as such in three clicks. Maximo's object dictionary, its object structures, its programming interface and its migration documentation are publicly accessible. One can read, without a licence and without a contract, which table holds the assets and which table holds the locations. The schema is not a trade secret.

This finding does not destroy the thesis; it sharpens it, and makes it more disturbing. If the schema is public and exit remains difficult, then the difficulty is not in the schema. It is in what the organisation has put into it.

An asset register in operation is not a schema; it is a filled schema. The functional hierarchy that attaches each pump to its station and each station to its network was built by engineers, one decision after another. The failure codes were chosen, debated, sometimes invented. The criticality thresholds encode a risk policy. The rules that trigger work encode a maintenance doctrine. None of this is protected by an intellectual property right of the provider: it is the customer's work. And yet none of it is found in a tabular export, because a tabular export carries values, not reasons.

The standard, here, is on the customer's side, and that is what makes the situation absurd. ISO 55001:2024, in its clause 7.6 devoted to data and information, requires the organisation, in substance, to determine the data and information required to support asset management; to determine the specifications of that data and information, including attributes, units of measure, quality and source; and to develop a plan for the collection, integration, quality improvement and sharing of data and information.

The second point is unambiguous: the specification of the data is an obligation of the organisation. Not of the provider. The standard places on the operator the definition of the model it uses. In practice, this specification is almost always produced, held and maintained by the software publisher and its integrator, and the customer discovers it the day it wants to leave. The ISO 55001 certified organisation complies with a requirement it does not control.

Clause 7.6 also adds a requirement that few operators know they must meet: the alignment, consistency and traceability of information and terminology between financial and non-financial functions. In other words, the same asset must bear the same name and the same identity in the accounts and in the workshop. This requirement presupposes a common model, independent of the two systems that host it on either side.

ISO 55013:2024, published in July 2024, finally names this data as assets in their own right. It is a twenty-page guidance document, and one must say what it does not do: its official abstract states that it "does not provide methodologies to derive or appraise value for data assets", nor for deriving financial values from them, nor even guidance on whether to do so. So data is recognised as an asset, and its valuation is given up. As long as a thing has no recorded value, no one defends its ownership in a negotiation.

What information that does not flow costs

This cost was measured once, seriously, and long ago. In 2004, the United States National Institute of Standards and Technology published a study carried out for it by RTI International and the Logistics Management Institute, under the reference GCR 04-867. It concerns the cost of inadequate interoperability in the capital facilities industry, that is, large commercial, institutional and industrial buildings. One hundred and five interviews, seventy organisations, an online survey, average costs per square foot extrapolated to a stock of thirty-seven billion square feet.

The method deserves describing, because it defines our subject exactly. The cost is obtained by comparing the actual situation with a counterfactual scenario in which data exchange, management and access would be seamless, which, the authors write, "implies that information need only be entered into electronic systems only once, and it is then available to all stakeholders instantaneously". The whole gap between that world and ours is the bill.

The results:

• 15.8 billion dollars per year for the year 2002, between 1 and 2% of the industry's revenue.
• Two thirds are borne by owners and operators, precisely 10.6 billion, or 68% of the total.
• About 85% of the owners' and operators' bill falls in the operation and maintenance phase, about 9 billion dollars for the year 2002 alone (9,027 of 10,648 million in the study's table ES-2).
• Among the cost items are, explicitly, manual re-entry costs and data translation costs.

The diagnosis made of operators is the one still heard in any maintenance management room: "An inordinate amount of time is spent locating and verifying specific facility and project information from previous activities", and "Legacy data issues are a significant concern for owners and operators", who receive over the years information in disparate formats which "does not always adequately reflect the true configuration of facilities".

Three caveats, which I prefer to state myself. This figure dates from 2002. It is American. And it concerns buildings, not water, energy or transport networks. I do not update it into today's euros, which would amount to manufacturing a figure that no one measured. It should also be noted that the authors themselves declare it conservative: opportunity losses were excluded from the calculation "because of their highly speculative nature", and tenants are outside the scope.

What strikes, twenty-two years on, is not the precision of the amount. It is that the problem was identified, quantified and published by a public institution in 2004, and that the first European text to tackle it dates from 2023, reserving its strongest guarantee for infrastructure alone.

Birmingham, or the remedy that consists in erasing one's configuration

The mechanism can be seen laid bare in a case documented by two public documents, not by the press: the external auditor's statutory recommendations, and the authority's statutory accounts.

In September 2023, the external auditor of Birmingham City Council, the largest local authority in England by population, issued to it statutory recommendations under the British local audit act. On the integrated management system that went live in April 2022, it wrote:

The Council has experienced significant problems during and resulting from the implementation of its new Enterprise Resource Planning (ERP) IT system, Oracle Cloud, leading to anticipated additional costs (total costs of £100 million compared to an initial budget of £38.7 million as approved by Cabinet in March 2021). [...] Due to these issues the Council has been unable to produce an outturn position for 2022/23 or a set of financial statements for 2022/23.

On the cause, the auditor is precise: the go-live had been rated "red" before launch, and "The finance system had several adaptations that did not subsequently operate effectively".

The statutory accounts for the year ended 31 March 2024, a two-hundred-and-fifty-nine-page audited document, give the sequel. The system "is still posting transactions incorrectly", and significant manual work remains necessary. Of the hundred million spent, the Council decided "to only capitalise spend up to what was deemed to be an appropriate sum of £19.6m, with all subsequent spend taken as expenditure". And the Council expects to have to impose "a limitation of scope on external audit activities" after the system is brought back into service.

But the decisive detail lies elsewhere, and it is the reason this case appears in this study. The decision taken in May 2024 is to reimplement the system in a standard version, removing the customisations, and to rely on "the tried and tested industry standard functionality in successful use by other Councils".

In other words: the organisation had spent years shaping the system its own way, and the remedy chosen consisted in erasing that work in order to adopt the publisher's model. The accumulated semantics were not carried elsewhere, nor documented, nor handed on. They were abandoned. This is the most radical form of what this study describes: when the model is not held, the only practicable exit is surrender.

Two caveats, again, and they are important. This is a financial and human resources management system, not an asset register: what transfers is the mechanism, not the scope. And the auditor writes in black and white that the Council's management arrangements for the implementation were "inadequate". Part of what happened lies in the authority's own governance, and it would be dishonest to attribute all of it to the supplier. Statutory recommendation number seven says what matters: "In the longer term, the Council will need to ensure that it rebuilds its own IT capacity and capability".

The regulator that cannot conclude

If the thesis is right, its effects should not stop at the operator. They should reach up to whoever supervises the operator. That is exactly what is observed, and the finding is public.

In December 2024, the water regulator for England and Wales published, as part of its price determinations, a roadmap on understanding the health of the sector's assets. In it, the regulator itself lists the obstacles that prevent asset condition from being compared between companies. The first on the list:

Different corporate systems are used for managing and recording core asset data, for example work-order management and failure reporting.

Then come the uneven quality of data according to each company's history, diverging interpretations of definitions, "for example of what constitutes the failure of an asset", heterogeneous maintenance strategies, and finally:

Inconsistent approaches to defining asset hierarchies and asset groups, for example different companies' considerations of electrical, mechanical and civil assets.

The regulator closes the section thus: "There is work ongoing to look at standardisation of definitions and modelling, but so far there are no common approaches being applied across the sector".

Yet it did use its powers. It had first found, on examining the companies' business plans, that "based on the data provided it was not possible to evidence that there is a sector wide challenge on asset health". As part of its draft determinations, it then issued a formal information request on asset condition and workload, addressed to companies over which it has powers of direction. The result, in its own words:

Companies strongly caveated the data provided given the limited time available to complete the data request, particularly as regards any comparisons in asset condition over time or between companies. This made it challenging to reach any firm conclusions on the state of asset condition in the water sector.

This sentence must be read for exactly what it says, and not for what one would like it to say. The regulator does not state that the infrastructure is deteriorating. Nor does it state that it is in good health. It says that it cannot conclude. A national regulator, with binding information powers over an entire sector, gets no answer to the simplest question that can be asked about essential infrastructure: what condition is it in.

It is not for want of warning. Three years earlier, in September 2021, the same regulator published the lessons of an asset management maturity assessment carried out with sixteen companies. Average maturity of the sector: "developing". Recommendation number four, verbatim: "Companies should develop a strategic approach to data and information management that takes into account the ability to share data". Three years separate this recommendation from the finding of failure. Ofwat cites the short time given to companies, but itself concludes that a standardised approach to the collection and assessment of asset condition data needs to be explored. What fails, in that interval, is not the operators' effort. It is the structure: as long as each company inherits its publisher's model, no amount of goodwill produces a common language.

The European scale

It remains to place the order of magnitude. To my knowledge, there is no recent European equivalent of the NIST figure applied specifically to physical infrastructure. On the other hand, several recent European studies measure the neighbouring phenomenon, software and cloud dependence, and their figures are accessible at source.

The consultancy Asterès, for Cigref, which brings together the digital departments of large French companies, established in April 2025 that European organisations spend about 400 billion euros per year on cloud services and software, of which 330 billion goes to American companies, 83% of the market, and that 80% of the value created by this spending, 264 billion euros, benefits the American economy. In a second study published in May 2026, the same consultancy projects, at constant spending volumes and over the period 2026-2030, an excess inflation averaging 140 billion euros per year, which would deprive the European economy of about 107 billion euros of value added per year, or 0.6 points of gross domestic product, and of 1.4 million jobs by 2030.

These studies were commissioned by an association of customers, and the second is a projection. I say so because symmetry matters: the study most often cited in the opposite direction, Professor Frédéric Jenny's study on licensing practices, was commissioned by an association of European cloud providers in dispute with a publisher. It estimates, in a range of 100 to 930 million euros with 560 million as the central estimate, the first-year additional cost borne by European customers of an office suite as a result of a change in licensing policy, and, in a range of 500 to 1,900 million with 1 billion as the central estimate, the additional cost cumulated from 2020 to 2022 on deployments of a database server outside its publisher's cloud. These two amounts often circulate added together and converted into an annual flow of 1.56 billion euros. The study never makes that addition, and neither term is annual. I give them separately.

The 264 billion figure was taken up, in December 2025, by a study requested by the European Parliament's Committee on Industry, Research and Energy, which places it at about 1.5% of the Union's gross domestic product, roughly one and a half times the European budget. That study did not produce the figure, it cites it, and this must be said. But it contributes in its own right something more useful than an amount, namely the mechanism, named by a European institution:

These dependencies are reinforced by vendor lock-in, long-term contracts, proprietary formats, and network effects that limit switching and suppress market entry for European innovators.

The same study also retains, among its indicators for measuring dependence, "qualitative and quantitative indicators of lock-in (e.g. proprietary formats, ecosystem control, open standards)". The European Parliament thus measures digital sovereignty, among other things, by the portability of formats.

Finally, the Commission puts a figure on its own expectations. The Data Act impact assessment estimates the gain from the cloud measures at 7.1 billion euros, corresponding to cloud demand 10.9% higher in 2025, and to 0.05 points of gross domestic product. It also puts at 653 million euros over two years the gross economic harm suffered by small and medium-sized enterprises from unbalanced contracts with cloud providers. And the official FAQ on the Interoperable Europe Act states that, according to its impact assessment, the Act is expected to save "up to 5 billion euro on a yearly basis", expressed as time saved when interacting with government services. These are expected gains, derived from models, not observed savings.

What an asset owner can demand

Everything above describes a dependence that is neither illegal, nor hidden, nor even malicious. It results from a void: no one ever required the model to belong to the operator. Yet the instruments to require it exist; they are international, public and purchasable, and they predate the problem.

First lever: a reference designation that belongs to the operator. The IEC 81346-1 standard, in its 2022 edition, published jointly by the International Electrotechnical Commission and the International Organization for Standardization, establishes the principles for structuring systems and the rules for forming unambiguous reference designations. Its official abstract says what matters:

The reference designation identifies objects for the purpose of creation and retrieval of information about an object and, where realized, about its corresponding component. A reference designation labelled at a component is the key to finding information about that object among different kinds of documents. The principles are general and are applicable to all technical areas [...].

This is exactly the answer to the problem. A reference designation describes a function within a system and a location. It is set by the operator, it survives the replacement of the equipment, and it survives the replacement of the software. It is a horizontal standard, that is, intended to be taken up by other standardisation committees, and it has existed since 2009 in its first edition.

A confusion to avoid, and a very widespread one. IEC 61406-1, from the same digital family, deals with a quite different object. It specifies "minimum requirements for a globally unique identification of physical objects which also constitutes a link to its related digital information", in the form of an address encoded in a two-dimensional code or a contactless tag. Its scope specifies that it applies to objects "that have already been given a unique identity by the manufacturer". It is therefore the identifier of the product, set by the manufacturer. It is useful, and it does not replace the former. Many projects buy the digital nameplate believing they have settled the question of the register. The two identifiers are complementary, and only the operator's protects against dependence.

Second lever: a standardised data model, enforceable in the specification. ISO 14224, in its 2016 edition confirmed in 2022, provides an equipment taxonomy, a standardised vocabulary of failure modes, and an exchange format. Its official abstract contains a sentence that a buyer should know by heart:

This International Standard establishes requirements that any in-house or commercially available RM data system is required to meet when designed for RM data exchange.

It was born in oil and gas, which limits its direct application outside those sectors, and it would be excessive to claim that it covers a water network or a building portfolio. But it shows that a normative exchange model is possible, that it has been written, and that it explicitly applies to commercial systems. The answer to "a reasonable and common format" is not a protest; it is a standard number.

What this gives, concretely, in a procurement. The following five requirements fit on one page of a specification, and none presupposes any particular balance of power.

• The reference designation belongs to the asset owner. It is defined according to IEC 81346, documented outside the system, and the contractor undertakes to carry it as is, without turning it into an internal technical key.
• The data specification is a contractual deliverable. In accordance with ISO 55001 clause 7.6 b), the contractor delivers and keeps up to date the list of attributes, units of measure, quality requirements and sources. This document belongs to the asset owner and remains with it at the end of the contract.
• The hierarchy, classifications and rules are exportable in a documented format. Not only the records: the structures, the value lists, the triggering rules, with their documentation.
• The list of exclusions is provided before signature. This is already an obligation of the regulation under article 25 paragraph 2 point (f); it is enough to require it explicitly, and to read it.
• Reversibility is tested during the contract, not at its end. A complete export is produced and reloaded into a third-party environment at an agreed interval, for example every two years. Reversibility that has never been tried is not reversibility; it is a clause.

The fifth is the most important and the least practised. It turns a promise into a verified fact, and it moves the discovery of the problem from the moment of divorce to a moment when one can still negotiate.

What we do not know, and what matters

Five uncertainties remain, and keeping quiet about them would weaken everything above.

There is no recent European figure equivalent to the NIST one. I found none, and I do not transpose the 2002 American figure to the Europe of 2026. The European orders of magnitude cited above concern software and cloud dependence in general, not the cost of asset information that does not flow. These are neighbouring phenomena, not the same phenomenon.

The central Union repository was not found published. The most recent official documents I could consult still describe it as yet to be built. An observed absence is not an established absence: a publication may have escaped me, and the check must be redone before any decision that depends on it.

The boundary of the custom-built exemption is defined nowhere. No decision and no published guideline says from what level of configuration a deployment ceases to fall under the catalogue. It is an area of interpretation, and it is entrusted in the first instance to the provider itself.

The fate of charged extraction assistance remains open. The date of 12 January 2027 is certain; its consequence for an assistance service sold as an option is not, and will depend on contracts and on the practice of the authorities.

Finally, a frequently cited study was not used here. A global figure for the cost of bad data in construction, of the order of one thousand eight hundred billion dollars, circulates widely. It comes from a study published by a software publisher with a consultancy, which is not disqualifying in itself, but its own pages do not agree: the share of rework attributed to bad data is 14% or 16%, and its cost appears with a factor of a thousand between documents. A study whose sponsor sells the solution to the problem it measures, and which never gives the same figures twice, has no place in a body of evidence. I prefer to say so rather than use it.

What remains, once these caveats are stated, fits in a few words. The right of exit exists, it is becoming free, and it delivers tables. The model, for its part, does not leave, because no one ever asked for it. This is not a technical fatality: it is a contractual void, and the standards to fill it have been written for fifteen years. The question is no longer whether one can leave. It is what one takes away, and who wrote the answer.

Sources and references

All sources were consulted and verified between September and October 2026. The [n] cross-references in the text point to this list.

1. Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). EUR-Lex, CELEX 32023R2854. Article 2, points 32, 33 and 38; articles 23, 24, 25, 29, 30, 31 and 35.
2. European Commission, Impact Assessment accompanying the proposal for a Data Act, SWD(2022) 34 final, 23 February 2022, sections 2.2 and 2.3, and summary of benefits and costs.
3. European Commission, Rolling Plan for ICT Standardisation, section "Cloud and edge computing", 2025 edition, Interoperable Europe Portal. Also the source of the passage on the SWIPO codes of conduct.
4. European Commission, Results of the study on interoperability of data processing services, page published on 23 February 2026, digital-strategy.ec.europa.eu. Study carried out by WIK, Decision and Schuman associates.
5. European Commission, frequently asked questions on the Interoperable Europe Act, Interoperable Europe Portal, consulted on 18 September 2026.
6. French Act no. 2024-449 of 21 May 2024 to secure and regulate the digital space (SREN Act), articles 26 and 27. Légifrance, JORFTEXT000049563368.
7. ARCEP, press release of 2 July 2026, reference 39-26, on the guidelines on switching charges and data transfer charges. Recalls decision no. 2025-0340 of 20 February 2025 and the ministerial order of 17 November 2025, published on 30 November 2025, setting the maximum charge at zero euros.
8. IBM, Cloud Services Agreement, IBM Cloud International B.V., reference Z126-6304-IBMCIBV_13_ZZ_08-2023, version 13, published on 7 December 2023, articles 2.f and 7.
9. IBM, Descriptif de Services IBM Cloud (French cloud service description), reference i126-6605-28, published on 9 April 2024, articles 6.1.1, 6.1.2 and 6.1.3.
10. IBM, IBM Cloud Terms of Use, cloud.ibm.com, sections "EU Data Act" and "French SREN Law", last updated on 26 August 2026.
11. IBM, Service Description, IBM Maximo Application Suite as a Service for Other Public Clouds, reference i126-9424-01, June 2022.
12. Digital Marketplace, G-Cloud framework, service listings published by the UK government, consulted on 18 September 2026: IBM Maximo Application Suite, service 796607983892135; Octave Attune EAM, formerly HxGN EAM, service 363440304862681; F0CUS Work and Asset Management System, service 210498469166781. Sections "Data export approach" and "End-of-contract data extraction".
13. Public documentation of the Maximo programming interface and object structures, IBM Docs and ibm-maximo-dev.github.io, consulted on 18 September 2026.
14. ISO 55001:2024, Asset management, Asset management system, Requirements, second edition, July 2024, clause 7.6.
15. ISO 55013:2024, Asset management, Guidance on the management of data assets, first edition, July 2024, ISO/TC 251, 20 pages.
16. ISO 14224:2016, Petroleum, petrochemical and natural gas industries, Collection and exchange of reliability and maintenance data for equipment, third edition, September 2016, confirmed in 2022.
17. IEC 81346-1:2022, Industrial systems, installations and equipment and industrial products, Structuring principles and reference designations, Part 1: Basic rules, joint IEC and ISO publication.
18. IEC 61406-1:2022, Identification Link, Part 1: General requirements, clause 1, scope.
19. NIST GCR 04-867, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry, August 2004, prepared for the National Institute of Standards and Technology by RTI International and the Logistics Management Institute. Executive summary and section 6.5.
20. Grant Thornton, Birmingham City Council External Audit 2020-21 to 2023-24, Statutory recommendations under Schedule 7 of the Local Audit and Accountability Act 2014, September 2023, section "Oracle implementation" and statutory recommendations 5 to 7.
21. Birmingham City Council, Statement of Accounts for the Year Ended 31 March 2024, 259 pages, sections "Oracle implementation issues", "Oracle" and "Oracle Issues".
22. Ofwat, PR24 final determinations: Roadmap for enhancing asset health understanding in the water sector, December 2024, section 3 "Industry Challenges".
23. Ofwat, Asset management maturity assessment, insights and recommendations, September 2021, recommendation no. 4 and summary of maturity scores.
24. Asterès for Cigref, La dépendance technologique aux softwares et cloud services américains, une estimation des conséquences économiques en Europe, April 2025.
25. Asterès for Cigref, From technological dependency to economic capture: the cost of cloud and software services inflation to Europe, May 2026, executive summary and section 4.
26. European Parliament, European Software and Cyber Dependencies, study requested by the ITRE Committee, PE 778.576, December 2025, key findings and section 3.
27. Frédéric Jenny, Unfair Software Licensing Practices: A quantification of the cost for cloud customers, report for CISPE, 21 June 2023, sections 2.3.1 and 2.3.2.
28. GFMAM, Asset Management Landscape, version 3.0, 2024, subject 5.5 "Asset Management Data and Information Systems".

Download

Read the document (PDF)

14 pages · English · 28 sources · 125 KB
Fully selectable and citable text
The document carries its own DOI, reserved before export
CC BY-NC-ND 4.0 licence, no registration

Bibliographic record

Title

Asset data: exit becomes free, the model stays captive

Author

Nizar Younes Mqam, ORCID 0009-0008-5549-7620

Serial publication

Cahiers de technopolitique, no. 3, Study format

ISSN

3131-7979

Publisher

Nizar Younes Mqam, Tourcoing, France

Publication date

18 September 2026

Revision

7 October 2026: every quotation, figure and attribution checked against its primary source; dates, figures, attributions and references corrected, cuts in quotations marked [...]. The argument is unchanged.

Language

English

DOI

10.5281/zenodo.23207208
All versions : 10.5281/zenodo.23199523

Permanent repository

Zenodo, hosted by CERN

Licence

CC BY-NC-ND 4.0

Other languages

Français (original)

To cite this study

Mqam, N. Y. (2026). Asset data: exit becomes free, the model stays captive. Cahiers de technopolitique, n° 3. https://doi.org/10.5281/zenodo.23207208

Read also

No. 7 · Study · October 2026

ISO 55001 and the AI agent: who signs before the auditor?

The next step: once the maintenance AI becomes an agent that acts, the question is no longer only who owns the data, but who answers for the decision.

11 pages · 30 sources · PDF 115 KB
DOI 10.5281/zenodo.23207212

Also inFrançaisالعربية

Read the record and download

No. 2 · Note · September 2026

Maintenance AI: you keep ownership, you lose control

The companion note: predictive maintenance contracts concede ownership of the data and keep what is derived from it.

5 pages · 12 sources · PDF 87 KB
DOI 10.5281/zenodo.23207206

Also inFrançaisالعربية

Read the record and download

No. 1 · Study · September 2026

When the cloud catches fire

When the cloud catches fire: the platforms that host maintenance AI are physical buildings, and in March 2026 drones reached them.

22 pages · 43 references · PDF 177 KB
DOI 10.5281/zenodo.23270771

Also inFrançais

Read the record and download