Digital Sovereignty in Real Estate Portfolios

A small conversion with surprisingly wide-reaching consequences

Two seminar rooms are merged into one larger room. The partition wall is removed and one door disappears. In construction terms this is a manageable undertaking. For the information about the building, the change is far more significant.

In design, the floor plan changes and, where applicable, so does the BIM model. Two room objects become one new room; the wall and the door cease to exist. For building operations, areas and allocations have to be adjusted. Leasing can no longer offer two seminar rooms, but one larger room with a different capacity, different equipment and possibly a different pricing logic. Cleaning, building services, cost centres, fire safety or later sustainability assessments can be affected as well.

This raises a simple question: Where is the valid information about this room to be found after the conversion?

The obvious answer is not: in a particular system. It is rather: That depends on which information is involved.

The geometry may come from a BIM model. Bookability comes from leasing. A cost centre is owned in the ERP system. Maintenance information sits in operations. An energy management system holds consumption data. None of this information is less relevant simply because it is created outside a building model.

This is precisely where the question of digital sovereignty in the real estate portfolio begins.

A building does not have just one digital representation

In a larger real estate portfolio, information about the same building exists simultaneously in many specialist contexts. In itself this is not a shortcoming, but a consequence of different tasks.

For design, a room is among other things a geometric object. For leasing it is a bookable resource. Technical operations look at equipment, plant and operator obligations. Accounting needs commercial allocations. For building automation, the same room may be part of a control zone. Sustainability managers, in turn, need area, consumption or occupancy information.

These perspectives cannot sensibly be reduced to a single one.

In software development, domain-driven design describes a comparable principle: disciplines have their own terms, rules and responsibilities. The point is not to abolish these differences. The point is that everyone involved can recognise when they are talking about the same real-world object and how their information belongs together.

For the seminar room this means: leasing does not have to manage door geometry. The BIM model does not have to contain booking prices. The ERP system does not need the room's full technical equipment. Even so, the systems and disciplines must be able to establish a common reference.

A shared language is therefore something other than a shared database.

This is already apparent in the established standards themselves: IBPDI (International Building Performance & Data Initiative), an industry-wide data model for portfolio reporting and ESG benchmarking, describes above all the portfolio and ESG level. RealEstateCore, an open ontology for smart building and IoT data, covers the operations and IoT level. IFC (Industry Foundation Classes), maintained by buildingSMART International, covers the building and component level. The Asset Administration Shell with its AASX exchange format, developed by the IDTA (Industrial Digital Twin Association), represents manufacturer data on plant and components in a vendor-neutral way – from the nameplate through to the maintenance documentation. With the forthcoming digital product passport, which the EU is prescribing for more and more product groups, the AAS gains further importance: it can provide the technical basis for it. Brick Schema, as an open ontology, describes sensors, plant and their relationships in building automation and HVAC. None of these standards covers the entire picture on its own, because they were created for different specialist purposes.

This does not amount to a plea for yet another, all-encompassing standard. Such a standard would hardly be worth developing either: each of the standards mentioned has grown within its own domain and matured there. What leads to results is not the one big standard, but a meaningful combination of the existing ones – each used where it plays to its strengths, and connected to the others at the edges.

Among these standards, BIM nevertheless holds a special position in the construction and real estate context: it is not only a data source for IFC but, in many organisations, also an established way of working and the first point of reference when it comes to building information. How much weight BIM should actually carry in a shared information layer therefore deserves a closer look.

BIM where BIM exists

BIM plays an important role here. Where a reliable model exists, it should of course be used. Geometry, rooms, components, technical plant and spatial relationships can be taken from it at high quality. It would make neither economic nor professional sense to capture this information a second time in parallel.

It only becomes problematic when this strength is turned into a general precondition: that modelling must come first before information can be used in a structured way. Or the other way round: that all information created during operations has to be fed back into the BIM model so that a complete data basis emerges.

For new-build projects with an end-to-end BIM process, such an approach can work for selected information. It cannot readily be transferred to large existing portfolios, however.

An owner managing 50,000 residential units, for example, and holding current BIM models for only some of them faces a different economic reality. Building master data may sit in the ERP system, areas in a CAFM system, energy information in a specialist application and further portfolio information in Excel files. If all these units first have to be modelled in detail before the existing information can be used together, information management becomes dependent on an additional modelling project.

The effort has to match the purpose at hand, though. A portfolio analysis may initially require building, use, area, year of construction and energy information. A geometric building model is not necessarily needed for that.

This leads to a pragmatic principle: “Information management has to be guided by the reality of the existing portfolio – not the portfolio by a preferred data format.”

Where BIM exists, BIM can be an authoritative source. Where a CAFM system holds the most reliable operational information, that is the appropriate source. Commercial information can come from the ERP system. And if a reliable Excel list is currently the best available source, it must be possible to integrate that too.

Excel is therefore not the target picture. It is one possible starting source.

The decisive step is to release the information it contains from its isolated file or system logic and to be able to relate it to the information held by other disciplines.

Digital sovereignty is more than the storage location

When it comes to digital sovereignty, the discussion often turns first to cloud providers, server locations and the question of whether software can be run in an organisation's own data centre. These questions matter. For handling real estate information, however, they are not sufficient.

A company can store all its data on its own servers and still deal with it in only a limited sovereign way.

This becomes clear from a few simple questions:

• What does a particular piece of information mean within the company?
• Which real building, room or item of plant does it refer to?
• Where does it come from?
• Which discipline is responsible for it?
• Which change led to its current state?
• Who is allowed to read or modify it?
• Can it be reused outside the originating system?

Where reliable answers to these are missing, there may be technical ownership of the data but only limited ability to act.

For real estate portfolios, three aspects can therefore be distinguished:

Semantic sovereignty means that the organisation itself determines how buildings, rooms, plant and other information are described and connected with one another.

Provenance sovereignty means that it remains traceable where information comes from, who is responsible for it and how it has changed.

Operational sovereignty means that the information infrastructure required for this can be run under the organisation's own control.

Digital sovereignty arises from the interplay of these three levels.

A shared language instead of a “single source of truth”

The frequently used notion of a “single source of truth” falls short of this task. It suggests that there has to be one central source for a building from which all other systems obtain their truth. In practice, however, there are various sources owned by different disciplines.

For the seminar room example, the allocation could look like this:

The specific allocation differs from organisation to organisation. What matters is the principle: “Not every system has to own every piece of information. But the organisation has to know which source is authoritative for which information and how the information is connected.”

Data mesh describes an organisational approach for this: responsibility for data stays, as far as possible, where the subject-matter expertise sits. The individual areas make their information available in an agreed form so that other areas can use it.

This does not create a central truth, but a network of information owned by the respective disciplines. A shared language ensures that this network does not turn into a new muddle. When the ERP system speaks of “property 4711”, leasing of “seminar centre, 1st floor” and the BIM model of a room with its own GUID, the information architecture has to be able to make these references intelligible.

Why is the room the way it is today?

After a few years, only Room C is still visible in the system. For day-to-day operations that may be sufficient at first. At the latest during a conversion, an audit or a data clean-up, however, the history becomes relevant.

Why does Room C exist? Which two rooms were there before? When was the partition wall removed? Why does the former door no longer exist? Where does the current area figure come from? When did leasing switch to the new room?

Such questions lead to the origin and development of the information. In data management, the term data lineage is frequently used for this.

For real estate operations this can be understood in non-technical terms as a traceable information history: Room A + Room B + Door T17 becomes, through a documented conversion, Room C.

The geometric change can come from the BIM model. The new capacity comes from leasing. The commercial allocation is changed in the ERP system. The individual disciplines retain their responsibility, while it remains traceable which changes are connected with one another.

This is more than technical logging. For an operator, this traceability determines whether information can later be explained, audited, corrected and used for new purposes.

ISO 19650 is evolving towards the asset lifecycle

The ongoing revision of ISO 19650 is also of interest in this context. The currently valid ISO 19650-1:2018 already describes information management across the entire lifecycle of a built asset. The current revision draft ISO/DIS 19650-1 places this lifecycle idea even more firmly at the centre and is still going through the revision process.

Dr Volker Krieger, a long-standing member of the responsible international working group, described the previous separation between project and asset management in a June 2026 interview with buildingSMART Deutschland as a “birth defect” of the first edition. The more modern perspective, he argues, is the asset lifecycle. Accordingly, the flow of information should not be understood as an isolated project with a single data handover at the end, but as part of a lifecycle.

For the question at hand this is relevant, without over-interpreting a standardisation process that has not yet been completed.

ISO 19650 does not answer which specific software system a real estate operator should use. It provides terms, concepts and processes for information management. The current draft also recommends free and open standards, but deliberately remains technology-neutral.

The change of perspective does, however, match a reality that operators experience every day: information is not created once and for all in the construction project. It is supplemented, corrected and newly created during operations. Conversions change the portfolio. Leasing and use change. Plant is replaced. New requirements are added.

Information management therefore does not end with the handover of a BIM model. 

Standards are necessary – but they do not execute themselves

The construction and real estate industry already has numerous standards, data models and sets of rules. They can define terms, formulate information requirements or harmonise the exchange between systems.

That is a necessary basis for interoperability.

But it does not yet solve an operator's organisational problem.

A standard does not automatically connect a building's BIM model with leasing's room data. It does not clarify by itself that two different identifiers refer to the same real-world object. It does not decide which discipline is responsible for a piece of information. And it does not run a permanently available infrastructure in which origin, rights and relationships remain traceable.

An information layer does not have to replace these standards in order to do so. It can implement established standards such as IFC, IBPDI or RealEstateCore and connect them at their edges, instead of adding yet another standard of its own.

This shifts the question: Does the real estate industry really need yet another standard – or does it increasingly need systems with which existing standards and data models can be applied in practice?

For an operator, what ultimately matters is not that a shared language exists on paper. It has to work in the daily flow of information.

An information layer between the specialist worlds

For this, an additional information layer is conceivable that does not try to replace the existing specialist systems.

It need be neither the next CAFM system nor the next BIM system. Its task is to connect information from different specialist worlds in an intelligible way.

Such a layer would have to, for example:

• be able to connect different information sources,
• manage shared terms and identities,
• represent relationships between pieces of information,
• respect responsibilities within the disciplines,
• make origin and changes traceable,
• control access and usage rights,
• and enable different applications to work on the same information basis.

It can be pictured as an “operating system for operator data”: not as the operating system of a computer, but as a permanently available foundation on which different specialist applications can work together.

The hybrid approach is important here.

The BIM model remains the source where it is the appropriate source. The ERP system remains the ERP system. Leasing keeps its own domain logic. Existing CAFM and GIS systems do not have to be replaced first. Even Excel data can be integrated as a starting point.

The shared information layer does not make all systems know the same things. It makes their information connectable.

A shared language alone is not enough for this, however. However uniformly terms may be defined: if it is not recorded anywhere which specific object is connected with which other one, the link between the systems remains incomplete. It is not enough to use the same terms – the actual objects must be concretely linked across disciplinary boundaries, and these links must be recorded permanently.

For the seminar room from the opening example this means: a sensor is installed in a specific room. The former door T17 was linked, via a fire alarm control panel, to a specific detector. And a complete room profile only emerges once geometry from the construction department, maintenance data from the CAFM system, occupancy data from leasing and climate data from building automation are brought together. Such connections arise during ongoing operations, often only at installation or during maintenance. No design model represents them in advance.

Why artificial intelligence depends on linked objects

A growing use case for such an information layer is the deployment of AI-assisted systems in real estate operations – for example to answer questions about the portfolio, detect anomalies or produce analyses automatically.

A language model can read texts from different systems and summarise them in linguistically sensible ways. But it does not know by itself that a ticket from the CAFM system, a cost centre in the ERP system and a room in the BIM model refer to the same real-world object, as long as this connection is not recorded anywhere. Without such a reference, all the AI can do is guess at plausible-sounding connections – with the risk that false or unreliable statements result.

If the objects are concretely linked with one another, on the other hand, an AI application can build on assured relationships instead of inferring them from free text. A question such as “Which rooms with overdue maintenance are currently vacant?” can then be answered reliably, because room, maintenance status and occupancy are traceably assigned to the same object – not because a language model happened to combine the right terms across different documents correctly.

The same foundation that creates semantic and provenance sovereignty for people thus also becomes the precondition for reliable AI results.

The sovereignty layer has to be operable

This requirement cannot be met on paper alone, however. It is not enough to describe relationships, responsibilities and provenance conceptually – that calls for concrete, operable software. Otherwise the same path threatens that many standards in the construction and real estate industry have already taken: years of coordination before practical tools even emerge.

Current AI developments provide the counter-example: standards catch on particularly quickly there when an active implementation is supplied from the outset instead of merely publishing a specification. One example is the Model Context Protocol (MCP), which established itself across industries within a few months – not because the document was more convincing than others, but because working software was available for it from the start.

The sovereignty layer must not become the next lock-in

This very software raises a question of its own, though. If it takes on a central role for a real estate portfolio in the long term, a new problem arises.

What happens if this very software is in turn entirely dependent on a single vendor and its cloud?

Various data silos would then be connected, but the strategic dependency would merely have been shifted by one level.

The opposite position – every operator develops its own platform – is no more convincing. Real estate companies want to manage buildings and portfolios. As a rule, they do not want to develop their own software product with release management, security updates, bug fixing and long-term product maintenance.

Nor does simply publishing source code automatically solve this problem. Software that is relevant to operations needs active maintenance. Dependencies have to be updated, security vulnerabilities closed, interfaces maintained and new requirements implemented.

Digital sovereignty must therefore not be confused with “doing everything yourself”.

Source available: control without building it yourself

At this point the licensing and business model becomes part of the architecture question. In this context, a source-available model can be understood as an approach that combines two interests: the organisation should be able to run the software and its data under its own control. At the same time, there has to be a commercially viable vendor that actively develops and maintains the software.

This differs both from a completely closed platform and from an open source project in which long-term maintenance and product responsibility are unclear.

For an operator the objective is pragmatic: I want to be able to run the information infrastructure in my company without having to build and permanently maintain it myself.

Such a model can combine source code access, in-house operability and extensibility with professional maintenance, releases, support and service levels.

The balance is what matters. It must be possible to develop the software further on a commercial basis without locking the customer's information base into a proprietary dead end.

Not modelling everything – making everything connectable

Back to the two seminar rooms.

After the conversion, leasing does not have to operate any BIM software. The BIM model does not have to store booking prices. The ERP system does not have to know about the former door. And technical operations do not have to keep their own copy of all commercial information.

Even so, the organisation should be able to trace unambiguously that everyone involved is talking about the same new room. It should know who is responsible for which information and where that information comes from. And it should be able to use information for new tasks without having to gather it manually from various systems every time.

For large existing portfolios this is more important than the idea of a fully modelled digital replica that unites all information within itself.

Digital sovereignty therefore does not mean transferring all information into a single model or system. It means connecting the existing information sources in such a way that the company itself can determine the meaning, origin and use of its data.

That requires open standards. But it equally requires software that makes these standards applicable within the company – permanently operable, commercially maintained and without creating the next unnecessary dependency.