Der digitale Gebäudepass als Plattform zur Umsetzung der europäischen Gebäuderichtlinie

· Inhaltsverzeichnis

1. 1  Management Summary
   1.1 Ausgangslage · 1.2 Ziel des digitalen Gebäudepasses · 1.3 Bedeutung für Eigentümer, Energieberater, Banken und Immobilienwirtschaft · 1.4 Wichtigste Ergebnisse · 1.5 Zentrale Handlungsempfehlungen · 1.6 Kernaussage
2. 2  Anlass, Ziel und Abgrenzung
   2.1 Zweck des Whitepapers · 2.2 Definition des digitalen Gebäudepasses · 2.3 Vom Dokument zum Datenmodell · 2.4 Abgrenzung zum Energieausweis · 2.5 Abgrenzung zum Renovierungspass · 2.6 Abgrenzung zum deutschen individuellen Sanierungsfahrplan · 2.7 Abgrenzung zum digitalen Gebäudelogbuch · 2.8 Abgrenzung zum digitalen Zwilling · 2.9 Abgrenzung zur klassischen Gebäudeakte · 2.10 Zusammenschau der Abgrenzungen · 2.11 Der finanzierungsfähige Gebäudedatensatz · 2.12 Rechtliche Einordnung
3. 3  Regulatorischer Rahmen der EPBD
   3.1 Entwicklung der europäischen Gebäuderichtlinie · 3.2 Die Richtlinie (EU) 2024/1275 als Ordnungs- und Datenrahmen · 3.3 Ziele für 2030, 2040 und 2050 · 3.4 Umsetzungsfristen der Mitgliedstaaten · 3.5 Verhältnis zum deutschen GEG und zur BEG · 3.6 Normstand: DIN V 18599:2018-09 und DIN/TS 18599:2025-10 · 3.7 Verbindung zu weiteren Regelungen · 3.8 Zwischenfazit
4. 4  Das Gebäudedatenmodell des digitalen Gebäudepasses
   4.1 Vom Gebäudedokument zum Gebäudedatensatz · 4.2 Grundstruktur des Gebäudedatensatzes · 4.3 Eindeutige Gebäudeidentität · 4.4 Stammdaten: Grundstück, Standort und Klimabezug · 4.5 Geometrie und Bezugsflächen · 4.6 Nutzung und Zonierung · 4.7 Gebäudehülle und Bauteildatensätze · 4.8 Technische Anlagen · 4.9 Energiebilanz und Berechnungszustand · 4.10 Der Energieausweis als Datensatz · 4.11 Verbrauchs- und Betriebsdaten · 4.12 Sanierungshistorie und Renovierungsfahrplan · 4.13 Fördermittel, Kosten und Wirtschaftlichkeit · 4.14 Lebenszyklus, GWP und Ressourcen · 4.15 ESG- und Finanzierungssicht · 4.16 Dokumente und Nachweise · 4.17 Datenqualität, Vertrauensstufen und Datenzustände · 4.18 Historisierung und Versionierung · 4.19 Maschinenlesbare Formate und Schnittstellen · 4.20 Die Gesamtarchitektur des Datenmodells
5. 5  Vom digitalen Gebäudepass zum digitalen Zwilling
   5.1 Der digitale Zwilling als funktionaler Begriff · 5.2 Vier Reifegrade · 5.3 Was die EPBD verlangt — und was darüber hinausgeht · 5.4 Automatische Datenerfassung als Voraussetzung der Skalierung · 5.5 Der Gebäudedatensatz als führende Quelle · 5.6 Von den Gebäudedaten zur normativen Berechnung · 5.7 Ist-Zustand, Plan-Zustand und Ziel-Zustand · 5.8 Der Zeitstrahl und die Gebäudechronik · 5.9 Abhängigkeitsmodell und automatische Neuberechnung · 5.10 Betriebsdaten und der Soll-Ist-Vergleich · 5.11 Dokumente als Ausgabe des Datenmodells · 5.12 Qualitätssicherung und fachliche Verantwortung · 5.13 Rollen, Sichten und Zugangspunkt · 5.14 Zielbild und Kernaussage
6. 6  Die EPBD-Instrumente im digitalen Gebäudepass
   6.1 Vom Einzelinstrument zur gemeinsamen Datenbasis · 6.2 Energieausweis — Artikel 19 bis 21 und Anhang V · 6.3 Renovierungspass — Artikel 12 und Anhang VIII · 6.4 Nationale Gebäuderenovierungspläne · 6.5 Gebäudedatenbanken — Artikel 22 · 6.6 Datenaustausch — Artikel 16 · 6.7 Digitales Gebäudelogbuch — Artikel 2 Nummer 41 und Artikel 12 Absatz 8 · 6.8 Smart Readiness Indicator — Artikel 15 · 6.9 Lebenszyklus-GWP und Ökobilanz — Artikel 7 und Anhang III · 6.10 Inspektionsberichte — Artikel 23 und 24 · 6.11 Nullemissionsgebäude — Artikel 11 · 6.12 Ein Datenkern, viele Anwendungen · 6.13 Übersicht
7. 7  Funktionsarchitektur des digitalen Gebäudepasses
   7.1 Vom Datenmodell zur operativen Plattform · 7.2 Baustein 1 — Digitale Gebäudeakte · 7.3 Baustein 2 — Energieausweis-Modul · 7.4 Baustein 3 — Renovierungspass · 7.5 Baustein 4 — Fördermittelmodul · 7.6 Baustein 5 — Finanzierungs- und Wirtschaftlichkeitsberechnung · 7.7 Baustein 6 — Bauphysik und technische Gebäudeausrüstung · 7.8 Baustein 7 — Ökobilanz, CO₂ und Treibhauspotenzial · 7.9 Baustein 8 — BIM- und IFC-Import · 7.10 Baustein 9 — KI-gestützte Plan- und Dokumentenanalyse · 7.11 Baustein 10 — Prüf-, Freigabe- und Qualitätssicherungsprozesse · 7.12 Querschnittsfunktionen: Rollen, Dokumente, Ereignisse und Fristen · 7.13 Anwendungssichten für externe Nutzergruppen · 7.14 Architekturgrundsatz und Gesamtbild
8. 8  Technische Architektur und Schnittstellen
   8.1 Anforderungen an die technische Architektur · 8.2 Das Schichtenmodell · 8.3 Datenbankstruktur: Objekte, Beziehungen, Zeitreihen · 8.4 Kanonisches Datenmodell statt Formularlogik · 8.5 Programmierschnittstellen: Zugriffsebenen, Versionierung, Ereignisse · 8.6 Maschinenlesbare Datenformate · 8.7 Gebäudeidentifikatoren und Zugriffsreferenzen · 8.8 Schnittstelle zu Energieausweisregistern · 8.9 Nationale Gebäudedatenbanken und Exportprofile · 8.10 Verbindung zum EU Building Stock Observatory · 8.11 Import von BIM-, CAD- und Messdaten · 8.12 Export für Behörden, Banken und Fachplaner · 8.13 Sicherheit, Audit Trail und Revisionssicherheit · 8.14 Langzeitarchivierung und Datenmigration · 8.15 Semantische Interoperabilität, Datenkatalog und Regelwerkskatalog · 8.16 Zielarchitektur und Stand der Schnittstellen
9. 9  Datenschutz, Datensouveränität und Revisionssicherheit
   9.1 Datenschutz als Bestandteil der Datenarchitektur · 9.2 Trennung von Gebäude- und Personendaten · 9.3 Eigentum an Gebäudedaten · 9.4 Rechte von Eigentümern, Mietern und Verwaltern nach Artikel 16 EPBD · 9.5 Statische Gebäudedaten und dynamische Nutzungsdaten — die Abgrenzung zum EU Data Act · 9.6 Zugriff durch bevollmächtigte Dritte · 9.7 DSGVO, Zweckbindung und Datenminimierung · 9.8 Rollen- und Berechtigungssystem · 9.9 Rechte auf Datenfeldebene und das Least-Privilege-Prinzip · 9.10 Betriebs- und Messdaten, Mehrparteiengebäude · 9.11 Datenschutz beim Eigentümerwechsel · 9.12 Verschlüsselung und Authentifizierung · 9.13 Protokollierung, Audit Trail und Revisionssicherheit · 9.14 Berechnungssnapshot, Zeitstempel und Dokumentenversionierung · 9.15 Datensicherung, Löschung und Aufbewahrung · 9.16 Datenqualität, Herkunft und Vertrauensmodell · 9.17 Die sieben Grundsätze der Vertrauensarchitektur · 9.18 Stand der Umsetzung im vorhandenen Gebäudepass · 9.19 Kernaussage
10. 10  Prozesse über den gesamten Gebäudelebenszyklus
    10.1 Der Lebenszyklus als Datenkette · 10.2 Neubau · 10.3 Bestandsaufnahme · 10.4 Verkauf und Eigentümerwechsel · 10.5 Vermietung · 10.6 Finanzierung · 10.7 Sanierungsplanung · 10.8 Fördermittelbeantragung · 10.9 Ausführung und Dokumentation · 10.10 Betrieb und Wartung · 10.11 Rückbau und Kreislaufwirtschaft · 10.12 Der rote Faden durch alle Phasen
11. 11  Nutzen des digitalen Gebäudepasses für die einzelnen Zielgruppen
    11.1 Ein Datenkern, unterschiedliche Sichten · 11.2 Der Building Trust Index als gemeinsame Bezugsgröße · 11.3 Eigentümer · 11.4 Energieberater · 11.5 Architekten und TGA-Planer · 11.6 Hausverwaltungen · 11.7 Banken · 11.8 Versicherungen · 11.9 Immobilienmakler · 11.10 Kommunen · 11.11 Wohnungsunternehmen · 11.12 Forschung und Statistik · 11.13 Weitere Beteiligte · 11.14 Netzwerkeffekt, Grenzen und Übersicht
12. 12  EPBD-Anforderungsmatrix für den digitalen Gebäudepass
    12.1 Aufbau, Statusskala und Lesart der Matrix · 12.2 Energieausweis und Register · 12.3 Renovierungspass und Sanierung · 12.4 Anlagen, Automation und Betrieb · 12.5 Lebenszyklus und Emissionen · 12.6 Daten, Zugriff und Fristen · 12.7 Auswertung der Matrix · 12.8 Von der Matrix zum Pflichtenheft
13. 13  Reifegradanalyse des vorhandenen digitalen Gebäudepasses
    13.1 Zweck der Reifegradanalyse und ihre Beweislage · 13.2 Bewertungsmaßstab: fünf Reifestufen · 13.3 Reifegradübersicht · 13.4 Bereits abgedeckte Funktionen · 13.5 Teilweise abgedeckte Anforderungen · 13.6 Noch fehlende Funktionen · 13.7 Fehlende Schnittstellen · 13.8 Rechtliche und technische Risiken · 13.9 Gesamtbewertung
14. 14  Entwicklungsroadmap
    14.1 Ordnungsprinzip: Abhängigkeit vor Wunschtermin · 14.2 Der regulatorische Taktgeber und die externen Blocker · 14.3 Stufe 1 — EPBD-Basisdatenmodell · 14.4 Stufe 2 — Energieausweis und Renovierungspass · 14.5 Stufe 3 — Maschinenlesbarkeit und Exportprofile · 14.6 Stufe 4 — Rollen für Banken, Makler und Hausverwaltungen · 14.7 Stufe 5 — Lebenszyklus-GWP, ESG-Kennzahlen und Finanzierungsevidenz · 14.8 Stufe 6 — Digitaler Zwilling und Betriebsdaten · 14.9 Stufe 7 — Nationale und europäische Registeranbindung · 14.10 Querschnitt: Prüfung, Compliance und Regulatory Watch · 14.11 Parallelisierbarkeit, Meilensteine und Grenzen der Gleichzeitigkeit · 14.12 Übersicht der Stufen und Priorisierung
15. 15  Geschäftsmodell und Marktstrategie
    15.1 Ausgangspunkt: eine Plattform, kein Einzelprodukt · 15.2 Die rechtliche Grundbedingung: Artikel 16 EPBD · 15.3 Der Vermögenswert ist der Datensatz, nicht das Dokument · 15.4 Lizenz pro Gebäude: die kleinste wirtschaftliche Einheit · 15.5 Ersterfassung, Fortschreibung und Dokumente · 15.6 Partnerzugänge: die Plattform als Arbeitsmittel der Fachpartner · 15.7 Banken: Berechtigte, Vertriebskanal und Grenze · 15.8 White Label, Verbände und externe Qualitätssicherung · 15.9 Kostenloser Einstieg, aber kein kostenloses Vollprodukt · 15.10 Der eigentliche Kostenblock: Datenqualität · 15.11 Positionierung · 15.12 Die fünf Markteintrittspfade · 15.13 Europäische Skalierung: Kern und Regelmodule · 15.14 Wiederkehrende Erlöse, Netzwerkeffekt und Bindung · 15.15 Marktentwicklung in drei Phasen und ihre Kennzahlen · 15.16 Übersicht der Erlösquellen und ihrer Grenzen · 15.17 Kernaussage
16. 16  Pilotprojekt zur Einführung des digitalen Gebäudepasses
    16.1 Zielsetzung des Piloten · 16.2 Ausgangsstand — worauf der Pilot aufsetzt · 16.3 Gebäudeauswahl und Pilotumfang · 16.4 Ausgangsdaten und Eingangsinventar · 16.5 Digitalisierung der vorhandenen Unterlagen · 16.6 Datenimport und Übernahmequoten · 16.7 Berechnungen und Referenzgleis · 16.8 Energieausweis · 16.9 Renovierungspass · 16.10 Partnerzugänge · 16.11 Schnittstellentest · 16.12 Erwartete Fehler und Erkenntnisse · 16.13 Kennzahlen des Piloten · 16.14 Notwendige Softwareänderungen · 16.15 Erfolgskriterien · 16.16 Stufung, Entscheidungstore und Empfehlung für den Rollout
17. 17  Chancen, Risiken und Grenzen
    17.1 Zweck und Systematik des Kapitels · 17.2 Chance: ein gemeinsamer, mehrfach nutzbarer Gebäudedatensatz · 17.3 Risiko: Datenqualität, Scheingenauigkeit und der Umgang mit Unsicherheit · 17.4 Risiken der eigenen Umsetzung: Datenhoheit, Automatik und Zugang · 17.5 Risiken der eigenen Umsetzung: Aussagekraft der Ergebnisse · 17.6 Risiko: Haftung des Erstellers und die Grenze der Fachverantwortung · 17.7 Risiko: Datenschutz und Informationssicherheit · 17.8 Das größte externe Risiko: fehlende staatliche Schnittstellen · 17.9 Risiko: unterschiedliche nationale Umsetzungen der EPBD · 17.10 Risiko: Akzeptanz bei Eigentümern · 17.11 Risiko: Betreiberabhängigkeit, Datenportabilität und Langzeitarchivierung · 17.12 Wirtschaftliche Grenzen und Erwartungsmanagement · 17.13 Gesamtbewertung: Risikomatrix · 17.14 Chancenbilanz und neue Dienstleistungen · 17.15 Der entscheidende Erfolgsfaktor
18. 18  Schlussfolgerungen und Empfehlungen
    18.1 Beitrag des Gebäudepasses zur EPBD-Umsetzung · 18.2 Notwendige technische Weiterentwicklung · 18.3 Empfehlungen an den Gesetzgeber · 18.4 Empfehlungen an Banken und Immobilienwirtschaft · 18.5 Empfehlungen an Energieberater und Fachplaner · 18.6 Perspektive einer europäischen Gebäudedatenplattform · 18.7 Die Empfehlungen im Überblick · 18.8 Ausblick
19. 19  Der Abgleich: Whitepaper-Zielbild und der Stand der eigenen Entwicklung
    19.1 Wozu dieser Abgleich · 19.2 Der Maßstab · 19.3 Datenmodell und Gebäudeidentität · 19.4 Datenqualität, Herkunft und Freigabe · 19.5 Rechenkerne, Nachweise und Dokumente · 19.6 Rollen, Rechte und Datenzugang · 19.7 Schnittstellen, Formate und Register · 19.8 Renovierungspass, Förderung und Wirtschaftlichkeit · 19.9 Lebenszyklus, Emissionen und Betriebsdaten · 19.10 Qualitätssicherung und Betrieb · 19.11 Die Gesamtdifferenz · 19.12 Was daraus folgt
20. A  Prüf- und Umsetzungskatalog
    A.1 Zweck des Katalogs und Anleitung zum Gebrauch · A.2 Aufbau einer Katalogzeile · A.3 Priorisierung der Prüfpunkte · A.4 Gebäudeidentität und Stammdaten · A.5 Flächen, Geometrie und Zonierung · A.6 Gebäudehülle und Fenster · A.7 Anlagentechnik und erneuerbare Energien · A.8 Berechnung nach DIN V 18599 · A.9 Energieausweis · A.10 Renovierungspass · A.11 Lebenszyklus und Treibhauspotenzial · A.12 Verbrauchs- und Betriebsdaten · A.13 Dokumente und KI-gestützte Erfassung · A.14 Datenqualität und Versionierung · A.15 Rollen, Rechte und Datenschutz · A.16 Schnittstellen und Registerfähigkeit · A.17 Banken und ESG-Auswertung · A.18 Förderung und Wirtschaftlichkeit · A.19 Gebäudechronik und digitaler Zwilling · A.20 Smart Readiness und Gebäudeautomation · A.21 Langzeitarchivierung und Datenhoheit · A.22 Softwarequalität und regulatorische Pflege · A.23 Rückverfolgbarkeit und Anbindung an die Entwicklung · A.24 Auswertung des Katalogs · A.25 Ergebnis des Anhangs
21. B  Datenkatalog
    B.1 Aufbau, Feld-Systematik und Lesart der Tabellen · B.2 Gruppen 01 bis 04 — Identität, Standort, Flächen, Geometrie · B.3 Gruppen 05 und 06 — Gebäudeteile und Zonen · B.4 Gruppen 07 bis 13 — Gebäudehülle · B.5 Gruppen 14 bis 18 — Wärmeerzeugung, Verteilung, Übergabe, Warmwasser · B.6 Gruppen 19 bis 21 — Lüftung, Kühlung, Beleuchtung · B.7 Gruppen 22 bis 25 — Stromerzeugung, Speicher, Ladeinfrastruktur, Gebäudeautomation · B.8 Gruppen 26 bis 28 — Berechnung, Ergebnisse, Energieausweis · B.9 Gruppen 29 und 30 — Verbrauch und Messwerte · B.10 Gruppen 31 bis 33 — Sanierungsmaßnahmen, Renovierungspass, iSFP · B.11 Gruppen 34 bis 37 — Förderung, Wirtschaftlichkeit, Ökobilanz, Umweltproduktdeklarationen · B.12 Gruppe 38 — ESG- und Bankenprofil · B.13 Gruppen 39 bis 43 — Dokumente, Datenherkunft, Freigaben, Eigentum, Ereignisse · B.14 Gruppen 44 und 45 — Wartung und Inspektionen · B.15 Gruppen 46 bis 48 — Versionen, Rechtsquellen, Prüfpunkte · B.16 Pflichtfeldlogik und bedingte Pflichtfelder · B.17 Einheiten, Aufzählungswerte und Quellenpflicht · B.18 Zeitgültigkeit, Plan- und Ist-Werte, berechnete und gemessene Werte · B.19 Kerndatensatz und Erweiterungsprofile · B.20 Versionierung des Datenmodells und Abbildung externer Formate · B.21 Exportprofile und Mindestqualität · B.22 Der Datenkatalog als Vertrag zwischen den Modulen
22. C  Quellen- und Rechtsquellenregister
    C.1 Vorbemerkung zur Systematik · C.2 Quellenhierarchie und Konfliktregel · C.3 Europäisches Recht · C.4 Deutsches Recht · C.5 Normen und Normstand · C.6 Förderrecht · C.7 Leitlinien und Auslegungen · C.8 Technische Spezifikationen und hausinterne Belegquellen · C.9 Verknüpfung mit Anhang A und Anhang B · C.10 Pflege des Registers
23. D  Faktendossier I — Entwicklungsstand der Plattform
    D.1 Was die App heute ist · D.2 Der Gebäudepass in der App · D.3 Das Datenmodell · D.4 Building Trust Index (BTI) · D.5 Vorhandene Fachmodule · D.6 Schnittstellen und Formate · D.7 GMoDG-/EPBD-Migration · D.8 Ehrliche Lückenliste (Zitate)
24. E  Faktendossier II — Regulatorische Anforderungen der EPBD
    E.1 Fristenkalender EPBD (EU) 2024/1275 · E.2 Energieausweis — Art. 19–21 + Anhang V · E.3 Renovierungspass — Art. 12 + Anhang VIII · E.4 Gebäudedatenbanken — Art. 22 · E.5 Datenaustausch — Art. 16 · E.6 GWP / Lebenszyklus — Art. 7 und Anhang III (i. d. F. M1) · E.7 Nullemissionsgebäude (ZEB) — Art. 11 · E.8 SRI (Art. 15) und Gebäudeautomation (Art. 13) — inkl. Leistungsschwelle · E.9 Deutsche Umsetzung — GEG, GMoDG, Normstand · E.10 Was die Richtlinie NICHT verlangt — Abgrenzung gegen Übererfüllung
25. F  Quellen- und Linkverzeichnis
    F.1 EPBD und europäische Grundlagen · F.2 Deutschland, GModG/GEG, Energieausweis und EPBD-Umsetzung · F.3 DIN V / DIN/TS 18599 und Gebäudeökobilanzierung · F.4 iSFP und Energieberatung · F.5 BAFA, KfW und Bundesförderung · F.6 QNG, Ökobilanzierung und Gebäudepass · F.7 Softwarevalidierung und Gütegemeinschaft

1 Management Summary

Die Neufassung der europäischen Gebäuderichtlinie verlagert den Schwerpunkt von einzelnen Nachweisen auf dauerhaft geführte Gebäudedaten. Dieses Whitepaper prüft, welche Anforderungen daraus für die Datenhaltung entstehen, wie weit der digitale Gebäudepass diesen Anforderungen heute entspricht und welche Entwicklungsschritte vorrangig sind. Das Management Summary fasst Ausgangslage, Ziel, Nutzen, Befunde und Empfehlungen so zusammen, dass es für sich allein gelesen werden kann.

1.1 Ausgangslage

Mit der Richtlinie (EU) 2024/1275 über die Gesamtenergieeffizienz von Gebäuden (EPBD) verändert sich die Art, wie ein Gebäude energetisch betrachtet wird. Die Bewertung ist künftig nicht mehr als punktuelle Erstellung einzelner Nachweise zu verstehen. Energieausweis, Renovierungsplanung, Energie- und Emissionsdaten, Lebenszyklusbetrachtung, technische Gebäudedaten und zunehmend auch Betriebsinformationen werden Bestandteile einer über den Lebenszyklus fortschreibbaren Datenstruktur. Die Richtlinie schreibt diesen Wechsel an mehreren Stellen ausdrücklich fest: Der Energieausweis muss digital und maschinenlesbar vorliegen, ein gescanntes PDF genügt nach Artikel 19 EPBD ausdrücklich nicht; die Mitgliedstaaten haben eine Gebäudedatenbank aufzubauen, in der nach Artikel 20 Absatz 8 EPBD der vollständige Ausweis einschließlich aller Berechnungs-Eingangsdaten hinterlegt wird; und Artikel 16 EPBD verpflichtet zum Zugang der Eigentümer, Mieter und Verwalter zu den Daten der Gebäudesysteme.

Der Rahmen, den die Richtlinie aufspannt, ist breit: Energieausweise mit der neuen geschlossenen Skala A bis G, der Renovierungspass nach Artikel 12 EPBD, nationale Gebäuderenovierungspläne, Gebäudedatenbanken nach Artikel 22 EPBD, Datenaustausch, das Lebenszyklus-Treibhauspotenzial nach Artikel 7 EPBD sowie intelligente Gebäudefunktionen. Die Fachkapitel arbeiten diese Themen einzeln auf; für die Ausgangslage genügt der gemeinsame Nenner: Jede dieser Anforderungen setzt strukturierte, nachvollziehbare und fortschreibbare Gebäudedaten voraus.

Zeitlich ist der Rahmen bereits weitgehend gesetzt. Die Richtlinie trat am 28. Mai 2024 in Kraft. Die wesentlichen neuen oder geänderten Bestimmungen waren nach Artikel 35 EPBD bis zum 29. Mai 2026 in nationales Recht umzusetzen; die frühere Richtlinie 2010/31/EU wird mit Wirkung zum 30. Mai 2026 durch die Neufassung ersetzt. Adressat aller dieser Pflichten ist zunächst der Mitgliedstaat. Für Eigentümer, Aussteller und Planer entstehen unmittelbare Pflichten erst aus dem nationalen Recht.

In Deutschland ist dieser Schritt mit dem Gebäudemodernisierungsgesetz (GMoDG) begonnen, aber noch nicht abgeschlossen. Das Gesetz wurde am 28. Juli 2026 verkündet (BGBl. 2026 I Nr. 226). In Kraft getreten sind seit dem 29. Juli 2026 zunächst die Artikel 1, 5, 6 und 8. Artikel 2, der die eigentliche EPBD-Umsetzung enthält, tritt nach dem Gesetzeswortlaut sechs Monate nach der Verkündung in Kraft; als Anwendungsdatum wird der 1. Januar 2027 geführt. Für die Praxis heißt das: Bis dahin sind das bisherige und das neue Verfahren parallel zu bedienen — etwa beim Verbrauchsausweis für Wohngebäude, für den § 80 GMoDG statt der drei Abrechnungsperioden nach § 82 GEG eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate verlangt.

Die Tabelle zeigt zweierlei. Erstens liegt der Schwerpunkt der Pflichten in den kommenden vier Jahren. Zweitens sind die Termine zwar gesetzt, die zugehörigen technischen Spezifikationen aber nicht durchgängig verfügbar: Deutschland verfügt nach dem Anhang der Kommissions-Leitlinien bislang über keine nationale Energieausweis-Datenbank; ein Datenbankschema nach Artikel 22 EPBD liegt ebenso wenig vor wie das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG oder das Datenformat für den Lebenszyklus-Treibhausgasbericht nach § 88b GMoDG. Wer heute plant, muss deshalb drei Verbindlichkeitsstufen unterscheiden: Recht und Spezifikation liegen vor, dann ist umsetzbar; die Spezifikation fehlt, dann ist die Umsetzung blockiert; etwas ist nur angekündigt, dann darf daraus keine Pflicht abgeleitet werden.

Für die praktische Digitalisierung des Gebäudebestands bleibt damit eine Aufgabe bestehen, die kein Gesetz allein löst: Die heute an unterschiedlichen Stellen liegenden Gebäudedaten müssen strukturiert, qualitätsgesichert, dauerhaft fortschreibbar und zwischen den Beteiligten austauschbar werden. Genau an diesem Punkt setzt der digitale Gebäudepass an.

1.2 Ziel des digitalen Gebäudepasses

Der digitale Gebäudepass ist weder als weiterer statischer Nachweis noch als digitale Ablage vorhandener PDF-Dokumente angelegt. Sein Ziel ist ein dauerhaftes digitales Datenmodell des Gebäudes. Die Grundidee lässt sich in einem Satz fassen: ein Gebäude, ein qualitätsgesicherter Datensatz, über den gesamten Lebenszyklus. Gebäudedaten werden möglichst nur einmal erfasst und anschließend für unterschiedliche Aufgaben weiterverwendet.

Der Kreis dieser Aufgaben ist größer, als es die energetische Herkunft des Themas vermuten lässt. Dieselben Angaben zu Geometrie, Bauteilen, Anlagentechnik und Nutzung liegen einer ganzen Reihe von Verfahren zugrunde:

• Energieausweise und Wärmeschutznachweise,
• Renovierungs- und Sanierungsplanung,
• Fördermittelverfahren, Finanzierungs- und Wirtschaftlichkeitsberechnungen,
• Ökobilanz-, CO₂- und GWP-Betrachtungen,
• Immobilienbewertung und technische Gebäudeplanung,
• Betriebs- und Wartungsinformationen,
• Eigentümerwechsel, Vermietung, Finanzierung und Beleihung,
• künftige gesetzliche Nachweis- und Datenübermittlungspflichten.

Diese Aufzählung ist zugleich die wirtschaftliche Begründung des Ansatzes. Jede der genannten Aufgaben beginnt heute in der Regel mit einer erneuten Datenerfassung, und jede dieser Erfassungen erzeugt eine eigene, nicht abgeglichene Wahrheit über dasselbe Gebäude. Wird der Datensatz dagegen einmal geführt und fortgeschrieben, verlagert sich der Aufwand von der Wiederbeschaffung zur Pflege — und die Ergebnisse verschiedener Fachverfahren werden untereinander vergleichbar.

Der vorhandene Gebäudepass verfolgt dieses Prinzip technisch bereits. Ein zentraler Gebäudedatensatz mit eigener Gebäude-Kennung, die Versionierung einzelner Werte, strukturierte Datenhaltung, automatische Dokumentenerzeugung sowie Prüf- und Validierungsmechanismen sind Bestandteil des bestehenden Systems. Verbindliche Regel des Datenmodells ist dabei, dass jede Information genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie hat; Werte werden nicht überschrieben, sondern in neuen Versionen fortgeschrieben, und ein Vier-Augen-Schritt trennt den gemeldeten Vorschlag von der Freigabe.

Die Weiterentwicklung betrifft deshalb nicht in erster Linie zusätzliche Berechnungsverfahren. Der Schwerpunkt liegt auf Interoperabilität: Daten müssen künftig in den national und europäisch vorgegebenen Strukturen bereitgestellt und über definierte Schnittstellen ausgetauscht werden können. Die Richtlinie stützt diesen Weg ausdrücklich. Nach Artikel 19 Absatz 14 Buchstabe c EPBD sind vereinfachte Aktualisierungen des Energieausweises über einen digitalen Zwilling oder zertifizierte Werkzeuge zulässig; Artikel 12 Absatz 8 EPBD verlangt, den Renovierungspass dort, wo ein digitales Gebäudelogbuch besteht, darin zu speichern oder über eine eindeutige Adresse zugänglich zu machen; Artikel 22 Absatz 7 EPBD fordert Interoperabilität der Gebäudedatenbank mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern. Der Gebäudepass soll sich damit von der digitalen Gebäudeakte zu einer digitalen Infrastruktur für das Gebäude entwickeln.

1.3 Bedeutung für Eigentümer, Energieberater, Banken und Immobilienwirtschaft

Der Nutzen eines zentralen Gebäudedatensatzes entsteht nicht durch die Menge gespeicherter Informationen, sondern dadurch, dass dieselben qualitätsgesicherten Daten in unterschiedlichen Prozessen tragen. Die vier wichtigsten Zielgruppen betrifft das auf jeweils eigene Weise.

Eigentümer

Für den Eigentümer entsteht eine über den Lebenszyklus fortschreibbare Chronik seines Gebäudes. Planunterlagen, energetische Kennwerte, Modernisierungen, technische Anlagen, Rechnungen, Nachweise und spätere Veränderungen lassen sich dauerhaft einem Gebäude zuordnen. Bei Verkauf, Finanzierung, Sanierung oder einer erneuten Energieberatung muss die technische Vergangenheit des Gebäudes dann nicht jedes Mal neu rekonstruiert werden. Der Datensatz ist so aufgebaut, dass der veröffentlichte Pass nur Gebäude-Kennwerte und keine personenbezogenen Daten enthält und der Zugang über eine PIN geschützt ist. Eine abgestufte Steuerung darüber, welche Beteiligten welche Angaben zu welchem Zweck sehen dürfen, ist konzipiert, aber noch nicht umgesetzt; sie gehört zu den vorrangigen Entwicklungsschritten in Abschnitt 1.5.

Energieberater und Fachplaner

Energieberater, Architekten und TGA-Planer können auf bereits erfasste und geprüfte Gebäudedaten zurückgreifen. Aus wiederholter Datenerfassung wird fortschreibbare Planung: Ein einmal erfasstes Bauteil, eine Fläche, eine technische Anlage oder ein energetischer Kennwert wird Grundlage mehrerer Berechnungen und Dokumente. Die bestehende Architektur unterstützt dabei die Übernahme vorhandener Unterlagen — Import von CAD- und Dokumentendaten, IFC-Modelle als Eingangsformat sowie eine KI-gestützte Auswertung von Plänen, Wärmeschutznachweisen und Energieausweisen über eine gemeinsame Ablagezone. Maßgeblich bleibt dabei der Grundsatz, dass automatisch erkannte Werte Vorschläge sind: Sie erhalten eine Herkunftskennzeichnung und werden erst durch die fachliche Freigabe zum offiziellen Wert.

Banken und Finanzierungsinstitute

Für Banken gewinnt die energetische und technische Qualität einer Immobilie an Bedeutung — nicht zuletzt, weil die Richtlinie in Artikel 22 EPBD Finanzinstituten einen eigenen, portfoliobezogenen Zugriff auf die nationale Datenbank zuweist. Der Gebäudepass kann dafür eine strukturierte Informationsbasis bereitstellen; neben dem aktuellen energetischen Zustand lassen sich perspektivisch Sanierungsbedarf, Investitionskosten, Fördermöglichkeiten, Energieeinsparungen und die Entwicklung des Gebäudes dokumentieren. Entscheidend sind dabei Herkunft, Aktualität und Nachvollziehbarkeit der Angaben. Versionierung, Zeitstempel, Herkunftskennzeichnung und dokumentierte Prüfprozesse schaffen den eigentlichen Mehrwert, ergänzt um eine Kennzahl, die Qualität und Belegbarkeit der Daten getrennt vom energetischen Ergebnis ausweist. Der Gebäudepass ersetzt weder eine Kreditentscheidung noch eine Immobilienbewertung. Er stellt eine gemeinsame, nachvollziehbare Datengrundlage bereit.

Immobilienmakler und Hausverwaltungen

Bei Verkauf, Vermietung und Verwaltung wiederholen sich dieselben Probleme: Dokumente fehlen, energetische Angaben sind veraltet, Modernisierungen wurden nicht vollständig dokumentiert, technische Angaben müssen erneut recherchiert werden. Ein fortgeschriebener Gebäudepass reduziert diese Informationsverluste, weil der Datensatz mit dem Gebäude verbunden bleibt und bei Eigentümer- oder Verwalterwechsel weitergeführt werden kann. Aus einer Sammlung einzelner Dokumente wird eine Gebäudehistorie — auch für die Pflichtangaben in Immobilienanzeigen, für die Artikel 19 EPBD Indikator und Effizienzklasse verlangt.

1.4 Wichtigste Ergebnisse

Die Gegenüberstellung der EPBD-Anforderungen mit dem Entwicklungsstand des digitalen Gebäudepasses führt zu einem klaren Befund: Die wesentlichen technischen Grundlagen einer digitalen Gebäudeakte sind vorhanden, die Anschlussfähigkeit an die entstehende Dateninfrastruktur ist es noch nicht. Die folgende Übersicht ordnet die Funktionen nach ihrem tatsächlichen Stand; die Fachkapitel führen die einzelnen Punkte im Detail aus.

Die Verteilung über die Statusspalte ist das eigentliche Ergebnis: Alles, was das Führen, Prüfen und Auswerten eines Gebäudedatensatzes betrifft, ist gebaut und im Einsatz. Alles, was den Datensatz mit der Außenwelt verbindet — Austauschformate, Rechteschicht, Register, Betriebsdaten —, hängt entweder an noch fehlenden Spezifikationen oder liegt als Konzept vor. Die Entwicklungsaufgabe besteht damit nicht mehr darin, eine digitale Gebäudeakte aufzubauen, sondern darin, die bestehende Plattform interoperabel, standardisiert und anschlussfähig an die entstehende nationale und europäische Gebäudedateninfrastruktur zu machen.

1.5 Zentrale Handlungsempfehlungen

Aus der Analyse ergeben sich fünf vorrangige Entwicklungsschritte. Sie sind bewusst so geschnitten, dass sie unabhängig von noch ausstehenden amtlichen Spezifikationen begonnen werden können und beim Vorliegen dieser Spezifikationen nur noch parametriert werden müssen.

1. EPBD-Basisdatenmodell definieren

Alle vorhandenen Datenfelder sollten systematisch den Anforderungen der EPBD und der deutschen Umsetzung gegenübergestellt werden. Ergebnis sollte ein eindeutiges Datenmodell sein, das zwischen Stammdaten, Geometriedaten, Bauteildaten, Anlagendaten, Energiekennwerten, Emissionsdaten, Lebenszyklusdaten, Renovierungsdaten, Dokumenten, Betriebsdaten und Metadaten unterscheidet. Der Nutzen liegt nicht allein in der Ordnung: Erst ein solches Modell macht sichtbar, welche der von Artikel 20 Absatz 8 EPBD geforderten Berechnungs-Eingangsdaten bereits geführt werden und welche fehlen. Wo eine Größe heute mehrfach unter verschiedenen Namen geführt wird, ist im gleichen Zug die kanonische Fassung festzulegen — die Bezugsfläche ist dafür das lehrreichste Beispiel.

2. EPBD-Anforderungsmatrix zum Steuerungsinstrument ausbauen

Für jede relevante Anforderung sollte durchgängig dokumentiert werden: Anforderung, erforderliche Daten, Funktion im Gebäudepass, aktueller Status, Rechtsgrundlage, Entwicklungsbedarf und Schnittstelle. Damit entsteht nicht nur eine technische Entwicklungsübersicht, sondern ein überprüfbarer Nachweis der regulatorischen Anschlussfähigkeit. Die Matrix sollte dabei die vier Daten einer Regelung — Veröffentlichung, Inkrafttreten, Anwendung und Produktivsetzung — getrennt führen und jede Anforderung einer der drei Verbindlichkeitsstufen aus Abschnitt 1.1 zuordnen. Nur so lässt sich ein Entwicklungsrückstand von einer Blockade durch fehlende Spezifikationen unterscheiden.

3. Renovierungspass vollständig integrieren

Der vorhandene Gebäudedatensatz und die bestehenden Sanierungs-, Kosten- und Förderfunktionen sollten zu einem vollständigen Renovierungspass nach Artikel 12 EPBD und Anhang VIII EPBD zusammengeführt werden. Ist-Zustand, Maßnahmen, zeitliche Reihenfolge, Energieeinsparung, Emissionswirkung, Investitionskosten und Förderungen sind dabei je Schritt miteinander zu verknüpfen. Der deutsche individuelle Sanierungsfahrplan ist in den Leitlinien der Kommission ausdrücklich als Vorbild genannt, deckt die Pflichtfelder des Anhangs VIII aber nicht vollständig ab — insbesondere die Veränderung der operativen Treibhausgase je Schritt, Zirkularität und Whole-Life-Carbon sowie die Auflistung der nationalen Stichtage fehlen. Ob Deutschland den Sanierungsfahrplan formal zum Renovierungspass erklärt, ist nicht entschieden; die Integration sollte deshalb am Feldmodell des Anhangs VIII ansetzen und die Darstellung austauschbar halten.

4. Rollen- und Rechtekonzept erweitern

Eigentümer, Energieberater, Architekten, Banken, Makler, Hausverwaltungen und Behörden benötigen unterschiedliche Zugriffsrechte. Der Gebäudepass sollte deshalb nicht nur Daten speichern, sondern steuern, wer welche Information zu welchem Zweck sehen, ergänzen, verändern oder exportieren darf. Die Richtlinie gibt die Grundzüge vor: Artikel 16 EPBD sichert Eigentümern, Mietern und Verwaltern den kostenlosen Zugriff und die kostenlose Weitergabe an selbst benannte Dritte, während Artikel 22 EPBD abgestufte Zugriffsstufen bis hin zur befristeten Ansicht für Kauf- und Mietinteressenten beschreibt. Hinzu kommt die Anforderung des Anhangs VI EPBD, dass der Urheber jeder Hinzufügung und Änderung ermittelbar bleibt. Die dafür nötige Herkunfts- und Versionsschicht besteht bereits; erforderlich ist ihre Durchsetzung als Rechteschicht, einschließlich der datenschutzrechtlichen Vorprüfung.

5. Register- und Plattformfähigkeit vorbereiten

Die Architektur sollte so ausgelegt werden, dass künftige nationale Gebäudedatenbanken, Energieausweisregister und gegebenenfalls europäische Datenplattformen über standardisierte Schnittstellen angebunden werden können. Weil das deutsche Schema nach Artikel 22 EPBD noch nicht existiert, wäre es ein Fehler, die Architektur auf eine einzelne staatliche Schnittstelle auszurichten. Ziel muss ein offenes, versionierbares und erweiterbares Schnittstellenmodell sein, das mehrere Empfänger bedienen kann und das Format vom Inhalt trennt. Als Orientierung dient dabei die Praxis der Mitgliedstaaten, deren Datenbanken keine PDF-Dokumente speichern, sondern den Ausweis aus den Rohdaten erzeugen — genau diese Reihenfolge, Daten vor Dokument, verfolgt der Gebäudepass bereits.

1.6 Kernaussage

Der digitale Gebäudepass ist nicht die Digitalisierung des bisherigen Energieausweises. Er verfolgt einen weitergehenden Ansatz: Aus einzelnen Nachweisen wird ein zusammenhängender Gebäudedatensatz. Aus wiederholter Datenerfassung wird dauerhafte Datennutzung. Aus der Gebäudeakte wird eine Gebäudechronik. Und aus der Gebäudechronik kann die digitale Infrastruktur für den gesamten Lebenszyklus einer Immobilie entstehen.

Dabei ist die Abgrenzung ebenso wichtig wie das Ziel. Die Richtlinie verlangt weder ein digitales Gebäudelogbuch noch einen digitalen Zwilling; sie definiert das Logbuch in Artikel 2 Nr. 41 EPBD und knüpft in Artikel 12 Absatz 8 EPBD und Artikel 22 Absatz 7 EPBD nur konditional daran an. Ein Gebäudepass ist deshalb keine Pflichterfüllung, sondern das Werkzeug, mit dem sich die tatsächlichen Pflichten — maschinenlesbarer Ausweis, vollständige Datenübergabe an die Datenbank, Renovierungspass, Datenzugang, Lebenszyklusbilanz — mit vertretbarem Aufwand und nachvollziehbarer Qualität erfüllen lassen.

Die technische Grundlage dafür ist in wesentlichen Teilen vorhanden. Die nächste Entwicklungsstufe besteht darin, diesen Gebäudedatensatz mit den sich konkretisierenden nationalen und europäischen Datenstrukturen, Rollenmodellen und Schnittstellen zu verbinden. Gelingt das, kann der digitale Gebäudepass zum Bindeglied zwischen Eigentümern, Fachplanern, Energieberatern, Banken, Immobilienwirtschaft und öffentlicher Verwaltung werden.

2 Anlass, Ziel und Abgrenzung

Dieses Kapitel beschreibt, warum ein digitaler Gebäudepass zum jetzigen Zeitpunkt untersucht wird, was in diesem Whitepaper unter dem Begriff verstanden wird und wie sich der Gebäudepass von den Instrumenten unterscheidet, mit denen er in der Praxis regelmäßig verwechselt wird: Energieausweis, Renovierungspass, digitales Gebäudelogbuch, digitaler Zwilling und klassische Gebäudeakte. Der Abschnitt zur rechtlichen Einordnung grenzt zugleich ab, was aus dem geltenden Recht folgt und was zum Stand August 2026 offen ist.

2.1 Zweck des Whitepapers

Die Transformation des europäischen Gebäudebestands ist nicht allein eine Frage neuer Heizsysteme, besserer Dämmung oder zusätzlicher erneuerbarer Energien. Sie ist in zunehmendem Maß auch eine Datenaufgabe. Damit Gebäude über Jahrzehnte hinweg energetisch bewertet, finanziert, modernisiert und schließlich bis zum Nullemissionsgebäude entwickelt werden können, müssen Informationen über ihren tatsächlichen Zustand verfügbar, nachvollziehbar und fortschreibbar sein. Wer eine Sanierung in mehreren Schritten über fünfzehn Jahre plant, braucht am Ende dieses Zeitraums noch dieselben Ausgangsdaten, mit denen der erste Schritt begründet wurde — und er braucht die Information, was zwischenzeitlich tatsächlich ausgeführt worden ist.

In der heutigen Praxis ist das häufig nicht gegeben. Baupläne liegen bei Eigentümern oder Architekten, Energieausweise als einzelne Dokumente in Ordnern oder Cloud-Verzeichnissen, technische Daten bei Fachplanern und Handwerkern, Förderunterlagen bei Energieberatern oder Förderstellen. Informationen über frühere Modernisierungen finden sich oft nur in Rechnungen oder privaten Unterlagen. Bei einem Eigentümerwechsel droht ein erheblicher Teil dieses Wissens verloren zu gehen, weil es nirgends an das Objekt, sondern an Personen gebunden war. Das Gebäude bleibt bestehen; seine Datenbiografie beginnt dagegen häufig immer wieder von vorn. Praktisch bedeutet das: Bei jeder neuen Beratung wird ein Teil der Erhebung wiederholt, jede Wiederholung erzeugt Kosten, und jede Neuerhebung kann zu abweichenden Ergebnissen führen, ohne dass sich die Abweichung erklären lässt.

Die Richtlinie (EU) 2024/1275 verändert diese Situation grundlegend. Energieausweise, Renovierungspässe, nationale Gebäudedatenbanken, Lebenszyklusinformationen und Regeln zum Datenaustausch schaffen zusammengenommen eine strukturierte Informationslandschaft rund um das einzelne Gebäude. Die Instrumente sind dabei in der Richtlinie bereits aufeinander bezogen — der Renovierungspass darf die Ausweisempfehlungen ersetzen, der Ausweis darf aus zertifizierten Werkzeugen aktualisiert werden, die Datenbank soll mit Kataster und Logbüchern interoperabel sein. Die einzelnen Fristen und Rechtsgrundlagen dazu stellt Kapitel 3 zusammen.

Das vorliegende Whitepaper untersucht deshalb, wie aus diesen bislang teilweise getrennten Informationsstrukturen ein zusammenhängendes digitales Gebäudemodell entstehen kann. Im Mittelpunkt steht die Frage, ob ein digitaler Gebäudepass zur gemeinsamen Datenbasis für energetische Bewertung, Sanierung, Förderung, Finanzierung, Immobilienwirtschaft und künftige regulatorische Anforderungen werden kann. Dazu werden drei Ebenen untersucht:

• Welche Daten und Instrumente verlangt oder entwickelt die EPBD, und in welcher Verbindlichkeitsstufe?
• Wie lassen sich diese Informationen in einem digitalen Gebäudepass strukturieren, fortschreiben und qualitätssichern?
• Welche Funktionen sind in der vorhandenen Plattform bereits umgesetzt, welche sind konzipiert und welche Erweiterungen sind für eine vollständige Interoperabilität noch erforderlich?

Die drei Ebenen werden im weiteren Verlauf getrennt gehalten. Das ist kein formaler Aufbau, sondern eine inhaltliche Notwendigkeit: Eine Anforderung der Richtlinie, eine mögliche technische Abbildung und ein tatsächlich vorhandenes Softwaremodul sind drei verschiedene Aussagen mit drei verschiedenen Belegwerten. Kapitel 12 führt sie in einer Anforderungsmatrix zusammen, Kapitel 13 bewertet den Reifegrad des vorhandenen Systems.

2.2 Definition des digitalen Gebäudepasses

Der in diesem Whitepaper beschriebene digitale Gebäudepass ist eine strukturierte, fortschreibbare und qualitätsgesicherte digitale Informationsplattform für ein einzelnes Gebäude. Er verbindet die relevanten Informationen eines Gebäudes über dessen Lebenszyklus miteinander und hält für jede Angabe fest, woher sie stammt, wie belastbar sie ist und wann sie zuletzt geändert wurde. Der Gebäudepass ist damit nicht auf einen Anlass bezogen — nicht auf einen Verkauf, nicht auf eine Förderung, nicht auf einen Nachweis —, sondern auf das Objekt.

Inhaltlich umfasst der Gebäudepass die folgenden Informationsbereiche. Der Katalog beschreibt die Zielgestalt; welche Bereiche im vorhandenen System heute produktiv, teilweise umgesetzt oder konzipiert sind, ist Gegenstand der Kapitel 7 und 13.

• Gebäudeidentität und Stammdaten
• Geometrie und Flächen
• Gebäudehülle, Bauteile und Baustoffe
• technische Anlagen
• Energiekennwerte und Energieverbräuche
• Energieausweise und die zugehörigen Berechnungen nach DIN V 18599
• CO₂- und Emissionsdaten sowie LCA- und GWP-Daten
• Renovierungs- und Sanierungsmaßnahmen, Sanierungsfahrpläne
• Fördermittel, Kosten und Wirtschaftlichkeit
• technische Nachweise, Rechnungen und Dokumente
• Wartungs- und Betriebsinformationen
• Eigentümerwechsel und Versionshistorien

Der Katalog ist bewusst breiter angelegt als jedes einzelne der bestehenden Instrumente. Er enthält Größen, die für den Energieausweis benötigt werden, ebenso wie solche, die erst für eine Ökobilanz, eine Förderprüfung oder eine Finanzierung erforderlich sind. Entscheidend ist nicht die Länge der Liste, sondern das Ordnungsprinzip dahinter: Jede Information hat genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie. Dieses Prinzip wird in Kapitel 4 als Datenmodell ausgearbeitet.

Das Grundprinzip des Gebäudepasses lautet, Gebäudedaten einmal qualitätsgesichert zu erfassen und anschließend über den gesamten Lebenszyklus weiterzuverwenden. Damit unterscheidet er sich grundsätzlich von einer reinen Dokumentenablage. Ein PDF-Dokument enthält Informationen; der digitale Gebäudepass macht dieselben Informationen zusätzlich als strukturierte Daten verfügbar. Dadurch können dieselben Daten für eine Berechnung nach DIN V 18599, einen Energieausweis, eine Sanierungsvariante, eine Fördermittelprüfung oder perspektivisch für eine Finanzierung verwendet werden, ohne erneut erhoben zu werden.

Zur Qualitätssicherung gehört, dass nicht jede Angabe denselben Rang hat. Im vorhandenen System werden Werte in vier Datenzuständen geführt — Entwurf, gemeldet, geprüft, freigegeben —, und nur freigegebene Werte dürfen in offizielle Berichte einfließen. Ergänzend trägt jeder Wert eine Vertrauensstufe von „unbekannt" bis „amtlich signiert". Ein Vorschlag ändert den offiziellen Wert nicht; erst eine Freigabe schreibt ihn fort. Dieses Vier-Augen-Prinzip ist die Voraussetzung dafür, dass ein Datensatz überhaupt für Nachweise, Förderanträge oder Finanzierungen taugt.

2.3 Vom Dokument zum Datenmodell

Der Unterschied zwischen Dokument und Datensatz ist für die weitere Digitalisierung entscheidend, weil er die Reihenfolge der Arbeitsschritte umkehrt. Die bisherige Gebäudeinformation ist überwiegend dokumentenorientiert: Aus dem Gebäude entsteht eine Berechnung, aus der Berechnung ein Dokument, aus dem Dokument ein Ablagevorgang. Am Ende dieser Kette steht ein Papier oder ein PDF, und die Eingangsdaten der Berechnung verschwinden mit der Projektdatei des Erstellers. Wird zwei Jahre später eine Variante gerechnet, beginnt die Kette erneut beim Gebäude.

Der Gebäudepass verfolgt dagegen einen datenorientierten Ansatz: Aus dem Gebäude entsteht ein strukturierter Datensatz, aus dem Datensatz die Berechnung, aus der Berechnung die Dokumente; Änderungen fließen in den Datensatz zurück und stehen für die nächste Nutzung wieder zur Verfügung. Nicht mehr das Dokument ist der primäre Informationsträger, sondern der Gebäudedatensatz. Aus ihm lassen sich anschließend unterschiedliche Dokumente und Auswertungen erzeugen — im vorhandenen System heute bereits mehrere automatisch erzeugte Dokumente, die neu geschrieben werden, sobald sich ihre Datengrundlage ändert.

Diese Umkehrung verändert die Rolle des Energieausweises. Er bleibt ein wichtiges standardisiertes Dokument mit eigener Rechtsfolge, ist aber inhaltlich nur eine bestimmte Sicht auf einen wesentlich umfangreicheren Gebäudedatensatz. Dasselbe gilt für einen Renovierungspass oder eine Ökobilanz: Sie greifen auf unterschiedliche Ausschnitte desselben Gebäudes zu. Die Richtlinie selbst folgt dieser Logik bereits, wenn sie in Artikel 20 Absatz 8 EPBD verlangt, dass der Ausweis einschließlich sämtlicher Berechnungs-Eingangsdaten in der nationalen Datenbank verfügbar ist. Wer die Eingangsdaten ohnehin vorhalten muss, hat den Schritt vom Dokument zum Datensatz rechtlich bereits vollzogen.

Aus der Umkehrung folgt zugleich eine Sorgfaltspflicht, die in der dokumentenorientierten Welt nicht bestand. Wenn Werte weiterverwendet werden, muss ausgeschlossen sein, dass unbemerkt unterschiedliche Größen unter demselben Namen kursieren. Ein Beispiel aus der eigenen Entwicklung: Die Bezugsfläche wird kanonisch als Nutzfläche nach DIN 277 geführt; die frühere Bezugsgröße A_N ist keine Umrechnung davon, sondern eine andere Größe, und fehlt die kanonische Fläche, meldet die Bilanz eine Lücke, statt einen Ersatzwert zu unterstellen. Ebenso werden CO₂-Angaben aus Ausweis, Betriebsbilanz und Ökobilanz getrennt ausgewiesen und ausdrücklich nicht zu einem Gesamtwert verrechnet, weil ihre Systemgrenzen verschieden sind.

2.4 Abgrenzung zum Energieausweis

Der Energieausweis beschreibt die energetischen Eigenschaften eines Gebäudes zu einem bestimmten Zeitpunkt und nach einem festgelegten Verfahren. Er ist eine standardisierte energetische Momentaufnahme mit klar geregelten Ausstellungsanlässen — Neubau, größere Renovierung, Verkauf, Neuvermietung, Verlängerung eines Mietvertrags, Gebäude öffentlicher Stellen — und einer Gültigkeit von höchstens zehn Jahren nach Artikel 19 EPBD. Seine Aussagekraft ist auf genau diesen Zweck zugeschnitten: Er macht Gebäude vergleichbar und erzeugt im Markt ein Preissignal. Er ist dagegen weder als Planungsinstrument noch als Gedächtnis eines Gebäudes angelegt.

Der digitale Gebäudepass geht darüber hinaus. Er speichert nicht lediglich das Ergebnis des Energieausweises, sondern die ihm zugrunde liegenden Informationen: Gebäudegeometrie, Bauteilflächen, U-Werte, Wärmebrückenansatz, Heizung, Lüftung, Kühlung, Warmwasser, Beleuchtung, erneuerbare Energien, Nutzungszonen, Berechnungsparameter und den Dokumentationsstand. Damit kann ein künftiger Energieausweis aus einem aktualisierten Gebäudedatensatz neu erzeugt werden, statt eine vollständige Neuerhebung auszulösen. Der Energieausweis ist ein Ergebnis des Gebäudedatensatzes, nicht dessen Ersatz.

Diese Sicht ist mit der Richtlinie nicht nur vereinbar, sie ist dort angelegt. Artikel 19 Absatz 14 EPBD verpflichtet die Mitgliedstaaten, vereinfachte Aktualisierungen des Ausweises zu ermöglichen — nach einer Einzelmaßnahme, nach umgesetzten Schritten eines Renovierungspasses und ausdrücklich auch über einen digitalen Zwilling oder zertifizierte Werkzeuge. Buchstabe c dieser Vorschrift ist damit die Rechtsgrundlage dafür, dass ein gepflegter Gebäudedatensatz als Datenquelle des Ausweises dienen kann. Hinzu kommt die Formanforderung: Der Ausweis muss digital und maschinenlesbar vorliegen, genannt werden CSV, JSON und XML; ein gescanntes PDF genügt ausdrücklich nicht. Eine reine Dokumentenablage erfüllt diese Anforderung strukturell nicht, ein strukturierter Datensatz erfüllt sie von selbst.

Zwei Grenzen sind dabei zu beachten. Erstens bleibt der Energieausweis ein Dokument mit eigenem Verfahren: Er wird von einem unabhängigen, berechtigten Aussteller nach einer Vor-Ort-Aufnahme erstellt und über die Registrierung nach Artikel 22 EPBD erfasst; das Kontrollsystem nach Anhang VI EPBD prüft ihn stichprobenweise. Ein Gebäudepass kann diese Rolle nicht übernehmen, er kann sie nur beliefern. Zweitens ist die im vorhandenen System vergebene Ausweisnummer eine systeminterne, aus der Gebäude-ID abgeleitete Kennung und ausdrücklich keine amtliche Registriernummer. Solange die deutschen Ausführungsregelungen — insbesondere das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG — nicht vollständig feststehen, bleibt die im Pass erzeugte Ausweisdarstellung eine fachliche Vorbereitung und ersetzt keinen registrierten Ausweis.

2.5 Abgrenzung zum Renovierungspass

Die EPBD definiert den Renovierungspass in Artikel 12 und Anhang VIII als Instrument für die langfristige, schrittweise Renovierung eines bestimmten Gebäudes. Sein Kern ist eine grafische Roadmap vom heutigen Zustand bis zum Zielzustand, wobei für jeden Schritt Maßnahmen, Kosten, Energie- und Treibhausgaseinsparung, Kostenersparnis mit offengelegten Preisannahmen und die nach dem Schritt erreichte Ausweisklasse anzugeben sind. Ergänzt wird das um die nationalen Anforderungen samt Stichtagen, eine Begründung der optimalen Schrittfolge zur Vermeidung von Lock-in-Effekten sowie Angaben zu Zirkularität, Whole-Life-Carbon, Förderung und Beratungsangeboten. Zielzustand ist die umfassende Renovierung: Niedrigstenergiegebäude vor dem 01.01.2030, Nullemissionsgebäude ab dem 01.01.2030, hilfsweise eine Primärenergiereduktion von mindestens 60 Prozent.

Der Renovierungspass ist damit ein Instrument mit Blickrichtung nach vorn. Er beantwortet die Frage, wohin das Gebäude entwickelt werden soll und in welcher Reihenfolge. Der digitale Gebäudepass verfolgt einen breiteren Ansatz: Er beantwortet zusätzlich, wo das Gebäude heute steht, woher es kommt und welche der geplanten Maßnahmen tatsächlich umgesetzt wurden. Der Renovierungspass kann deshalb Bestandteil des Gebäudepasses sein — als eine seiner Sichten, gespeist aus demselben Datenbestand, der auch den Ausweis trägt.

Für diese Kopplung liefert die Richtlinie mehrere Anknüpfungspunkte. Nach Artikel 12 Absatz 3 EPBD und Artikel 19 Absatz 6 EPBD dürfen Ausweis und Renovierungspass gemeinsam ausgestellt werden; in diesem Fall ersetzt der Pass die Modernisierungsempfehlungen des Ausweises. Nach Anhang VIII EPBD sind die Ausweisdaten als Startzustand zu berücksichtigen, dürfen aber durch die Befunde der ohnehin vorgeschriebenen Vor-Ort-Aufnahme überschrieben werden — auch das ein Argument für eine gemeinsame, versionierte Datenhaltung statt zweier getrennter Dokumente. Nach Artikel 12 Absatz 7 EPBD muss der Pass in die Datenbank nach Artikel 22 EPBD hochladbar sein.

Zwei Punkte sind bei der Abgrenzung nicht zu übersehen. Erstens ist der Renovierungspass für Eigentümer freiwillig: Artikel 12 EPBD verpflichtet die Mitgliedstaaten, ein System bereitzustellen; sie können eine Nutzungspflicht vorsehen, müssen es aber nicht. Zweitens gilt für ihn eine schwächere Formanforderung als für den Ausweis — verpflichtend ist eine digitale und druckfähige Fassung, die Maschinenlesbarkeit in XML ist Empfehlung der Kommissionsleitlinien, nicht Pflicht. Ein Gebäudepass, der den Renovierungspass strukturiert führt, erfüllt damit mehr als das rechtlich Geforderte; das ist eine bewusste Entscheidung und kein Nachweis von Konformität. Im vorhandenen System existiert eine Renovierungspass-Engine mit eigenen Faktortabellen, dazu ein Maßnahmenbericht und ein Fahrplan-Datenblatt als Ausgabe; die dafür benötigten Bausteine — Maßnahmen, Varianten, Kosten, Förderlogik und Wirtschaftlichkeit — sind vorhanden, jedoch nicht als geschlossenes Anhang-VIII-Feldmodell. Dessen Vervollständigung ist als vorrangiger Ausbauschritt geführt.

2.6 Abgrenzung zum deutschen individuellen Sanierungsfahrplan

Auch der individuelle Sanierungsfahrplan (iSFP) ist nicht mit dem Gebäudepass gleichzusetzen — und ebenso wenig ohne Weiteres mit dem Renovierungspass. Der iSFP beschreibt einen empfohlenen Sanierungsweg in aufeinander abgestimmten Schritten und ist in Deutschland fest an ein Förderverfahren gebunden. Die Kommissionsleitlinien zum Renovierungspass nennen ihn zweimal als Best-Practice-Vorbild, insbesondere wegen der Einseiten-Grafik und der Förderhinweise je Schritt. Vorbild bedeutet jedoch nicht Gleichsetzung: Nicht automatisch abgedeckt sind die Pflichtfelder zur Veränderung der operativen Treibhausgasemissionen, zur Zirkularität und zum Whole-Life-Carbon sowie die Liste der nationalen Anforderungen mit Stichtagen. Ob Deutschland den iSFP formal zum Renovierungspass im Sinne von Artikel 12 EPBD erklärt, ist zum Stand dieses Whitepapers nicht entschieden; ebenso offen ist, ob ein Anhang-VIII-Feldmodell in iSFP-Darstellung oder das förmliche Druckbild maßgeblich wird.

Für den Gebäudepass ist der iSFP deshalb zunächst eine Datenquelle und ein Zielformat, nicht eine Systemgrenze. Er lässt sich aufnehmen, und anschließend lässt sich dokumentieren, welche der empfohlenen Maßnahmen tatsächlich durchgeführt wurden. Daraus entsteht ein geschlossener Kreislauf:

1. Ausgangszustand des Gebäudes, erhoben und qualitätsgesichert
2. iSFP beziehungsweise Renovierungspass mit empfohlener Schrittfolge
3. geplante Maßnahmen mit Kosten, Förderung und Wirkung
4. Umsetzung einzelner Schritte
5. Nachweise, Rechnungen und Fachunternehmererklärungen
6. neuer Gebäudezustand
7. aktualisierte Energiebilanz und aktualisierter Ausweis
8. nächster Sanierungsschritt auf aktualisierter Grundlage

Der Gebäudepass wird damit zur fortlaufenden Dokumentation der tatsächlichen Transformation eines Gebäudes und schließt die Lücke, die zwischen Empfehlung und Ausführung heute regelmäßig entsteht. Eine Einschränkung gehört an dieser Stelle ausdrücklich dazu: Ein förderfähiger iSFP entsteht ausschließlich in der amtlichen Druckapplikation der BAFA. Ein aus dem Gebäudepass erzeugtes Datenblatt ist eine fachliche Ausgabe und kein amtliches Austauschformat; ein maschinelles Importformat für die amtliche Anwendung ist nicht veröffentlicht.

2.7 Abgrenzung zum digitalen Gebäudelogbuch

Von allen hier betrachteten Instrumenten kommt das digitale Gebäudelogbuch dem beschriebenen Gebäudepass am nächsten. Die EPBD enthält dafür in Artikel 2 Nummer 41 eine Legaldefinition: ein gemeinsames Repositorium für alle relevanten Gebäudedaten, das Informationen über den Lebenszyklus zusammenführt und zugänglich hält. Wichtig für die Einordnung ist, was daraus folgt und was nicht. Eine Pflicht, ein solches Logbuch einzuführen, enthält die Richtlinie nicht. Artikel 12 Absatz 8 EPBD knüpft nur konditional an: Wo ein digitales Gebäudelogbuch existiert, ist der Renovierungspass dort zu speichern oder über eine eindeutige Adresse zugänglich zu machen. Artikel 22 Absatz 7 EPBD verlangt für die nationalen Datenbanken lediglich Interoperabilität mit Kataster, Grundbuch und digitalen Gebäudelogbüchern.

Der hier beschriebene Gebäudepass erweitert die Logbuch-Idee um eine operative Ebene. Er soll Gebäudedaten nicht ausschließlich speichern und bereitstellen, sondern sie unmittelbar mit Berechnungs-, Prüf-, Planungs- und Dokumentationsfunktionen verbinden. Dazu gehören Berechnungen nach DIN V 18599, Varianten- und Vergleichsrechnungen, Ökobilanz, Wirtschaftlichkeit, Fördermittel und die automatisierte Dokumentenerstellung. Ein Logbuch im engeren Sinn beantwortet die Frage, welche Information zu einem Gebäude vorliegt; der Gebäudepass beantwortet zusätzlich, welche Folgen eine geänderte Information für Bilanz, Nachweis, Klasse und Kosten hat. Die Verbindung lautet: Datenhaltung, Berechnung, Dokumentation, Planung und Historisierung in einem Modell.

Die Abgrenzung hat auch eine nüchterne Seite. Ob ein System die Merkmale der Legaldefinition erfüllt, ist zunächst eine Selbsteinschätzung; verbindlich wird sie erst durch eine nationale Ausgestaltung, die es in Deutschland zum Stand dieses Whitepapers nicht gibt. Für die geforderte Interoperabilität nach Artikel 22 Absatz 7 EPBD fehlt derzeit die Gegenstelle: Deutschland verfügt nach den Anhängen der Kommissionsleitlinien noch über keine nationale Energieausweis-Datenbank, und ein Schema für die Datenbank nach Artikel 22 EPBD liegt nicht vor. Auf Seiten der Plattform ist die dafür erforderliche Service-Schnittstelle als Ausbauschritt vorgesehen und noch nicht umgesetzt.

2.8 Abgrenzung zum digitalen Zwilling

Der digitale Zwilling stellt die weitergehende Entwicklungsstufe dar. Die Abstufung lässt sich präzise formulieren: Eine statische Gebäudeakte dokumentiert einen Zustand. Ein fortschreibbarer Gebäudepass dokumentiert Veränderungen. Ein digitaler Zwilling verbindet das digitale Modell darüber hinaus mit dem realen Betrieb des Gebäudes und bildet damit nicht nur die dokumentierte, sondern die gemessene Wirklichkeit ab. Dazu können künftig Smart-Meter-Daten, gemessene Verbräuche, Raumtemperaturen, Anlagenzustände, Erträge von Photovoltaikanlagen, Betriebsdaten von Wärmepumpen, Wartungsinformationen und Daten der Gebäudeautomation gehören.

Die Architektur entwickelt sich damit schrittweise von der digitalen Gebäudeakte über den strukturierten Gebäudepass und die digitale Gebäudechronik zum digitalen Zwilling. Jede Stufe setzt die vorige voraus: Ohne belastbare Stammdaten ist ein Messwert nicht interpretierbar, und ohne Historisierung lässt sich eine Abweichung zwischen Bedarf und Verbrauch keiner Ursache zuordnen.

Regulatorisch ist der digitale Zwilling keine Pflicht. Er erscheint in Artikel 19 Absatz 14 Buchstabe c EPBD ausschließlich als zulässiger Kanal für vereinfachte Ausweis-Aktualisierungen, also als Option. Zu beachten ist außerdem die Zuständigkeitsgrenze beim Datenzugang: Artikel 16 EPBD erfasst die statischen Gebäudesystemdaten — Bauteil-Performance, gebäudetechnische Dienste, Lebensdauerprognose der Heizung, Automationssysteme, Zähler, Mess- und Regeleinrichtungen, Ladepunkte. Die dynamischen Daten vernetzter Produkte fallen dagegen unter den Data Act, Verordnung (EU) 2023/2854; Abrechnungsdaten der Zähler unterliegen dem Strom- und Gasbinnenmarktrecht. Ein Gebäudepass, der Betriebsdaten aufnimmt, bewegt sich damit in mindestens zwei Rechtskreisen — Kapitel 9 behandelt die Folgen für Zweckbindung und Berechtigungen.

Im vorhandenen System ist diese Stufe noch nicht erreicht. Verbrauchsdaten werden als Verbrauchshistorie geführt und ausgewertet, also als erfasste Größe, nicht als angebundener Datenstrom. Die Anbindung von Messdaten, Anlagen- und Wartungsdaten ist als Ausbaustufe vorgesehen; sichtbar wird die Lücke unter anderem daran, dass die Wartungssäule des Building Trust Index derzeit ohne Beitrag bleibt, solange Dokumente und Wartungsvorgänge nicht verdrahtet sind. Diese Lücke wird hier offen benannt, weil ein Zwilling ohne belastbare Betriebsdatenquelle nur eine Beschriftung wäre.

2.9 Abgrenzung zur klassischen Gebäudeakte

Die klassische Gebäudeakte ist die heute verbreitetste Form der Gebäudedokumentation und zugleich diejenige, mit der der Gebäudepass am häufigsten gleichgesetzt wird. Sie ist eine Sammlung von Unterlagen zu einem Objekt: Bauakte, Genehmigungen, Pläne, Statik, Nachweise, Rechnungen, Wartungsprotokolle, Energieausweise. Ob sie in Ordnern, auf einem Netzlaufwerk oder in einem Dokumentenmanagementsystem liegt, ändert an ihrer Natur wenig. Sie ist dokumentenorientiert, in der Regel chronologisch geordnet und in ihrem Umfang davon abhängig, was jemand aufgehoben hat.

Daraus ergeben sich vier strukturelle Unterschiede zum Gebäudepass. Erstens fehlt der Akte die Strukturebene: Ein U-Wert, der in einem eingescannten Nachweis steht, ist für eine Berechnung nicht verfügbar, sondern muss erneut abgetippt und dabei erneut geprüft werden. Zweitens fehlen Metadaten: Eine Akte sagt nicht, welche von zwei widersprechenden Angaben die führende ist, wer sie erhoben hat und ob sie geprüft wurde. Drittens fehlt die Fortschreibungslogik: Ein Dokument wird ergänzt, aber die Aussage des älteren Dokuments bleibt gleichrangig daneben stehen, ohne dass ein Ersetzungsverhältnis erkennbar wäre. Viertens fehlt die Auswertbarkeit über den Einzelfall hinaus — für Portfolios, kommunale Wärmeplanung oder Statistik ist eine Aktensammlung nicht nutzbar.

Der Gebäudepass löst die Akte nicht ab, sondern setzt auf ihr auf. Die Dokumente bleiben erhalten und behalten ihren Beweiswert; sie werden jedoch mit den strukturierten Daten verknüpft, die sie belegen. Im vorhandenen System geschieht das über einen Objektgraphen mit expliziten Kanten für „belegt durch", „beeinflusst" und „ersetzt"; ergänzend analysiert eine Schnittstelle hochgeladene Pläne, Wärmeschutznachweise und Energieausweise und schlägt daraus Werte vor. Dabei gilt durchgängig, dass Vorschläge eines Drittsystems oder einer automatischen Auswertung Vorschläge bleiben: Konflikte werden erzeugt und sichtbar gemacht, nicht automatisch aufgelöst. Aus der Ablage wird so ein Beleg-Netz — die Akte wird zur Beweisschicht des Datensatzes.

2.10 Zusammenschau der Abgrenzungen

Die einzelnen Abgrenzungen lassen sich in einer Übersicht zusammenführen. Vergleichbar sind die Instrumente entlang von vier Merkmalen: welchem Zweck sie dienen, in welcher Form ihre Daten gehalten werden, ob und wie sie fortgeschrieben werden und in welchem Verhältnis sie zum digitalen Gebäudepass stehen. Die Übersicht beschreibt die Instrumente in ihrer regulatorischen beziehungsweise praktischen Gestalt, nicht den Umsetzungsstand eines bestimmten Systems.

Aus der Übersicht lassen sich drei Beobachtungen ableiten. Erstens unterscheiden sich die Instrumente weniger im Inhalt als in der Zeitachse: Die Akte blickt zurück, der Ausweis auf den Stichtag, der Renovierungspass nach vorn, der Zwilling auf den laufenden Betrieb. Ein Gebäudepass ist genau dann sinnvoll, wenn er alle vier Zeitbezüge auf denselben Datenbestand stützt. Zweitens sind die Formanforderungen uneinheitlich — nur der Energieausweis muss maschinenlesbar sein, der Renovierungspass nicht. Wer alles strukturiert führt, erfüllt mehr als gefordert; das ist ein Vorteil in der Praxis, aber kein Konformitätsnachweis. Drittens ist keines der drei digitalen Instrumente — Logbuch, Zwilling und, für Eigentümer, der Renovierungspass — verpflichtend. Der Gebäudepass steht damit auf freiwilligem Terrain und muss seinen Nutzen aus der Sache heraus begründen, nicht aus einer Pflicht.

2.11 Der finanzierungsfähige Gebäudedatensatz

Die Bedeutung eines solchen Systems endet nicht beim Energie- oder Baurecht. Für Banken und institutionelle Immobilieninvestoren werden energetische Gebäudedaten zunehmend Bestandteil von Risiko-, Portfolio- und Finanzierungsprozessen. Die Richtlinie greift diese Entwicklung auf: Nach Artikel 22 EPBD gehören Finanzinstitute zu den Zugriffsberechtigten der nationalen Gebäudedatenbank und erhalten für die von ihnen finanzierten Objekte den vollständigen Ausweis maschinenlesbar und als Druckdokument. Damit ist die Verwendung von Gebäudedaten im Finanzierungsprozess nicht mehr nur Marktpraxis, sondern regulatorisch vorgezeichnet.

Ein Energieausweis allein kann die Anforderungen dieser Prozesse nur teilweise erfüllen, weil er auf einen Stichtag und auf wenige Kennwerte beschränkt ist. Für eine weitergehende Beurteilung werden regelmäßig zusätzliche Informationen benötigt: der energetische Zustand des Gebäudes, der erwartete Sanierungsbedarf und der daraus folgende Investitionsbedarf, die technischen Anlagen und ihre verbleibende Nutzungsdauer, die Modernisierungshistorie, die Emissionen, die Fördermöglichkeiten, ein plausibler Dekarbonisierungspfad sowie — und dies ist der eigentliche Unterschied — Angaben zur Qualität, Herkunft und Aktualität der Informationen selbst.

Genau hier eröffnet der Gebäudepass eine zusätzliche Funktion. Er kann die technische Gebäudeakte in einen strukturierten Evidenzdatensatz erweitern, in dem jeder Wert seine Quelle, seinen Prüfstatus und seine Version mitführt. Für einen Kreditprozess ist die Frage, wie belastbar eine Angabe ist, ebenso entscheidend wie die Angabe selbst. Der Building Trust Index bildet diese Belastbarkeit im vorhandenen System als nachvollziehbares, erklärbares Maß ab, bei dem jeder Beitrag einzeln ausgewiesen wird. Ausdrücklich bewertet er die Qualität der Gebäudedaten und den technischen Zustand, nicht die Bonität des Eigentümers.

Dabei ersetzt der Gebäudepass weder die Immobilienbewertung noch das Kreditrating einer Bank. Er stellt die qualitätsgesicherte Gebäudedatenbasis bereit, auf der solche Prozesse aufbauen können. Perspektivisch entsteht so eine durchgehende Kette vom Gebäude über den Gebäudepass zu Energie- und ESG-Daten, weiter zu Sanierungsbedarf und Investitionsplanung und von dort in Immobilienbewertung und Kreditentscheidung. Diese Verbindung ist von erheblicher strategischer Bedeutung, weil sie den Gebäudepass aus der reinen Nachweiswelt herauslöst; die Anforderungen der einzelnen Zielgruppen behandelt Kapitel 11, die dafür erforderlichen Zugriffs- und Rollenmodelle Kapitel 9. Das abgestufte Zugriffsmodell für Banken, Makler und Verwalter ist seit dem 23. August 2026 umgesetzt: Jede dieser Gruppen erhält einen eigenen, befristeten und widerrufbaren Zugang mit festgelegtem Datenausschnitt. Die Anzeigerollen der Kennwerteseite bestehen daneben fort; sie priorisieren die Darstellung und bilden weiterhin keine Rechteschicht.

2.12 Rechtliche Einordnung

Der digitale Gebäudepass wird in diesem Whitepaper als technische Plattform zur Unterstützung der EPBD-Umsetzung beschrieben. Diese Formulierung ist bewusst gewählt. Eine amtliche oder gesetzlich bestätigte „EPBD-Konformität" wird nicht behauptet und sollte erst behauptet werden, wenn die nationalen Ausführungsregelungen, die Datenstandards und die Prüfprozesse vollständig feststehen. Die Gründe dafür sind nicht formaler Natur, sondern lassen sich konkret benennen.

Erstens richtet sich die Richtlinie an die Mitgliedstaaten, nicht an Private. Die EPBD verpflichtet die Mitgliedstaaten, bis zum 29.05.2026 die erforderlichen Regelungen zu erlassen. Pflichten für Eigentümer, Aussteller oder Softwareanbieter entstehen erst durch die nationale Umsetzung. Ein Werkzeug kann daher nicht unmittelbar „der Richtlinie entsprechen"; es kann nur den Anforderungen entsprechen, die das nationale Recht aus ihr ableitet. In Deutschland geschieht das über das Gebäudemodernisierungsgesetz (GMoDG), verkündet am 28.07.2026, BGBl. 2026 I Nr. 226. Ein Teil des Gesetzes ist seit dem 29.07.2026 in Kraft; die eigentliche EPBD-Umsetzung folgt zeitversetzt. Der dafür in den Quellen genannte Anwendungszeitpunkt 01.01.2027 ist mit Vorbehalt zu führen, weil die Fristangabe „sechs Monate nach Verkündung" rechnerisch auf einen späteren Termin führt; die genaue Terminlage ist am amtlichen Wortlaut gegenzuprüfen und wird in Kapitel 3 im Zusammenhang dargestellt.

Zweitens fehlen zentrale Spezifikationen, an denen eine Konformität überhaupt gemessen werden könnte. Zum Stand dieses Whitepapers sind unter anderem offen:

• das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG;
• das Datenformat des Lebenszyklus-Treibhausgasberichts nach § 88b GMoDG;
• das Schema der nationalen Gebäudedatenbank nach Artikel 22 EPBD — eine nationale Energieausweis-Datenbank besteht in Deutschland nach den Anhängen der Kommissionsleitlinien bislang nicht;
• die Klassenskala und die Klassengrenzen für Nichtwohngebäude;
• das Schema für den Smart Readiness Indicator sowie der Nachweis für Nullemissionsgebäude;
• die Mindestanforderungen an die Gesamtenergieeffizienz für Nichtwohngebäude im Bestand;
• das Kontrolldatei-Schema für die künftig monatliche Verbrauchserfassung.

Solange eine Spezifikation nicht vorliegt, ist die zugehörige Funktion nicht umsetzbar, sondern blockiert. Eine Software kann diesen Zustand sauber vorbereiten — etwa indem sie Felder vorhält, Umschaltmöglichkeiten zwischen Rechtsständen anlegt und Lücken als Lücken meldet, statt Ersatzwerte zu unterstellen —, sie kann ihn aber nicht auflösen. Für die Darstellung im Whitepaper gilt deshalb durchgängig eine Dreiteilung: Wo Recht und Spezifikation vorliegen, ist eine Anforderung umsetzbar; wo die Spezifikation fehlt, ist sie blockiert; wo etwas nur angekündigt ist, wird keine Pflicht behauptet. Ebenso werden vier Daten getrennt gehalten, die in der Praxis regelmäßig vermengt werden: Veröffentlichung, Inkrafttreten, Anwendung und Produktivsetzung.

Drittens ist der Berechnungsstand selbst zu benennen. Öffentlich-rechtlich verbindlich gerechnet wird nach DIN V 18599 in der Ausgabe 2018-09; sie ist die vom Gesetz in Bezug genommene Grundlage. Die Technische Spezifikation DIN/TS 18599:2025-10 ist keine Grundlage des Ordnungsrechts; Ergebnisse daraus sind Vergleichsrechnung. Für ein Werkzeug folgt daraus eine harte Regel: Jede Ausgabe, die das System verlässt, muss die gerechnete Normfassung und den zugrunde gelegten Rechtsstand benennen. Wo Norm und Gesetz auseinanderfallen — etwa bei Primärenergie- und Emissionsfaktoren — gelten für Energieausweise und öffentlich-rechtliche Nachweise die Werte des Gesetzes.

Viertens ist genau zu unterscheiden, was die Richtlinie verlangt und was sie ermöglicht. Ein digitales Gebäudelogbuch ist definiert, aber nicht vorgeschrieben; ein digitaler Zwilling ist ein zulässiger Aktualisierungskanal, keine Anforderung; der Renovierungspass ist für Eigentümer freiwillig; eine Pflicht zum Smart Readiness Indicator entsteht erst mit einem delegierten Rechtsakt und dann nur für größere Nichtwohngebäude; die Maschinenlesbarkeit ist für den Ausweis Pflicht, für den Renovierungspass Empfehlung; Anforderungen zum Lebenszyklus-Treibhauspotenzial gelten für Neubauten in Stufen, nicht für den Bestand. Wer diese Unterschiede einebnet, erzeugt Scheinpflichten — und beschädigt damit die Glaubwürdigkeit der Argumente, die tatsächlich tragen.

Fünftens bleibt die Prüfebene beim Staat. Registrierung und Kontrolle der Ausweise erfolgen über die Datenbank nach Artikel 22 EPBD und das Kontrollsystem nach Anhang VI EPBD; für die Datenbank fordert die Richtlinie, dass der Urheber jeder Hinzufügung oder Änderung für die Behörden ermittelbar ist. Ein Gebäudepass kann diese Nachvollziehbarkeit auf seiner Seite herstellen — durch Versionierung, Herkunftskennzeichnung und einen Freigabeprozess —, er kann die behördliche Prüfung jedoch nicht vorwegnehmen. Entsprechend sind systeminterne Kennungen keine amtlichen Registriernummern, und eine im System erzeugte Ausgabe ist kein amtliches Austauschformat, solange kein amtliches Format veröffentlicht ist.

Diese Zurückhaltung ist kein Nachteil für das Vorhaben, sondern seine Voraussetzung. Ein System, das offene Punkte als offen führt, bleibt anschlussfähig, wenn die Spezifikationen kommen. Ein System, das Konformität behauptet, bevor es einen Maßstab gibt, muss sie später zurücknehmen. Die weitere Argumentation dieses Whitepapers folgt deshalb durchgehend der Trennung zwischen Anforderung, Konzept und Umsetzungsstand; Kapitel 12 führt diese Trennung in der Anforderungsmatrix systematisch durch, Kapitel 13 bewertet auf dieser Grundlage den Reifegrad, und Kapitel 14 leitet daraus die Entwicklungsroadmap ab.

3 Regulatorischer Rahmen der EPBD

Der digitale Gebäudepass ist kein freies Produkt, sondern bewegt sich in einem dicht geregelten Umfeld. Dieses Kapitel legt das rechtliche Fundament: Es zeichnet die Entwicklung der europäischen Gebäuderichtlinie bis zur Richtlinie (EU) 2024/1275 nach, ordnet deren Fristen, beschreibt das Verhältnis zum deutschen Gebäudeenergierecht und zur Bundesförderung und klärt, welche Berechnungsnorm für welchen Zweck gilt. Es benennt außerdem ausdrücklich die Stellen, an denen die Rechtslage noch offen ist — denn eine Plattform, die auf ungesicherte Annahmen gebaut wird, muss später an genau diesen Stellen wieder aufgebrochen werden.

3.1 Entwicklung der europäischen Gebäuderichtlinie

Die europäische Gebäuderichtlinie ist kein neues Instrument, sondern das Ergebnis von rund zwei Jahrzehnten schrittweiser Verschärfung. Ihre Entwicklungslinie zu kennen, ist für den Gebäudepass mehr als Rechtsgeschichte: Sie erklärt, warum die Richtlinie heute so stark auf Daten, Register und Nachvollziehbarkeit setzt — und warum die nächste Novelle voraussichtlich erneut an diesen Stellen ansetzen wird.

Die Richtlinie 2002/91/EG führte den Energieausweis als europäisches Instrument ein. Ihr Grundgedanke war die Markttransparenz: Wer ein Gebäude kauft oder mietet, sollte dessen energetische Qualität in einer vergleichbaren Form vorgelegt bekommen. Der Ausweis war damals in erster Linie ein Dokument, gedacht für den Aushang und die Übergabe an eine natürliche Person. Eine Datenhaltung im heutigen Sinne war nicht vorgesehen.

Die Neufassung 2010/31/EU verlagerte den Schwerpunkt vom Dokument zur Anforderung. Sie verankerte das kostenoptimale Anforderungsniveau als methodische Grundlage der nationalen Mindestanforderungen und verpflichtete die Mitgliedstaaten auf das Niedrigstenergiegebäude als Neubaustandard. Damit entstand erstmals eine Rechenlogik, die europaweit vergleichbar sein sollte, deren konkrete Umsetzung aber national blieb — in Deutschland über die Energieeinsparverordnung und später das Gebäudeenergiegesetz.

Die Änderungsrichtlinie (EU) 2018/844 brachte die für den Gebäudepass entscheidende Wendung. Sie verpflichtete die Mitgliedstaaten auf langfristige Renovierungsstrategien für den gesamten Gebäudebestand, führte Anforderungen an die Gebäudeautomation und an die Ladeinfrastruktur für Elektrofahrzeuge ein und legte mit dem Smart Readiness Indicator erstmals einen Indikator an, der nicht den Energiebedarf, sondern die Fähigkeit eines Gebäudes zur Interaktion mit Nutzern und Netzen beschreibt. Der Blick weitete sich damit vom Einzelgebäude auf den Bestand und von der Jahresbilanz auf das Betriebsverhalten. Beides erzeugt Datenbedarf, den ein reines Ausweisdokument nicht deckt.

Die Richtlinie (EU) 2024/1275 zieht daraus die Konsequenz. Sie ersetzt die Fassung von 2010 vollständig, formuliert erstmals Zielpfade für den Bestand statt nur Anforderungen an den Einzelfall und führt mit dem Renovierungspass, den nationalen Gebäudedatenbanken, dem Datenzugriffsrecht und dem Lebenszyklus-Treibhauspotenzial vier Instrumente ein, die ohne strukturierte, dauerhaft geführte Gebäudedaten nicht funktionieren. Aus einer Richtlinie über Anforderungen an Gebäude ist damit zugleich eine Richtlinie über Informationen zu Gebäuden geworden.

3.2 Die Richtlinie (EU) 2024/1275 als Ordnungs- und Datenrahmen

Die Richtlinie (EU) 2024/1275 über die Gesamtenergieeffizienz von Gebäuden bildet den zentralen europäischen Rahmen für die Transformation des Gebäudebestands. Ihr langfristiges Ziel ist ein hoch energieeffizienter und dekarbonisierter Gebäudebestand bis 2050. Für den Gebäudepass ist dabei nicht allein maßgeblich, welche energetischen Zielwerte vorgegeben werden. Von mindestens ebenso großer Bedeutung ist die Frage, welche Daten benötigt werden, um die Transformation von Millionen Gebäuden überhaupt messen, planen, finanzieren und kontrollieren zu können. Genau an dieser Stelle erhält die Richtlinie ihre digitale Dimension.

Betrachtet man den Regelungstext aus der Perspektive einer Datenplattform, ordnen sich die Instrumente zu einer erkennbaren Struktur. Der Energieausweis nach den Artikeln 19 bis 21 beschreibt den energetischen Zustand eines Gebäudes zu einem Zeitpunkt. Der Renovierungspass nach Artikel 12 beschreibt mögliche Entwicklungspfade desselben Gebäudes über die Zeit. Die nationalen Gebäuderenovierungspläne übertragen dieselbe Betrachtung auf den gesamten Bestand eines Mitgliedstaates. Die Gebäudedatenbank nach Artikel 22 führt die Einzelinformationen zusammen und macht sie auswertbar. Der Datenzugriff nach Artikel 16 regelt, wer diese Informationen unter welchen Bedingungen nutzen darf. Das Lebenszyklus-Treibhauspotenzial nach Artikel 7 erweitert die Betrachtung von der Betriebsenergie auf die Klimawirkung über den gesamten Lebenszyklus. Der Smart Readiness Indicator nach Artikel 15 schließlich adressiert die Fähigkeit eines Gebäudes, auf Nutzer, Netze und Energiesysteme zu reagieren.

Aus diesen Elementen entsteht schrittweise eine digitale Informationsstruktur des europäischen Gebäudebestands. Sie lässt sich als durchgehende Kette lesen, die vom realen Gebäude bis zur europäischen Auswertung reicht:

• das reale Gebäude mit seiner Geometrie, seiner Hülle und seiner Anlagentechnik,
• der daraus erhobene Gebäudedatensatz,
• die energetische Berechnung auf Grundlage dieses Datensatzes,
• der Energieausweis als normiertes Ergebnisdokument,
• der Renovierungspass als Fahrplan für die weitere Entwicklung,
• die tatsächlich umgesetzten Sanierungsmaßnahmen,
• der aktualisierte Gebäudezustand,
• die nationale Gebäudedatenbank nach Artikel 22,
• die aggregierte Auswertung des nationalen Bestands und
• die europäische Auswertung über das Building Stock Observatory.

Der digitale Gebäudepass nimmt innerhalb dieser Kette eine bestimmte Position ein: Er sitzt zwischen dem realen Gebäude und den daraus abgeleiteten Dokumenten, Registern und Anwendungen. Er ist damit weder ein weiteres Dokument noch ein Register, sondern die Datenebene, aus der Dokumente und Registermeldungen erzeugt werden. Diese Einordnung wird in Kapitel 6 als Zielbild ausgeführt und in Kapitel 4 in ein Datenmodell überführt.

Zwei Eigenschaften der Richtlinie prägen diese Datenebene besonders. Erstens verlangt Artikel 19 den Energieausweis in digitaler und maschinenlesbarer Form; die Kommissionsleitlinien nennen CSV, JSON und XML, und ein gescanntes PDF genügt ausdrücklich nicht. Zweitens verlangt Artikel 20 Absatz 8 die Registrierung des vollständigen Ausweises einschließlich aller Berechnungs-Eingangsdaten. Beides zusammen bedeutet, dass es langfristig nicht mehr genügt, ein korrektes Ausweisdokument zu erzeugen. Die zugrunde liegenden Daten müssen strukturiert, eindeutig und austauschbar vorliegen — und sie müssen den Weg in ein staatliches Register finden. Für die Softwarearchitektur folgt daraus eine Trennung, die in Kapitel 8 vertieft wird: zwischen dem internen Gebäudedatensatz des Passes, dem gesetzlichen Datensatz für Ausweise und Nachweise und dem Austauschdatensatz für die Registerschnittstelle. Diese Trennung verhindert, dass jede Änderung eines staatlichen Austauschformats das gesamte interne Datenmodell erfasst.

3.3 Ziele für 2030, 2040 und 2050

Die Richtlinie arbeitet mit zwei unterschiedlichen Zielarten, die im Gebäudepass auch unterschiedlich abgebildet werden müssen. Die eine Art betrifft das Einzelgebäude und wirkt über Anforderungen an Neubau und Renovierung. Die andere betrifft den Bestand als Ganzes und wirkt über statistische Schwellen, die der Mitgliedstaat einzuhalten hat.

Auf der Ebene des Einzelgebäudes markiert das Nullemissionsgebäude nach Artikel 11 den Zielstandard. Neubauten öffentlicher Einrichtungen müssen ihn ab dem 1. Januar 2028 erfüllen, alle Neubauten ab dem 1. Januar 2030. Ein Nullemissionsgebäude setzt kumulativ voraus, dass on-site kein fossiler Brennstoff eingesetzt wird, dass der Bedarf eine nationale Schwelle unterschreitet, die mindestens zehn Prozent unter dem am 28. Mai 2024 geltenden Niedrigstenergie-Schwellenwert liegt, dass eine Treibhausgasschwelle eingehalten wird, dass die Jahresbilanz aus erneuerbaren oder karbonfreien Quellen gedeckt wird und dass das Gebäude, soweit machbar, lastvariabel betrieben werden kann. Parallel dazu greift ab dem 1. Januar 2028 die Ausweispflicht für das Lebenszyklus-Treibhauspotenzial bei Neubauten über 1 000 m², ab dem 1. Januar 2030 für alle Neubauten.

Auf der Ebene des Bestands arbeitet Artikel 9 mit Pfaden. Für Nichtwohngebäude sind Mindeststandards so festzulegen, dass bis 2030 die energetisch schlechtesten 16 Prozent und bis 2033 die schlechtesten 26 Prozent des Bestands aus dem betreffenden Bereich herausfallen. Für Wohngebäude ist der durchschnittliche Primärenergieverbrauch bis 2030 um 16 Prozent gegenüber 2020 und bis 2035 um 20 bis 22 Prozent zu senken. Entscheidend für die Datenhaltung ist eine Nebenbedingung dieses Pfades: Mindestens 55 Prozent der bis 2030 zu erreichenden Reduktion müssen aus den 43 Prozent energetisch schlechtesten Wohngebäuden stammen. Ohne ein belastbares Merkmal, das ein Gebäude diesem Segment zuordnet, lässt sich diese Quote weder steuern noch nachweisen. Der Gebäudepass benötigt dafür ein eigenes Kennzeichen für besonders schlecht abschneidende Gebäude, das in Kapitel 4 als Feld des Datenmodells aufgenommen wird.

Für 2040 enthält die Richtlinie in der hier zugrunde gelegten Quellenlage keine eigene, isolierte Bestandsschwelle. Die Verbindung zwischen den Zwischenzielen 2030 beziehungsweise 2033/2035 und dem Zielbild 2050 wird stattdessen über zwei Mechanismen hergestellt: über die nationalen Gebäuderenovierungspläne, die den Pfad fortschreiben, und über die Grenzwerte für das Lebenszyklus-Treibhauspotenzial, für die die Mitgliedstaaten bis zum 1. Januar 2027 einen Fahrplan vorlegen und die ab spätestens 1. Januar 2030 gelten und anschließend degressiv fortgeschrieben werden. Wer im Whitepaper oder in einer Software ein hartes Bestandsziel für 2040 setzt, geht damit über den gesicherten Stand hinaus. Sinnvoller ist es, 2040 als Stützstelle eines fortgeschriebenen Pfades zu behandeln, dessen Werte aus den nationalen Plänen kommen und die deshalb als Parameter zu führen sind.

3.4 Umsetzungsfristen der Mitgliedstaaten

Die zentrale Umsetzungsfrist der Richtlinie ist der 29. Mai 2026 nach Artikel 35. Zu diesem Datum bündeln sich die für den Gebäudepass wichtigsten Pflichten: das Renovierungspass-System, die neue Ausweisskala, die nationale Gebäudedatenbank, das Kontrollsystem und der Datenzugriff. Alle weiteren Termine liegen entweder vorbereitend davor oder bauen darauf auf. Die folgende Übersicht führt die Fristen in der Fassung der konsolidierten Richtlinie zusammen; sie ist zugleich die Referenz für die Fristenlogik des in Kapitel 14 beschriebenen Umsetzungsplans.

Zwei Beobachtungen aus dieser Übersicht sind für den Gebäudepass unmittelbar handlungsleitend. Erstens verteilen sich die Pflichten nicht gleichmäßig, sondern verdichten sich am 29. Mai 2026 und erneut zum Jahreswechsel 2029/2030. Wer eine Plattform plant, sollte die Datenfelder für die späteren Termine — insbesondere für das Lebenszyklus-Treibhauspotenzial und für das Nullemissionsgebäude — früh anlegen, auch wenn sie zunächst leer bleiben; das Nachrüsten von Feldern in einem bereits gefüllten Bestand ist deutlich aufwendiger als deren vorsorgliche Aufnahme. Zweitens ist der Adressat aller in Tabelle 3.1 genannten Pflichten der Mitgliedstaat, nicht der Eigentümer. Aus der Richtlinie selbst folgt keine unmittelbare Pflicht für Private; erst die nationale Umsetzung bindet Eigentümer, Verkäufer, Vermieter und Aussteller. Diese Unterscheidung ist keine juristische Spitzfindigkeit, sondern entscheidet darüber, welche Anforderungen eine Software als geltendes Recht ausweisen darf und welche sie als angekündigt kennzeichnen muss.

3.5 Verhältnis zum deutschen GEG und zur BEG

Die Richtlinie verpflichtet die Mitgliedstaaten; wirksam wird sie für Eigentümer und Aussteller erst über das nationale Recht. In Deutschland verläuft diese Umsetzung über zwei getrennte Stränge, die im Gebäudepass nicht vermischt werden dürfen: das Ordnungsrecht des Gebäudeenergiegesetzes und das Förderrecht der Bundesförderung für effiziente Gebäude.

Ordnungsrecht: GEG und Gebäudemodernisierungsgesetz

Das Gebäudeenergiegesetz führt die Anforderungen der Richtlinie in nationales Recht über. Es bestimmt die Berechnungsverfahren, die Anforderungswerte, die Ausweisarten und die Pflichten bei Verkauf, Vermietung und Modernisierung. Die Anpassung an die Richtlinie (EU) 2024/1275 erfolgt über das Gebäudemodernisierungsgesetz (GMoDG), verkündet am 28. Juli 2026 im Bundesgesetzblatt 2026 I Nr. 226. Die Artikel 1, 5, 6 und 8 dieses Gesetzes sind seit dem 29. Juli 2026 in Kraft. Der für die EPBD-Umsetzung maßgebliche Artikel 2 tritt nach dem Gesetzeswortlaut sechs Monate nach der Verkündung in Kraft.

Inhaltlich greift Artikel 2 GMoDG an mehreren für den Gebäudepass relevanten Stellen ein. § 80 GMoDG setzt Artikel 19 und Anhang V der Richtlinie um und ändert die Grundlage des Verbrauchsausweises für Wohngebäude: An die Stelle der bisher nach § 82 GEG geforderten drei Abrechnungsperioden über 36 Monate tritt eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate. Bis zum Anwendungsdatum müssen beide Verfahren parallel bedienbar bleiben — eine Anforderung, die weniger die Rechenlogik als die Datenhaltung betrifft, weil Verbrauchsdaten in beiden Auflösungen vorgehalten und einander zugeordnet werden müssen. § 85 Absatz 3 GMoDG regelt das amtliche Ausweismuster, § 88b den Lebenszyklus-Treibhausgasbericht im Ausweis samt zugehörigem Datenformat, § 20 den pauschalen Trinkwarmwasser-Kennwert von 12,5 kWh/(m²·a) bezogen auf die Nutzfläche nach GEG-Systematik. Die Umnummerierung betrifft auch die Automationspflicht: Der bisherige § 71a GEG wird zu § 56 GMoDG.

Wesentliche Teile dieser Umsetzung sind zum Quellenstand jedoch noch nicht spezifiziert. Ausdrücklich offen sind die Klassenskala und die Klassengrenzen für Nichtwohngebäude, das amtliche Ausweismuster nach § 85 Absatz 3, das Datenformat nach § 88b, das SRI-Schema, das Schema der Datenbank nach Artikel 22, der Nachweis für Nullemissionsgebäude, die Mindeststandards für Nichtwohngebäude sowie die nationale Ausgestaltung des Data Act. Hinzu kommt, dass Deutschland nach Anhang 5 der Kommissionsleitlinien bislang über keine nationale Energieausweis-Datenbank verfügt; der Eintrag lautet dort „n/a". Ein deutsches Austauschschema nach Artikel 22 existiert zum Quellenstand nicht. Für die Architektur des Gebäudepasses ist das eine zentrale Randbedingung: Die Registerschnittstelle kann vorbereitet, aber nicht fertiggestellt werden, und sie sollte deshalb als austauschbare Ausgabeschicht auf einem stabilen internen Datenmodell aufsetzen.

Förderrecht: Bundesförderung für effiziente Gebäude

Die Bundesförderung für effiziente Gebäude ist kein Umsetzungsinstrument der Richtlinie, sondern das ökonomische Gegenstück zum Ordnungsrecht. Sie definiert eigene Anforderungsniveaus, eigene Nachweispflichten und eigene Antragsverfahren. Für den Gebäudepass ist die Abgrenzung wichtig: Ein Gebäude kann die ordnungsrechtlichen Anforderungen erfüllen und dennoch keinen Förderanspruch begründen, und umgekehrt setzt die Förderung an Kennwerten an, die im Energieausweis nicht in derselben Form erscheinen. Die Daten überschneiden sich weitgehend, die Bezugsgrößen und Stichtage tun es nicht.

Die Richtlinie stellt allerdings ihrerseits eine Verbindung zur Förderlandschaft her. Anhang VIII verlangt für den Renovierungspass Angaben zu verfügbaren Förderungen einschließlich Links sowie die Kontaktdaten der zuständigen Anlaufstellen; auch der Energieausweis führt nach Anhang V die Kontaktdaten einer Anlaufstelle. Artikel 19 Absatz 13 verpflichtet die Mitgliedstaaten, Eigentümer von Gebäuden unterhalb der Klasse C nach fünf Jahren beziehungsweise bei Ablauf des Ausweises zu einer Beratung einzuladen. Förderinformation wird damit vom freiwilligen Zusatz zum Pflichtbestandteil zweier EPBD-Instrumente — und für den Gebäudepass zu einem Datenbestand, der gepflegt und mit einem Gültigkeitsdatum versehen werden muss, weil Förderkonditionen deutlich schneller wechseln als Gebäudedaten.

Eine besondere Rolle spielt der individuelle Sanierungsfahrplan. Die Renovierungspass-Leitlinie der Kommission (Commission Notice C/2025/6438 vom 18. Dezember 2025) nennt den deutschen iSFP in Anhang 4 zweimal als Vorbild guter Praxis, namentlich für die einseitige grafische Darstellung und für die Förderhinweise je Sanierungsschritt. Daraus folgt jedoch nicht, dass der iSFP bereits ein Renovierungspass im Sinne von Artikel 12 wäre. Nicht automatisch abgedeckt sind insbesondere die Angabe der Veränderung der betrieblichen Treibhausgasemissionen je Schritt, die Angaben zu Zirkularität und Whole-Life-Carbon sowie die Liste der nationalen Anforderungen mit ihren Stichtagen. Ob Deutschland den iSFP formal zum Renovierungspass erklärt, ist nicht entschieden; ebenso offen ist, ob ein künftiges deutsches Instrument dem Feldmodell des Anhangs VIII mit iSFP-Darstellung folgt oder dem förmlichen Layout der amtlichen Druckapplikation. Der Gebäudepass sollte diese Frage nicht vorwegnehmen, sondern die Anhang-VIII-Felder vollständig führen und die Darstellung davon trennen. Kapitel 5 führt das aus.

3.6 Normstand: DIN V 18599:2018-09 und DIN/TS 18599:2025-10

Zwischen dem Gebäudedatensatz und dem regulatorischen Ergebnis liegt die energetische Berechnung. In Deutschland übernimmt die Normenreihe DIN V 18599 diese Rolle. Die Wirkungskette verläuft von der Richtlinie über das nationale Gebäudeenergierecht zur Norm, von dort über die Gebäudedaten zur Berechnung und schließlich zu den Energiekennwerten, aus denen Energieausweis, Renovierungsplanung und Förderanträge entstehen. Für den Gebäudepass folgt daraus, dass die Norm nicht als externes Rechenprogramm behandelt werden sollte, sondern als Bestandteil der Daten- und Berechnungsarchitektur: Ändert sich ein Fenster, eine Dämmung oder ein Wärmeerzeuger, ändert sich zunächst der Gebäudedatensatz; die Bilanz wird daraufhin neu gerechnet. Damit entsteht eine direkte, nachvollziehbare Verbindung zwischen realer Gebäudeveränderung und energetischem Ergebnis.

Diese Verbindung wird jedoch dadurch erschwert, dass Normausgabe und gesetzlich anzuwendende Berechnungsgrundlage nicht identisch sein müssen. Genau das ist derzeit der Fall.

Verbindlich gerechnet wird die Ausgabe 2018-09. Das Gebäudeenergiegesetz nimmt DIN V 18599:2018-09 in Bezug; diese Ausgabe ist die öffentlich-rechtliche Grundlage für Energieausweise und Nachweise. DIN/TS 18599:2025-10 ist demgegenüber eine Technische Spezifikation und keine GEG-Grundlage. Ergebnisse aus dieser Fassung sind Vergleichsrechnungen, nicht öffentlich-rechtlich verbindliche Nachweise. Zwischenzeitlich wurde eine vollständige Umschaltung der Berechnungsmodule auf die Ausgabe 2025 erwogen; die spätere Grundsatzentscheidung legt fest, dass ausschließlich die Ausgabe 2018 gerechnet wird und die Ausgabe 2025 als Vergleich mitläuft. Es gilt die spätere Entscheidung.

Der Änderungsumfang der Reihe 2025-10 ist begrenzt und lässt sich gut abgrenzen: Geändert sind allein die Teile 1, 2 und 10; die Teile 3 bis 9 sowie Teil 11 sind unverändert. In Teil 10 betrifft die größte Änderung die Trinkwarmwasser-Tabelle für Nichtwohngebäude; hinzu kommen eine Nummernverschiebung der Nutzungsprofile ab Nummer 22 infolge einer Aufteilung der Hallenprofile, vierzehn erhöhte Beleuchtungsstärken und eine neue Tabelle zur Gebäudeautomation. In Teil 2 sind ein Wärmebrückenzuschlag von 0,03 W/(m²·K) für die Kategorie B, die saisonale Fensterlüftung bei Wohngebäuden, eine geänderte Bestimmung des Bauteil-Kennwerts nach Anhang F, der Speicherwärme-Übertrag und ein projektbezogener Wärmebrückenzuschlag zu nennen. In Teil 1 sind die CO₂-Äquivalente normativ neu gefasst. Das Referenzklima bleibt unverändert: Potsdam bleibt Referenzort, Monatsaußentemperaturen und Strahlungswerte sind wertidentisch mit der Ausgabe 2018-09, die minimale Auslegungstemperatur für die Heizperiode bleibt bei −12 °C.

Eine Besonderheit betrifft die Primärenergie- und Emissionsfaktoren. Anhang A der Ausgabe 2025 weicht von der Faktorentabelle des Gebäudeenergiegesetzes ab. Das ist jedoch kein Grund, die Faktoren im Nachweis zu ändern: Für Energieausweise und öffentlich-rechtliche Nachweise gelten die Anlagen des GEG; der Gesetzeswert hat Vorrang vor dem Normwert. Ebenfalls offen und deshalb als Vorbehalt zu führen ist die Bezugsflächenfrage. Die Nettogrundfläche nach der neueren Systematik liegt je nach Gebäude rund neun bis dreiundzwanzig Prozent unter der bisherigen energiebezogenen Nutzfläche. Für den Trinkwarmwasser-Kennwert von Wohngebäuden nennen die Quellen zurückgerechnete Werte auf die Nettogrundfläche, die gegenüber dem Wert des GMoDG auf die bisherige Bezugsfläche um rund zwölf Prozent abweichen; beide Bezüge sind zulässig, die zurückgerechneten Werte sind in den Quellen ausdrücklich nicht belegt. Eine Kennzahl in kWh/(m²·a) ohne Angabe der Bezugsfläche ist daher nicht interpretierbar.

3.7 Verbindung zu weiteren Regelungen

Die EPBD steht nicht für sich. Sie verweist an mehreren Stellen auf andere Rechtsakte, und die dort geregelten Anforderungen wirken unmittelbar auf die Datenhaltung eines Gebäudepasses. Tabelle 3.2 ordnet die wichtigsten Verbindungen; die anschließenden Absätze erläutern die für die Architektur folgenreichsten.

Der Data Act zieht eine Grenze, die in der Praxis leicht übersehen wird. Artikel 16 EPBD gibt Eigentümern, Mietern und Verwaltern einen direkten und kostenlosen Zugang zu den Daten der Gebäudesysteme — genannt sind unter anderem die Performance der Bauteile, die gebäudetechnischen Dienste, die Lebensdauerprognose der Heizung, die Gebäudeautomation, Zähler sowie Mess- und Regelgeräte und Ladepunkte. Die Weitergabe an selbst benannte Dritte ist ebenfalls kostenlos; für andere Berechtigte wie Banken, Aggregatoren, Versorger oder die amtliche Statistik dürfen die Mitgliedstaaten Gebühren festlegen. Erfasst sind dabei die statischen Daten. Die dynamischen Daten vernetzter Produkte fallen unter den Data Act, Abrechnungsdaten der Zähler unter das Strom- und Gasbinnenmarktrecht. Ein Gebäudepass, der beide Datenarten in derselben Struktur führt, vermischt zwei Rechtsregime mit unterschiedlichen Zugriffs-, Löschungs- und Entgeltregeln. Die Trennung gehört deshalb in das Datenmodell und nicht erst in die Berechtigungslogik.

Datenschutzrechtlich ist bemerkenswert, dass Artikel 22 die Zugriffsstufen selbst vorgibt. Eigentümer, Mieter und Verwalter sowie Finanzinstitute für ihre Portfolios erhalten den vollständigen Ausweis kostenlos, maschinenlesbar und zugleich als druckbares Dokument. Unabhängige Fachleute sowie Kauf- und Mietinteressenten erhalten Zugriff nur mit Erlaubnis des Eigentümers, empfohlen befristet und gegebenenfalls als reine Bildschirmansicht. Kommunen erhalten Gebietsdaten einschließlich Geoinformationen für die Wärmeplanung, die Öffentlichkeit aggregierte und anonymisierte Auswertungen mindestens zweimal jährlich, die Forschung Zugriff auf Anfrage. Diese Abstufung ist damit keine Produktentscheidung, sondern eine Vorgabe — und sie deckt sich weitgehend mit dem Rollenmodell, das Kapitel 9 für den Gebäudepass beschreibt. Hinzu kommt eine Anforderung aus Anhang VI, die technisch weit reicht: Der Urheber jeder Hinzufügung und jeder Änderung in der Datenbank muss für die Behörden ermittelbar sein. Ohne durchgehende Protokollierung auf Feldebene ist diese Anforderung nicht erfüllbar.

Die Bauproduktenverordnung wirkt über die Datenhierarchie des Anhangs III. Für das Lebenszyklus-Treibhauspotenzial gilt eine feste Rangfolge der Datenquellen: Angaben nach der Bauproduktenverordnung stehen vor Ökodesign-Daten, diese vor projekt- oder produktspezifischen Daten, diese vor generischen Datensätzen nach EN 15804 und diese vor Standardwerten. Die Systemgrenzen folgen EN 15978, der Bezugszeitraum beträgt fünfzig Jahre, die Einheit ist kg CO₂-Äquivalent je Quadratmeter Nutzfläche, und der Bilanzstand ist der As-built-Zustand: Vor Baubeginn wird geschätzt, danach bestätigt. Für den Gebäudepass folgt daraus, dass jeder Materialkennwert nicht nur einen Wert, sondern auch eine Qualitätsstufe und eine Herkunft tragen muss — und dass die Bilanz zweimal geführt wird, als Prognose und als Bestätigung.

Die Verbindung zu den nationalen Registern schließlich entscheidet über die Anschlussfähigkeit der gesamten Plattform. Artikel 22 Absatz 7 verlangt Interoperabilität sowohl mit Kataster und Grundbuch als auch mit digitalen Gebäudelogbüchern. Die Leitlinien betonen, dass eindeutige Gebäude- und Einheitenkennungen mit Georeferenz „von Anfang an" datenbankübergreifend angelegt sein müssen; als gute Praxis wird Portugal genannt, wo bis zu elf Kennungen je Objekt geführt werden. Dänemark und Portugal speichern zudem keine PDF-Dokumente, sondern erzeugen den Ausweis aus den Rohdaten. Beides sind Konstruktionsentscheidungen, die sich nachträglich kaum korrigieren lassen. Der Gebäudepass muss deshalb von Beginn an mehrere parallele Identifikatoren je Gebäude tragen können und das Dokument als abgeleitetes Erzeugnis der Daten behandeln, nicht umgekehrt. Kapitel 8 beschreibt die daraus folgende Schnittstellenarchitektur, Kapitel 4 die Identitätsfelder.

Ein Hinweis zur Abgrenzung gehört an dieser Stelle ausdrücklich dazu, weil die Richtlinie in der Diskussion regelmäßig überdehnt wird. Die EPBD verlangt kein digitales Gebäudelogbuch: Sie definiert es in Artikel 2 Nummer 41 und knüpft in Artikel 12 Absatz 8 nur konditional daran an — wo ein Logbuch existiert, ist der Renovierungspass dort zu speichern oder über eine eindeutige Adresse zugänglich zu machen. Sie verlangt keinen digitalen Zwilling; dieser erscheint in Artikel 19 Absatz 14 Buchstabe c ausschließlich als zulässiger Kanal für vereinfachte Aktualisierungen des Energieausweises. Sie verpflichtet keinen Eigentümer zum Renovierungspass, sondern nur den Mitgliedstaat zur Bereitstellung eines Systems. Sie begründet noch keine SRI-Pflicht, sondern erst der delegierte Rechtsakt bis zum 30. Juni 2027. Und sie verlangt keine Maschinenlesbarkeit des Renovierungspasses: Pflicht ist dort „digital und druckfähig", XML ist Empfehlung der Leitlinien. Maschinenlesbar muss allein der Energieausweis sein. Der Gebäudepass darf diese Optionen selbstverständlich anbieten — er darf sie nur nicht als geltende Pflicht darstellen.

3.8 Zwischenfazit

Die EPBD sollte nicht ausschließlich als neues Energiegesetz gelesen werden. Sie ist zugleich der wesentliche Treiber für die Digitalisierung der Gebäudeinformation. Der Energieausweis beschreibt den energetischen Zustand, der Renovierungspass einen möglichen Weg dorthin, die DIN V 18599 liefert in Deutschland das Berechnungsverfahren, und die nationalen Gebäudedatenbanken schaffen die übergeordnete Datenebene. Weil Banken und Immobilienwirtschaft für Bewertung, Transformationsplanung und Risikosteuerung zunehmend dieselben Kennwerte benötigen, gewinnt diese Datenebene über den energierechtlichen Zweck hinaus an Bedeutung — Kapitel 11 führt das für die einzelnen Zielgruppen aus. Entscheidend bleibt dabei, dass jede aggregierte Kennzahl auf ihre Ausgangsdaten zurückführbar ist; das unterscheidet einen qualitätsgesicherten Gebäudepass von einer reinen Kennzahlenanzeige.

Für die weitere Arbeit ergeben sich aus dem regulatorischen Rahmen drei Randbedingungen. Erstens sind vier Daten strikt zu trennen: Veröffentlichung, Inkrafttreten, Anwendung und Produktivsetzung einer Regelung. Zweitens sind drei Verbindlichkeitsstufen zu unterscheiden — liegen Recht und Spezifikation vor, ist eine Anforderung umsetzbar; fehlt die Spezifikation, ist sie blockiert; ist eine Regelung nur angekündigt, darf daraus keine Pflicht behauptet werden. Drittens ist alles, was die Quellen als offen ausweisen, auch im Produkt als offen zu kennzeichnen: die deutsche Klassenskala für Nichtwohngebäude, das amtliche Ausweismuster, das Datenformat des Lebenszyklusberichts, das SRI-Schema, das Datenbankschema nach Artikel 22, der Status des iSFP als Renovierungspass und die Leistungsschwelle für die Gebäudeautomation.

Die strategische Funktion des Gebäudepasses lässt sich vor diesem Hintergrund in einem Satz zusammenfassen: Er bildet die Datenebene zwischen dem realen Gebäude und den regulatorischen, energetischen, finanziellen und immobilienwirtschaftlichen Anwendungen seiner Daten. Er ist damit nicht das Endprodukt einer einzelnen Berechnung, sondern die Infrastruktur, aus der unterschiedliche Anwendungen entstehen. Kapitel 4 überführt dieses Verständnis in ein konkretes Datenmodell.

4 Das Gebäudedatenmodell des digitalen Gebäudepasses

Die in Kapitel 3 dargestellten Anforderungen der EPBD sind in ihrem Kern Datenanforderungen. Ein Energieausweis, der maschinenlesbar registriert und später vereinfacht aktualisiert werden soll, ein Renovierungspass mit fünf Pflichtfeldern je Sanierungsschritt, eine nationale Gebäudedatenbank, die den vollständigen Ausweis einschließlich aller Berechnungs-Eingangsdaten aufnimmt: All das setzt voraus, dass ein Gebäude nicht als Sammlung von Dokumenten, sondern als strukturierter, dauerhafter und nachvollziehbarer Datensatz vorliegt. Dieses Kapitel beschreibt das Datenmodell, das der digitale Gebäudepass dafür benötigt, und gleicht es Abschnitt für Abschnitt mit dem tatsächlich umgesetzten Datenmodell der vorhandenen Software ab.

4.1 Vom Gebäudedokument zum Gebäudedatensatz

Der entscheidende Schritt bei der Digitalisierung eines Gebäudes besteht nicht darin, vorhandene Unterlagen digital abzulegen. Ein eingescannter Bauplan bleibt ein Dokument, auch wenn er als PDF auf einem Server liegt. Gleiches gilt für einen Energieausweis, eine Handwerkerrechnung oder einen Förderbescheid. Solange die Information ausschließlich in der Bilddatei steckt, kann keine Software sie prüfen, keine Berechnung sie verwenden und keine Schnittstelle sie übertragen. Die EPBD zieht daraus eine ausdrückliche Konsequenz: Der Energieausweis muss digital und maschinenlesbar vorliegen, genannt werden CSV, JSON und XML, und ein gescanntes PDF genügt ausdrücklich nicht.

Für einen digitalen Gebäudepass folgt daraus eine klare Zielsetzung. Er verwaltet nicht Dokumente, sondern bildet das Gebäude selbst als strukturierten Datensatz ab. Dokumente verlieren ihre Bedeutung nicht, sie erhalten eine neue Funktion: Sie werden zum Nachweis und zur Herkunft eines Datenwertes.

Was das praktisch bedeutet, zeigt ein einzelner Zahlenwert. Für sich genommen ist die Angabe „Außenwand U-Wert = 0,24 W/(m²K)" wertlos, weil niemand weiß, woher sie stammt und ob sie noch gilt. Erst mit ihren Metadaten wird sie belastbar: als Quelle der Wärmeschutznachweis vom 12.03.2025, als Qualität „rechnerisch nachgewiesen", als Gültigkeit „ab Sanierung 2025", als Berechnungsgrundlage der zugehörige Datensatz nach DIN V 18599 in einer benannten Fassung. Erst damit lässt sich Jahre später beantworten, ob der Wert für einen neuen Ausweis, einen Förderantrag oder eine Bankbewertung noch verwendbar ist.

Im vorhandenen Datenmodell ist das nicht bloß Absicht, sondern niedergelegte Regel:

Jede Information hat genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie.

Datenmodell-Spezifikation des Gebäudepasses, Fassung 2026

Aus diesem Satz leiten sich fünfzehn Konsistenzregeln ab, unter anderem: genau eine führende Quelle je Information, kein Überschreiben bestehender Werte, sondern eine neue Version je Änderung, Metadaten für jeden Wert aus Quelle, Methode, Erfasser, Datum, Prüfstatus und Version, die Verknüpfung von Dokument und Datensatz über eine Kante „belegt_durch", Änderungen ausschließlich über einen Freigabeprozess, das Erzeugen statt automatischen Auflösen von Konflikten sowie der Grundsatz, dass Drittsysteme nur Vorschläge liefern. Diese Regeln sind der eigentliche Unterschied zwischen einer digitalen Gebäudeakte und einem Gebäudepass; sie kehren bei nahezu jeder der folgenden Datenebenen wieder.

4.2 Grundstruktur des Gebäudedatensatzes

Aus den regulatorischen Anforderungen und der Praxis der energetischen Bearbeitung ergibt sich eine Gliederung in zwanzig Datenebenen. Sie ist bewusst nicht nach Werkzeugen geordnet, sondern nach Gegenständen: Sie beschreibt, was am Gebäude existiert, und nicht, welches Programm es gerade berechnet. Damit bleibt sie stabil, wenn Rechenverfahren, Normfassungen oder Förderprogramme wechseln. Die folgende Tabelle ordnet jeder Ebene ihren regulatorischen Anknüpfungspunkt zu und ist zugleich die Landkarte für die Abschnitte 4.3 bis 4.19.

Die rechte Spalte benennt, welche Vorschrift die jeweilige Datenebene fordert oder voraussetzt, nicht welche Pflicht daraus für einen einzelnen Eigentümer folgt: Adressat der Richtlinie ist der Mitgliedstaat, erst die nationale Umsetzung durch GEG und GMoDG bindet Eigentümer und Aussteller. Einzelne Ebenen — insbesondere Lebenszyklus und ESG — gehen über den heutigen Pflichtenkreis hinaus und bereiten Anforderungen vor, die nach dem Fristenkalender zwischen 2028 und 2030 wirksam werden. Der Vorteil einer einheitlichen Grundstruktur liegt gerade darin, dass sie bereits vorgesehen sind, auch wenn sie zunächst leer bleiben: Einfamilienhaus, Mehrfamilienhaus und Nichtwohngebäude erhalten denselben Datenrahmen und unterscheiden sich nur im Füllgrad.

4.3 Eindeutige Gebäudeidentität

Jeder Gebäudedatensatz beginnt mit einer eindeutigen Identität. Artikel 22 EPBD verlangt eindeutige Gebäude- und Einheiten-Identifikatoren, die datenbankübergreifend funktionieren und mit einer Geo-Referenz versehen sind; die Kommissions-Leitlinien empfehlen, sie von Anfang an zu vergeben und nicht nachträglich einzuführen. Der Grund ist praktischer Natur: Ein Gebäude taucht in Kataster, Grundbuch, Adressregister, Energieausweisregister, Förderakte und Bankportfolio unter jeweils eigenen Nummern auf — für Portugal nennen die Leitlinien bis zu elf parallele Identifikatoren je Gebäude. Der Gebäudepass löst das nicht dadurch, dass er eine weitere Nummer erfindet, sondern dadurch, dass er die fremden Identifikatoren als Felder mitführt und auf seine eigene stabile Kennung abbildet.

Die folgende Tabelle listet die Felder der Identitätsebene. Sie dient zwei Anforderungen zugleich: der Auffindbarkeit des Gebäudes über Registergrenzen hinweg nach Artikel 22 EPBD und der Zuordnung zu einer Gebäudekategorie, ohne die weder Bilanzierung noch Klassenbildung möglich sind.

Zwei Felder verdienen eine Anmerkung. Feld 01.18 ist kein Einzelwert, sondern eine Liste aus Quellsystem, Kennung und Gültigkeit — nur so lässt sich die von Artikel 22 Absatz 7 EPBD geforderte Interoperabilität mit Kataster und Grundbuch später herstellen, ohne den Datensatz umzubauen. Feld 01.16 wirkt unmittelbar auf die Bewertung, weil der Denkmalstatus energetische Anforderungen und Förderwege verändert; er gehört in die Stammdaten und nicht in eine Bemerkungsspalte. Von personenbezogenen Eigentümerdaten ist die Identitätsebene konsequent zu trennen: Der Gebäudepass beschreibt primär das Gebäude.

Das Gebäude als dauerhafte Identität

Ein Gebäude überdauert typischerweise mehrere Eigentümergenerationen. Seine digitale Identität darf deshalb nicht an die Identität eines Eigentümers gebunden sein: Der Eigentümer wechselt, das Gebäude bleibt. Ein Datensatz, der bei jedem Verkauf neu beginnt, kann weder eine Sanierungshistorie noch eine Entwicklung der Datenqualität abbilden. Bei einem Eigentümerwechsel entsteht daher nicht zwingend ein neuer Gebäudepass; übertragen wird die Berechtigung, den vorhandenen Datensatz zu nutzen und zu verwalten, während der Zugriff auf personenbezogene Bestandteile endet. Diese Trennung von Objektidentität und Zugriffsberechtigung ist der Punkt, an dem Datenmodell und Rechtemodell aufeinandertreffen; letzteres behandelt Kapitel 9.

Eine zweite Kennung betrifft den Energieausweis. Der Pass erzeugt für den automatisch erstellten Bedarfsausweis eine aus der Gebäude-ID deterministisch abgeleitete Dokumentnummer; sie ist ausdrücklich keine Registriernummer einer amtlichen Stelle. Solange das deutsche Schema für die Datenbank nach Artikel 22 EPBD nicht vorliegt — die Leitlinien führen Deutschland insoweit als „n/a" —, kann keine Software eine registrierungsfähige Nummer vergeben. Der Gebäudepass führt das Feld deshalb bereits, lässt es aber leer, bis es befüllbar ist: Struktur vorhalten, Inhalt nicht erfinden.

4.4 Stammdaten: Grundstück, Standort und Klimabezug

Der Standort beeinflusst eine große Zahl nachgelagerter Rechnungen: den Klimadatensatz der Bilanzierung, den Ertrag einer Photovoltaikanlage, die Verschattung, die Anschlussoption an ein Wärmenetz und zunehmend die Risikobewertung durch Versicherer und Banken. Standortdaten sind typische Mehrfachnutzungsdaten — einmal erfasst, in vielen Anwendungen verwendet. Die folgende Tabelle bedient zugleich die von Artikel 22 EPBD geforderte Geo-Referenzierung und die Gebietsauswertung für die kommunale Wärmeplanung.

Daraus entstehen typische Verwertungsketten: Der Standort liefert die Klimadaten für die Bilanz nach DIN V 18599, die Dachausrichtung die Grundlage der Photovoltaikberechnung, und die Risikofelder speisen perspektivisch die Finanzierungssicht nach Abschnitt 4.15. Für die Bilanzierung ändert der Normwechsel daran nichts: Das Referenzklima bleibt in der Ausgabe 2025-10 unverändert, Potsdam bleibt Referenzort, die Monatswerte für Außentemperatur und Strahlung sind wertidentisch mit der Ausgabe 2018-09. Standortdaten sind damit besonders langlebig.

Im vorhandenen System ist die Standortebene nur teilweise ausgebaut. Adresse, Ausrichtung und Verschattung werden über Gebäudesteckbrief und CAD-Editor erfasst und in der Bilanz verwendet. Ein eigenständiges Grundstücksmodul führt das Pflichtenheft dagegen als offenen Punkt der Roadmap; ein automatischer Katasterbezug ist nicht implementiert. Die Felder 02.03 und 02.10 sind daher als konzipiert, nicht als vorhanden zu beschreiben.

4.5 Geometrie und Bezugsflächen

Die Geometrie gehört zu den wichtigsten und zugleich fehleranfälligsten Grunddaten. Der Grund liegt weniger in der Messung als in der Begrifflichkeit: In der Praxis kursieren Wohnfläche, Nutzfläche, Nettoraumfläche, Bruttogrundfläche und energetische Bezugsfläche nebeneinander, häufig unter demselben Wort „Fläche". Werden sie in einem Feld gespeichert, entsteht ein Fehler, der sich durch die gesamte Bilanz zieht und meist erst am Ergebnis auffällt, wenn die Ursache nicht mehr auffindbar ist. Ein Datenmodell darf deshalb kein Feld „Fläche" kennen; jede Flächengröße erhält einen fachlich eindeutigen Namen und eine eigene Feld-ID.

Die folgende Tabelle unterscheidet die Flächen- und Volumengrößen, die der Gebäudepass getrennt führen muss. Sie dient unmittelbar Artikel 20 Absatz 8 EPBD, wonach die Datenbank die Bezugsfläche als Rohdatum je Ausweis erhält und bei Mischnutzung zusätzlich deren Aufschlüsselung.

Jede dieser Größen benötigt neben ihrem Wert vier Zusatzangaben: Einheit, Berechnungsmethode, Quelle und Datum. Erst damit ist erkennbar, ob eine Wohnfläche aus einem Mietvertrag, einer Aufmaßskizze oder dem digitalen Grundriss stammt. Besonders folgenreich ist die Unterscheidung der Felder 03.08 und 03.09: Die Umstellung der energetischen Bezugsfläche im Zuge des GMoDG ist keine Umrechnung, sondern der Wechsel auf eine andere Größe. Wer sie als Umrechnungsfaktor behandelt, erzeugt systematisch falsche Kennwerte. Die Quellenlage ist hier zudem in Teilen offen: Eine an die Wohnfläche gekoppelte Nettogrundfläche liegt rund 9 bis 23 Prozent unter der Gebäudenutzfläche A_N, und der Trinkwarmwasser-Kennwert wird je nach Bezug unterschiedlich angegeben — 12,5 kWh/(m²·a) auf A_N nach § 20 GMoDG gegenüber zurückgerechneten Werten auf die Nettogrundfläche, die in den Quellen ausdrücklich als nicht belegt gelten. Ein Datenmodell, das die Bezugsfläche mitsamt Bezugssystem speichert, übersteht diese Unschärfe; eines mit einem einzigen Flächenfeld nicht.

Das vorhandene System folgt diesem Grundsatz. Die kanonische Bezugsfläche ist ein eigenes, benanntes Feld mit Quellenangabe; Gebäudenutzfläche, Wohnfläche, Bruttogrundfläche und ein früher dreifach belegtes allgemeines Nutzflächenfeld sind als Ersatz unzulässig. Fehlt die Bezugsfläche, meldet die Bilanz eine Lücke, statt einen Ersatzwert zu setzen. Der CAD-Editor rechnet nach DIN 277 mit den Beziehungen Bruttogrundfläche gleich Konstruktions-Grundfläche plus Netto-Raumfläche sowie Netto-Raumfläche gleich Nutzungsfläche plus Verkehrsfläche plus Technikfläche und ermittelt die Raumflächen polygongenau statt über umschreibende Rechtecke. Wohnfläche und A_N werden dort bewusst nicht aus dem Grundriss abgeleitet, weil beide anderen Regelwerken folgen als der Raumgeometrie.

Geometrische Bauteile

Aus Flächengrößen allein entsteht noch kein Gebäudemodell. Dafür wird die Hülle in geometrische Elemente zerlegt, die jeweils eine eigene Identität und eine Zuordnung zu einer angrenzenden Zone oder zum Erdreich erhalten.

Damit entsteht ein geometrisches Gebäudemodell, das sich später mit IFC- und BIM-Daten verbinden lässt. Im vorhandenen System sind Geometrie und Bauteile im Steckbrief und im CAD-Editor erfasst und werden von den Rechenkernen verwendet; als eigenständige, verlinkte Knoten des Passes führt sie das Pflichtenheft jedoch erst als teilweise umgesetzt. Der IFC-Weg besteht als Eingang ohne Ausgang: Ein CAD-Modell kann eingelesen werden, ein vollwertiger IFC-Export ist nicht vorhanden.

4.6 Nutzung und Zonierung

Für die Bilanzierung nach DIN V 18599 ist insbesondere bei Nichtwohngebäuden die Zonierung entscheidend. Nutzungsunterschiede, technische Ausstattung, innere Lasten und Tageslichtversorgung führen dazu, dass sich Räume energetisch unterschiedlich verhalten und getrennt bilanziert werden müssen. Die EPBD setzt dieselbe Struktur voraus, wenn sie in den Mindest-Rohdaten je Ausweis die Aufschlüsselung der Bezugsfläche bei Mischnutzung und den nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Anlagentechnik disaggregierten Bedarf verlangt. Beides ist ohne Zonenmodell nicht darstellbar.

Jede Zone erhält deshalb eine dauerhafte Kennung — etwa Zone 01 Büro, Zone 02 Besprechung, Zone 03 Verkehrsfläche, Zone 04 Lager, Zone 05 Sanitär. Diese Kennung ist der Anknüpfungspunkt, über den Anlagen, Messstellen, Maßnahmen und Dokumente später mit einem konkreten Gebäudebereich verknüpft werden.

Der eigentliche Fortschritt liegt darin, dass die Zonierung nicht mehr Bestandteil einer einzelnen Berechnung ist, sondern Teil des dauerhaften Gebäudemodells; sie steht dann für Heizlast, sommerlichen Wärmeschutz, Kühllast, Sanierungsplanung und Betriebsdatenauswertung gleichermaßen zur Verfügung. Das vorhandene System führt das Nutzungsprofil inzwischen unter genau einem kanonischen Namen je Gebäude und je Zone. Der Weg dorthin ist lehrreich: Vor der Vereinheitlichung trug dieselbe Größe an vier Stellen vier verschiedene Feldnamen, mit der Folge, dass die zonenweise Bilanz für Nichtwohngebäude in keinem einzigen Projekt tatsächlich griff. Der Fehler lag nicht im Rechenkern, sondern im Datenmodell.

Gemischt genutzte Gebäude

Besondere Bedeutung erhält die Struktur bei gemischt genutzten Gebäuden. Der Gebäudepass benötigt dafür eine Hierarchie: Das Gesamtobjekt bleibt eine wirtschaftliche und dokumentarische Einheit, während darunter ein Gebäudeteil als Wohngebäude und ein weiterer als Nichtwohngebäude geführt wird, der seinerseits in Zonen für Büro, Verkauf und Lager zerfällt. Nur so lassen sich unterschiedliche Anforderungsniveaus, getrennte Ausweise und eine aufgeschlüsselte Bezugsfläche abbilden, ohne die Immobilie künstlich zu zerlegen.

Ein Hinweis zur Zitierweise gehört an diese Stelle. Die Abgrenzung zwischen Wohn- und Nichtwohngebäudeteilen bei gemischter Nutzung war in § 106 GEG geregelt; nach der Neunummerierung durch das GMoDG trägt § 106 die Solarpflicht mit ihren Stufen ab 2027. Ein Paragrafenverweis ohne Rechtsstand ist im Datenmodell damit unbrauchbar. Der Gebäudepass speichert Rechtsverweise deshalb nur zusammen mit dem Rechtsstand, unter dem sie gelten — technisch als Registry, die zwischen den Ständen umschaltet und Lücken ausdrücklich als Lücken führt.

4.7 Gebäudehülle und Bauteildatensätze

Auf der Hüllebene erhält jedes Bauteil einen eigenen Datensatz. Der Grund ist regulatorisch: Die Mindest-Rohdaten, die nach Artikel 20 Absatz 8 EPBD je Ausweis in die Gebäudedatenbank gelangen, umfassen ausdrücklich Fläche und U-Werte der Hauptbauteile, und Anhang V EPBD nennt mittlere U-Werte und Verglasungstyp als weitere Indikatoren. Er ist ebenso praktisch: Ein Bauteil ist die kleinste Einheit, an der Sanierungsmaßnahme, Nachweis, Rechnung und Materialangabe gemeinsam ansetzen.

Entscheidend ist Feld 05.12. Wer nur den U-Wert speichert, kennt das Ergebnis, aber nicht seine bauliche Ursache. Mit dem Schichtaufbau lassen sich Ökobilanz, Wärmebrückennachweis, Sanierungsplanung und Materialbewertung bedienen, ohne das Bauteil erneut aufzunehmen. Die Felder 05.07 und 05.08 werden getrennt geführt, weil Heizlastauslegung und Bilanz den sanierten Zustand brauchen, die Maßnahmendokumentation dagegen den Ausgangszustand. Das vorhandene System trennt diese Werte bereits auf Feldebene, führt die Wärmebrücken in einem eigenen Zweig und legt die Heizlast seit August 2026 auf den sanierten Zustand aus; der Wärmeschutznachweis prüft die U-Werte je Bauteilzeile gegen die Anforderungswerte der Anlage 7 zum GEG und zeigt das Ergebnis als Ampel. Zu beachten ist, dass die Ausgabe DIN/TS 18599:2025-10 in Teil 2 den pauschalen Wärmebrückenzuschlag der Kategorie B auf 0,03 W/(m²K) verändert und einen projektbezogenen Zuschlag einführt — ein weiterer Grund, den Zuschlag als Feld mit Normbezug zu speichern und nicht als Konstante im Rechenweg.

Fenster und transparente Bauteile

Fenster benötigen einen deutlich detaillierteren Datensatz als opake Bauteile, weil sie gleichzeitig Verlust- und Gewinnfläche sind und in mehrere Nachweise zugleich eingehen. Die Angaben zu Verglasungstyp und Sonnenschutz bedienen unmittelbar die Indikatoren „Verglasungstyp" und „Überhitzungsrisiko" nach Anhang V Nummer 2 EPBD.

Der Gewinn liegt in der Mehrfachnutzung: Derselbe Fensterdatensatz bedient die Bilanz nach DIN V 18599, den sommerlichen Wärmeschutz, Heizlast, Kühllast, Sanierungsplanung und Ökobilanz. Im vorhandenen System zeigt der Pass eine eigene Auswertung der Fensterorientierung, und die Wirkungskette ist so verdrahtet, dass die Freigabe geänderter Fensterdaten dreizehn nachgelagerte Aufgaben auslöst. Damit ist erreicht, was ein Bauteildatensatz leisten soll: Eine Änderung an einem Ort wird an allen abhängigen Stellen sichtbar, ohne dass jemand sie manuell nachzieht.

4.8 Technische Anlagen

Die technische Gebäudeausrüstung benötigt eine eigene Objektstruktur. Artikel 16 EPBD verlangt für Eigentümer, Mieter und Verwalter direkten und kostenlosen Zugriff auf Gebäudesystemdaten und benennt als Mindestumfang die Bauteil-Performance, die gebäudetechnischen Dienste, die Lebensdauerprognose der Heizung, die Gebäudeautomation, die Zähler, die Mess- und Regelgeräte sowie die Ladepunkte. Anhang V Nummer 2 EPBD ergänzt die Restlebensdauer von Heizung und Klimaanlage sowie die Machbarkeit eines Niedertemperaturbetriebs.

Zwei Felder verdienen eine Erläuterung. Feld 06.09 bedient die Empfehlungslogik des Ausweises: Die Kommissions-Leitlinien nennen Richtwerte für die Restlebensdauer von sieben bis fünfundzwanzig Jahren bei Heizungen, zwanzig bis fünfundzwanzig bei Wärmepumpen und zehn bis fünfzehn bei Klimaanlagen und verlangen, bei etwa zwei Jahren Restlebensdauer fossilfreie Alternativen zu benennen. Ohne gespeichertes Einbaujahr ist diese Empfehlung nicht erzeugbar. Feld 06.01 mit den Auslegungstemperaturen bedient die Niedertemperaturfähigkeit, die als Ja-Nein-Feld im Ausweis auszuweisen ist; die Leitlinien definieren sie über eine Auslegungstemperatur von höchstens 45 Grad Celsius beziehungsweise einen saisonalen Wert von höchstens 42 Grad Celsius und schreiben ein vierstufiges Prüfverfahren von der Heizlast über Heizkörperleistung und Volumenstrom zur Systemtemperatur vor.

Für die Gebäudeautomation gilt eine Besonderheit. Die maßgebliche Leistungsschwelle ist in den Quellen nicht eindeutig: Belegt sind 290 Kilowatt für die Automationspflicht bei Nichtwohngebäuden und die dreijährige Inspektion sowie 70 Kilowatt für die Frist zum 31.12.2029 und die fünfjährige Inspektion; ein dritter kursierender Wert von 100 Kilowatt ist ohne Rechtsgrundlage. Die Arbeitsregel lautet deshalb, die Schwelle nicht als Konstante über den Programmcode zu verteilen, sondern als einen Parameter mit Herkunftsangabe zu führen und in jeder Ausgabe die verwendete Schwelle zu nennen. Das vorhandene System setzt genau das um.

Anlagen brauchen Beziehungen

Anlagen dürfen nicht isoliert gespeichert werden. Eine Liste technischer Geräte ist noch kein energetisches Gebäudemodell; erst die Beziehung macht sie dazu. Die Software muss wissen, welche Anlage welche Zone versorgt: Eine Wärmepumpe WP-01 versorgt etwa die Heizung der Zonen 01 und 02 sowie das Trinkwarmwasser des gesamten Gebäudes, während ein Splitgerät ausschließlich die Kühlung der Zone 03 übernimmt. Aus diesen Kanten ergeben sich Deckungsanteile, Verteilverluste und die Zuordnung von Verbrauchswerten zu Systemen.

Im vorhandenen System ist diese Beziehungsschicht als eigene Datenschicht umgesetzt. Ein Objektgraph führt die Kanten „belegt_durch" für den Nachweis, „beeinflusst" für die fachliche Wirkung und „ersetzt" für die Ablösung eines Wertes. Eine Abhängigkeitsschicht bildet darauf die Wirkkette vom Bauteil über U-Wert und Heizlast zu den Bilanzgrößen, weiter zu Wärmeschutznachweis und Ausweis, zu den CO₂-Werten und schließlich zum Bewertungsindex und zum Finanzierungsbericht ab. Eine Neuberechnungsschicht bildet je Eingabebereich einen Fingerabdruck, erkennt daraus die betroffenen Auswertungen, markiert den Pass als veraltet und stößt die Rechenkette an.

Erneuerbare Erzeuger

Erneuerbare Erzeuger erhalten eigene Datenobjekte, weil sie energetisch wie wirtschaftlich ausgewertet werden und weil Anhang V Nummer 1 EPBD den Anteil erneuerbarer Energie aus Erzeugung am Gebäude als Pflichtangabe der Ausweis-Titelseite führt. Für das Nullemissionsgebäude nach Artikel 11 EPBD kommt hinzu, dass exportierter Solarstrom mit einem Primärenergiefaktor von −0,9 angerechnet werden darf, gekappt bei netto Null — eine Rechnung, die ohne getrennt gespeicherte Erzeugungs-, Eigenverbrauchs- und Einspeisemengen nicht führbar ist. Vorzusehen sind Objekte für Photovoltaik, Solarthermie, Batteriespeicher, Wärmepumpen, Biomasse und Geothermie; für eine Photovoltaikanlage sind das Leistung in Kilowatt-Peak, Modulfläche, Orientierung, Neigung, Wechselrichter, Speicher, Eigenverbrauchsanteil, Ertrag und Inbetriebnahmejahr.

4.9 Energiebilanz und Berechnungszustand

Hier liegt einer der wesentlichen Unterschiede zwischen digitaler Gebäudeakte und Gebäudepass. Eine Akte enthält das Ergebnis einer Berechnung als Dokument; der Pass speichert den Berechnungszustand selbst — Eingangsdaten, Randbedingungen und Ergebnisse in einer Form, aus der sich die Rechnung nachvollziehen und wiederholen lässt. Genau das verlangt Artikel 20 Absatz 8 EPBD für die Registrierung: den vollständigen Ausweis einschließlich aller Berechnungs-Eingangsdaten. Dänemark und Portugal ziehen daraus bereits die Konsequenz und speichern keine PDF-Dokumente mehr; der Ausweis wird aus den Rohdaten erzeugt.

Zum Berechnungszustand gehören drei Gruppen: erstens die Eingabedaten aus Gebäudehülle, Geometrie, Zonen, Anlagen, Nutzungsprofilen und Randbedingungen; zweitens die Berechnungsinformationen aus Normausgabe, Rechtsstand, Softwareversion, Berechnungsdatum und Bearbeiter; drittens die Ergebnisse aus Nutz-, End- und Primärenergie, CO₂-Emissionen, Transmissions-, Lüftungs- und Anlagenverlusten sowie regenerativen Deckungsanteilen.

Die zweite Gruppe verdient besondere Aufmerksamkeit, weil Normstand und Rechtsstand auseinanderfallen. Die Reihe wurde 2025 technisch als DIN/TS 18599:2025-10 neu herausgegeben, geändert wurden dabei nur die Teile 1, 2 und 10; die Teile 3 bis 9 und 11 blieben unverändert. Für Energieausweise und öffentlich-rechtliche Nachweise wird weiterhin nach DIN V 18599:2018-09 gerechnet, weil nur diese Ausgabe die öffentlich-rechtliche Grundlage bildet; eine Technische Spezifikation ist keine GEG-Grundlage, Ergebnisse daraus sind Vergleichsrechnung. Dasselbe gilt für die Faktoren: Der Anhang der Norm 2025 nennt für Strom andere Primärenergie- und Verdrängungswerte als die Anlagen zum GEG, maßgeblich bleiben die Werte des Gesetzes. Der Gebäudepass führt Normstand und Rechtsstand deshalb als zwei getrennte Felder, und jede Ausgabe, die das System verlässt, benennt die gerechnete Normfassung. Das vorhandene System hält dafür zwei Registries vor — eine für den Normstand mit den Ständen 2018-09 und 2025-10, eine für den Rechtsstand mit den Ständen 2026 und 2027 —, jeweils mit ausgewiesenen Lücken und einem Rechtsstandstempel an jedem Ergebnis.

Der Berechnungs-Snapshot

Für jede offizielle Berechnung wird ein unveränderlicher Snapshot erzeugt. Er beantwortet eine Frage, die in Prüf-, Förder- und Streitverfahren regelmäßig auftritt: Mit welchen Gebäudedaten wurde dieser Energieausweis oder dieser Förderantrag tatsächlich gerechnet? Ohne Snapshot ist sie nicht beantwortbar, weil sich der Gebäudedatensatz seither verändert hat.

Der Snapshot ist das Bindeglied zwischen Datenmodell und Nachweisführung: Er friert einen Zustand ein, während der lebende Datensatz weiterläuft. Das vorhandene System erzeugt für den veröffentlichten Pass einen bereinigten Snapshot mit Versionsstand und Signaturfeld und erkennt über einen Prüfsummenvergleich, wenn ein abgelegtes Dokument und die aktuellen Daten auseinanderlaufen; die Energieausweis-Kachel warnt dann vor der Abweichung der Endenergie. Sieben Dokumenttypen werden automatisch neu erzeugt, sobald sich ihre Datengrundlage ändert. Eine qualifizierte elektronische Signatur je Freigabe ist dagegen nicht implementiert und im Datenmodell als offener Punkt geführt.

4.10 Der Energieausweis als Datensatz

Der Energieausweis erhält im Gebäudepass einen eigenen Datensatz, nicht bloß einen Dateianhang. Die Begründung liefert Anhang V EPBD mit fünf Pflichtangaben der Titelseite und einer Reihe weiterer Pflichtfelder sowie Artikel 19 Absatz 14 EPBD, der vereinfachte Aktualisierungen zur Pflicht macht — nach einer Einzelmaßnahme, nach umgesetzten Schritten eines Renovierungspasses und über einen digitalen Zwilling oder zertifizierte Werkzeuge. Buchstabe c dieser Vorschrift ist die ausdrückliche Rechtsgrundlage dafür, dass ein Gebäudepass als Datenquelle des Ausweises dient. Vereinfachte Aktualisierung setzt allerdings voraus, dass der Ausweis als strukturierter Datensatz und nicht als abgeschlossenes Dokument vorliegt.

Drei Anmerkungen dazu. Erstens ist die Skala A bis G seit dem 29.05.2026 verbindlich und geschlossen; Klasse A ist dem Nullemissionsgebäude vorbehalten, sodass ein Gebäude mit fossilem Kessel, das rechnerisch A erreichen würde, auf B eingestuft wird. Zweitens ist Feld 09.23 heute ein Platzhalter: Eine SRI-Pflicht entsteht erst durch einen delegierten Rechtsakt bis zum 30.06.2027 und dann nur für Nichtwohngebäude oberhalb von 290 Kilowatt. Drittens folgt Feld 09.11 einer eigenen Fristenlogik, die Abschnitt 4.14 behandelt.

Der Pass bewahrt nicht nur den aktuellen Ausweis, sondern führt eine Historie und macht damit die energetische Entwicklung eines Gebäudes über Jahrzehnte sichtbar. Eine Bedingung ist dabei einzuhalten: Klassenangaben aus verschiedenen Skalen dürfen nicht ohne Kennzeichnung der Skala in einer Zeitreihe stehen. Ein vor 2026 ausgestellter deutscher Ausweis trägt eine andere Klassenskala als die geschlossene Skala A bis G; ohne Skalenkennzeichnung ist der Vergleich irreführend. Das Datenmodell speichert deshalb zu jeder Klassenangabe die Skala, unter der sie vergeben wurde.

Im vorhandenen System ist die Ausweisebene teilweise umgesetzt. Der Pass erzeugt bei vollständigem Energiekern automatisch einen Bedarfsausweis, bildet Effizienzklassen ab und legt bei geänderter Endenergie eine neue Version an. Ausdrücklich offen sind die vollständige Abbildung der Ausweisarten, die Gültigkeitsführung, die Registriernummer und die getrennte Übernahme der CO₂-Werte aus dem Ausweis. Hinzu kommt, dass das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG und das Datenformat des Lebenszyklusberichts nach § 88b GMoDG zum Quellenstand nicht vorliegen. Solange das so ist, kann der Pass die Felder strukturell vorhalten, aber keine formatkonforme amtliche Ausgabe erzeugen.

4.11 Verbrauchs- und Betriebsdaten

Eine eigene Datenebene bildet den Unterschied zwischen berechnetem Bedarf und tatsächlichem Verbrauch ab. Sie ist aus zwei Richtungen gefordert: Artikel 22 EPBD nennt berechneten wie gemessenen Verbrauch als Quelle der nationalen Datenbank, und Anhang V Nummer 2 EPBD führt den gemessenen Verbrauch als Indikator des Ausweises. Praktisch entscheidend ist die deutsche Umsetzung: § 80 GMoDG verlangt beim Verbrauchsausweis für Wohngebäude keine drei Abrechnungsperioden über 36 Monate mehr, sondern eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate. Das ist keine Verkürzung, sondern eine Verdichtung — aus drei Jahressummen werden 24 Monatswerte je Energieträger. Ein Datenmodell, das Verbräuche als Jahressumme speichert, erfüllt diese Anforderung nicht.

Die Felder 10.10 und 10.11 sind der Grund, warum ein Soll-Ist-Vergleich nicht trivial ist. Berechneter Bedarf und gemessener Verbrauch beruhen auf unterschiedlichen Randbedingungen — Standardnutzung gegen tatsächliche Nutzung, Referenzklima gegen tatsächliche Witterung. Ein Vergleich ohne diese Korrekturangaben erzeugt Scheinabweichungen und beschädigt das Vertrauen in beide Zahlen. Das Beiblatt 1 zur DIN/TS 18599 adressiert genau diesen Bedarfs- und Verbrauchsabgleich und verbindet damit das normative Gebäudemodell mit den tatsächlichen Messdaten.

Im vorhandenen System besteht eine Verbrauchshistorie, deren Auswertung im Pass angezeigt wird, sowie ein Umschalter zwischen dem bisherigen Verfahren mit 36 Monaten und dem künftigen mit 24 Monatswerten. Das amtliche Kontrolldateischema für Monatswerte liegt allerdings noch nicht vor; bis dahin sind Monatszeilen im bisherigen Periodenformat zu übergeben. Ebenfalls offen ist die Verwendung gemessener Verbräuche und tatsächlicher Photovoltaikerträge in der CO₂-Auswertung, die heute mit Pauschalwerten arbeitet. Für dynamische Daten vernetzter Produkte gilt zudem eine andere Rechtsgrundlage: Artikel 16 EPBD erfasst statische Daten, dynamische fallen unter den Data Act, Abrechnungszähler unter die Strom- und Gasrichtlinien.

4.12 Sanierungshistorie und Renovierungsfahrplan

Jede relevante Veränderung des Gebäudes wird als Ereignis gespeichert, nicht als Überschreibung des betroffenen Werts. Ein Fenstertausch am 15.06.2025 ist demnach ein Datensatz mit Ausgangszustand — etwa U_w gleich 2,7 W/(m²K) —, Zielzustand von 0,85 W/(m²K), Kosten von 42.500 Euro, Förderung von 8.500 Euro sowie den zugehörigen Dokumenten aus Rechnung, Produktdatenblatt, Fotos und Förderbescheid. Der Bauteildatensatz nach Tabelle 4.7 erhält dadurch eine neue Version, während die alte erhalten bleibt; über die Jahre entsteht so die Chronik des Gebäudes. Anhang VIII Nummer 2 EPBD führt die Renovierungshistorie als optionalen Bestandteil des Renovierungspasses — im Datenmodell ist sie die Voraussetzung dafür, dass ein späterer Fahrplan auf einem belastbaren Ausgangszustand aufsetzt.

Hier verbinden sich Ist-Zustand und Zukunft. Der Renovierungspass nach Artikel 12 EPBD ist der Fahrplan von der Baseline zum Endzustand; Zielzustand ist vor dem 01.01.2030 das Niedrigstenergiegebäude und ab dem 01.01.2030 das Nullemissionsgebäude, und ist beides nicht machbar, gilt eine Primärenergiereduktion von mindestens 60 Prozent als Rückfallschwelle. Anhang VIII Nummer 1 Buchstabe e verlangt für jeden Schritt fünf Pflichtfelder; die folgende Tabelle bildet das als Datensatz je Maßnahme ab.

Aus diesen Maßnahmen entsteht eine Kette, die typischerweise vom Ausgangszustand über Wärmeerzeuger, Fenster, Fassade und Photovoltaik zum Zielzustand führt. Feld 12.10 ist dabei mehr als Terminplanung: Anhang VIII EPBD verlangt die Begründung der Schrittfolge ausdrücklich zur Vermeidung von Lock-in-Effekten, und die Leitlinien empfehlen für das Experten-Werkzeug automatische Lock-in-Warnungen. Ein Datenmodell, das Abhängigkeiten zwischen Maßnahmen speichert, kann solche Warnungen erzeugen; eine Maßnahmenliste ohne Abhängigkeiten nicht.

Für die deutsche Praxis ist die Abgrenzung zum individuellen Sanierungsfahrplan wichtig. Der iSFP wird in der Renovierungspass-Leitlinie zweimal als Best-Practice-Vorbild genannt, insbesondere wegen der Einseiten-Grafik und der Förderhinweise je Schritt. Er ist damit kein Renovierungspass im Sinne des Artikels 12 EPBD, sondern ein Vorbild; nicht abgedeckt sind die Pflichtfelder zur Änderung der operativen Treibhausgase, zur Zirkularität und zum Lebenszyklus-Kohlenstoff sowie die Liste der nationalen Stichtage. Ob Deutschland den iSFP formal zum Renovierungspass erklärt, ist nicht entschieden. Im vorhandenen System besteht ein iSFP-Datenblatt als reine Ausgabe; ein förderfähiger iSFP entsteht ausschließlich in der amtlichen Druckapplikation der BAFA, ein maschinelles Importformat dafür wird nicht veröffentlicht. Eine durchgehende Zeitleiste im Pass führt das Pflichtenheft als offenen Punkt.

4.13 Fördermittel, Kosten und Wirtschaftlichkeit

Fördermittel gehören nicht als Dokument in eine Ablage, sondern als Prozess an die Maßnahme: Maßnahme, Förderprogramm, Antrag, Zusage, Durchführung, Rechnung, Bestätigung, Auszahlung. Erst wenn diese Stationen als Felder existieren, lässt sich je Maßnahme nachvollziehen, welches Programm genutzt wurde, wann beantragt wurde, welcher Förderstand galt, welche Kosten angesetzt, welcher Betrag bewilligt und welcher ausgezahlt wurde. Anhang VIII Nummer 1 Buchstabe i EPBD verlangt für den Renovierungspass Angaben zur Förderung mit Verweisen; Nummer 2 ergänzt die Amortisation mit und ohne Förderung als optionale Angabe.

Ein Punkt verdient besondere Beachtung: Förderregeln selbst müssen versioniert werden. Förderbedingungen ohne Gültigkeitsdatum fest im Programmcode zu hinterlegen, ist der häufigste Grund dafür, dass eine ältere Berechnung Jahre später nicht mehr reproduzierbar ist. Feld 13.02 ist deshalb kein Verwaltungsdetail, sondern die Voraussetzung dafür, dass eine Wirtschaftlichkeitsrechnung von 2026 im Jahr 2032 noch nachvollziehbar bleibt. Dasselbe gilt für die Annahmen der Felder 14.08 und 14.09: Anhang VIII Nummer 4 EPBD verlangt, dass alle Schätzungen auf offengelegten Standardbedingungen beruhen.

Im vorhandenen System bestehen ein Förder- und Wirtschaftlichkeitsrechner mit Variantenvergleich und Tilgungsplan, ein Kostenmodul für Neubau und Sanierung mit eigener Spalte für Sowieso-Anteile sowie eine gepflegte Fördermatrix. Die Förderebene führt das Pflichtenheft allerdings als nur teilweise umgesetzt, die Spalte für Sowieso-Anteile ist in keinem Projekt befüllt, und der Leistbarkeits-Check ist nicht an den Projektdatenspeicher angebunden. Feld 14.03 existiert also, wird aber nicht genutzt — ein Beispiel dafür, dass ein vorhandenes Feld noch keine gelebte Datenhaltung ist.

4.14 Lebenszyklus, GWP und Ressourcen

Die nächste Ebene erweitert die Betrachtung über die Betriebsenergie hinaus. Artikel 7 EPBD in Verbindung mit Anhang III in der Fassung der Delegierten Verordnung (EU) 2026/52 legt einen festen Rahmen fest: Systemgrenzen nach EN 15978, Bezugszeitraum 50 Jahre, Einheit Kilogramm CO₂-Äquivalent je Quadratmeter Nutzfläche und Bilanzstand „as built", also Schätzung vor Baubeginn und Bestätigung danach. Die Pflichtfristen sind gestaffelt: ab dem 01.01.2028 für Neubauten über 1.000 Quadratmeter, ab dem 01.01.2030 für alle Neubauten; die Mitgliedstaaten legen bis zum 01.01.2027 einen Fahrplan vor, erste Grenzwerte gelten spätestens ab 2030 und werden danach degressiv verschärft. Für den Bestand besteht keine GWP-Pflicht; Ausnahme ist die Sanierung auf die freiwillige Klasse A+, bei der der GWP-Ausweis Pflicht wird.

Damit die Module rechenbar werden, benötigen Bauteile und Anlagen zusätzliche Felder: Material, Masse, Lebensdauer, Austauschzyklen, Umweltproduktdeklaration, Herstellungs-, Nutzungs- und Entsorgungsphase, Wiederverwendbarkeit und Recyclingfähigkeit. Die Datenhierarchie ist vorgegeben — Angaben nach der Bauprodukteverordnung stehen vor Ökodesign-Daten, diese vor projekt- oder produktspezifischen, diese vor generischen Datensätzen und diese vor Standardwerten. Hier zeigt sich der Vorteil einer strukturierten Bauteilebene: Wenn Wandaufbauten, Fenster, Dämmstoffe und Anlagen bereits nach den Tabellen 4.7 bis 4.9 erfasst sind, muss für die Ökobilanz nicht erneut aufgenommen werden, was ohnehin vorliegt. Rohdatenbasis ist die Mengenliste des Gebäudes, die sich aus BIM- und IFC-Daten extrahieren lässt; die Leitlinien führen dafür in Annex 13 ein „Standard-Gebäudedokument" als maschinenlesbare Feldliste mit Projektkennung, Typologie, Bewertungstyp, Flächen, Koordinaten, GWP je Modul, biogenem Kohlenstoff, Datenqualitätsmetrik und Photovoltaik-Szenario.

Im vorhandenen System besteht ein Ökobilanz-Werkzeug, das für Nichtwohngebäude den projektspezifischen Anforderungswert des Qualitätssiegels gegen eine amtlich verifizierte Wertetabelle rechnet; im Pass ist eine entsprechende Kachel aktiv. Die eigentliche Lebenszyklusrechnung ist erst teilweise umgesetzt: Die vorhandene Auswertung kombiniert den Betrieb mit einem geschätzten Benchmark für graue Emissionen, während die Berechnung aus Bauteilflächen, Materialmengen und EPD-Datensätzen sowie die Unterscheidung zwischen Neubau- und Sanierungsbilanz offen sind. Das Datenformat für den Lebenszyklusbericht nach § 88b GMoDG liegt zudem nicht vor. Feld 09.11 der Ausweisebene bleibt daher eine strukturell vorgesehene, inhaltlich noch nicht amtlich belegbare Angabe.

4.15 ESG- und Finanzierungssicht

Diese Ebene erzeugt aus den technischen Daten einen finanzierungsfähigen Evidenzdatensatz. Regulatorischer Anknüpfungspunkt ist Artikel 22 EPBD, der Finanzinstituten für Portfoliozwecke eine eigene Zugriffsstufe einräumt und ihnen den kostenlosen vollständigen Ausweis maschinenlesbar und als Druckdokument zusichert. Was ein Institut daraus baut, ist keine Energieklasse, sondern ein Risikobild.

Sechs Informationsblöcke genügen dafür: erstens der energetische Status mit Effizienzklasse, End- und Primärenergie sowie Emissionen; zweitens der Transformationsbedarf, also die notwendigen Maßnahmen; drittens der Sanierungs-Kapitalbedarf; viertens die Zeitachse, zu der diese Investitionen fällig werden; fünftens die Datenqualität, also die Auskunft darüber, ob die Werte gemessen, berechnet, dokumentiert oder geschätzt sind; sechstens die Nachweise. Für den vierten Block greift unmittelbar der Bestandspfad nach Artikel 9 EPBD: Für Wohngebäude ist bis 2030 eine Reduktion um 16 Prozent gegenüber 2020 vorgesehen, und mindestens 55 Prozent dieser Reduktion müssen aus den 43 Prozent schlechtesten Gebäuden stammen. Daraus folgt unmittelbar ein Datenfeld — ein Kennzeichen, ob ein Gebäude zu diesem Segment gehört.

Der fünfte Block ist der eigentliche Unterschied zu einer Energieklassenmeldung. Eine Bank, die zwei Gebäude mit identischer Klasse vergleicht, von denen das eine auf geprüften und das andere auf geschätzten Daten beruht, trägt zwei sehr verschiedene Risiken; erst die Offenlegung der Datenqualität macht das sichtbar. Im vorhandenen System ist die Wirkkette bis zu einem Finanzierungsbericht verdrahtet, der zu den automatisch erzeugten Dokumenten gehört, und ein Bewertungsindex führt Datenqualität und Dokumentationsqualität als eigene gewichtete Säulen. Die Kennwertansicht kennt zudem eine Anzeigerolle für Banken, die ausschließlich die Darstellung ordnet; die Zugriffsentscheidung trifft seit dem 23. August 2026 daneben die Bankenrolle der Rechteschicht mit einem eigenen, befristeten Zugang auf einen festgelegten Ausschnitt. Das abgestufte Zugriffsrollenmodell ist damit vorhanden; offen bleiben getrennte Freigabepakete je Empfängertyp, also die Auswahl einzelner Felder für einen bestimmten Empfänger über den Zuschnitt seiner Rolle hinaus.

4.16 Dokumente und Nachweise

Dokumente werden weiterhin vollständig gespeichert: Baupläne, Berechnungen, Energieausweise, Rechnungen, Fotos, Förderbescheide, Fachunternehmererklärungen, Wartungsnachweise, Bedienungsanleitungen und Prüfberichte. Der Unterschied zur klassischen Ablage liegt nicht im Bestand, sondern in der Verknüpfung: Jedes Dokument wird mit dem Datenobjekt verbunden, das es belegt. Eine Wärmepumpe trägt damit Rechnung, Datenblatt, Inbetriebnahmeprotokoll, hydraulischen Abgleich, Foto und Förderbescheid als Kanten an sich. Der Nutzer findet dadurch nicht nur Dokumente, sondern versteht, wozu sie gehören — und die Software kann prüfen, ob ein behaupteter Wert überhaupt einen Beleg hat.

Diese Verknüpfung ist der Anknüpfungspunkt an Artikel 12 Absatz 8 EPBD: Wo ein digitales Gebäudelogbuch existiert, ist der Renovierungspass darin zu speichern oder über eine eindeutige Adresse zugänglich zu machen; die Legaldefinition steht in Artikel 2 Nummer 41 EPBD. Wichtig ist die Abgrenzung: Die Richtlinie verlangt nicht, ein Logbuch einzuführen, sie knüpft nur konditional daran an, und Artikel 22 Absatz 7 EPBD fordert lediglich Interoperabilität. Ein Gebäudepass, der ein Logbuch im Sinne der Definition ist, erfüllt damit keine zusätzliche Pflicht, sondern schafft die Voraussetzung dafür, dass die konditionalen Vorschriften greifen können.

Im vorhandenen System besteht die Dokumentkante als Teil des Objektgraphen, und die Dokumentationsqualität geht mit 20 Prozent in den Bewertungsindex ein. Die Verdrahtung ist jedoch unvollständig: Die Säule „Wartungszustand" desselben Index bleibt auf null, solange Dokumente und Wartungen nicht verknüpft sind — ein Befund, der zum Datenmodell und nicht zur Bewertungslogik gehört.

4.17 Datenqualität, Vertrauensstufen und Datenzustände

Jeder wesentliche Datenwert erhält einen Qualitätsstatus. Ohne ihn ist ein Gebäudedatensatz eine Sammlung gleich aussehender Zahlen unterschiedlicher Belastbarkeit. Das Kontrollsystem nach Anhang VI EPBD setzt Vergleichbares voraus, wenn es Plausibilitätswarnungen beim Hochladen empfiehlt, und Artikel 20 Absatz 8 EPBD gewinnt seinen Sinn erst dadurch, dass die übergebenen Eingangsdaten als geprüft oder ungeprüft erkennbar sind.

Die Modellskizze dieses Whitepapers sah dafür sechs Stufen von Q0 bis Q5 vor. Das umgesetzte System arbeitet mit einer sechsstufigen Vertrauensskala von 0 bis 5, die anders geschnitten ist. Die folgende Tabelle stellt beide gegenüber; die Abweichung ist bewusst sichtbar gemacht, weil sie eine inhaltliche Entscheidung betrifft und nicht nur eine Benennung.

Die Unterschiede sind aufschlussreich. Der Modellentwurf ordnet die Stufen nach der Erkenntnisart und setzt die Messung an die Spitze; das umgesetzte System ordnet sie nach dem Grad der formalen Absicherung und setzt die amtliche Signatur an die Spitze. Die Messung ist dort keine Stufe, sondern eine von acht Herkunftskategorien — neben Dokument, Nutzereingabe, KI-Erkennung, Berechnung, Fachplaner, amtlicher Quelle und Annahme. Das umgesetzte Modell trennt also zwei Achsen, die der Entwurf in einer Skala vermischt: woher der Wert stammt und wie gut er abgesichert ist. Diese Trennung ist die tragfähigere Lösung und sollte beibehalten werden — ein aus einem Dokument erkannter Wert kann geprüft oder ungeprüft sein, eine Messung plausibel oder fehlerhaft. Beide Achsen sind als Herkunftsangabe je Wert und je Kante hinterlegt und werden für die Erklärbarkeit des Bewertungsindex ausgewertet. Einschränkend gilt, dass die Stufe „amtlich signiert" praktisch noch nicht erreichbar ist, weil digitale Signaturen je Freigabe als offener Punkt geführt werden.

Neben der Vertrauensstufe führt das umgesetzte System einen zweiten, davon unabhängigen Status: den Datenzustand. Er beschreibt nicht die Qualität eines Werts, sondern seine Stellung im Freigabeprozess.

Der Übergang von GEMELDET nach FREIGEGEBEN ist als Vier-Augen-Verfahren realisiert: Das Melden erzeugt einen Vorschlag im Arbeitsbereich und ändert den offiziellen Wert ausdrücklich nicht, erst die Freigabe schreibt in den führenden Pfad. Diese Trennung macht die Regel „nur freigegebene Werte gelangen in offizielle Berichte" überprüfbar statt bloß behauptet. Eine weitergehende Zielspezifikation mit neun Datenwert-Status — von verifiziert über Eigentümer bestätigt bis widersprüchlich und veraltet — ist Konzept und nicht implementiert; produktiv ist die Herkunftsplakette der Kennwertansicht.

Für die Anzeige der Datenlage verwendet das umgesetzte System keine frei gebildete Prozentzahl, sondern zwei belegte Größen: eine Vollständigkeitsprüfung über 23 Pflichtfelder in acht Kategorien, jeweils mit Priorität und Sprungziel, sowie die Datenqualität als Säule des Bewertungsindex mit einem Gewicht von 15 Prozent. Der Kennwertkatalog umfasst 43 Kennwerte, zeigt zu jedem eine Herkunftsplakette und stellt fehlende Werte als Strich dar. Fantasiewerte werden nicht erzeugt — eine Regel, die im Datenmodell mehr wiegt als jede Anzeigeoptimierung.

4.18 Historisierung und Versionierung

Kein bestehender Gebäudedatensatz darf einfach überschrieben werden. Diese Regel ist nicht nur gute Praxis, sondern regulatorisch unterlegt: Nach Anhang VI EPBD muss der Urheber jeder Hinzufügung oder Änderung für die Behörden ermittelbar sein. Ein Datenmodell, das den alten Wert beim Speichern verwirft, kann diese Anforderung grundsätzlich nicht erfüllen.

Wie daraus eine Gebäudebiografie entsteht, zeigt ein einzelner U-Wert. Version 1 lautet 1,20 W/(m²K) und ist geschätzt, Version 2 lautet 0,85 W/(m²K) und stammt aus dem Bauplan, Version 3 lautet 0,24 W/(m²K) und ist nach der Sanierung nachgewiesen. Der Wert hat sich dreimal geändert, aber nur einmal ist das Gebäude saniert worden — die ersten beiden Schritte sind Erkenntnisgewinn, der dritte ist bauliche Veränderung. Diese Unterscheidung ist nur ablesbar, wenn Änderungsgrund und Quelle mitgeführt werden, und sie verhindert, dass eine Kennwertentwicklung als Sanierungserfolg fehlgedeutet wird.

Im umgesetzten System ist die Wertversionierung Teil der Governance-Schicht, an die die Datenzustände nach Tabelle 4.17 gekoppelt sind. Der Projektdatenspeicher schreibt Änderungen an Ort und Stelle, sichert aber vor jedem Schreibvorgang eine Kopie in einem Sicherungsverzeichnis und schreibt nur bei tatsächlicher Änderung. Wertversionierung und projektweite Sicherung sind damit zwei getrennte Mechanismen; das ist konsistent, verlangt aber Sorgfalt bei der Frage, welcher Stand für einen Nachweis maßgeblich ist. Genau dafür existiert der Snapshot nach Abschnitt 4.9.

4.19 Maschinenlesbare Formate und Schnittstellen

Ein Gebäudepass darf kein geschlossenes System sein. Die EPBD verlangt für den Energieausweis Maschinenlesbarkeit in CSV, JSON oder XML, für die Datenbank nach Artikel 22 maschinenlesbare Formate zuzüglich einer digitalen Schnittstelle, für den Transfer an das europäische Building Stock Observatory mindestens einen jährlichen Datenlauf nach den Vorlagen der Durchführungsverordnung (EU) 2025/1328, und sie räumt in Artikel 16 den Berechtigten Zugriff auf Gebäudesystemdaten ein. Für den Renovierungspass gilt ein anderer Maßstab: Pflicht ist die digitale und druckfähige Form, Maschinenlesbarkeit in XML ist Empfehlung der Leitlinien, nicht Pflicht.

Die Tabelle zeigt ein Muster: Was innerhalb des eigenen Systems und in Richtung Nutzer gebraucht wird, ist weitgehend vorhanden; was auf externe Standards angewiesen ist, ist offen oder blockiert. Der wichtigste blockierte Punkt ist die Anbindung an die nationale Datenbank. Deutschland verfügt zum Quellenstand über keine nationale Energieausweis-Datenbank, das Schema nach Artikel 22 EPBD existiert nicht, und das amtliche Ausweismuster liegt nicht vor. Die saubere Unterscheidung ist hier wichtiger als der optimistische Ausblick: Liegen Recht und Spezifikation vor, ist eine Funktion umsetzbar; fehlt die Spezifikation, ist sie blockiert; ist etwas nur angekündigt, besteht keine Pflicht. Nach dieser Regel ist die Registeranbindung nicht offen im Sinne fehlender Entwicklung, sondern blockiert im Sinne fehlender Vorgabe.

Ein Ansatzpunkt für die Interoperabilität liegt in der Normung selbst. Ein standardisiertes normseitiges Ausgabeformat für den Austausch von Bilanzdaten zwischen Fachprogrammen ist in den ausgewerteten Quellen nicht belegt; die Interoperabilität ist deshalb bis auf Weiteres über eigene Exportprofile in CSV, JSON und XML zu führen — unabhängig davon, dass die Bilanz selbst weiterhin nach der Ausgabe 2018-09 zu rechnen ist.

4.20 Die Gesamtarchitektur des Datenmodells

Aus den zwanzig Ebenen ergibt sich eine Schichtung mit fester Reihenfolge. Am Anfang steht das reale Gebäude; es wird über drei Eingangsarten abgebildet: Dokumente, strukturierte Daten und Messwerte. Diese Eingänge durchlaufen die Qualitätssicherung, also die Zuordnung von Herkunft, Vertrauensstufe und Datenzustand nach Abschnitt 4.17. Erst danach folgt die Berechnungsebene mit Bilanz nach DIN V 18599, Heizlast, Ökobilanz, Wirtschaftlichkeit und CO₂-Werten. Darauf setzt die Planungsebene mit Sanierungsvarianten, Sanierungsfahrplan, Renovierungspass und Förderung auf. Deren Ergebnisse münden in die Nachweisebene mit Energieausweis, Förderbestätigung und technischen Nachweisen, aus der sich die Wirtschaftsebene mit Kosten, Immobilienwert, ESG-Angaben und Finanzierung speist. Am Ende steht die Austauschebene gegenüber Behörden, Registern, Banken, Käufern, Planern und Energieberatern.

Die Reihenfolge ist nicht beliebig: Keine Berechnung findet vor der Qualitätssicherung statt und keine Ausgabe vor der Nachweisebene. Wo sie durchbrochen wird — etwa weil ein Werkzeug direkt in ein Ergebnisfeld schreibt —, entstehen genau die Widersprüche, die der Vorbehalt in Abschnitt 4.17 beschreibt. Die Architektur ist deshalb weniger ein Bild als eine Prüfordnung.

Der entscheidende Unterschied

Mit diesem Datenmodell lässt sich präziser sagen, was der digitale Gebäudepass ist — und was er nicht ist. Er ist nicht nur ein Energieausweis, nicht nur ein Renovierungspass, nicht nur ein individueller Sanierungsfahrplan, nicht nur eine Dokumentenablage, nicht nur ein Bauwerksmodell, nicht nur eine Bilanz nach DIN V 18599 und nicht nur ein Nachhaltigkeits-Dashboard. Er ist die gemeinsame Dateninfrastruktur, auf der diese Anwendungen aufsetzen: Jede greift auf dieselben Bauteile, Anlagen, Flächen und Verbrauchswerte zu — mit demselben Qualitätsstatus und derselben Historie.

Kapitel 5 setzt darauf auf und ordnet dem Datenmodell die einzelnen EPBD-Instrumente zu — Energieausweis, Renovierungspass, Gebäudedatenbank, Datenaustausch, digitales Logbuch, Smart Readiness Indicator, Lebenszyklus-GWP, Inspektionsberichte und Nullemissionsgebäude. Die Funktionsarchitektur folgt in Kapitel 7, die technische Umsetzung der Schnittstellen aus Abschnitt 4.19 in Kapitel 8.

5 Vom digitalen Gebäudepass zum digitalen Zwilling

Ein digitaler Gebäudepass beginnt als geordnete Sammlung von Informationen zu einem Gebäude. Seine strategische Bedeutung entsteht erst dort, wo die Daten nicht nur abgelegt, sondern gerechnet, fortgeschrieben und mit dem realen Betrieb verglichen werden. Dieses Kapitel beschreibt diesen Weg als vier Reifegrade, benennt für jede Stufe die Voraussetzung und trennt dabei ausdrücklich, was die EPBD verlangt und was über die Richtlinie hinausgeht.

5.1 Der digitale Zwilling als funktionaler Begriff

Der digitale Gebäudepass ist zunächst eine strukturierte Informationsplattform für ein einzelnes Gebäude. Er sammelt technische, energetische, bauliche und wirtschaftliche Informationen und ordnet sie einem eindeutig identifizierten Gebäudedatensatz zu. Die eigentliche Entwicklung beginnt jedoch erst danach: Sobald die Gebäudedaten nicht nur dokumentiert, sondern für Berechnungen, Varianten, Prognosen und laufende Aktualisierungen verwendet werden, entwickelt sich der Gebäudepass schrittweise zu einem digitalen Zwilling. Aus einer Ablage wird ein Modell.

Der Begriff „digitaler Zwilling" ist dabei funktional zu verstehen. Es geht nicht um ein fotorealistisches dreidimensionales Abbild, sondern darum, dass das Modell die für Bewertung, Planung und Betrieb relevanten Eigenschaften des Gebäudes so strukturiert abbildet, dass Zustände, Änderungen und künftige Entwicklungen rechnerisch nachvollzogen werden können. Ein geometrisch grob beschriebenes Gebäude mit belastbaren Bauteil-, Anlagen- und Flächendaten ist in diesem Sinne ein besserer Zwilling als ein hochaufgelöstes Modell ohne energetische Kennwerte. Daraus folgen drei Anforderungen: Das Modell muss den Zustand zu einem bestimmten Zeitpunkt eindeutig beschreiben, Änderungen dieses Zustands erkennen und verarbeiten und die Herkunft jeder Angabe offenlegen. Ohne die dritte Eigenschaft entsteht kein Zwilling, sondern eine unüberprüfbare Datenmenge.

5.2 Vier Reifegrade

Die Entwicklung vom Dokumentenarchiv zum betriebsdatengestützten Modell verläuft in vier aufeinander aufbauenden Stufen. Jede setzt die vorhergehende voraus, und jede wird durch eine andere technische Hürde begrenzt. Diese Unterscheidung ist die Grundlage dafür, in der Entwicklungsplanung (Kapitel 14) zu trennen zwischen dem, was wirtschaftlich erreichbar ist, und dem, was von Voraussetzungen außerhalb der eigenen Plattform abhängt.

Stufe 1 — Digitale Gebäudeakte. Dokumente werden zentral gespeichert: Baupläne, Energieausweise, Rechnungen, Förderbescheide, technische Datenblätter, Fotos, Prüfberichte. Die Informationen bleiben jedoch in Dokumenten gebunden; sie sind lesbar, aber nicht rechenbar. Wer aus einem abgelegten Wärmeschutznachweis einen U-Wert benötigt, muss ihn abschreiben.

Stufe 2 — Strukturierter Gebäudepass. Die wesentlichen Informationen werden in Datenfelder überführt: eine Bezugsfläche von 182,4 m², ein Außenwand-U-Wert von 0,24 W/(m²K), ein Fenster-Uw von 0,85 W/(m²K), eine Wärmepumpenleistung von 8 kW, eine Photovoltaikleistung von 9,8 kWp. Wie in Kapitel 4 dargestellt, ist dabei die Feldkanonik entscheidend: Die Plattform führt die Bezugsfläche kanonisch als Nutzfläche nach DIN 277 mit eigener Quellenangabe; Wohnfläche, Bruttogrundfläche oder A_N sind kein Ersatz, weil es andere Größen sind.

Stufe 3 — Dynamisches Gebäudemodell. Änderungen am Gebäude werden unmittelbar in die Berechnungen übernommen: Wird ein Fenster ausgetauscht, eine Außenwand gedämmt oder eine Wärmepumpe eingebaut, ändert sich zunächst der Gebäudedatensatz, anschließend werden die abhängigen Ergebnisse neu erzeugt. Das Modell beantwortet damit erstmals systematisch die Frage, was sich verändert, wenn am Gebäude etwas verändert wird. Voraussetzung ist ein Abhängigkeitsmodell (Abschnitt 5.9).

Stufe 4 — Digitaler Zwilling. Das Modell wird zusätzlich mit dem tatsächlichen Betrieb verbunden; als Datenquellen kommen Smart Meter, Wärmepumpenregelungen, Wechselrichter, Batteriespeicher, Gebäudeautomation, Zählerstände sowie Temperatur- und Wartungsdaten in Betracht. Erst hier lässt sich der berechnete Zustand mit dem realen Betrieb vergleichen. Diese Stufe ist die einzige, deren Voraussetzungen überwiegend außerhalb der Plattform liegen (Abschnitt 5.3).

Die Tabelle zeigt eine Verschiebung, die für eigene Entwicklungsschritte wesentlich ist: Von Stufe 1 zu Stufe 3 wächst der Aufwand vor allem im Datenmodell und damit in der eigenen Verantwortung. Der Sprung auf Stufe 4 ist dagegen kein reines Softwareproblem; er setzt Datenquellen voraus, über die der Anbieter einer Gebäudepassplattform nicht verfügt. Wer diesen Unterschied verwischt, verspricht Stufe 4 für einen Zeitpunkt, zu dem realistisch Stufe 3 erreichbar ist.

5.3 Was die EPBD verlangt — und was darüber hinausgeht

Die vier Stufen beschreiben einen technischen Entwicklungsweg, keinen regulatorischen Pflichtenkatalog. Das muss deutlich gesagt werden, weil in der fachlichen Diskussion regelmäßig das Gegenteil unterstellt wird. Die Richtlinie (EU) 2024/1275 verlangt weder die Einführung eines digitalen Gebäudelogbuchs noch die eines digitalen Zwillings.

Das digitale Gebäudelogbuch ist in Artikel 2 Nr. 41 EPBD legaldefiniert; Artikel 12 Abs. 8 EPBD knüpft daran ausschließlich konditional an: Wo ein solches Logbuch existiert, ist der Renovierungspass darin zu speichern oder über eine eindeutige Adresse zugänglich zu machen. Eine Pflicht, ein Logbuch einzuführen, enthält die Richtlinie nicht. Artikel 22 Abs. 7 EPBD verlangt lediglich, dass die nationale Gebäudedatenbank mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern interoperabel ist — also Anschlussfähigkeit, nicht Existenz.

Für den digitalen Zwilling gilt Entsprechendes in noch engerem Rahmen. Er erscheint an genau einer Stelle des Richtlinientextes: Artikel 19 Abs. 14 EPBD verpflichtet die Mitgliedstaaten, vereinfachte Aktualisierungen des Energieausweises zu ermöglichen, und nennt dafür drei Wege — nach einer Einzelmaßnahme, nach umgesetzten Schritten eines Renovierungspasses sowie über einen digitalen Zwilling oder zertifizierte Werkzeuge. Der digitale Zwilling ist damit ein zulässiger Kanal, nicht eine Anforderung. Diese Stelle ist gleichwohl die tragende Rechtsgrundlage dafür, dass ein Gebäudepass als Datenquelle des Energieausweises dienen darf; sie begründet die Option, nicht die Pflicht.

Was die EPBD tatsächlich verlangt, ist enger und konkreter: einen maschinenlesbaren Energieausweis in CSV, JSON oder XML — ein gescanntes PDF genügt ausdrücklich nicht —, dessen Registrierung einschließlich aller Berechnungs-Eingangsdaten nach Artikel 20 Abs. 8 EPBD, eine nationale Gebäudedatenbank nach Artikel 22 EPBD ab dem 29.05.2026 sowie den kostenlosen Zugriff von Eigentümern, Mietern und Verwaltern auf die statischen Gebäudesystemdaten nach Artikel 16 EPBD. Adressat dieser Pflichten ist der Mitgliedstaat; erst die nationale Umsetzung über GEG und GMoDG bindet Eigentümer und Aussteller.

Die Tabelle trennt drei Kategorien: geltende Pflichten des Mitgliedstaats, ausdrücklich eröffnete Optionen und Funktionen, die die Richtlinie nicht regelt. Der digitale Zwilling gehört in die zweite und dritte Kategorie. Er wird hier nicht vorgeschlagen, weil die EPBD ihn fordert, sondern weil er die geforderten Ergebnisse — maschinenlesbare Ausweise, registrierfähige Rohdaten, fortschreibbare Renovierungspässe — mit geringerem Aufwand und höherer Datenqualität erzeugt als eine dokumentenbasierte Arbeitsweise.

5.4 Automatische Datenerfassung als Voraussetzung der Skalierung

Ein digitales Gebäudemodell ist nur skalierbar, wenn die Datenerfassung weitgehend automatisiert werden kann; bei Bestandsgebäuden liegt der überwiegende Teil des Beratungsaufwands nicht in der Berechnung, sondern in der Beschaffung und Erfassung der Eingangsdaten. Der Prozess lässt sich als Kette darstellen: vorhandene Gebäudeunterlagen — KI-gestützte Dokumentenanalyse — Erkennung relevanter Gebäudedaten — Zuordnung zu Datenfeldern — Plausibilitätsprüfung — Gebäudedatensatz. Entscheidend ist das vorletzte Glied; ohne Prüfschritt entsteht kein Datenmodell, sondern eine schnell befüllte Fehlerquelle. Die vorhandene Systemarchitektur deckt die Kette teilweise ab: Es bestehen ein Import für CAD-Daten in JSON und XML, ein IFC-Eingang sowie eine KI-gestützte Dokumentenauswertung, die Grundriss, Wärmeschutznachweis und Energieausweis über eine gemeinsame Ablagezone entgegennimmt und den Dokumenttyp selbst erkennt. Für die IFC-Schnittstelle gilt eine für Kapitel 8 wesentliche Einschränkung: Sie ist als Eingang ohne Ausgang angelegt.

Aus Grundrissen und Schnitten sind perspektivisch Gebäudeabmessungen, Geschosszahl, Raumstrukturen, Fensterpositionen, Außenwände, Dachflächen und Nutzungsbereiche erkennbar, aus einer Wärmepumpenrechnung Hersteller, Gerätetyp, Nennleistung und Installationsdatum, aus einem Energieausweis Primärenergie- und Endenergiebedarf, Effizienzklasse, Registriernummer und Ausstellungsdatum. Diese Angaben werden nicht nur archiviert, sondern dem zugehörigen Datenobjekt zugeordnet — die Rechnung dem Wärmeerzeuger, der Ausweis dem energetischen Zustand zu einem Stichtag. Produktiv ausgewertet werden derzeit die drei genannten Dokumenttypen; weitere Klassen wie Heizlastberechnungen, Produktdatenblätter, Förderbescheide und Wartungsberichte beschreiben die vorgesehene Ausbaustufe.

Jeder erkannte Wert erhält eine vollständige Datenherkunft: Eine Geschosshöhe von 2,75 m ist erst dann eine brauchbare Modellangabe, wenn festgehalten ist, dass sie aus Schnitt A-A stammt, durch Plananalyse gewonnen wurde, den Status „automatisch erkannt" trägt und fachlich nicht bestätigt ist. Eine erkannte, aber ungeprüfte Angabe darf damit in einer Bilanzrechnung verwendet werden, in einem freigegebenen Nachweis nicht. Zusätzlich wird jeder Wert gegen andere Angaben im Datensatz gestellt: Ergibt die Planerkennung eine Fensterfläche von 36,8 m² und das Berechnungsmodell nach DIN V 18599 einen Wert von 37,1 m², liegt die Abweichung bei 0,8 Prozent und der Wert gilt als plausibel; weist der Grundriss eine Wohnfläche von 165 m² aus und der Energieausweis 193 m², lautet der Status: Prüfung erforderlich. Die Plattform folgt dieser Logik bereits — für vier doppelt geführte Angaben, nämlich Bauweise, Keller, Firstrichtung und Geschossanzahl, prüft der Gebäudesteckbrief gegen die andere Quelle, meldet Abweichungen und überschreibt nichts automatisch. Eine Grenze ist bewusst gezogen: Wohnfläche und A_N werden im CAD-Modul nicht aus dem Grundriss abgeleitet, weil ihre Herleitung nicht geometrisch, sondern normativ ist.

5.5 Der Gebäudedatensatz als führende Quelle

Das Ziel besteht darin, je Gebäude einen eindeutig definierten aktuellen Datenbestand zu führen. Dieser Datensatz wird zur führenden Quelle, zur Single Source of Truth. Der Begriff wird häufig missverstanden: Er bedeutet nicht, dass es zu einer Größe nur einen einzigen Wert geben darf. Für die Wohnfläche kann der Bauplan 173 m², die Eigentümerangabe 180 m² und eine förmliche Wohnflächenberechnung 176,4 m² ausweisen; alle drei beruhen auf unterschiedlichen Verfahren und Stichtagen. Der Gebäudepass speichert deshalb alle drei und legt fest, welcher Wert für welche Anwendung maßgeblich ist. So entsteht Transparenz statt künstlicher Eindeutigkeit — und ein prüfbarer Konflikt statt einer stillen Überschreibung.

Die zugehörigen Regeln beschreibt Kapitel 4 im Einzelnen; für den Zwilling sind drei davon tragend. Änderungen laufen über ein Vier-Augen-Verfahren: Ein gemeldeter Wert liegt zunächst im Arbeitsbereich und verändert den offiziellen Wert nicht, erst die Freigabe schreibt in den führenden Datenpfad. Das Modell führt vier Datenzustände — Entwurf, gemeldet, geprüft, freigegeben — und sechs Vertrauensstufen von „unbekannt" bis „amtlich signiert"; nur freigegebene Werte dürfen in offizielle Berichte einfließen. Und Konflikte werden erzeugt, nicht automatisch aufgelöst. Eine Einschränkung gehört hierher: Das Rollenmodell der Schreibrechte war lange beschrieben, aber nicht erzwungen; die mehreren Dutzend Verstöße, die eine Auswertung der Schreibzugriffe ergeben hatte, sind am 23. August 2026 abgearbeitet worden, und die Prüfung läuft seither erzwingend mit.

5.6 Von den Gebäudedaten zur normativen Berechnung

Der zentrale technische Vorteil des Gebäudepasses liegt in der direkten Verbindung zwischen Gebäudedaten und energetischer Berechnung: Der Gebäudepass liefert die Gebäudedaten, die DIN V 18599 die Berechnungsmethodik. Wesentlich ist dabei ein architektonisches Detail: Die Berechnung übernimmt ihre Eingaben nicht aus einer separaten Projektdatei, sondern greift auf den zentralen Gebäudedatensatz zu. Damit entfallen Datenredundanzen und die typischen Abweichungen zwischen Nachweis, Heizlastberechnung und Sanierungsbericht, die in der Praxis fast immer daher rühren, dass drei Werkzeuge drei eigene Projektdateien mit drei Erfassungsständen führen.

Für die Normfassung gilt eine klare Festlegung: Verbindlich gerechnet wird DIN V 18599:2018-09, weil das GEG diese Ausgabe in Bezug nimmt. Die Technische Spezifikation DIN/TS 18599:2025-10 ist keine öffentlich-rechtliche Berechnungsgrundlage; Ergebnisse daraus sind Vergleichsrechnung. Die Plattform führt beide Fassungen parallel und benennt in jeder Ausgabe, die ein Dokument verlässt, die gerechnete Normfassung; entsprechend besteht ein Umschalter zwischen dem Rechtsstand 2026 und dem ab 2027 anzuwendenden Recht, und jedes Ergebnis trägt einen Rechtsstands-Stempel. Zur Belastbarkeit der Rechenkerne liegen Validierungsfälle vor: 34 Fälle mit 964 geprüften Größen, sämtlich innerhalb der Toleranz von einem Prozent, die Wärmepumpenfälle als Teilabnahme.

Was daraus folgt, zeigt ein einfaches Beispiel. Ein Gebäude weist im Ausgangszustand einen Außenwand-U-Wert von 1,20 W/(m²K) auf; nach der Fassadendämmung beträgt er 0,20 W/(m²K). Ist die Änderung dokumentiert und freigegeben, lassen sich Heizwärmebedarf, Endenergiebedarf, Primärenergiebedarf, CO₂-Emissionen, Heizlast, erreichbare Effizienzklasse und Wirtschaftlichkeit neu bestimmen, ohne dass ein Wert erneut erfasst wird. Der regulatorische Anschluss ist angelegt: Artikel 13 Abs. 6 EPBD verlangt, dass nach der Installation eines gebäudetechnischen Systems die Gesamtenergieeffizienz des veränderten Teils bewertet, dokumentiert und dem Eigentümer übergeben wird — eine Pflicht, die ohne Zusatzaufwand erfüllt wird, wenn sie aus dem Modell heraus entsteht.

5.7 Ist-Zustand, Plan-Zustand und Ziel-Zustand

Sobald ein Modell Änderungen rechnen kann, entsteht eine neue Verwechslungsgefahr: Geplante und tatsächlich ausgeführte Maßnahmen dürfen nicht in denselben Datenbestand fallen. Die Architektur muss deshalb mindestens drei Zustandsarten unterscheiden.

Diese Trennung ist nicht nur Ordnungsprinzip, sondern Haftungsfrage. Ein Energieausweis aus einem Plan-Zustand beschreibt ein Gebäude, das es nicht gibt; umgekehrt ist eine Sanierungsplanung wertlos, wenn sie den Ist-Zustand nicht sauber als Ausgangspunkt führt. Der Renovierungspass nach Artikel 12 und Anhang VIII EPBD setzt genau diese Trennung voraus: Er verlangt für jeden Schritt die Veränderung von Primär- und Endenergie gegenüber dem Zustand vor dem Schritt sowie die danach erreichte Ausweisklasse.

Besonders wertvoll wird die Funktion vor der Umsetzung einer Maßnahme, wenn der Gebäudepass mehrere Zukunftszustände nebeneinander erzeugt — Variante A nur Wärmepumpe, Variante B mit Fenstern, Variante C mit Fassade, Variante D zusätzlich mit Photovoltaik. Vergleichbar werden Investitionskosten, Endenergie, Primärenergie, CO₂-Emissionen, Energieklasse, Fördermittel, Betriebskosten und Amortisationszeit. Für den heutigen Stand ist zu unterscheiden: Variantenvergleiche existieren produktiv im Leistbarkeits- und Finanzierungsteil der Plattform, allerdings ohne Anbindung an den zentralen Projektdatenbestand. Die durchgängige Sanierungs-Variantenrechnung am Gebäudedatensatz ist vorgesehen und noch nicht umgesetzt; sie ist damit der wichtigste Einzelschritt von Stufe 2 zu Stufe 3.

5.8 Der Zeitstrahl und die Gebäudechronik

Mit den Zustandsarten erhält das Modell eine zeitliche Dimension. Es führt nicht nur einen aktuellen Zustand, sondern eine Folge von Zuständen: Neubau 1975, Fenstertausch 1998, Dachsanierung 2012, Ausgangsanalyse 2026, Wärmepumpe 2028, Fassadendämmung 2030, Photovoltaik 2032, Zielzustand 2050. Jeder dieser Punkte ist ein vollständiger, rechenbarer Gebäudezustand, nicht nur ein Tagebucheintrag; das Gebäude wird damit auch zeitlich modelliert.

Diese Zeitachse bildet die technische Grundlage der Gebäudechronik. Zu jedem Ereignis lassen sich vorheriger und neuer Zustand, Datum, ausführendes Unternehmen, Kosten, Fördermittel, Dokumente und energetische Auswirkungen speichern. Der Nutzen reicht über die Dokumentation hinaus: Eine belegte Chronik beantwortet Fragen, die heute offenbleiben — ob die Kellerdecke gedämmt ist und mit welcher Stärke, welche Bauteile aus welcher Sanierungsphase stammen. Diese Angaben entscheiden über die Ansetzbarkeit von U-Werten und damit über die Belastbarkeit jeder Bilanz. Zugleich ordnet die Chronik historische Dokumente korrekt ein: Ein Energieausweis aus 2016 beschreibt nicht das heutige Gebäude, sondern einen früheren Zustand. Im vorhandenen System ist diese Modellierung angelegt, aber nicht ausgebaut — Werte werden versioniert statt überschrieben und jeder Projektstand gesichert, eine durchgängige Ereignis-Timeline als eigene Erfassungsebene ist dagegen als offener Punkt geführt.

5.9 Abhängigkeitsmodell und automatische Neuberechnung

Ein Modell, das Änderungen verarbeiten soll, muss wissen, welche Ergebnisse von welchen Eingaben abhängen. Ohne explizit modellierte Abhängigkeitsstruktur bleiben nur zwei schlechte Möglichkeiten: alles nach jeder Änderung neu zu rechnen oder darauf zu vertrauen, dass der Bearbeiter selbst weiß, was nun veraltet ist. Die Plattform löst dies über einen Abhängigkeitsgraphen; die Wirkkette führt vom Bauteil über U-Wert und Heizlast zu Transmissionswärmeverlust und Primärenergiebedarf, weiter zu Wärmeschutznachweis und Energieausweis, zur CO₂-Bilanz, zum Building Trust Index und bis in den Finanzierungsbericht. Wird ein Wert geändert und freigegeben, markiert das System alle abhängigen Ergebnisse als nicht mehr aktuell und stößt die betroffenen Rechenschritte an. Eine ergänzende Neuberechnungslogik bildet je Eingabesektion einen Fingerabdruck, ermittelt die betroffenen Rechenagenten, setzt ein Veraltet-Kennzeichen, startet die Rechenkette und protokolliert den Vorgang.

Das Abhängigkeitsmodell markiert damit die eigentliche Schwelle zwischen Stufe 2 und Stufe 3: Es macht aus einem Datenspeicher ein Modell und verhindert, dass ein Gebäudepass mit der Zeit stillschweigend veraltet.

Dasselbe Prinzip gilt für Dokumente. Ein Energieausweis wird 2026 ausgestellt, 2028 die Heizung ersetzt: Der Ausweis bleibt nach Artikel 19 EPBD rechtlich gültig, denn seine Gültigkeitsdauer beträgt höchstens zehn Jahre — inhaltlich bildet er das Gebäude jedoch nicht mehr zutreffend ab. Der Gebäudepass muss deshalb zwischen „rechtlich gültig" und „inhaltlich aktuell" unterscheiden können. Im vorhandenen System ist das für den Energieausweis bereits wirksam: Die Ausweiskachel warnt, wenn der Endenergiewert des abgelegten Dokuments von den aktuellen Gebäudedaten abweicht, und ein neuer Bedarfsausweis entsteht automatisch, sobald sich die Endenergie ändert. Genau hier setzt Artikel 19 Abs. 14 EPBD an: Die vereinfachte Aktualisierung nach einer Einzelmaßnahme ist die regulatorische Entsprechung dieses Mechanismus.

5.10 Betriebsdaten und der Soll-Ist-Vergleich

Die vierte Stufe beginnt, sobald reale Verbrauchs- und Betriebsdaten verfügbar sind. Dann lassen sich normativer Bedarf und tatsächlicher Verbrauch vergleichen: Ergibt die Berechnung nach DIN V 18599 einen Wert von 68 kWh/(m²a) und der gemessene Verbrauch 91 kWh/(m²a), beträgt die Abweichung rund ein Drittel. Diese Differenz ist kein Fehler, sondern ein Befund — Nutzerverhalten, fehlerhafte Anlagenregelung, höhere Raumtemperaturen, eine technische Störung, unzutreffende Gebäudedaten oder ungünstige Betriebszeiten kommen als Ursachen in Betracht. Aus dem Gebäudepass wird damit ein Diagnoseinstrument.

Voraussetzung ist eine methodische Trennung, die nicht aufgeweicht werden darf: Messdaten dürfen den berechneten Gebäudedatensatz niemals ungefiltert überschreiben. Die Struktur lautet normatives Gebäudemodell plus reale Betriebsdaten ergibt Soll-Ist-Analyse — nicht: Messwert ersetzt Rechenwert. Die Berechnung nach DIN V 18599 arbeitet mit standardisierten Randbedingungen zu Innentemperatur, Luftwechsel, Nutzungszeiten und Klima; nur deshalb sind ihre Ergebnisse zwischen Gebäuden vergleichbar, und ein realer Bewohner verhält sich nicht standardisiert. Die Plattform folgt diesem Grundsatz sichtbar, indem sie die drei CO₂-Größen aus Energieausweis, automatischer Betriebsbilanz und Ökobilanz getrennt und ohne Gesamtwert führt. Der regulatorische Rahmen bestätigt die Systematik: Anhang V EPBD führt den gemessenen Verbrauch als optionalen Indikator neben den berechneten Pflichtangaben, und Artikel 22 EPBD nennt berechneten und gemessenen Verbrauch als zwei getrennte Datenquellen der nationalen Datenbank.

Wärmepumpen eignen sich besonders für diese Verbindung, weil ihre Effizienz stark von der Einbindung in das Gebäude abhängt. Erfassbar wären Stromverbrauch, erzeugte Wärmemenge, Vorlauf- und Rücklauftemperatur, Betriebsstunden, Verdichterstarts, Warmwasseranteil und daraus die Jahresarbeitszahl; steht einer erwarteten Jahresarbeitszahl von 4,2 eine gemessene von 3,1 gegenüber, lässt sich der Abweichung über Heizkurve, Takten, hydraulischen Abgleich oder Warmwasserbereitung nachgehen. Die Energieberatung endet dann nicht mit der Sanierung, sondern wird als Betriebsoptimierung fortgesetzt. Für den heutigen Stand ist zu präzisieren: Die Plattform ermittelt die Jahresarbeitszahl rechnerisch nach VDI 4650; eine gemessene liegt nicht vor, ebenso wenig das stundenbasierte Bilanzverfahren, das eine belastbare Gegenüberstellung erfordern würde. Entsprechendes gilt für Photovoltaik, wo einem prognostizierten Ertrag von 9.500 kWh/a bei 10 kWp ein gemessener von 8.750 kWh/a gegenüberzustellen wäre: Auch hier arbeitet das System mit Pauschalen; der Anlagenbestand aus Photovoltaik, Wallbox, Smart Meter und Energiemanagement wird dagegen bereits erfasst.

Der Weg zur vierten Stufe hängt damit an drei Voraussetzungen, von denen nur die erste in der eigenen Hand liegt: an einer Datenstruktur, die Messwerte getrennt vom Modell führt, an Schnittstellen der Geräte- und Zählerhersteller und an einem tragfähigen Rechtsrahmen für die Datenherausgabe. Dort ist die Zuordnung eindeutig, aber häufig missverstanden: Artikel 16 EPBD regelt den Zugang zu den statischen Gebäudesystemdaten, während dynamische Daten vernetzter Produkte unter den Data Act, die Verordnung (EU) 2023/2854, fallen. Zugleich sorgt die EPBD dafür, dass die Datenquellen im Gebäude überhaupt entstehen: Artikel 13 Abs. 11 EPBD verlangt für neue Wohngebäude und für Wohngebäude bei größerer Renovierung ab dem 29.05.2026 ein elektronisches Monitoring mit Effizienzwarnung, Steuerfunktionen und Demand-Response-Fähigkeit. In dieselbe Richtung wirkt § 80 GMoDG, der beim Verbrauchsausweis für Wohngebäude nicht mehr drei Abrechnungsperioden verlangt, sondern eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate; die Plattform bedient beide Verfahren parallel. Das Anwendungsdatum dieser Regelung ist zum Quellenstand mit Vorbehalt geführt.

5.11 Dokumente als Ausgabe des Datenmodells

Aus einem vollständigen Gebäudedatensatz lassen sich Dokumente automatisch erzeugen. Damit kehrt sich das gewohnte Verhältnis um: Nicht das Dokument ist die Datenquelle und die Datenbank sein Abbild, sondern die Daten sind der Bestand und das Dokument eine Ausgabe daraus. Dänemark und Portugal betreiben ihre Ausweisregister bereits so und speichern keine PDF-Dokumente; auch Artikel 20 Abs. 8 EPBD, der die Registrierung des vollständigen Ausweises einschließlich aller Berechnungs-Eingangsdaten verlangt, weist in diese Richtung.

Die vorhandene Plattform arbeitet nach diesem Muster: Eine Auto-Dokumentenschicht erzeugt sieben Dokumente aus dem Datenbestand — Bedarfsausweis, Wärmeschutznachweis, Grundriss, Hydraulischer Abgleich, Heiz- und Kühllastbericht, Maßnahmenbericht und Finanzierungsbericht —, jeweils mit einem Merker über die zugrunde liegenden Daten, sodass ein Dokument nur bei geänderter Datengrundlage neu entsteht; perspektivisch gehören Renovierungspass, Ökobilanz-Bericht, Bankenreport und ESG-Datenblatt dazu. Drei Einschränkungen sind zu benennen: Der intern erzeugte Bedarfsausweis trägt eine aus der Gebäude-ID abgeleitete Dokumentnummer und ausdrücklich keine amtliche Registriernummer; ein förderfähiger individueller Sanierungsfahrplan entsteht weiterhin ausschließlich in der amtlichen Druckapplikation; und die Automatik ist zu weitgehend, weil bereits das Öffnen des Gebäudepasses die Dokumentenerzeugung ohne Nutzeraktion anstößt. Für die Ökobilanz kommt mit Blick auf die GWP-Pflichten ab 2028 und 2030 nach Artikel 7 EPBD hinzu, dass die grauen Emissionen bislang über einen geschätzten Richtwert eingehen; ihre Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen ist der nächste erforderliche Schritt.

5.12 Qualitätssicherung und fachliche Verantwortung

Je mehr Daten miteinander verbunden werden, desto größer wird die Möglichkeit automatischer Qualitätskontrollen, denn Widersprüche werden erst sichtbar, wenn zwei Angaben zur selben Größe im selben System liegen. Weist der Gebäudepass eine Wohnfläche von 150 m² aus, die Plananalyse 175 m² und der Energieausweis 190 m², erkennt das System eine Inkonsistenz und erzeugt eine Prüfmeldung, ohne selbst zu entscheiden; steht einer Wärmepumpenleistung von 18 kW eine berechnete Heizlast von 5,5 kW gegenüber, meldet es, dass die Dimensionierung zu prüfen ist. Daraus kann ein Gebäudewächter entstehen, der laufend Datenvollständigkeit, widersprüchliche Angaben, abgelaufene Dokumente, veraltete Berechnungen, fehlende Nachweise, anstehende Wartungen und erreichte Sanierungszeitpunkte prüft — Artikel 19 Abs. 13 EPBD etwa sieht für Gebäude unterhalb der Klasse C eine Einladung zur zentralen Anlaufstelle nach fünf Jahren oder bei Ablauf des Ausweises vor, eine Frist, die ein Gebäudemodell selbst überwachen kann.

Der heutige Stand ist genau zu benennen, weil zwei Prüfsysteme leicht verwechselt werden: Ein Funktions-Wächter mit inzwischen 499 Prüfungen läuft täglich und sichert den Code gegen Regressionen, ein davon getrennter Quellen-Abgleich mit sechs Regeln prüft, ob die Daten in sich stimmen. Beides ist produktiv; der gebäudebezogene Wächter für Dokumentenfristen, Wartungstermine und Sanierungszeitpunkte ist dagegen ein Ausbauschritt, der an dieselben Voraussetzungen wie die Ereignis-Timeline gebunden ist. Langfristig sollte der Gebäudepass ereignisgesteuert arbeiten: Wird eine Rechnung hochgeladen, erkennt das System den Einbau einer Wärmepumpe, aktualisiert den Anlagenbestand, stößt die Bilanz nach DIN V 18599 neu an, prüft den Förderprozess und schreibt den Sanierungsfahrplan fort. Automatisierung bedeutet jedoch nicht, dass fachliche Verantwortung entfällt: Bei Nachweisen mit rechtlicher Wirkung muss erkennbar bleiben, wer den Datenwert geliefert, wer ihn geprüft, wer gerechnet und wer freigegeben hat; das System unterscheidet deshalb zwischen automatisch erkannt, automatisch plausibilisiert, fachlich geprüft und freigegeben. Auch Anhang VI EPBD verlangt für das Kontrollsystem der Datenbanken, dass der Urheber jeder Änderung für die Behörden ermittelbar bleibt. Der Leitsatz der Plattform fasst dies knapp: Die maschinelle Auswertung schlägt vor, der Mensch entscheidet.

5.13 Rollen, Sichten und Zugangspunkt

Ein digitaler Zwilling muss unterschiedlichen Beteiligten unterschiedliche Ansichten bieten: dem Eigentümer eine verständliche Übersicht, dem Energieberater die vollständigen energetischen Daten, dem Architekten Geometrie und Bauteile, dem TGA-Planer die Anlagentechnik, der Bank Energie-, ESG- und Dokumentenqualitätsdaten, dem Makler die freigegebenen Verkaufsinformationen und der Behörde die gesetzlich erforderlichen Datensätze. Alle greifen auf denselben Gebäudedatensatz zu, sehen aber nicht dieselben Informationen. Die EPBD gibt diese Abstufung vor: Artikel 22 EPBD unterscheidet Zugriffsstufen für Eigentümer, Mieter, Verwalter und Finanzinstitute einerseits, für unabhängige Experten sowie Kauf- oder Mietinteressenten nur mit Erlaubnis des Eigentümers andererseits, dazu Gebietsdaten für Kommunen und aggregierte Veröffentlichungen für die Öffentlichkeit.

Im vorhandenen System existiert die Darstellungsebene dieser Abstufung: Die Kennwerteseite bietet Rollenansichten für Architekten, Makler, Hausverwaltungen, TGA-Planer, Banken und Energieberater. Das ist ausdrücklich eine Priorisierung der Darstellung, keine Rechteschicht; das abgestufte Zugriffsmodell mit eigener Rechtezuweisung je Rolle liegt daneben und ist seit dem 23. August 2026 umgesetzt; Kapitel 9 behandelt es im Einzelnen. Der QR-Code kann als Zugangspunkt dienen: Er enthält nicht die Gebäudedaten, sondern verweist auf den Pass, aus dem sich nach Authentifizierung rollenabhängig unterschiedliche Ansichten öffnen ließen. Umgesetzt ist die Grundfunktion — ein veröffentlichter Pass wird als Momentaufnahme ohne personenbezogene Daten abgelegt, über eine eindeutige Gebäude-ID adressiert und durch eine vierstellige PIN mit gestaffelter Sperre nach Fehlversuchen geschützt, der QR-Druck erfolgt ohne PIN. Die veröffentlichte Ansicht arbeitet dabei auf der Momentaufnahme, nicht auf der laufenden Rechenschicht.

5.14 Zielbild und Kernaussage

Das bisherige System arbeitet in weiten Teilen nach einem einfachen Muster: Energieausweis erstellen, zehn Jahre ablegen, neuen Energieausweis erstellen. Zwischen diesen Punkten geschieht datenseitig nichts, obwohl am Gebäude in dieser Zeit häufig erhebliche Veränderungen stattfinden. Der Gebäudepass ermöglicht stattdessen einen fortlaufenden Kreislauf aus Gebäudezustand, laufender Aktualisierung, Energiekennwerten, Sanierung und daraus neu erzeugten Dokumenten. Das Zielbild beschreibt eine durchgehende Kette von Planung und Bau über digitale Gebäudeakte, Berechnung, Energieausweis, Betrieb und Messdaten zu Sanierungsplanung, Förderung, Finanzierung, Modernisierung und aktualisiertem Gebäudezustand bis zum Eigentümerwechsel, an den sich die Fortführung des Passes anschließt.

Diese Entwicklung verändert langfristig die Rolle der Energieberatung. Die heute übliche Frage lautet, wie energieeffizient ein Gebäude ist. Mit einem fortschreibbaren Modell kommen weitere hinzu: Wie hat sich das Gebäude entwickelt? Wie verändert es sich bei einer bestimmten Maßnahme, und in welcher Reihenfolge sind Maßnahmen technisch und wirtschaftlich sinnvoll? Wie entwickelt sich der reale Verbrauch gegenüber der Erwartung? Welche Investitionen werden künftig notwendig, und welche regulatorischen Anforderungen betreffen dieses Gebäude zu welchem Zeitpunkt? Aus einer punktuellen Beratung wird damit ein kontinuierliches Gebäudemanagement — mit Folgen für Leistungsbilder und Geschäftsmodelle, die in Kapitel 15 behandelt werden.

Der vorhandene zentrale Gebäudedatensatz mit seinen Governance-, Abhängigkeits- und Neuberechnungsschichten ist die tragfähige Grundlage dieses Zwillings; was fehlt, ist im Wesentlichen die Anbindung realer Betriebsdaten; die durchgesetzte Rechteschicht ist seit dem 23. August 2026 vorhanden. Aus dem digitalen Gebäudepass wird auf diesem Weg nicht lediglich eine modernere Gebäudeakte, sondern die digitale Betriebs- und Entscheidungsgrundlage einer Immobilie über ihren gesamten Lebenszyklus. Dass die EPBD diesen Schritt nicht verlangt, ändert daran nichts — sie macht ihn möglich, und die Wirtschaftlichkeit macht ihn erforderlich.

6 Die EPBD-Instrumente im digitalen Gebäudepass

Die EPBD steuert den Gebäudebestand nicht über ein einzelnes Dokument, sondern über ein Bündel von Instrumenten, die auf denselben Gegenstand blicken: das Gebäude. Dieses Kapitel geht die Instrumente einzeln durch und stellt für jedes dieselben drei Fragen — was die Richtlinie verlangt, welche Daten das im Gebäudepass bedeutet, und wie weit die vorhandene Plattform das heute trägt. Die regulatorischen Grundlagen aus Kapitel 3 und das Datenmodell aus Kapitel 4 werden dabei vorausgesetzt und nicht wiederholt.

6.1 Vom Einzelinstrument zur gemeinsamen Datenbasis

Energieausweis, Renovierungspass, nationale Gebäuderenovierungspläne, Gebäudedatenbanken, Datenaustausch, digitales Gebäudelogbuch, Smart Readiness Indicator, Lebenszyklus-GWP, Inspektionsberichte und die Anforderungen an Nullemissionsgebäude verfolgen unterschiedliche Zwecke. Der Energieausweis informiert den Markt, der Renovierungspass strukturiert eine Investitionsentscheidung, die Datenbank speist die staatliche Bestandsanalyse, die Inspektion sichert den technischen Betrieb. Die Instrumente sind rechtlich getrennt geregelt und werden in der Praxis auch getrennt bearbeitet — häufig von unterschiedlichen Personen, in unterschiedlichen Programmen, zu unterschiedlichen Zeitpunkten.

Betrachtet man jedoch nicht die Zwecke, sondern die Eingangsdaten, ergibt sich ein anderes Bild. Die Fläche eines Bauteils, sein Aufbau, sein U-Wert, das Baujahr, die Anlagentechnik, der Energieträger, der gemessene Verbrauch — dieselben Größen werden von mehreren Instrumenten gleichzeitig benötigt. Ein Renovierungspass, der die Wirkung einer Fassadendämmung beziffert, greift auf dieselbe Bauteilbeschreibung zu wie der Energieausweis, der den Ist-Zustand ausweist, und wie die Ökobilanz, die die Herstellungsemissionen des Dämmstoffs bewertet. Wenn jedes Instrument seinen eigenen Datensatz mitbringt, entstehen drei Beschreibungen desselben Bauteils, die auseinanderlaufen, sobald sich eine von ihnen ändert.

Daraus folgt die zentrale Systemidee des digitalen Gebäudepasses: nicht ein Datensatz je Instrument, sondern ein gemeinsamer Gebäudedatenkern, aus dem die einzelnen Instrumente als Sichten und Auswertungen entstehen. Die Richtlinie selbst legt diesen Weg an mehreren Stellen nahe. Artikel 19 Absatz 14 Buchstabe c erlaubt vereinfachte Aktualisierungen des Energieausweises ausdrücklich über einen digitalen Zwilling oder zertifizierte Werkzeuge. Artikel 12 Absatz 3 und Artikel 19 Absatz 6 erlauben die gemeinsame Ausstellung von Ausweis und Renovierungspass; dann ersetzt der Pass die Modernisierungsempfehlungen des Ausweises. Anhang VIII Nummer 3 verlangt, die Ausweisdaten als Startzustand des Renovierungspasses zu berücksichtigen. Artikel 22 Absatz 7 verlangt Interoperabilität der nationalen Datenbank mit Kataster, Grundbuch und digitalen Gebäudelogbüchern. Die Verknüpfung der Instrumente ist also nicht nur technisch sinnvoll, sie ist regulatorisch angelegt.

Die folgenden Abschnitte behandeln die zehn Instrumente einzeln und jeweils in derselben Reihenfolge: zuerst die Anforderung der Richtlinie, dann der daraus abgeleitete Datenbedarf im Gebäudepass, zuletzt der belegte Stand der vorhandenen Plattform. Der dritte Teil ist bewusst zurückhaltend formuliert. Wo eine Funktion produktiv läuft, wird das benannt; wo sie als Konzept vorliegt oder von externen Vorgaben abhängt, wird auch das benannt. Eine Gesamtwürdigung des Reifegrads leistet Kapitel 13, die feldgenaue Zuordnung zu den einzelnen Artikeln leistet die Anforderungsmatrix in Kapitel 12.

6.2 Energieausweis — Artikel 19 bis 21 und Anhang V

Der Energieausweis ist das bekannteste und zugleich das am dichtesten geregelte Instrument der Richtlinie. Verbindlich ist seit dem 29. Mai 2026 die geschlossene Skala A bis G nach Artikel 19 Absatz 2, wobei Klasse A dem Nullemissionsgebäude vorbehalten ist: ein Gebäude, das rechnerisch den A-Kennwert erreicht, seine Wärme aber aus einem Gaskessel bezieht, wird auf B eingestuft. Klasse G bezeichnet die schlechtesten Bestandsgebäude mit einem Benchmark von 14 bis 18 Prozent und höchstens 26 Prozent des Bestands. Die freiwillige Stufe A+ verlangt einen Bedarf von mindestens 20 Prozent unter der ZEB-Schwelle, Fossilfreiheit und eine On-site-Erzeugung oberhalb des Jahres-Primärenergieverbrauchs; wer im Zuge einer Sanierung A+ erreichen will, muss zusätzlich den GWP-Ausweis führen. Mitgliedstaaten, die zwischen 2019 und 2024 bereits neu skaliert haben, dürfen die Umstellung bis längstens 31. Dezember 2029 aufschieben.

Anhang V Nummer 1 bestimmt die Titelseite abschließend: Energieeffizienzklasse; jährliche Primärenergie in kWh/(m²·a) je Energieträger; jährliche Endenergie in kWh/(m²·a) je Energieträger; Anteil erneuerbarer Energie on-site in Prozent; operative Treibhausgasemissionen in kg CO₂eq/(m²·a), ergänzt um den GWP-Wert in kg CO₂eq/m², sofern verfügbar. Hinzu treten die absoluten Primär- und Endenergiemengen, die Angabe von Hauptenergieträger und Art der erneuerbaren Erzeugung, der Energiebedarf je System, die Demand-Response-Fähigkeit als Ja-Nein-Angabe, die Niedertemperaturfähigkeit des Verteilsystems, die Kontaktdaten der One-Stop-Shops und die Referenzwerte nach Artikel 19 Absatz 1. Die Modernisierungsempfehlungen entfallen nur bei Klasse A und A+; im Übrigen müssen sie kostenoptimal sein und je Empfehlung eine quantifizierte Schätzung der Energie- und Treibhausgaswirkung sowie der Wirkung auf die Innenraumqualität enthalten. Die Niedertemperatur-Eignung ist nach den Kommissions-Leitlinien bei einer Auslegungstemperatur von höchstens 45 °C beziehungsweise einer saisonalen Systemtemperatur von höchstens 42 °C gegeben und über vier Schritte zu prüfen: Heizlast, Heizkörperleistung, Volumenstrom, Systemtemperatur.

Formal ist der Ausweis digital und maschinenlesbar auszustellen — die Leitlinien nennen CSV, JSON und XML; ein gescanntes PDF genügt ausdrücklich nicht, Papier nur auf ausdrücklichen Wunsch. Er wird von einem unabhängigen Sachverständigen nach einem Vor-Ort-Besuch ausgestellt, der auch virtuell mit Video-Sichtprüfung erfolgen darf. Auslöser sind Neubau, größere Renovierung — definiert über mehr als 25 Prozent des Gebäudewerts oder mehr als 25 Prozent der Hüllfläche —, Verkauf, Neuvermietung, Mietvertragsverlängerung sowie alle Gebäude öffentlicher Stellen. Die Gültigkeit beträgt höchstens zehn Jahre; unterhalb Klasse C ist nach fünf Jahren oder bei Ablauf zum One-Stop-Shop einzuladen (Artikel 19 Absatz 13). Artikel 19 Absatz 14 macht vereinfachte Aktualisierungen zur Pflicht: nach einer Einzelmaßnahme, nach umgesetzten Renovierungspass-Schritten und über digitale Zwillinge oder zertifizierte Werkzeuge. Registriert wird über die Datenbank nach Artikel 22, wobei Artikel 20 Absatz 8 den vollständigen Ausweis einschließlich sämtlicher Berechnungs-Eingangsdaten verlangt.

Für den Gebäudepass folgt daraus zunächst eine Abgrenzung: Der Energieausweis ist dort kein abgelegtes Dokument, sondern das Ergebnis eines Berechnungszustands. Er wird aus dem vorhandenen Gebäudedatensatz erzeugt — Gebäudedaten führen zur energetischen Berechnung, die Berechnung liefert die Kennwerte, aus den Kennwerten entsteht der Ausweis, der anschließend registriert und dokumentiert wird. Damit dieser Zusammenhang auch nach Jahren nachvollziehbar bleibt, muss jeder ausgestellte Ausweis fest mit dem Datenstand verbunden sein, aus dem er hervorgegangen ist. Zu speichern sind mindestens:

• Version des Gebäudedatensatzes, aus dem gerechnet wurde
• Berechnungsdatum und Berechnungsverfahren
• Rechtsstand (GEG beziehungsweise GMoDG) und gerechnete Norm-Fassung
• Softwareversion des Rechenkerns
• Aussteller, Registriernummer, Ausstellungsdatum, Gültigkeitszeitraum
• sämtliche Berechnungs-Eingangsdaten nach Artikel 20 Absatz 8

Die Nennung der gerechneten Norm-Fassung ist keine Formalie. Öffentlich-rechtlich verbindlich gerechnet wird DIN V 18599:2018-09; die Technische Spezifikation DIN/TS 18599:2025-10 ist keine GEG-Grundlage, Ergebnisse daraus sind Vergleichsrechnungen. Jede Ausgabe, die den Gebäudepass verlässt, muss deshalb benennen, nach welcher Fassung gerechnet wurde — und ebenso, dass für Primärenergie- und CO₂-Faktoren die Anlagen 4 und 9 des GEG Vorrang vor den abweichenden Anhangswerten der Norm haben.

Zweitens folgt aus der Zehnjahresfrist, dass ein Gebäude über seine Lebensdauer mehrere Ausweise erhält. Der Gebäudepass sollte nicht nur den jeweils gültigen Ausweis führen, sondern die vollständige Reihe: ein Gebäude, das 2016 mit einer schwachen Klasse bewertet wurde, 2026 nach dem Heizungstausch besser dasteht und nach Fassade und Fenstern erneut aufsteigt, dokumentiert mit dieser Reihe seine eigene Entwicklung. Aus einer Momentaufnahme wird ein Verlauf — und dieser Verlauf ist genau das, was Banken, Käufer und Förderstellen benötigen, wenn sie die Glaubwürdigkeit eines angekündigten Sanierungspfads einschätzen wollen.

Drittens folgt aus der Maschinenlesbarkeitspflicht eine Trennung in zwei Ebenen. Die Darstellungsebene ist die für Menschen lesbare Ausgabe, in der Regel ein PDF. Die Datenebene ist der strukturierte Datensatz, der die Felder des Anhangs V einzeln, benannt, mit Einheit und mit Bezugsfläche trägt. Nur die Datenebene ist übertragbar, prüfbar und in eine Datenbank übernehmbar. Ein aus dem Datensatz erzeugtes PDF erfüllt die Anforderung; ein gescanntes PDF, aus dem die Werte nachträglich wieder herausgelesen werden müssten, erfüllt sie nicht.

Viertens verschiebt sich die Rolle des Ausweises im Markt. Für die Kreditwirtschaft ist die Energieklasse zunehmend ein Risikomerkmal, für die Bewertung reicht sie aber selten aus. Gefragt sind zusätzlich der Zustand der Gebäudehülle, das Heizungssystem und dessen Restlebensdauer, der Sanierungs- und Investitionsbedarf, die Emissionen, der Stand geplanter Modernisierungen und — mit wachsender Bedeutung — die Qualität der zugrunde liegenden Daten. Der Gebäudepass kann den Ausweis daher als Einstiegspunkt in einen umfassenderen, belegten Gebäudedatensatz verwenden, statt ihn als Endprodukt zu behandeln.

Die vorhandene Plattform trägt diesen Instrumententeil am weitesten. Der Bedarfsausweis wird real erzeugt: das Modul für Auto-Dokumente erstellt ihn bei vollständigem Energie-Kern selbsttätig als PDF, versieht ihn mit einer aus der Gebäude-ID abgeleiteten, deterministischen Ausweisnummer und erzeugt eine neue Version, sobald sich die Endenergie ändert; die Kachel im Gebäudepass warnt, wenn abgelegtes Dokument und aktueller Datenstand auseinanderlaufen. Der Rechenkern beruht auf DIN V 18599:2018-09 mit umschaltbarem Rechts- und Normstand; jedes Ergebnis trägt einen Rechtsstands-Stempel. Für das Verbrauchsgleis existiert bereits der Umschalter zwischen den bisherigen 36 Monaten nach GEG und der nach GMoDG § 80 ab 2027 verlangten, nach Energieträgern differenzierten monatlichen Erfassung über 24 Monate. Die Belastbarkeit der Berechnung ist geprüft: 34 Validierungsfälle mit 964 Einzelgrößen liegen innerhalb der Ein-Prozent-Vorgabe, die Wärmepumpenfälle als Teilabnahme; ein Funktions-Wächter mit inzwischen 499 Prüfungen läuft täglich.

Offen bleiben drei Punkte, und sie liegen nicht sämtlich in der Hand des Entwicklers. Die Ausweisnummer der Plattform ist keine amtliche Registriernummer — eine Registrierung ist erst möglich, wenn ein nationales Register mit Schnittstelle existiert. Die Klassenlogik folgt heute noch der nationalen Skala; die Umstellung auf die geschlossene Skala A bis G setzt voraus, dass die Klassengrenzen feststehen, und genau diese sind in der Plattform bewusst als Lücke geführt — bei Nichtwohngebäuden gibt die Klassenfunktion zwischen den Randklassen absichtlich keinen Wert zurück, statt einen zu erfinden. Und die Maschinenlesbarkeit ist erst teilweise erreicht: ein maschinenlesbarer Export der Pflichtangaben nach § 85 sowie ein XML-Artefakt des Passes existieren, ein vollständiger Anhang-V-Datensatz je Energieträger ist damit noch nicht ausgeliefert. Er ist konzipiert, aber nicht abgeschlossen.

6.3 Renovierungspass — Artikel 12 und Anhang VIII

Der Renovierungspass verfolgt einen anderen Zweck als der Energieausweis: Er beschreibt nicht den Zustand, sondern den Weg. Die Mitgliedstaaten mussten bis zum 29. Mai 2026 ein Renovierungspass-System einführen; für Eigentümer ist die Inanspruchnahme freiwillig, ein Mitgliedstaat kann sie verpflichtend machen, muss es aber nicht. Der Pass gilt für Gebäude und ausdrücklich auch für Gebäudeteile, so dass ihn einzelne Wohnungseigentümer erhalten können. Zielzustand ist die tiefgreifende Renovierung: bis zum 31. Dezember 2029 das Niedrigstenergiegebäude, ab dem 1. Januar 2030 das Nullemissionsgebäude; ist beides nicht machbar, gilt eine Primärenergiereduktion von mindestens 60 Prozent als Rückfallschwelle.

Anhang VIII Nummer 1 nennt die Pflichtinhalte abschließend. Verlangt sind die aktuelle Gesamtenergieeffizienz mit mindestens der Primärenergie im Ist-Zustand; eine grafische Roadmap vom Ausgangs- zum Endzustand mit Maßnahmen, Kosten, Einsparung und Klassensprung je Schritt; die nationalen Anforderungen einschließlich ihrer Stichtage, also Mindestanforderungen, MEPS und Fossilausstieg; eine Begründung der optimalen Schrittfolge, ausdrücklich zur Vermeidung von Lock-in-Effekten; die Anschlussoption an Fernwärme oder Fernkälte; der Anteil erneuerbarer Energie und der Eigenverbrauchsanteil nach der Renovierung; Angaben zur Zirkularität der Bauprodukte, zum Whole-Life-Carbon und zu den Co-Benefits für Gesundheit, Komfort, Innenraumqualität und Klimaanpassung; Fördermöglichkeiten mit Links; sowie technische Beratung mit den Kontaktdaten der One-Stop-Shops. Für jeden einzelnen Schritt sind fünf Felder verbindlich: Name und Beschreibung einschließlich der Technologie- und Materialoptionen; die Änderung von Primär- und Endenergie in kWh und in Prozent gegenüber dem Zustand vor dem Schritt; die Änderung der operativen Treibhausgasemissionen; die Einsparung in Euro mit offengelegten Energiepreis-Annahmen; und die Zielklasse des Energieausweises nach dem Schritt.

Formal ist der Renovierungspass digital und druckfähig bereitzustellen; Maschinenlesbarkeit in XML ist Empfehlung der Leitlinien, nicht Pflicht. Ausgestellt wird er von einem qualifizierten oder zertifizierten Sachverständigen nach mindestens einem Vor-Ort-Besuch, der ausdrücklich tiefer geht als die Aufnahme für den Energieausweis; bei der Übergabe ist ein Gespräch anzubieten. Artikel 12 Absatz 7 verlangt, dass der Pass in die Datenbank nach Artikel 22 hochladbar ist. Artikel 12 Absatz 8 bestimmt, dass er dort, wo ein digitales Gebäudelogbuch existiert, in diesem zu speichern oder über eine eindeutige URL zugänglich zu machen ist. Nach Artikel 12 Absatz 6 sollen die Mitgliedstaaten ein Fachwerkzeug für Sachverständige bereitstellen, das Bedarfsberechnung und Roadmap mit den Pflichtparametern und offengelegten Standardbedingungen erzeugt und nach Möglichkeit automatische Lock-in-Warnungen ausgibt; ein optionales Laienwerkzeug erzeugt ausdrücklich keinen offiziellen Renovierungspass.

Für den Gebäudepass bedeutet dieses Instrument den Übergang von einem Zustandsmodell zu einer Folge von Plan-Zuständen. Ein Renovierungspfad — etwa Ausgangszustand, Heizung, Fenster, Fassade, Dach, Photovoltaik mit Speicher, Zielzustand — lässt sich abbilden, indem jeder Schritt als eigener, vollständig gerechneter Gebäudezustand gespeichert wird. Nur dann sind die Pflichtfelder des Anhangs VIII überhaupt erzeugbar: die Energiedifferenz je Schritt setzt voraus, dass der Zustand vor und nach dem Schritt gerechnet vorliegt, und die Zielklasse je Schritt setzt voraus, dass für jeden Zwischenzustand eine Klassenzuordnung möglich ist. Je Maßnahme sind mindestens zu führen:

• technische Beschreibung mit Technologie- und Materialoptionen
• Ausgangs- und Zielzustand des betroffenen Bauteils oder Systems
• geplantes Jahr und Abhängigkeiten zu anderen Maßnahmen
• Investitionskosten, Energieeinsparung in kWh und Prozent, Wirkung auf die operativen Treibhausgasemissionen
• Euro-Ersparnis mit offengelegter Preisannahme und Fördermöglichkeiten mit Bezugsquelle
• Zielklasse nach dem Schritt und Bearbeitungsstatus

Der Status verwandelt den Fahrplan in einen fortschreibbaren Prozess: von vorgeschlagen über geplant, beauftragt und in Ausführung bis fertiggestellt und fachlich bestätigt. Genau hier liegt der Mehrwert gegenüber einem als Dokument abgelegten Sanierungsfahrplan. Ist die Fassadendämmung für 2029 geplant und wird sie 2029 ausgeführt, kann der Gebäudepass die tatsächliche Dämmstärke, das eingesetzte Material, Rechnung und Fotos, die realen Kosten, den bewilligten Förderbetrag und den neuen U-Wert an derselben Stelle festhalten. Aus dem Plan wird eine belegte Ausführung, und aus der Ausführung wird der neue Ist-Zustand, der wiederum die vereinfachte Ausweis-Aktualisierung nach Artikel 19 Absatz 14 Buchstabe b trägt.

Das Verhältnis zum deutschen individuellen Sanierungsfahrplan ist dabei genauer zu fassen, als es die verbreitete Gleichsetzung nahelegt. Der iSFP wird in der Renovierungspass-Leitlinie der Kommission zweimal als Best-Practice-Vorbild genannt, insbesondere wegen der Einseiten-Grafik und der schrittbezogenen Förderhinweise. Er ist damit Vorbild, aber kein Renovierungspass im Sinne des Artikels 12: nicht abgedeckt sind die Pflichtangabe der Änderung operativer Treibhausgase je Schritt, die Angaben zu Zirkularität und Whole-Life-Carbon sowie die Liste der nationalen Anforderungen mit Stichtagen. Ob Deutschland den iSFP formal zum Renovierungspass erklärt, ist nicht entschieden; auch die Strukturfrage, ob ein Anhang-VIII-Feldmodell mit iSFP-Darstellung oder das förmliche BAFA-Layout maßgeblich wird, ist offen. Für den Gebäudepass ist daraus die tragfähige Arbeitsteilung abzuleiten: Der iSFP beschreibt den Weg, der Gebäudepass dokumentiert das Gebäude und den tatsächlich erreichten Zustand. Der iSFP wird nicht ersetzt, seine Ergebnisse werden Bestandteil des Passes.

Die vorhandene Plattform trägt hier deutlich weniger weit als beim Energieausweis. Vorhanden sind wesentliche Bausteine: ein iSFP-Datenblatt als reine Ausgabe, Maßnahmen- und Baukostenwerkzeuge einschließlich der Sanierungs-Baukosten mit Sowieso-Anteilen, eine gepflegte Förder-Matrix, Wirtschaftlichkeits- und Finanzierungsrechnungen sowie ein automatisch erzeugter Maßnahmen- und Finanzierungsbericht. Ebenfalls vorhanden ist eine Abhängigkeitskette, die von der Bauteiländerung über U-Wert und Heizlast bis zu Ausweis, CO₂-Bilanz und Finanzierungsbericht durchgerechnet wird. Nicht vorhanden ist ein vollständiger Renovierungspass nach Anhang VIII. Die fünf Pflichtfelder je Schritt sind nicht durchgängig erzeugt, die Stichtagsliste der nationalen Anforderungen fehlt, Zirkularität und Whole-Life-Carbon werden nicht je Schritt ausgewiesen, und ein förderfähiger iSFP entsteht ausschließlich in der amtlichen BAFA-Druckapplikation, für die kein maschinelles Importformat veröffentlicht ist. Das Renovierungspass- und iSFP-Modul ist in der eigenen Planung als vorrangiger offener Punkt geführt.

6.4 Nationale Gebäuderenovierungspläne

Mit den nationalen Gebäuderenovierungsplänen wechselt die Betrachtung vom einzelnen Gebäude auf den gesamten Bestand. Die Mitgliedstaaten müssen darlegen, wie sie die Bestandsziele der Richtlinie erreichen: für Nichtwohngebäude die Absenkung unter die 16-Prozent- beziehungsweise 26-Prozent-Schwellenwerte bis 2030 und 2033, für Wohngebäude eine Minderung des durchschnittlichen Primärenergieverbrauchs um 16 Prozent bis 2030 gegenüber 2020 und um 20 bis 22 Prozent bis 2035 (Artikel 9). Bemerkenswert ist die Verteilungsregel: Mindestens 55 Prozent der bis 2030 zu erbringenden Minderung müssen aus den 43 Prozent schlechtesten Gebäuden stammen. Adressat dieser Pflichten ist ausschließlich der Mitgliedstaat; unmittelbare Pflichten für Eigentümer entstehen erst durch die nationale Umsetzung.

Der Datenbedarf ist damit aggregierter Natur: Wie viele Gebäude existieren, in welchem energetischen Zustand befinden sie sich, welche gehören zum schlechtesten Segment, welche Sanierungsraten werden erreicht, wie entwickelt sich der Bestand in Richtung 2030, 2040 und 2050. Für den Gebäudepass folgt daraus zweierlei. Erstens braucht das Datenmodell ein Merkmal, das die Zugehörigkeit zum schlechtesten Bestandssegment kennzeichnet — ohne ein solches Kennzeichen lässt sich die 55-Prozent-Regel weder planen noch belegen. Zweitens ist strikt zu unterscheiden: Ein einzelner Gebäudepass ist kein nationaler Renovierungsplan. Er kann eine Datenquelle für übergeordnete Auswertungen sein, sofern die rechtlichen und technischen Voraussetzungen dafür bestehen — mehr nicht. Die Kette führt vom einzelnen Gebäude über standardisierte Gebäudedaten und die nationale Datenbank zur aggregierten Bestandsanalyse und erst von dort zur Strategie; die Qualität der Strategie hängt an der Qualität der ersten Stufe.

In der vorhandenen Plattform gibt es keine Aggregationsfunktion über Gebäudebestände und keine Anbindung an eine Bestandsauswertung. Was vorhanden ist, betrifft die Voraussetzungsseite: eine strukturierte, versionierte Erfassung des Einzelgebäudes mit dokumentierter Herkunft je Wert, ein Rechenkern mit ausgewiesenem Rechts- und Normstand und ein Modul, das die Schwellenwertlogik des GMoDG-Worst-First-Ansatzes mit den Faktoren für 2030 und 2033 abbildet. Das ist die Zulieferseite eines Bestandsplans, nicht der Bestandsplan selbst. Eine Auswertung über Portfolios ist konzipiert; sie wird erst dann sinnvoll umsetzbar, wenn feststeht, welche Felder eine nationale Auswertung tatsächlich anfordert.

6.5 Gebäudedatenbanken — Artikel 22

Artikel 22 verlangt seit dem 29. Mai 2026 eine nationale Gebäudedatenbank oder einen Datenbankverbund mit einer öffentlichen Schnittstelle. Aufzunehmen sind Energieausweise — vollständig und nach Artikel 20 Absatz 8 einschließlich aller Berechnungs-Eingangsdaten —, Inspektionsberichte, Renovierungspässe, SRI-Bewertungen sowie berechnete und gemessene Verbräuche. Als Mindest-Rohdatensatz je Ausweis sind Gebäudekategorie, Bezugsfläche mit Aufschlüsselung bei Mischnutzung, der nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Gebäudetechnik disaggregierte Bedarf, Leistung und Effizienz der technischen Anlagen, die installierte Leistung erneuerbarer Erzeugung sowie Flächen und U-Werte der Hauptbauteile zu führen.

Der Zugriff ist abgestuft. Eigentümer, Mieter, Verwalter und — für Portfolios — Finanzinstitute erhalten den vollständigen Ausweis kostenlos, maschinenlesbar und zugleich als Druckdokument. Unabhängige Sachverständige sowie Kauf- und Mietinteressenten erhalten Zugriff nur mit Erlaubnis des Eigentümers, nach Empfehlung befristet und gegebenenfalls als reine Bildschirmansicht. Kommunen erhalten Gebietsdaten mit Geobezug für die Wärmeplanung, die Öffentlichkeit mindestens zweimal jährlich aggregierte und anonymisierte Auswertungen, die Forschung auf Anfrage. Verlangt werden ferner eindeutige, datenbankübergreifende Gebäude- und Einheiten-Identifikatoren mit Geo-Referenz von Anfang an, Interoperabilität mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern (Artikel 22 Absatz 7), maschinenlesbare Formate und eine digitale Schnittstelle. Anhang VI verlangt, dass der Urheber jeder Hinzufügung oder Änderung für die Behörden ermittelbar bleibt. Der Transfer an das Building Stock Observatory erfolgt mindestens einmal jährlich nach den Vorlagen der Durchführungsverordnung (EU) 2025/1328. Bemerkenswert ist die Praxis in Dänemark und Portugal: Dort werden keine PDF-Ausweise gespeichert, der Ausweis wird aus den Rohdaten erzeugt.

Für den Gebäudepass ist die entscheidende Festlegung, dass er nicht mit einer staatlichen Datenbank gleichzusetzen ist. Beide Systeme haben verschiedene Aufgaben: Der Gebäudepass führt den vollständigen operativen Gebäudedatensatz, die nationale Datenbank die gesetzlich oder statistisch erforderliche Teilmenge. Daraus folgt das Prinzip der Datenminimierung an der Schnittstelle. Im Gebäudepass liegen Rechnungen, Fotos, vollständige Bauteilaufbauten, Wartungsverträge und Eigentümernotizen; eine nationale Datenbank benötigt davon nichts, sondern die Gebäudeidentifikation, die Kennwerte, die Klasse, die Emissionen, das Ausstellungsdatum und den Renovierungsstatus. Der interne Datensatz bleibt davon unberührt. Übertragen wird, was verlangt ist — und nur das.

Die vorhandene Plattform bringt für dieses Instrument mehr mit, als der Stand der nationalen Umsetzung derzeit abrufen kann. Vorhanden sind eine persistente, idempotent vergebene Gebäude-ID im Format DG-JJJJ-NNNNNNNN, ein Snapshot-Mechanismus, der für die Veröffentlichung ausschließlich Gebäudekennwerte ohne personenbezogene Daten überträgt, sowie ein öffentlich adressierbarer Pass mit PIN-Absicherung und gestaffelter Sperre nach Fehlversuchen. Vorhanden ist ferner die von Anhang VI geforderte Nachvollziehbarkeit im Kern: Jeder Wert trägt Herkunft, Methode, Erfasser, Datum, Prüfstatus und Version, Änderungen erzeugen eine neue Version statt zu überschreiben, und die Freigabe folgt einem Vier-Augen-Prinzip, bei dem eine Meldung den offiziellen Wert noch nicht verändert. Nicht vorhanden sind die Registerschnittstelle selbst und die Katasteranbindung; beides ist als offener Punkt geführt. Der wesentliche Hemmschuh liegt jedoch außerhalb der Software: Deutschland verfügt zum Quellenstand über keine nationale Energieausweis-Datenbank, das Datenbankschema nach Artikel 22 existiert nicht. Eine Schnittstelle lässt sich nicht gegen eine Spezifikation bauen, die es noch nicht gibt; sinnvoll ist allein, den Datenbestand so zu führen, dass die geforderten Rohdaten vollständig vorliegen, wenn das Schema kommt.

6.6 Datenaustausch — Artikel 16

Artikel 16 regelt den Zugang zu Gebäudesystemdaten. Eigentümer, Mieter und Verwalter erhalten direkten und kostenlosen Zugriff, auch über ein Datenbankkonto; die Weitergabe an selbst benannte Dritte ist ebenfalls kostenlos. Für andere Berechtigte — Banken, Aggregatoren, Versorger, Statistik — dürfen die Mitgliedstaaten Gebühren festlegen. Zum Mindestumfang gehören die Leistungsdaten der Bauteile, die Daten der gebäudetechnischen Dienste, die Lebensdauerprognose der Heizung, die Gebäudeautomation, Zähler, Mess- und Regelgeräte sowie Ladepunkte; die Vorschrift ist ausdrücklich mit dem digitalen Logbuch verknüpft. Wichtig ist die Abgrenzung: Artikel 16 erfasst statische Daten. Dynamische Daten vernetzter Produkte fallen unter den Data Act, Abrechnungsdaten der Zähler unter die Strom- und Gasrichtlinien. Die Durchführungsakte zur Interoperabilität nach Artikel 16 Absatz 5 waren bis zum 31. Dezember 2025 zu erlassen.

Für den Gebäudepass ist beim Datenaustausch nicht das Dateiformat die eigentliche Schwierigkeit, sondern die Semantik. Ein Wert wie „125“ ist ohne Kontext bedeutungslos. Verwendbar wird er erst, wenn Feldbezeichnung, Einheit, Bezugsfläche, Berechnungsstand und Datum mitgeliefert werden — also etwa: Endenergiebedarf 125 kWh/(m²·a), bezogen auf die Nutzfläche nach DIN 277, Berechnung vom 22. August 2026, Datenstand Version 17, gerechnet nach DIN V 18599:2018-09. Zu einem austauschbaren Datensatz gehören deshalb eindeutig benannte Datenfelder, Einheiten, Versionen, Zugriffsrechte, Datenherkunft, Qualitätsstatus und Übertragungszeitpunkt. Erst diese Metadaten machen aus einer Zahl eine Information, die der Empfänger prüfen und weiterverwenden kann.

Technisch folgt daraus, dass ein Dateiexport auf Dauer nicht genügt. Der Gebäudepass benötigt eine standardisierte Schnittstellenarchitektur, die das Lesen definierter Gebäudedaten, das Übergeben neuer Informationen und das Aktualisieren freigegebener Werte erlaubt. Wie diese Schnittstelle im Einzelnen aussieht, hängt von den verbindlichen Spezifikationen ab, die noch ausstehen; unabhängig davon sind die Datenfelder so zu führen, dass sie einer künftigen Spezifikation zugeordnet werden können. Ebenso wenig darf der Austausch für alle Empfänger gleich aussehen. Ein Eigentümer benötigt den vollständigen Zugriff, ein Energieberater die technischen und energetischen Informationen, eine Bank die freigegebenen Energie-, Risiko- und Dokumentendaten, ein Makler die Verkaufsinformationen, eine Behörde die gesetzlich erforderlichen Felder, die Forschung anonymisierte oder aggregierte Daten. Das Rollen- und Berechtigungssystem ist damit kein Zusatz, sondern Bestandteil der Austauscharchitektur; Kapitel 9 behandelt seine datenschutzrechtliche Seite.

In der vorhandenen Plattform stehen die Formatbausteine neben der Rechteschicht. Real vorhanden sind JSON als Projektformat mit Export und Import, CAD-Import über JSON und XML, ein IFC-Eingang ohne korrespondierenden Ausgang, PDF-Erzeugung, CSV, ZIP für die Nachhaltigkeitsdokumentation sowie ein Zertifikats-Export, der die Pflichtangaben nach § 85 maschinenlesbar trägt. Hinzu kommt eine KI-gestützte Plan- und Dokumentenanalyse über eine gemeinsame Ablagezone, die Grundriss, Wärmeschutznachweis und Energieausweis selbst unterscheidet. Nicht vorhanden ist die durchgängige Service-Schnittstelle mit adressierbaren Endpunkten je Rechner, Agent und Prüfmechanismus; sie ist als offener Roadmap-Punkt geführt, ebenso das geschlossene Modul weiterer Exportformate und der Ein-Klick-Import als Kombination aus Schnittstelle und Oberfläche.

Beim Rollenmodell ist besondere Genauigkeit geboten, weil hier leicht mehr behauptet wird, als vorhanden ist. Was existiert, sind Anzeige-Rollen der Kennwerte-Seite — Alle Werte, Architekt, Makler, Hausverwaltung, TGA-Planer, Bank, Energieberater —, die Reihenfolge und Vorauswahl der dargestellten Kennwerte steuern. Das ist eine Priorisierung der Darstellung, keine Rechteschicht. Das abgestufte Zugriffs-Rollenmodell liegt seit dem 23. August 2026 daneben und ist durchgesetzt: zehn Rollen, getrennte Rechte für Lesen, Schreiben, Melden, Freigeben und Exportieren, Sichtbarkeit bis auf die Feldebene, befristete und widerrufbare Zugänge, vollständiges Protokoll. Eigene Freigaben je Empfängertyp — die Auswahl einzelner Felder für einen bestimmten Empfänger — und die Konfliktauflösung bleiben im Datenmodell offene Punkte. Für die Kommunikation nach außen heißt das: Der Gebäudepass ist auf rollenbasierten Austausch vorbereitet, er leistet ihn heute noch nicht.

6.7 Digitales Gebäudelogbuch — Artikel 2 Nummer 41 und Artikel 12 Absatz 8

Beim digitalen Gebäudelogbuch ist zuerst eine Abgrenzung nötig, die häufig unterbleibt: Die EPBD verpflichtet niemanden, ein Logbuch einzuführen. Sie definiert es in Artikel 2 Nummer 41 und knüpft daran konditional an. Artikel 12 Absatz 8 bestimmt, dass der Renovierungspass dort, wo ein Logbuch existiert, in diesem zu speichern oder über eine eindeutige URL zugänglich zu machen ist. Artikel 22 Absatz 7 verlangt, dass die nationale Datenbank mit digitalen Gebäudelogbüchern interoperabel ist. Beide Vorschriften setzen ein Logbuch voraus, sie schreiben es nicht vor. Wer ein Logbuch betreibt, übernimmt damit freiwillig eine Rolle, die die Richtlinie kennt und an die sie anknüpft — mit dem Vorteil, dass die Anknüpfungspunkte bereits definiert sind.

Der Datenbedarf ergibt sich aus dieser Anknüpfungsfunktion. Ein Logbuch muss eine dauerhafte, stabile Gebäudeidentität führen, weil sonst weder die URL-Referenz des Renovierungspasses noch die Interoperabilität mit der Datenbank trägt. Es muss Dokumente und Datensätze miteinander verbinden, damit erkennbar bleibt, welcher Beleg welchen Wert stützt. Es muss eine Historie führen, weil sein Zweck gerade das Gedächtnis des Gebäudes ist. Und es muss adressierbar sein, also eine stabile, extern verwendbare Referenz auf den jeweils gültigen Stand bereitstellen. Als Vorbild nennen die Leitlinien den flämischen Woningpas.

Von allen zehn Instrumenten ist dies dasjenige, bei dem die vorhandene Plattform der Anforderung strukturell am nächsten kommt — was wenig überrascht, da sie als Gebäudepass genau diese Funktion verfolgt. Die eigene Bewertung im EPBD-Anforderungskatalog ordnet den Pass als Gebäudelogbuch im Sinne des Artikels 2 Nummer 41 ein. Belegt vorhanden sind die persistente Gebäude-ID, die Verknüpfung von Dokument und Datensatz über eine ausgewiesene Belegkante, die durchgängige Versionierung mit Datenzuständen von Entwurf über gemeldet und geprüft bis freigegeben, ein Objektgraph mit Wirkbeziehungen zwischen den Datenknoten sowie eine öffentlich adressierbare Passansicht mit eigener Kennung. Nicht vorhanden sind die weitergehenden Identitätsmerkmale der Zielspezifikation — ein national gegliedertes Identifikationsschema, eine eigene Passport-Kennung, maschinenlesbare Kartenmerkmale und Nahfeldkommunikation sind konzipiert, nicht implementiert. Da an all dem keine Pflicht hängt, ist das kein Defizit gegenüber der Richtlinie, sondern eine Frage der eigenen Ausbaustufe.

6.8 Smart Readiness Indicator — Artikel 15

Der Smart Readiness Indicator bewertet, wie gut ein Gebäude auf Nutzer, Energiesysteme und Netze reagieren kann. Sein regulatorischer Status ist derzeit schwächer, als die öffentliche Aufmerksamkeit vermuten lässt. Die Kommission hatte bis zum 30. Juni 2026 einen Bericht vorzulegen; eine Anwendungspflicht entsteht erst durch einen delegierten Rechtsakt, der bis zum 30. Juni 2027 zu erlassen ist, und auch dann nur für Nichtwohngebäude oberhalb von 290 kW Nennleistung. Im Energieausweis ist der SRI nach Anhang V Nummer 2 ein optionaler Zusatz in der Form „ja/nein plus Wert“; die nationale Datenbank soll SRI-Bewertungen aufnehmen können. Bis zum delegierten Rechtsakt ist der SRI im Ausweis damit ein Feld ohne Inhaltspflicht. Anders als für Energieausweis, Renovierungspass, Datenbanken, Datenaustausch, Nullemissionsgebäude und GWP führen die Kommissions-Leitlinien für den SRI keinen eigenen Anhang.

Für den Gebäudepass ist die richtige Reaktion darauf, die Datenseite vorzubereiten und die Bewertungsseite offen zu lassen. Die Datenfelder, die eine spätere SRI-Bewertung benötigt, sind ohnehin auch für andere Zwecke nützlich: Gebäudeautomation und Regelungstechnik, Zähler und Messtechnik, Energiemanagement, steuerbare Wärmeerzeuger, Batteriespeicher, Lastmanagement, Ladeinfrastruktur und flexible Verbraucher. Dieselben Angaben werden von Artikel 16 als Mindestumfang des Datenzugangs verlangt, von Artikel 11 für den Nachweis der Demand-Response-Fähigkeit benötigt und von Anhang V als optionale Ausweisindikatoren aufgeführt. Sie fallen also nicht allein für den SRI an. Inhaltlich verschiebt sich damit die Leitfrage vom Verbrauch zur Betriebsfähigkeit: nicht nur, wie viel Energie ein Gebäude benötigt, sondern wie gut es Energie erzeugen, speichern und zeitlich verlagern kann. Der Gebäudepass dokumentiert diese Anlagen zunächst; die Verknüpfung ihrer Betriebsdaten ist Gegenstand der in Kapitel 5 beschriebenen Ausbaustufe zum digitalen Zwilling.

In der vorhandenen Plattform gibt es keine SRI-Bewertung und kein SRI-Schema — letzteres ist auch national ausdrücklich offen. Vorhanden sind Teile der Datenbasis: Angaben zu Photovoltaik im Bestand, Ladepunkt, intelligentem Zähler und Energiemanagementsystem werden geführt und fließen in die Säule Zukunftsfähigkeit des Building Trust Index ein. Das ist eine hausinterne Bewertung mit offengelegtem Regelwerk, ausdrücklich kein SRI. Die Unterscheidung sollte in jeder Ausgabe erkennbar bleiben, damit eine eigene Kennzahl nicht mit einem künftigen amtlichen Indikator verwechselt wird.

Ein verwandter Punkt betrifft die Leistungsschwelle. Für Gebäudeautomation, Inspektionsintervalle und die künftige SRI-Pflicht kursieren die Werte 70, 100 und 290 kW. Belegt sind 290 kW für die Automationspflicht bei Nichtwohngebäuden, für das dreijährige Inspektionsintervall und für die künftige SRI-Pflicht sowie 70 kW für das fünfjährige Inspektionsintervall und für die zum 31. Dezember 2029 fällige Automations- und Beleuchtungssteuerung. Der Wert 100 kW erscheint in den Quellen ohne Rechtsgrundlage und ist als geltende Schwelle nicht verwendbar. Die vorhandene Plattform behandelt die Schwelle bereits richtig, nämlich als einen Parameter mit ausgewiesener Herkunft statt als über den Code verstreute Konstante — der dort hinterlegte Wert ist jedoch der nicht belegte, und jede Ausgabe muss die verwendete Schwelle nennen.

6.9 Lebenszyklus-GWP und Ökobilanz — Artikel 7 und Anhang III

Mit dem Treibhauspotenzial über den Lebenszyklus verlässt die Richtlinie die reine Betriebsbetrachtung. Anhang III in der Fassung der delegierten Verordnung (EU) 2026/52 legt die Systemgrenzen nach EN 15978 fest, einen Bezugszeitraum von 50 Jahren, die Einheit kg CO₂eq je Quadratmeter Nutzfläche nach IPMS und den Bilanzstand „as built“ — vor Baubeginn wird geschätzt, danach bestätigt. Pflichtmodule sind A1 bis A5, B1 bis B4, B6 sowie C1 bis C4, D1 und D2; B5, B7 und B8 sind optional. Im Ausweis ist je Phasengruppe auszuweisen, zuzüglich eines Gesamtwerts. Für die Datenqualität gilt eine Hierarchie von der Bauproduktenverordnung über Ökodesign und projekt- oder produktspezifische Daten zu generischen Datensätzen nach EN 15804 und erst zuletzt zu Vorgabewerten.

Die Pflichtfristen sind gestaffelt: Ab dem 1. Januar 2028 gilt die GWP-Ausweispflicht für Neubauten über 1 000 m², ab dem 1. Januar 2030 für alle Neubauten. Die Mitgliedstaaten müssen bis zum 1. Januar 2027 einen Fahrplan für Grenzwerte vorlegen; erste Grenzwerte gelten spätestens ab dem 1. Januar 2030 und sinken danach. Für den Bestand besteht keine GWP-Pflicht, mit einer Ausnahme: Wer bei einer Sanierung die freiwillige Klasse A+ anstrebt, muss den GWP-Ausweis führen. Die Leitlinien enthalten in ihrem Anhang zum Lebenszyklus ein Standard-Gebäudedokument als maschinenlesbare Feldliste mit Projektkennung, Typologie, Bewertungstyp, Flächen, Geokoordinaten, GWP je Modul, biogenem Kohlenstoff, einer Datenqualitätsmetrik und dem Photovoltaik-Szenario; Rohdatenbasis ist die Materialliste, die sich aus BIM- beziehungsweise IFC-Modellen gewinnen lässt.

Für den Gebäudepass bedeutet das eine Erweiterung des Datenmodells, aber keine Parallelstruktur. Bislang stehen Geometrie, Energiebedarf, Anlagen und Verbrauch im Vordergrund; für die Ökobilanz kommen Baustoffe, Materialmengen, Bauteilschichten, EPD-Datensätze, Lebensdauern, Austauschzyklen sowie Entsorgungs- und Recyclingannahmen hinzu. Der Vorteil des gemeinsamen Datenkerns zeigt sich hier besonders deutlich. Eine Außenwand wird für die energetische Berechnung ohnehin mit Fläche, Aufbau und U-Wert geführt; für die Ökobilanz treten Materialart, Materialmenge und Umweltkennwerte hinzu. Das Bauteil wird also nicht ein zweites Mal modelliert, es erhält zusätzliche Attribute. Praktisch heißt das, dass die Materialliste kein neues Erfassungsprojekt ist, sondern eine Anreicherung der bestehenden Bauteilbeschreibung.

Daraus entsteht eine Bewertungsmöglichkeit, die energetische und ökologische Wirkung zusammenführt. Eine Fassadendämmung senkt den Heizwärmebedarf, verursacht aber Herstellungsemissionen des Dämmstoffs und vermeidet über die Nutzungsdauer betriebliche Emissionen. Der Gebäudepass kann darstellen, ab welchem Zeitpunkt die vermiedene Betriebsemission die Herstellungswirkung ausgleicht. Damit wird ein Sanierungsszenario mehrdimensional beurteilbar: Eine Variante kann energetisch mittelmäßig, aber in der Herstellung günstig sein, eine andere energetisch sehr gut, dafür in der Herstellung emissionsintensiv und teurer. Erst die gleichzeitige Betrachtung von Energie, betrieblichen Emissionen, Herstellungsaufwand und Kosten erlaubt eine begründete Entscheidung — und erst sie deckt Fälle auf, in denen die energetisch beste Variante über den Lebenszyklus nicht die beste ist.

Die vorhandene Plattform trägt diesen Bereich teilweise. Vorhanden ist ein Ökobilanz-Werkzeug, das für Nichtwohngebäude den projektspezifischen Anforderungswert des Qualitätssiegels Nachhaltiges Gebäude gegen einen amtlich verifizierten Wertekatalog rechnet; im Gebäudepass ist die zugehörige Kachel aktiv. Konsequent umgesetzt ist die Trennung der Emissionsangaben: Die Werte aus Energieausweis, aus der betrieblichen Bilanz und aus der Ökobilanz werden in drei getrennten Karten geführt und bewusst nicht zu einem Gesamtwert verschmolzen — ein eigener Prüfmechanismus überwacht diese Trennung. Das entspricht der Ausweislogik des Anhangs V, die operative Emissionen und GWP nebeneinander stellt. Nicht vorhanden ist die eigentliche Lebenszyklusrechnung: Die grauen Emissionen werden derzeit über einen geschätzten Vergleichswert je Quadratmeter angesetzt, nicht aus Bauteilflächen, Materialmengen und EPD-Datensätzen berechnet. Ebenfalls offen sind die Unterscheidung der Bilanzlogik zwischen Neubau und Sanierung sowie eine Ausgabe je Phasenmodul nach Anhang III. Der IFC-Eingang ist vorhanden und wäre der plausible Weg zur Materialliste; ein IFC-Ausgang fehlt.

6.10 Inspektionsberichte — Artikel 23 und 24

Die Inspektionspflichten für Heizungs- und Klimaanlagen sind das älteste und am wenigsten spektakuläre der hier behandelten Instrumente, für die Datenqualität eines Gebäudepasses aber keineswegs unwichtig. Anlagen über 70 kW sind alle fünf Jahre zu inspizieren, Anlagen über 290 kW alle drei Jahre. Die Inspektionsberichte gehören nach Artikel 22 zu den Inhalten der nationalen Gebäudedatenbank. Bemerkenswert ist die Entlastungsregel: Wo eine Gebäudeautomation nach Artikel 13 Absatz 10 oder 11 vorhanden ist, entfällt die Inspektionspflicht. Hinzu kommt Artikel 13 Absatz 6, wonach nach der Installation eines gebäudetechnischen Systems die Gesamtenergieeffizienz des veränderten Teils zu bewerten, zu dokumentieren und dem Eigentümer zu übergeben ist — eine Dokumentation, die unmittelbar für den Energieausweis nutzbar ist.

Im Gebäudepass gehört ein Inspektionsbericht nicht in eine allgemeine Dokumentenablage, sondern an das Anlagenobjekt, das er betrifft. Eine Wärmepumpe trägt dann ihre eigene Historie: Inbetriebnahme, Inspektionstermine, Feststellungen, daraus abgeleitete Maßnahmen, durchgeführte Wartungen, ausgetauschte Komponenten und der nächste fällige Termin. Aus dieser Zuordnung entsteht mehr als eine Ablage. Sie liefert die Restlebensdauer der Heizung, die Artikel 16 zum Mindestumfang des Datenzugangs zählt und die Anhang V als optionalen Ausweisindikator führt; sie liefert die Grundlage für die von den Leitlinien geforderte Empfehlungspraxis, bei etwa zwei Jahren Restlebensdauer fossilfreie Alternativen zu benennen; und sie liefert im Renovierungspass die zeitliche Begründung dafür, warum ein Heizungstausch an einer bestimmten Stelle der Schrittfolge steht. Wartung wird damit vom Verwaltungsvorgang zum Bestandteil der Anlagenhistorie.

In der vorhandenen Plattform ist die Anlagenseite fachlich gut ausgebaut — Heizlast- und Kühllastberechnung, Erzeugerauslegung einschließlich Trinkwarmwasser, Anlagenkette und Netztypwahl, Jahresarbeitszahl nach VDI 4650 —, die Wartungs- und Inspektionsseite dagegen nicht. Das ist im eigenen Bestand ausdrücklich belegt: Die Säule Wartungszustand des Building Trust Index steht auf null, solange Dokumente und Wartungen nicht mit den Anlagenobjekten verdrahtet sind. Inspektionsberichte werden derzeit also nicht als strukturierte, an das Anlagenobjekt gebundene Datensätze geführt. Die Voraussetzungen dafür — Objektgraph, Belegkanten, Versionierung, Dokumentenerkennung — sind vorhanden; die Verbindung ist nicht hergestellt. Das ist die technisch am einfachsten zu schließende der hier genannten Lücken und zugleich diejenige mit der unmittelbarsten Wirkung auf die Datenqualität.

6.11 Nullemissionsgebäude — Artikel 11

Das Nullemissionsgebäude ist kein weiteres Dokument, sondern der Zielzustand, auf den die übrigen Instrumente zulaufen. Artikel 11 verlangt kumulativ: erstens keinen fossilen Brennstoff vor Ort, womit Gas- und Ölkessel ausgeschlossen sind, während Wärmepumpe, Solarthermie und Biomasse zulässig bleiben; zweitens einen Energiebedarf unterhalb einer nationalen Schwelle, die mindestens 10 Prozent unter dem Niedrigstenergie-Schwellenwert mit Stand 28. Mai 2024 liegen und dauerhaft gelten muss; drittens die Einhaltung einer Treibhausgasschwelle in kg CO₂eq/(m²·a); viertens die Deckung des verbleibenden Bedarfs in der Jahresbilanz aus erneuerbarer Erzeugung vor Ort oder in der Nähe, aus einer Erneuerbare-Energie-Gemeinschaft, aus effizienter Fernwärme oder aus karbonfreien Netzquellen; fünftens die zulässige Kompensation fossilen Netzstroms durch exportierte Erzeugung vor Ort, wobei Photovoltaik-Export mit einem Primärenergiefaktor von −0,9 angerechnet und bei netto null gekappt wird; und sechstens die Demand-Response-Fähigkeit, wo machbar, die zudem im Ausweis auszuweisen ist. Die Termine sind bekannt: ab 1. Januar 2028 Neubauten öffentlicher Einrichtungen, ab 1. Januar 2030 alle Neubauten; die deutsche Umsetzung nennt dieselben Jahre.

Für den Gebäudepass ergibt sich daraus zweierlei. Zum einen wird der Zielzustand hinterlegbar: Statt ihn abstrakt zu formulieren, kann er als gerechneter Gebäudezustand mit Bedarfswert, Emissionswert, Erzeugungsdeckung und Fossilfreiheits-Merkmal geführt und mit einem Datum verbunden werden. Zwischen Ist-Zustand und Zielzustand liegen dann die Schritte des Renovierungspfads, jeder mit eigener Zwischenklasse. Zum anderen ist die Prüflogik anspruchsvoller als ein Kennwertvergleich: Sie erfordert eine Ja-Nein-Prüfung der Fossilfreiheit, zwei Schwellenvergleiche, eine Jahresbilanz mit Bewertung der Deckungsquelle, eine Exportbilanz mit besonderem Faktor und Kappungsregel sowie ein Merkmal zur Demand-Response-Fähigkeit. Alle diese Größen müssen als eigene, dokumentierte Felder vorliegen; keine von ihnen lässt sich aus dem Endenergiewert ableiten.

Die vorhandene Plattform liefert die Rechenseite weitgehend, den Nachweis dagegen nicht. Bedarfsberechnung, Anlagenbilanz, Emissionsrechnung, Photovoltaik im Bestand und die Umstellung der Primärenergie- und Emissionsfaktoren auf den Rechtsstand 2027 sind vorhanden und über einen Registry-Umschalter geführt. Nicht vorhanden ist ein Nullemissionsgebäude-Nachweis als eigenes Modul; er ist in der nationalen Umsetzung ebenso offen wie die zugehörigen Schwellenwerte und Klassengrenzen. Damit gilt hier dieselbe Ordnung wie bei der Gebäudedatenbank: Die Berechnungsgrundlagen können vorbereitet werden, der förmliche Nachweis erst geführt werden, wenn die nationalen Schwellen feststehen. Bis dahin sollte der Gebäudepass den Zielzustand als geplanten Gebäudezustand führen und ihn nicht als bestätigte Konformität ausgeben.

6.12 Ein Datenkern, viele Anwendungen

Nach dem Durchgang durch die zehn Instrumente lässt sich die Ausgangsthese des Kapitels präzisieren. Die Instrumente unterscheiden sich in Zweck, Verbindlichkeit und Adressat, aber sie greifen auf denselben Bestand an Gebäudeinformationen zu: Gebäudeidentität, Geometrie, Gebäudehülle, Nutzung, Anlagentechnik, Energie, Emissionen, Materialien, Dokumente und Historie. Aus diesem Kern entstehen die Anwendungen — die Bilanz nach DIN V 18599, der Energieausweis, der Renovierungspfad, die Förderprüfung, die Ökobilanz, die Wirtschaftlichkeitsbetrachtung, der Datensatz für Nachhaltigkeitsberichte, der Bankenreport, die Immobilieninformation. Die Instrumente sind damit Module über einem Kern, nicht voneinander unabhängige Anwendungen.

Daraus folgt die wichtigste Architekturentscheidung dieses Kapitels: Der Gebäudepass darf nicht um einzelne Dokumente herum entwickelt werden. Wird das Datenmodell aus dem amtlichen Ausweisformular abgeleitet, erzwingt jede Formularänderung einen Eingriff in das Gebäudemodell. Wird umgekehrt ein neutraler Gebäudedatenkern geführt und werden Dokumente und regulatorische Instrumente als Module daran angebunden, lässt sich ein neues Formular austauschen, ohne das Modell neu zu entwickeln. Angesichts des Umfangs dessen, was in der deutschen Umsetzung noch offen ist — das amtliche Ausweismuster, das Datenformat des Lebenszyklusberichts, die Klassengrenzen für Nichtwohngebäude, das SRI-Schema, das Datenbankschema nach Artikel 22, der Nullemissionsgebäude-Nachweis —, ist diese Entscheidung nicht theoretisch, sondern die Bedingung dafür, dass die Plattform die kommenden Jahre übersteht.

Der Gebäudepass wirkt damit als Übersetzungsschicht zwischen zwei Welten. Auf der einen Seite stehen die realen Gebäudeeigenschaften: Bauteile, Anlagen, Verbräuche, Belege. Auf der anderen Seite stehen EPBD, nationales Recht, DIN V 18599, Förderprogramme, Kreditwirtschaft und Immobilienwirtschaft, jeweils mit eigenen Begriffen, Bezugsgrößen und Formaten. Der Gebäudepass macht aus Gebäudeeigenschaften strukturierte Daten, aus strukturierten Daten Berechnungen und aus Berechnungen regulatorisch und wirtschaftlich verwendbare Informationen. Jede dieser Übersetzungen muss ihre Herkunft mitführen — sonst entsteht statt Übersetzung eine Behauptung.

6.13 Übersicht

Die folgende Tabelle fasst den Durchgang zusammen. Die Spalte „Pflicht/optional“ bezieht sich auf die Richtlinie und benennt zugleich den Adressaten, weil dieser Unterschied in der Praxis regelmäßig verwischt wird: Alle Pflichten der EPBD richten sich an den Mitgliedstaat; Eigentümer und Aussteller werden erst durch GEG und GMoDG gebunden. Die Spalte „Stand im Gebäudepass“ gibt den belegten Entwicklungsstand wieder, nicht eine Zielvorstellung.

Die Übersicht zeigt ein klares Muster. Dort, wo die Anforderung aus einer Berechnung entsteht — Energieausweis, Wärmeschutznachweis, Bedarfs- und Emissionswerte —, trägt die vorhandene Plattform bereits produktiv. Dort, wo die Anforderung aus einer festgelegten Ausgabestruktur entsteht — Anhang-VIII-Renovierungspass, Anhang-V-Datensatz, Anhang-III-Modulausgabe —, ist die Datenbasis überwiegend vorhanden, die normierte Ausgabe aber noch nicht. Und dort, wo die Anforderung eine Gegenstelle voraussetzt — Registrierung, Datenbankanbindung, Rollenmodell für externe Empfänger —, hängt die Umsetzung an Spezifikationen, die national noch nicht vorliegen. Diese Dreiteilung sollte die Entwicklungsplanung leiten: erst die Ausgabestrukturen schließen, deren Datenbasis bereits steht, dann die Schnittstellen bauen, sobald ihre Spezifikation existiert.

7 Funktionsarchitektur des digitalen Gebäudepasses

Das in Kapitel 4 beschriebene Gebäudedatenmodell legt fest, welche Informationen zu einem Gebäude gespeichert werden. Die Funktionsarchitektur beantwortet die anschließende Frage: Was geschieht mit diesen Informationen? Dieses Kapitel beschreibt die zehn Funktionsbausteine, aus denen der digitale Gebäudepass besteht — jeweils mit Zweck, Eingangsdaten, Ergebnissen und Abhängigkeiten zu den übrigen Bausteinen. Für jeden Baustein wird getrennt ausgewiesen, was Zielbild ist und was die vorhandene Software heute leistet.

7.1 Vom Datenmodell zur operativen Plattform

Ein Datenmodell allein erzeugt keinen Nutzen. Erst die Fachlogik, die auf diesen Daten arbeitet, macht aus einer Datenbank eine operative Plattform: Berechnungen, die aus Bauteilen und Anlagen Kennwerte ermitteln; Prüfungen, die diese Kennwerte auf Vollständigkeit und Widerspruchsfreiheit kontrollieren; Dokumente, die das Ergebnis in eine rechtlich verwertbare Form bringen; Schnittstellen, die es an Register, Banken und Behörden weiterreichen. Der digitale Gebäudepass benötigt dafür unterschiedliche Fachmodule, die alle auf denselben Gebäudedatenkern zugreifen.

Die Grundarchitektur verläuft in einer Kette vom Datenkern über die Fachmodule, die Berechnungen, die Prüfungen, die Dokumente und die Schnittstellen bis zu den Nutzern und externen Systemen. Der entscheidende Vorteil dieser Anordnung ist nicht die Kette selbst, sondern ihr Ausgangspunkt: Alle Module verwenden denselben aktuellen Gebäudedatensatz. Eine Außenwand, deren U-Wert nach einer Sanierung von 1,4 auf 0,18 W/(m²K) sinkt, ändert damit gleichzeitig die Heizlast, die Bilanz nach DIN V 18599, den Wärmeschutznachweis, die Energieeffizienzklasse, die CO₂-Bilanz und die Wirtschaftlichkeitsrechnung — ohne dass der Wert an sechs Stellen erneut eingegeben werden müsste. In getrennten Programmen entsteht genau an dieser Stelle der typische Fehler: dieselbe Außenwand trägt in vier Anwendungen vier verschiedene Werte, und keiner der Beteiligten kann sagen, welcher der richtige ist.

Der Gebäudepass sollte deshalb nicht als Sammlung einzelner Programme entstehen, sondern als zentraler Datenkern mit darauf aufsetzenden Funktionsmodulen. Die Architektur lässt sich in sechs Ebenen gliedern, die klar voneinander getrennt bleiben:

• Ebene 1 — Daten. Gebäudeidentität, Geometrie, Bauteile, Anlagen, Nutzung, Energie- und Emissionsdaten, Materialien, Dokumente und Historie. Diese Ebene enthält keine Rechenvorschrift und kein Regelwerk.
• Ebene 2 — Fachlogik. Bilanzierung nach DIN V 18599, Heizlast und Kühllast, Bauphysik, Ökobilanz, Wirtschaftlichkeit und Förderung. Hier liegen die Verfahren, die aus Daten Ergebnisse machen.
• Ebene 3 — Qualität. Datenvalidierung, Plausibilitätsprüfung, Vollständigkeits- und Versionsprüfung. Diese Ebene entscheidet, ob ein Ergebnis überhaupt verwendet werden darf.
• Ebene 4 — Dokumente. Energieausweis, Wärmeschutznachweis, Renovierungspass, Fach- und Förderberichte. Dokumente sind Ausgaben, keine eigenständigen Datenhalter.
• Ebene 5 — Schnittstellen. XML, JSON, CSV, Programmierschnittstellen, IFC sowie die Verbindungen zu Registern, Banken und Behörden.
• Ebene 6 — Nutzer. Eigentümer, Energieberater, Architekten und TGA-Planer, Banken, Makler, Hausverwaltungen und Behörden — jeweils mit unterschiedlichem Ausschnitt derselben Datenbasis.

Die Trennung dieser Ebenen ist keine Ordnungsfrage, sondern eine Voraussetzung für Wartbarkeit. Regelwerke der Ebene 2, Prüfregeln der Ebene 3 und Ausgabeformate der Ebene 4 ändern sich im Gebäudeenergierecht im Jahresrhythmus; die Ebenen 1 und 6 verändern sich erheblich langsamer. Wer Rechenvorschriften und Ausgabeformate in die Datenhaltung einbaut, muss bei jeder Gesetzesänderung den Datenbestand anfassen. Wer sie trennt, tauscht ein Modul.

Die vorhandene Software folgt dieser Trennung bereits in ihrer Grundstruktur. Der Datenkern ist ein globaler Projektspeicher mit Pfadzugriff, der die Projektdaten als JSON-Objekt je Gebäude hält und Ergebnisse getrennt von Eingaben unter einem eigenen Zweig ablegt; die Rechenkerne für die Bedarfsbilanz, die Anlagentechnik, das Referenzgebäude und die Monatsbilanz liegen als eigene Engines daneben. Ein Audit vom 10. August 2026 weist 74 Werkzeuge, 64 Registerfelder und 96 Projekte aus. Ergänzend regelt ein Rollenmodell der Schreibrechte, welches Werkzeug welchen Datenbereich beschreiben darf: Der Gebäudesteckbrief ist Quelle, der CAD- und der Geschoss-Editor sind Ermittler, die Rechenwerkzeuge schreiben ausschließlich in den Ergebniszweig, und die Ausgabewerkzeuge — Berichte und Pass — schreiben überhaupt nicht. Dieses Modell ist seit dem 23. August 2026 technisch erzwungen: Die Auswertung von 1.258 Schreibzugriffen zählt 0 Verstöße, nachdem die 55 Altfälle abgearbeitet wurden. 35 Registerfelder haben weiterhin mehrere schreibende Werkzeuge, jeder dieser Schreibvorgänge ist jedoch benannt und an eine Nutzerhandlung gebunden; 58 Aufrufe mit dynamisch gebildetem Pfad bleiben der statischen Prüfung entzogen. Die Architektur ist also angelegt, ihre Durchsetzung steht aus.

7.2 Baustein 1 — Digitale Gebäudeakte

Die digitale Gebäudeakte bildet die dokumentarische Basis des Systems. Sie ist der Ort, an dem alles zusammenläuft, was ein Gebäude an Papier hervorbringt: Baupläne, statische und energetische Berechnungen, Genehmigungen, Energieausweise, Rechnungen, Produktdatenblätter, Förderbescheide, Wartungsunterlagen, Fotos und Prüfberichte. Der Zweck des Bausteins ist zunächst banal — nichts geht verloren. Sein eigentlicher Wert entsteht jedoch erst eine Stufe darüber.

Denn die reine Speicherung von Dateien erzeugt lediglich ein digitales Archiv. Ein Ordner mit 300 PDF-Dateien ist gegenüber einem Aktenschrank mit 300 Blatt Papier kaum im Vorteil. Aus einem Dateispeicher wird erst dann eine Gebäudeakte, wenn jedes Dokument strukturierte Metadaten trägt:

• Dokumenttyp und Ausstellungsdatum,
• Gültigkeit beziehungsweise Ablaufdatum,
• Aussteller mit Qualifikation,
• betroffener Gebäudeteil, Geschoss oder Zone,
• zugehöriges Bauteil oder zugehörige technische Anlage,
• Qualitätsstatus und Prüfvermerk.

Erst diese Metadaten machen ein Dokument auffindbar, prüfbar und verknüpfbar. Ein Prüfbericht ohne Ausstellungsdatum lässt sich nicht auf Aktualität prüfen; ein Produktdatenblatt ohne Bauteilbezug lässt sich keinem U-Wert zuordnen.

Dokumente als Evidenz

Die zentrale Funktion der Gebäudeakte besteht darin, Dokumente mit Datenwerten zu verbinden. Ein einzelner Zahlenwert im Datenmodell — etwa ein Fenster mit einem U-Wert von 0,82 W/(m²K) — wird dadurch belegbar: Das Produktdatenblatt des Herstellers weist den Wert aus, die Rechnung belegt den Einbau, die Fachunternehmererklärung bestätigt die fachgerechte Ausführung. Jeder Nutzer kann damit die Frage beantworten, die über die Verwertbarkeit eines Gebäudedatensatzes entscheidet: Woher stammt dieser Wert?

Diese Evidenzebene ist für externe Nutzer wesentlich. Ein Energieberater kann eine Angabe fachlich einordnen, weil er das Gebäude kennt. Eine Bank, die ein Portfolio bewertet, kann das nicht — sie braucht die Herkunft des Werts, weil sie die Belastbarkeit ihrer eigenen Bewertung dokumentieren muss. Die EPBD verstärkt diese Anforderung von zwei Seiten: Artikel 20 Absatz 8 verlangt, dass der Energieausweis vollständig einschließlich aller Berechnungs-Eingangsdaten in die nationale Datenbank eingeht, und Anhang VI verlangt, dass der Urheber jeder Hinzufügung und jeder Änderung für die Behörden ermittelbar bleibt. Eine Gebäudeakte, die nur Dateien ablegt, kann beides nicht leisten.

Abhängigkeiten. Die Gebäudeakte ist Vorleistung für nahezu alle übrigen Bausteine. Sie liefert der KI-gestützten Analyse (Abschnitt 7.10) das Ausgangsmaterial, dem Prüf- und Freigabeprozess (Abschnitt 7.11) die Belege, dem Fördermittelmodul (Abschnitt 7.5) die geforderten Nachweise und der Bankensicht die Evidenzkette. Umgekehrt erhält sie von jedem Modul neue Dokumente zurück.

Stand. Vorhanden sind der Projektspeicher mit automatischer, entprellter Sicherung in den Projektdatensatz — jede Speicherung schreibt an derselben Stelle weiter, nur bei echter Änderung, und legt zuvor eine Sicherung an, von denen die letzten zwanzig vorgehalten werden. Vorhanden ist ferner die Beziehungsschicht, die Dokument und Datensatz über eine Kante „belegt durch" verknüpft, und die Herkunftskennzeichnung, die zu jedem Wert Quelle, Methode, Erfasser, Datum, Prüfstatus und Version führt. Die dokumentarische Vollständigkeit wird über eine Checkliste mit 23 Pflichtfeldern in acht Kategorien geprüft, jeweils mit Priorität und Sprungziel. Noch nicht verdrahtet ist die Wartungs- und Dokumentenseite im engeren Sinne: Die entsprechende Säule des Gebäude-Vertrauensindex steht ausdrücklich so lange auf null, wie Dokumente und Wartungen nicht angebunden sind. Ein durchgängiger Metadatenkatalog je Dokument und eine Zeitleiste der Gebäudeereignisse sind konzipiert, aber nicht umgesetzt.

7.3 Baustein 2 — Energieausweis-Modul

Das Energieausweis-Modul erzeugt aus dem Gebäudedatenkern das zentrale Dokument der EPBD. Es greift dafür auf Gebäudeart, Bezugsfläche, Geometrie, Hüllbauteile mit ihren U-Werten, Anlagentechnik, Nutzungsprofil und die energetischen Kennwerte zu und übernimmt fünf Aufgaben: die Berechnung beziehungsweise Übernahme der Kennwerte, die Zusammenstellung der Ausweisdaten, die Plausibilitätskontrolle, die Dokumenterzeugung und die Versionierung samt Registrierdaten.

Der Umfang der Pflichtangaben ist durch Anhang V der EPBD abschließend beschrieben und geht deutlich über den heutigen deutschen Ausweis hinaus. Auf der Titelseite stehen die Effizienzklasse, die jährliche Primärenergie und die jährliche Endenergie jeweils in kWh/(m²·a) und je Energieträger, der Anteil erneuerbarer Energie vor Ort in Prozent sowie die operativen Treibhausgasemissionen in kg CO₂eq/(m²·a), ergänzt um das Lebenszyklus-Treibhauspotenzial in kg CO₂eq/m², sofern verfügbar. Hinzu kommen der Energiebedarf je System, die Demand-Response-Fähigkeit und die Niedertemperaturfähigkeit des Verteilsystems jeweils als Ja-/Nein-Angabe sowie die Kontaktdaten der zentralen Anlaufstelle. Die Skala ist ab dem 29. Mai 2026 als geschlossene Skala A bis G verbindlich, wobei Klasse A dem Nullemissionsgebäude vorbehalten bleibt: Ein Gebäude mit Gaskessel, das den Rechenwert erreicht, wird auf B eingestuft.

Zwei Anforderungen prägen die Modularchitektur besonders. Erstens muss der Ausweis digital und maschinenlesbar sein — CSV, JSON oder XML; ein gescanntes PDF genügt ausdrücklich nicht. Zweitens verlangt Artikel 19 Absatz 14 vereinfachte Aktualisierungen, und zwar nach Einzelmaßnahmen, nach umgesetzten Schritten eines Renovierungspasses und über einen digitalen Zwilling beziehungsweise zertifizierte Werkzeuge. Buchstabe c dieser Vorschrift ist die ausdrückliche Rechtsgrundlage dafür, dass ein Gebäudepass als Datenquelle des Ausweises dient. Genau darin liegt die strategische Bedeutung dieses Bausteins.

Energieausweis als Modul statt als Datensilo

Der entscheidende Punkt ist deshalb ein negativer: Der Energieausweis besitzt keinen eigenen, isolierten Gebäudedatensatz. Er verwendet denselben Datenkern wie die Heizlastberechnung, der Renovierungspass, die Ökobilanz und die Wirtschaftlichkeitsrechnung. Damit ist ausgeschlossen, dass dieselbe Außenwand in der Ausweisberechnung anders angesetzt wird als in der Heizlast — ein Fehler, der in getrennt geführten Programmen regelmäßig auftritt und im Nachhinein kaum aufzuklären ist.

Abhängigkeiten. Das Modul bezieht die Bilanzergebnisse aus der Fachlogik nach DIN V 18599 (Abschnitt 7.7), das Treibhauspotenzial aus dem Ökobilanzmodul (Abschnitt 7.8), den Renovierungspass-Verweis aus Abschnitt 7.4 und den Freigabestatus aus Abschnitt 7.11. Es liefert seinerseits die Effizienzklasse an den Vertrauensindex, an die Bankensicht und an die Registerschnittstelle.

Stand. Das Modul ist produktiv. Der Gebäudepass erzeugt bei vollständigem Energiekern automatisch einen Bedarfsausweis als PDF, versieht ihn mit einer deterministisch aus der Gebäude-ID abgeleiteten Ausweisnummer und erzeugt eine neue Version, sobald sich die Endenergie ändert; die zugehörige Kachel warnt, wenn das abgelegte Dokument von den aktuellen Daten abweicht. Für den Verbrauchsausweis besteht bereits ein Umschalter zwischen dem bisherigen Verfahren mit drei Abrechnungsperioden und der nach Energieträgern differenzierten, mindestens monatlichen Erfassung über 24 Monate, die § 80 GMoDG verlangt. Ausdrücklich nicht vorhanden ist eine amtliche Registriernummer — die erzeugte Nummer ist eine interne Kennung, keine Registrierung beim Deutschen Institut für Bautechnik. Offen sind ferner die Ausweisarten, die Gültigkeitsführung und die getrennte Ausweisung der CO₂-Angabe aus dem Ausweis. Die vom Werkzeug verwendete Klassenskala folgt noch dem bisherigen deutschen Zuschnitt von A+ bis H; die Klassengrenzen B bis F für Nichtwohngebäude nach Anlage 10a sind im Rechtsstandregister als Lücke geführt, und die Klassenfunktion für Nichtwohngebäude gibt zwischen A und G bewusst keinen Wert zurück, statt einen zu erfinden.

7.4 Baustein 3 — Renovierungspass

Während der Energieausweis den heutigen Zustand beschreibt, erzeugt der Renovierungspass mögliche zukünftige Zustände. Er baut auf dem Ist-Zustand auf und führt über eine Folge von Maßnahmen und Zwischenzuständen zu einem Zielzustand. Zu jedem Schritt werden die technischen Maßnahmen, die resultierenden Energiekennwerte, die Investitionskosten, die Emissionen, die Fördermöglichkeiten und der vorgesehene Zeitpunkt gespeichert. Aus einer Empfehlung wird damit ein Transformationspfad.

Anhang VIII der EPBD gibt den Inhalt vor und ist für die Datenstruktur des Moduls maßgeblich. Gefordert sind die aktuelle Gesamtenergieeffizienz mindestens als Primärenergie im Ist-Zustand, eine grafische Roadmap vom Ausgangs- zum Endzustand, die nationalen Anforderungen einschließlich ihrer Stichtage sowie eine Begründung der optimalen Schrittfolge — letztere ausdrücklich zur Vermeidung von Lock-in-Effekten. Je Schritt sind fünf Felder verbindlich: Name und Beschreibung einschließlich der Technologie- und Materialoptionen; die Änderung von Primär- und Endenergie in kWh und in Prozent gegenüber dem Zustand vor dem Schritt; die Änderung der operativen Treibhausgase; die Kostenersparnis in Euro mit offengelegten Energiepreisannahmen; und die Ziel-Effizienzklasse nach dem Schritt. Hinzu kommen die Anschlussoption an Fernwärme oder Fernkälte, der Anteil erneuerbarer Energien und der Eigenverbrauch nach der Sanierung, Aussagen zur Zirkularität der Bauprodukte und zum Lebenszyklus-Kohlenstoff sowie Förderhinweise mit Links und die Kontaktdaten der zentralen Anlaufstellen.

Für die Zielbestimmung gilt: Eine umfassende Renovierung führt vor dem 1. Januar 2030 auf das Niedrigstenergiegebäude, ab dem 1. Januar 2030 auf das Nullemissionsgebäude; ist das nicht machbar, gilt eine Reduktion des Primärenergiebedarfs um mindestens 60 Prozent als Rückfalloption. Der Pass ist digital und druckfähig bereitzustellen; maschinenlesbares XML ist Empfehlung, nicht Pflicht. Zwei Kopplungen sind für die Architektur wichtig: Nach Artikel 19 Absatz 6 ersetzt der Renovierungspass bei gemeinsamer Ausstellung die Modernisierungsempfehlungen des Energieausweises, und nach Artikel 12 Absatz 8 ist er dort, wo ein digitales Gebäudelogbuch existiert, in diesem zu speichern oder über eine eindeutige Adresse zugänglich zu machen. Für Eigentümer bleibt der Pass freiwillig; verpflichtet ist allein der Mitgliedstaat zur Bereitstellung eines Systems.

Szenarien statt einer statischen Empfehlung

Ein einziger Pfad wird der Entscheidungssituation vieler Eigentümer nicht gerecht. Sinnvoll ist deshalb der Vergleich mehrerer Szenarien: eine Variante mit minimaler Investition, eine wirtschaftlich optimierte Sanierung, eine Variante mit maximaler Energieeinsparung und eine Variante mit dem Ziel Nullemissionsgebäude. Erst der Vergleich macht sichtbar, was die EPBD mit der Begründungspflicht zur Schrittfolge meint: Eine Maßnahme, die für sich genommen wirtschaftlich ist, kann einen späteren Schritt versperren — eine neue Fassade ohne ausreichende Dämmstärke bindet den Gebäudezustand für Jahrzehnte. Aus einer Empfehlung wird so ein Entscheidungsmodell.

Abhängigkeiten. Der Renovierungspass ist der am stärksten vernetzte Baustein. Er bezieht den Ausgangszustand aus dem Energieausweismodul, die Maßnahmenwirkung aus der Bauphysik- und Anlagenrechnung, die Kosten aus dem Kostenmodul, die Fördersätze aus dem Fördermittelmodul, die Wirtschaftlichkeit aus Abschnitt 7.6 und die Emissionswirkung aus dem Ökobilanzmodul. Er liefert zurück: die Zielklassen je Schritt an den Ausweis und den Maßnahmenplan an das Eigentümer- und das Bankenprofil.

Stand. Teilweise vorhanden. Eine eigene Renovierungspass-Engine mit Faktortabellen existiert, ebenso ein Maßnahmenbericht als automatisch erzeugtes Dokument und ein iSFP-Datenblatt als reine Ausgabe. Wichtig ist die rechtliche Abgrenzung: Ein förderfähiger individueller Sanierungsfahrplan entsteht ausschließlich in der amtlichen Druckapplikation des Bundesamts für Wirtschaft und Ausfuhrkontrolle; ein maschinelles Importformat veröffentlicht diese Anwendung nicht. Der deutsche iSFP wird in der Renovierungspass-Leitlinie der Kommission zweimal als Best-Practice-Vorbild genannt, ist damit aber kein Renovierungspass im Sinne des Artikels 12 — nicht abgedeckt sind insbesondere die Änderung der operativen Treibhausgase je Schritt, die Zirkularität und der Lebenszyklus-Kohlenstoff sowie die Stichtagsliste. Ob Deutschland den iSFP formal zum Renovierungspass erklärt, ist nicht entschieden. Der oben beschriebene Szenarienvergleich ist konzipiert, aber nicht umgesetzt: Sanierungsvarianten und Neubauzustände stehen in der Entwicklungsplanung als offener Punkt.

7.5 Baustein 4 — Fördermittelmodul

Das Fördermittelmodul verbindet technische Maßnahmen mit den dafür verfügbaren Förderprogrammen. Seine Prozesslogik führt von der Sanierungsmaßnahme über die technischen Anforderungen zum passenden Programm, prüft die Förderfähigkeit, ermittelt den möglichen Förderbetrag, begleitet den Antragsprozess und dokumentiert das Ergebnis. Der Nutzen liegt weniger in der Rechenoperation als in der Vollständigkeit: Ein Eigentümer erfährt bereits in der Planungsphase, welche Anforderung er erfüllen muss, damit eine Maßnahme förderfähig bleibt, und nicht erst nach der Beauftragung.

Damit das funktioniert, muss jede Förderregel als eigenes Datenobjekt geführt und versioniert werden. Eine Regel besteht sinnvollerweise aus:

• Programm und Programmvariante,
• Gültigkeit von und Gültigkeit bis,
• Gebäudeart und Nutzungsart,
• geförderter Maßnahme,
• technischer Mindestanforderung,
• Förderquote und Höchstbetrag,
• Boni und Zuschlägen,
• Kombinationseinschränkungen mit anderen Programmen,
• erforderlichen Nachweisen.

Das Gültigkeitsdatum ist dabei kein Nebenfeld, sondern die Voraussetzung dafür, dass ein Förderergebnis später überhaupt nachvollziehbar bleibt. Förderbedingungen ändern sich mehrfach im Jahr; ohne Datumsbezug lässt sich in drei Jahren nicht mehr feststellen, nach welcher Fassung ein Antrag gerechnet wurde. Aus demselben Grund benötigt jedes Gebäude eine eigene Förderhistorie mit den gestellten, bewilligten und abgelehnten Anträgen, den ausgezahlten Mitteln, den verwendeten Programmen und den zugehörigen Maßnahmen. Sie beantwortet die für Folgeanträge entscheidende Frage, welche Förderung für welche Sanierung bereits eingesetzt wurde — und verhindert Doppelförderungen, die im Nachhinein zurückgefordert werden.

Abhängigkeiten. Das Modul erhält die Maßnahmen aus dem Renovierungspass, die technischen Kennwerte aus der Bauphysik- und Anlagenrechnung und die Kosten aus dem Kostenmodul; es liefert Förderbeträge an die Wirtschaftlichkeitsberechnung, Nachweisanforderungen an die Gebäudeakte und Förderhinweise an den Renovierungspass, wo Anhang VIII Buchstabe i sie ausdrücklich verlangt.

Stand. Teilweise vorhanden. Eine administrativ gepflegte Fördermatrix, ein Werkzeug für die Konditionen der Förderbank sowie die Kostenwerkzeuge für Neubau und Sanierung sind im Einsatz; die Regeln für die Honorarzuschüsse sind hinterlegt, einschließlich der Unterscheidung, dass die beiden Zuschusstöpfe zu je 50 Prozent neben den Höchstkosten stehen und dass die Beträge von 650 beziehungsweise 850 Euro für den Sanierungsfahrplan Höchstzuschüsse und keine Kostengrenzen sind. Die durchgängige Versionierung jeder Förderregel mit Gültigkeitszeitraum und die gebäudebezogene Förderhistorie sind konzipiert, aber nicht umgesetzt; im Pflichtenheft ist der Förderbereich als teilweise abgedeckt geführt.

7.6 Baustein 5 — Finanzierungs- und Wirtschaftlichkeitsberechnung

Technische Machbarkeit entscheidet nicht über die Umsetzung einer Sanierung; die Finanzierbarkeit tut es. Deshalb sollte jede Maßnahme und jeder Renovierungsschritt mit einer Finanzierungs- und Wirtschaftlichkeitsrechnung verbunden werden können. Als Kennwerte kommen in Betracht: Investitionskosten, Förderung, Eigenanteil, Finanzierungsbetrag, Zinssatz, Laufzeit, Betriebskosten, Energieeinsparung, Wartungskosten, Amortisationszeit und Kapitalwert. Damit beantwortet das System nicht nur die Frage, was technisch möglich ist, sondern auch die, was wirtschaftlich sinnvoll ist — und in welcher Reihenfolge.

Der Baustein ist der deutlichste Beleg für den Nutzen eines gemeinsamen Datenkerns, weil er ausschließlich aus Ergebnissen anderer Module lebt: Die Bilanz nach DIN V 18599 liefert die Energieeinsparung, das Fördermittelmodul den Förderbetrag, das Kostenmodul die Investitionskosten, das Finanzierungsmodul die Kreditbelastung. Erst die Zusammenführung ergibt eine belastbare Gesamtbetrachtung — und erst sie zeigt den in der Praxis häufigen Fall, dass die monatliche Belastung aus Kredit und Energiekosten nach der Sanierung niedriger liegt als die Energiekosten davor.

Für den Renovierungspass ist die Verbindung zusätzlich normativ vorgezeichnet: Anhang VIII fordert die Kostenersparnis je Schritt mit offengelegten Energiepreisannahmen und nennt die Amortisation mit und ohne Förderung als optionale Angabe. Offengelegt heißt dabei, dass die Annahmen im Dokument stehen müssen — eine Wirtschaftlichkeitsrechnung ohne sichtbare Preis- und Zinsannahmen ist für den Adressaten wertlos.

Abhängigkeiten. Eingang aus den Abschnitten 7.4, 7.5, 7.7 und 7.8; Ausgang an das Eigentümerprofil, an den Renovierungspass und an den Finanzierungsbericht für die Bankensicht.

Stand. Teilweise vorhanden, mit einer klar benannten Lücke. Vorhanden sind ein achtstufiger Leistbarkeitsassistent mit Ampelbewertung, den Varianten A bis D und einem Tilgungsplan für Bank- und Förderdarlehen, ein Übergabeweg in das Finanzierungswerkzeug, die Kostenwerkzeuge für Neubau und Sanierung — letzteres mit einer eigenen Spalte für Sowieso-Anteile — sowie die Marktwertermittlung. Der Finanzierungsbericht wird als automatisches Dokument erzeugt, und die Abhängigkeitskette führt von der Bauteilfreigabe über U-Wert und Heizlast bis zu diesem Bericht. Die entscheidende Einschränkung: Der Leistbarkeitsassistent ist bislang ohne Anbindung an den Projektspeicher, arbeitet also noch nicht auf dem gemeinsamen Gebäudedatensatz. Zwei weitere Befunde sind dokumentiert und offen — eine Konstellation mit einer Monatsrate von null Euro bei negativer Nettobelastung sowie die Marktwertermittlung für Nichtwohngebäude, deren Ertragswert derzeit null ergibt. Ebenfalls offen ist, dass die Sowieso-Anteile in keinem der geführten Projekte tatsächlich erfasst sind; die Spalte existiert, die Daten fehlen.

7.7 Baustein 6 — Bauphysik und technische Gebäudeausrüstung

Neben der energetischen Gesamtbilanz benötigt der Gebäudepass eine Reihe weiterer bauphysikalischer Berechnungen: U-Werte, Wärmebrücken, sommerlicher Wärmeschutz, Feuchteschutz, Heizlast, Kühllast und Lüftungskonzept. Diese Berechnungen greifen weitgehend auf dieselben Grunddaten zu. Ein Fenster mit Fläche, U-Wert und Orientierung wird gleichzeitig für die Heizlast, für die Bilanz nach DIN V 18599, für den Nachweis des sommerlichen Wärmeschutzes und für die Kühllast benötigt. Werden diese Werkzeuge getrennt geführt, wird dasselbe Fenster viermal eingegeben — und spätestens beim dritten Mal abweichend.

Das TGA-Modul bildet die technische Gebäudeausrüstung ab: Heizung, Trinkwarmwasser, Lüftung, Kühlung, Beleuchtung, Gebäudeautomation, Photovoltaik und Speicher. Entscheidend ist, dass es Anlagen nicht nur speichert, sondern ihre Beziehungen zu den Gebäudezonen abbildet. Eine Wärmepumpe versorgt nicht „das Gebäude", sondern bestimmte Zonen und gegebenenfalls die Trinkwarmwasserbereitung. Erst diese Zuordnung erzeugt ein Anlagenmodell, aus dem sich eine zonenweise Bilanz für Nichtwohngebäude, eine sinnvolle Erzeugerauslegung und eine belastbare Aussage zur Netz- und Systemtemperatur ableiten lassen. Letzteres gewinnt an Bedeutung, weil die Niedertemperaturfähigkeit des Verteilsystems nach Anhang V im Ausweis auszuweisen ist und die Kommissionsleitlinien sie über eine Auslegungstemperatur von höchstens 45 °C beziehungsweise saisonal 42 °C definieren, ermittelt in vier Schritten von der Heizlast über die Heizkörperleistung und den Volumenstrom zur Systemtemperatur.

Abhängigkeiten. Der Baustein ist der Rechenkern der Plattform. Er bezieht Geometrie und Bauteile aus dem Datenkern und liefert Kennwerte an den Energieausweis, an den Renovierungspass, an die Ökobilanz, an die Wirtschaftlichkeitsrechnung und an den Wärmeschutznachweis.

Stand. Weitgehend vorhanden und der am besten abgesicherte Bereich der Plattform. Im Einsatz sind die Bedarfs-Engine nach Teil 2 der DIN V 18599 einschließlich der Heizzeitermittlung nach Anhang D.2, die im August 2026 neu aufgebaute Anlagen-Engine nach den Teilen 5 und 8, die Referenzgebäude-Engine mit Referenzausführung, Lüftung, Anlagenkette und Netztypwahl sowie Monatsbilanz und Energiebilanz. Die Heizlastberechnung arbeitet raumweise über ein Raumprofil, berücksichtigt Trinkwarmwasser und Schwimmbad, bildet die Erzeugerauslegung aus Heizlast, Trinkwarmwasser und Pool und liest bei den Bauteilen zuerst den sanierten U-Wert, legt also den Zielzustand aus; die Kühllast ist analog aufgebaut. Der Wärmeschutznachweis prüft die U-Werte gegen die Anforderungen und rechnet den Wärmebrückenzuschlag aus dem Hüllendatensatz; ein Umschalter für Normstand und Rechtsstand ist vorhanden. Das TGA-Kostenwerkzeug führt die Gewerke einzeln, die Hülldämmung als eigenes Gewerk. Verbindlich gerechnet wird die Ausgabe DIN V 18599:2018-09; die Technische Spezifikation von 2025-10 läuft als Vergleichsrechnung mit und ist keine Grundlage öffentlich-rechtlicher Nachweise — jede Ausgabe benennt die gerechnete Fassung. Offen sind das BIN-Verfahren für Wärmepumpen, weil die dafür nötigen 8.760 Stundenwerte des Testreferenzjahrs nicht vorliegen, drei kommentierte Schwachstellen der Monatsbilanz sowie die vollständige Anlagen-Zonen-Zuordnung im oben beschriebenen Sinn.

7.8 Baustein 7 — Ökobilanz, CO₂ und Treibhauspotenzial

Das Ökobilanzmodul erweitert das Gebäudemodell um die Lebenszyklusebene. Es benötigt dafür Bauteile, Materialien und Mengen, Umweltproduktdeklarationen, Lebensdauern und Austauschzyklen sowie Annahmen zur Entsorgung. Berechnet werden daraus das Treibhauspotenzial der Herstellung, der Nutzung, des Austauschs und der Entsorgung sowie der Gesamtwert.

Die EPBD gibt den Rahmen inzwischen präzise vor. Systemgrenzen und Berechnungsverfahren richten sich nach EN 15978, der Bezugszeitraum beträgt 50 Jahre, die Einheit ist kg CO₂eq je Quadratmeter Nutzfläche, und der Bilanzstand ist der As-built-Zustand: vor Baubeginn wird geschätzt, danach bestätigt. Pflichtmodule sind A1 bis A5, B1 bis B4, B6 sowie C1 bis C4, D1 und D2; B5, B7 und B8 bleiben optional. Im Ausweis erfolgt die Ausweisung je Phasengruppe zuzüglich eines Gesamtwerts. Für die Datenqualität gilt eine Hierarchie von den Angaben nach der Bauprodukteverordnung über Ökodesign-Daten und projekt- oder produktspezifische Datensätze bis zu generischen Werten nach EN 15804 und erst zuletzt Standardwerten. Verbindlich wird die Ausweisung ab dem 1. Januar 2028 für Neubauten über 1.000 m² und ab dem 1. Januar 2030 für alle Neubauten; die Mitgliedstaaten legen bis zum 1. Januar 2027 einen Fahrplan vor, die ersten Grenzwerte gelten spätestens ab 2030 und werden danach abgesenkt. Eine Pflicht für den Bestand besteht nicht — mit einer Ausnahme: Wird auf die freiwillige Klasse A+ saniert, wird der GWP-Ausweis Pflicht.

Verbindung zwischen Betriebsenergie und Lebenszyklus

Die eigentliche Systemleistung liegt in der Verknüpfung beider Ebenen. Ein Sanierungsszenario lässt sich dann gleichzeitig nach Energie, operativen Emissionen, Lebenszyklus-Treibhauspotenzial und Kosten auswerten. Der Zielkonflikt wird dabei sichtbar statt verdeckt: Eine stärkere Dämmung senkt den Energiebedarf und die operativen Emissionen, erhöht aber zunächst den Materialeinsatz und damit das Herstellungs-Treibhauspotenzial. Ohne gemeinsame Auswertung wird dieser Effekt entweder ignoriert oder überzeichnet; mit ihr wird er zu einer Optimierungsaufgabe mit nachvollziehbarem Ergebnis.

Abhängigkeiten. Eingang aus dem Bauteil- und Materialbestand des Datenkerns, aus den Mengen der Geometrie und aus den Betriebsergebnissen der Bilanzrechnung; Ausgang an den Energieausweis (Anhang V Buchstabe e), an den Renovierungspass (Anhang VIII Buchstabe h) und an die Nachhaltigkeitsdokumentation.

Stand. Teilweise vorhanden. Ein Ökobilanzwerkzeug ist im Einsatz und rechnet für Nichtwohngebäude den projektspezifischen Anforderungswert des Qualitätssiegels gegen eine amtlich verifizierte Wertetabelle; im Gebäudepass ist die zugehörige Kachel aktiv. Die Berechnung selbst ist jedoch noch nicht materialbasiert: Der heutige Nachhaltigkeitskern bildet den Betrieb ab und setzt für die grauen Emissionen einen geschätzten Benchmark von 500 kg/m² an. Offen sind damit die eigentliche Berechnung aus Bauteilflächen, Materialmengen und EPD-Datensätzen sowie die Unterscheidung zwischen Neubau- und Sanierungsbilanzlogik; Materialpässe stehen als eigener Punkt auf der Entwicklungsliste. Bemerkenswert ist die Sorgfalt bei der Darstellung: Der Pass führt drei getrennte CO₂-Karten — aus dem Ausweis, aus der automatischen Betriebsbilanz und aus der Ökobilanz — und bildet ausdrücklich keinen zusammengeführten Gesamtwert; ein eigener Prüftest überwacht, dass diese Trennung erhalten bleibt. Das ist die richtige Reihenfolge: erst die Bezugssysteme sauber trennen, dann zusammenführen.

7.9 Baustein 8 — BIM- und IFC-Import

Ein langfristig skalierbarer Gebäudepass muss bestehende digitale Gebäudemodelle übernehmen können, statt sie nachzuerfassen. IFC ist dafür der maßgebliche herstellerneutrale Austauschstandard. Übernehmbar sind Gebäudegeometrie, Geschosse, Räume, Wände, Fenster, Türen, Materialien und technische Anlagen — im günstigen Fall also der gesamte Aufwand einer Bestandsaufnahme. Für die Ökobilanz ist der Weg besonders wertvoll, weil die Rohdatenbasis der Massenermittlung, die Stückliste des Gebäudes, unmittelbar aus dem Modell ableitbar ist.

IFC darf nicht ungeprüft übernommen werden

Ein IFC-Modell ist jedoch nicht automatisch ein korrektes energetisches Gebäudemodell. Es entsteht meist für andere Zwecke — Planung, Ausschreibung, Kollisionsprüfung — und trägt Eigenschaften, die für eine Energiebilanz unbrauchbar oder irreführend sind. Beim Import ist deshalb zu prüfen, ob die Hüllflächen geschlossen sind, ob die Bauteile korrekt klassifiziert wurden, ob Außen- und Innenmaße konsistent verwendet sind, ob die Räume sinnvoll zoniert sind, ob die Materialangaben vollständig sind und ob jedes Fenster einem Bauteil und einer Orientierung zugeordnet ist. Ein Import ohne diese Prüfungen erzeugt schneller falsche Ergebnisse, als eine manuelle Erfassung es könnte, weil er den Anschein von Vollständigkeit hat. Der IFC-Import gehört deshalb nicht in die Erfassung, sondern in das Qualitätssicherungssystem nach Abschnitt 7.11.

Abhängigkeiten. Eingang aus externen Planungswerkzeugen; Ausgang in Geometrie, Bauteile und Anlagen des Datenkerns — und zwar ausschließlich über den Vorschlags- und Freigabeweg, nie durch direktes Überschreiben.

7.10 Baustein 9 — KI-gestützte Plan- und Dokumentenanalyse

Nicht jedes Gebäude besitzt ein digitales Modell. Im Bestand — also in dem Teil des Gebäudebestands, um den es der EPBD vorrangig geht — liegen typischerweise PDF-Dateien, Scans und alte Papierpläne vor. Zwischen dem regulatorischen Anspruch strukturierter, maschinenlesbarer Gebäudedaten und der Realität eines Aktenordners aus dem Jahr 1978 liegt der eigentliche Erfassungsaufwand. Genau hier setzt die KI-gestützte Analyse an: Sie übernimmt nicht die fachliche Bewertung, sondern die Übersetzung von unstrukturierten Unterlagen in Vorschläge für Datenfelder.

Der Arbeitsablauf verläuft in sieben Schritten: Dokument hochladen, Dokumenttyp erkennen, relevante Daten extrahieren, den Datenfeldern des Modells zuordnen, Plausibilität prüfen, Bestätigung durch den fachlich Verantwortlichen einholen und erst danach den Gebäudedatensatz aktualisieren. Die Reihenfolge ist bewusst so gewählt, dass zwischen Erkennung und Datenänderung immer eine menschliche Entscheidung liegt.

KI ändert keine freigegebenen Daten

Daraus folgt eine Systemregel, die für die Glaubwürdigkeit der gesamten Plattform entscheidend ist: KI-Vorschläge ändern keinen fachlich freigegebenen Gebäudedatensatz ohne nachvollziehbaren Prüfprozess. Die KI kann erkennen, vorschlagen und vergleichen. Sie kann einen Widerspruch zwischen Rechnung und Bauteildatensatz sichtbar machen. Die fachliche Freigabe bleibt beim qualifizierten Menschen, und sie bleibt dokumentiert. Dieselbe Regel gilt für alle Drittsysteme: Sie liefern Vorschläge, keine Wahrheiten. Ohne diese Grenze wäre die Herkunftskennzeichnung wertlos, denn ein Wert, der sich unbemerkt ändern kann, ist kein Nachweis.

Abhängigkeiten. Eingang aus der Gebäudeakte; Ausgang als Vorschlag in den Governance-Prozess nach Abschnitt 7.11 und von dort — nach Freigabe — in den Datenkern.

Stand. In Grundzügen vorhanden. Eine Analyseschnittstelle für PDF-Dateien und Pläne ist produktiv: Grundriss, Wärmeschutznachweis und Energieausweis werden über eine einzige Ablagezone entgegengenommen, die Erkennung des Dokumenttyps erfolgt automatisch; für die Nachhaltigkeitsdokumentation existiert ein eigener Analyseweg. Der Grundsatz „Die KI schlägt vor — der Mensch entscheidet" ist als Leitsatz festgehalten und in der Governance-Schicht technisch abgebildet: Ein Meldevorgang erzeugt einen Vorschlag im Arbeitsbereich und ändert den offiziellen Wert nicht; erst die Freigabe schreibt in den führenden Datenpfad. Der Ausbau zu eigenständigen Fachagenten steht als offener Punkt auf der Entwicklungsliste, ebenso die neun differenzierten Datenwert-Status der Zielspezifikation, von denen produktiv bisher die Herkunftsplakette der Kennwerteseite umgesetzt ist.

7.11 Baustein 10 — Prüf-, Freigabe- und Qualitätssicherungsprozesse

Dieser Baustein entscheidet über die Glaubwürdigkeit des gesamten Gebäudepasses. Ein Datensatz, dessen Qualität niemand prüft, ist für eine Bank, eine Behörde und einen Käufer gleich wertlos — unabhängig davon, wie vollständig er aussieht. Geprüft werden Vollständigkeit, Datenformate, Wertebereiche, Widersprüche, Abhängigkeiten, Normkonformität und der Status der zugehörigen Dokumente.

Sinnvoll ist eine Gliederung in drei Ebenen, die unterschiedliche Fehlerarten erfassen:

• Ebene A — technische Validierung. Ist der Wert technisch korrekt gespeichert? Ein U-Wert, der als Text abgelegt ist, ist kein U-Wert, sondern eine Zeichenkette.
• Ebene B — fachliche Plausibilität. Ist der Wert überhaupt möglich? Ein Fenster mit einem U-Wert von 7,5 W/(m²K) existiert nicht und löst eine Warnung aus.
• Ebene C — fachliche Konsistenz. Passt der Wert zu den übrigen Informationen? Wenn die Handwerkerrechnung 160 mm Dämmung ausweist, der Bauteildatensatz aber 100 mm, liegt ein Konflikt vor, der aufgelöst werden muss.

Prüfregeln sollten dabei selbst als versionierte Datenobjekte geführt werden, nicht als verstreuter Programmcode. Eine Regel könnte lauten: Wenn eine Außenwandfläche größer als null ist und der U-Wert fehlt, ist der Datensatz unvollständig. Eine andere: Wenn die Leistung des Wärmeerzeugers das Dreifache der Heizlast übersteigt, ist die Dimensionierung zu prüfen. In dieser Form lässt sich der Regelbestand kontinuierlich erweitern, ohne die Fachmodule anzufassen — und jede Meldung lässt sich auf eine benannte, datierte Regel zurückführen.

Freigabeprozess und Verantwortlichkeit

Nicht jede Änderung darf sofort den offiziellen Gebäudezustand verändern. Deshalb benötigt das System einen Freigabeprozess mit klar definierten Zuständen: Entwurf, gemeldet, geprüft, fachlich freigegeben. Nur der freigegebene Stand darf in offizielle Berichte und Nachweise eingehen. Damit können Angaben von Eigentümern und Ergebnisse der KI-Analyse zunächst als Vorschlag existieren, ohne die Nachweisqualität des Datensatzes zu beschädigen.

Zu jeder Freigabe gehört die Dokumentation von Person, Qualifikation, Datum, Prüfumfang und den freigegebenen Datenfeldern. Erst dann lässt sich nachvollziehen, wer für welche Information einsteht — was bei technischen Nachweisen auch eine Haftungsfrage ist und was Anhang VI der EPBD für die Datenbank ausdrücklich verlangt: Der Urheber jeder Änderung muss für die Behörden ermittelbar bleiben.

Abhängigkeiten. Der Baustein liegt quer zu allen anderen. Er nimmt Vorschläge aus KI-Analyse, IFC-Import und Nutzereingabe entgegen, gibt Werte für Rechenmodule und Dokumente frei und stößt bei jeder Freigabe die betroffenen Neuberechnungen an.

Stand. Der am weitesten entwickelte Querschnittsbereich. Umgesetzt und im Einsatz sind eine Governance-Schicht mit Vertrauensstufen von 0 bis 5, den vier Datenzuständen und der Wertversionierung nach dem Vier-Augen-Prinzip; eine Beziehungsschicht mit den Kanten „belegt durch", „beeinflusst" und „ersetzt"; eine Abhängigkeitsschicht, die die Wirkkette vom Bauteil über U-Wert und Heizlast bis zu Nachweis, Ausweis, CO₂-Bilanz, Vertrauensindex und Finanzierungsbericht führt — die Freigabe eines Fensters erzeugt dort 13 Folgeaufgaben; sowie eine Neuberechnungsschicht, die je Eingabesektion einen Fingerabdruck bildet, die betroffenen Auswertungen als veraltet markiert, die Rechenkette anstößt und den Vorgang protokolliert. Verbindlich ist die Regel, dass jede Information genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie hat; Änderungen überschreiben nichts, sondern erzeugen eine neue Version, und Konflikte werden erzeugt statt automatisch aufgelöst.

Auf der Codeseite arbeitet ein Funktions-Wächter, der von 116 auf zuletzt 499 Prüfungen gewachsen ist, statisch, über HTTP und im Browser prüft, nächtlich läuft und seine Läufe archiviert; der Sollstand vom 17. August 2026 weist 493 grüne Prüfungen aus, die beiden roten sind bekannte Datenbefunde aus Live-Projekten und keine Regression. Davon zu unterscheiden ist der Quellen-Abgleich mit sechs Regeln, der nicht den Code, sondern die Daten auf innere Stimmigkeit prüft; vier doppelt geführte Felder gleicht der Steckbrief gegen die jeweils andere Quelle ab — überschrieben wird dabei nichts automatisch. Offen sind digitale Signaturen je Freigabe, die technische Durchsetzung der Rollen, die Konfliktauflösung, die datenschutzrechtliche Vorprüfung der Freigabeschicht, agentenbezogene Prüfregeln und eine Oberfläche für die Wächterbereiche.

7.12 Querschnittsfunktionen: Rollen, Dokumente, Ereignisse und Fristen

Vier weitere Funktionen liegen quer zu den zehn Bausteinen und werden hier nur so weit beschrieben, wie sie die Architektur betreffen; Kapitel 9 behandelt die Rechte- und Datenschutzseite ausführlich.

Rollen und Berechtigungen. Der Gebäudepass benötigt unterschiedliche Rollen: Eigentümer mit vollem Einblick in die eigenen Daten, Energieberater für die fachliche Bearbeitung der energetischen Angaben, Architekten für Geometrie und Bauteile, TGA-Planer für die Anlagen, Banken für die freigegebenen Finanzierungsdaten, Makler für Verkaufsinformationen, Hausverwaltungen für Betrieb und Dokumentation, Behörden für die gesetzlich erforderlichen Daten. Leitprinzip ist die Beschränkung auf das Erforderliche: Ein Makler benötigt keine vollständigen Rechnungsdaten, eine Bank keine Baupläne, eine Behörde keine privaten Dokumente. Damit werden Datennutzung und Datenschutz voneinander getrennt, statt sie gegeneinander auszuspielen. Im vorhandenen System ordnen sieben Anzeigerollen der Kennwerteseite die Darstellung — sie bestimmen Reihenfolge und Hervorhebung. Darüber liegt seit dem 23. August 2026 eine davon getrennte Rechteschicht: Zehn Rollen, darunter die hier genannten Fachrollen für Geometrie, Anlagen und Behörden, tragen je einen eigenen Lese- und Schreibumfang; Schreiben, Melden, Freigeben und Exportieren sind verschiedene Rechte, die Sichtbarkeit wirkt bis auf einzelne Felder, und jeder Zugriff wird protokolliert. Das genannte Leitprinzip ist damit nicht mehr nur Absicht, sondern durchgesetzt: Der Makler erhält den Datensatz ohne die Rechnungsdaten, weil sie darin fehlen, nicht weil sie ausgeblendet sind. Offen bleibt die Freigabe als Vorgang — wer melden, aber nicht freigeben darf, hat heute noch keine Warteschlange, in der sein Beitrag bis zur Entscheidung liegt.

Dokumentengenerator. Alle Ausgaben — Energieausweis, Gebäudesteckbrief, Wärmeschutznachweis, Renovierungspass, Sanierungs- und Ökobilanzbericht, Förderübersicht, Bankenbericht — entstehen aus demselben Datenbestand. Damit ist ausgeschlossen, dass zwei Berichte desselben Gebäudes widersprüchliche Angaben enthalten. Vorhanden ist eine Berichtsschicht, die keine U-Werte erfindet und einen fehlenden Nachweis als fehlend ausweist, sowie eine Automatik, die sieben Dokumente erzeugt — Bedarfsausweis, Wärmeschutznachweis, Grundriss, hydraulischer Abgleich, Heiz- und Kühllastbericht, Maßnahmenbericht und Finanzierungsbericht — jeweils mit einem Merker über die Datengrundlage, sodass eine Neuerzeugung nur bei geänderten Daten erfolgt.

Ereignisse und Neuberechnung. Ein Gebäude verändert sich fortlaufend. Jede relevante Veränderung — ein neues Dokument, eine neue Anlage, eine Sanierung, ein Eigentümerwechsel, eine Wartung, ein neuer Ausweis, eine Förderzusage, neue Verbrauchsdaten — sollte als Ereignis behandelt werden, das weitere Aktionen auslöst. Der Einbau einer Wärmepumpe etwa ändert den Anlagenbestand, historisiert den alten Wärmeerzeuger, markiert den Energiezustand als geändert, stößt die Neuberechnung der Bilanz an, prüft Heizlast und Ausweisstatus, aktualisiert den Sanierungsfahrplan, dokumentiert den Förderprozess und ergänzt die Gebäudechronik. Die technische Grundlage dafür — Fingerabdruck, Veraltungsmarkierung, Rechenkette, Protokoll — ist umgesetzt; die durchgängige Ereigniszeitleiste als Nutzeransicht ist es nicht.

Fristen und Benachrichtigungen. Ein Gebäudewächter überwacht Zustände, die von selbst kritisch werden: Ein Energieausweis läuft nach spätestens zehn Jahren ab, eine Wartung wird fällig, ein Dokument fehlt, eine Berechnung ist veraltet, eine Förderfrist läuft, ein Sanierungsschritt steht an, Daten widersprechen sich. Damit wird aus einer passiven Datenbank ein aktives Gebäudemanagement. Auf der regulatorischen Seite existiert bereits ein Monitor, der 18 amtliche Quellen täglich auswertet, Änderungen an einem fachlichen Fingerabdruck erkennt statt am Seitentext und Vorlaufwarnungen von 180 Tagen bis zu einem Tag ausgibt; er trennt dabei Veröffentlichungs-, Inkrafttretens-, Anwendungs- und Produktivdatum. Gebäudebezogen sind bislang die Vollständigkeitsprüfung, die Veraltungsmarkierung und die Abweichungswarnung des Ausweises umgesetzt; die Wartungs- und Fristenüberwachung im engeren Sinne setzt die noch fehlende Dokumentenanbindung voraus.

7.13 Anwendungssichten für externe Nutzergruppen

Die Funktionsbausteine erzeugen Daten; die Anwendungssichten entscheiden, wer davon was sieht. Kapitel 6 beschreibt die Portale, Kapitel 11 den Nutzen je Zielgruppe; hier interessiert nur der architektonische Punkt, dass keine dieser Sichten einen eigenen Datenbestand besitzt. Sie sind Filter über demselben Kern.

Das Eigentümerportal beantwortet sieben Fragen in nicht-fachlicher Sprache: Wie steht mein Gebäude heute da? Was wurde bisher gemacht? Was sollte als Nächstes geschehen? Welche Kosten entstehen? Welche Förderung ist möglich? Welche Unterlagen fehlen? Wie verändert sich die technische Qualität? Das Partnerportal dagegen ist eine gemeinsame Arbeitsumgebung für Energieberater, Architekten, Ingenieure, TGA-Planer, Handwerksbetriebe und Hausverwaltungen: Projekte einsehen, Daten ergänzen, Dokumente hochladen, Berechnungen durchführen, Freigaben anfordern.

Eine eigene Sicht verdient die Kreditwirtschaft. Banken benötigen nicht den gesamten Gebäudepass, sondern einen strukturierten Evidenzdatensatz: Effizienzklasse, End- und Primärenergie, Emissionen, technischer Zustand, Sanierungsbedarf, Investitionsbedarf, Förderfähigkeit, Datenqualität und Dokumentenstatus. Die EPBD stützt diese Sicht ausdrücklich: Artikel 22 räumt Finanzinstituten für ihr Portfolio einen kostenfreien Zugang zum vollständigen Ausweis ein, maschinenlesbar und als Druckdokument. Daraus lässt sich ein standardisierter, finanzierungsfähiger Gebäudereport ableiten, gegliedert nach Basisdaten, Energie, Technik, Transformationspfad, Investition, Förderung und Risiko — wobei die Risikoposition ausdrücklich die Datenqualität und die offenen Punkte umfasst. Der Unterschied zu einem einzelnen Energieausweis liegt weniger in der Menge der Angaben als darin, dass jede Angabe ihre Herkunft mitführt. Die Makler- und Verkaufssicht folgt derselben Logik mit kleinerem Ausschnitt: Baujahr, Fläche, Effizienzklasse, Ausweis, Heizsystem, durchgeführte und geplante Maßnahmen sowie die verkaufsrelevanten Unterlagen.

Im vorhandenen System ist der veröffentlichte Pass umgesetzt: Ein bereinigter Datenauszug ohne personenbezogene Angaben wird als Momentaufnahme abgelegt und über eine öffentliche Adresse mit vierstelliger PIN, gestaffelter Sperre nach Fehlversuchen und QR-Druck zugänglich gemacht; eine Kartenausgabe und ein schreibgeschützter Demonstrationspass ergänzen ihn. Die inhaltliche Differenzierung nach Empfängertyp — also die Freigabepakete je Rolle — ist konzipiert, aber nicht umgesetzt.

7.14 Architekturgrundsatz und Gesamtbild

Führt man die Bausteine zusammen, ergibt sich eine durchgehende Verarbeitungslinie: Der Gebäudedatenkern nimmt Daten aus IFC, PDF-Analyse, KI-Erkennung, manueller Eingabe und Schnittstellen auf; die Fachmodule für Bilanzierung, Bauphysik, TGA, Ökobilanz, Förderung und Wirtschaftlichkeit rechnen darauf; die Qualitätsschicht validiert, plausibilisiert und gibt frei; die Dokumentschicht erzeugt Ausweis, Renovierungspass, Nachweise und Berichte; die Historienschicht führt Versionen, Ereignisse und Gebäudechronik; die Schnittstellenschicht bedient Register, Banken und Behörden; und die Nutzerschicht stellt jeder Gruppe ihren Ausschnitt bereit.

Dieser Grundsatz ist im Gebäudeenergierecht keine Eleganzfrage, sondern eine Überlebensbedingung. Gesetze, Normen, Förderbedingungen und Datenformate ändern sich in kurzen Abständen — das GMoDG ist seit dem 29. Juli 2026 in Kraft, seine zweite Stufe mit den Rechenverfahren und den Energieausweisen folgt zum 1. Januar 2027, und mehrere Ausführungsregelungen stehen noch aus. Das reale Gebäude verändert sich dagegen langsam. Eine Architektur, die Gebäudedaten einerseits und Regelwerke, Berechnungsmethoden und Ausgabeformate andererseits konsequent trennt, übersetzt diese unterschiedlichen Änderungsgeschwindigkeiten in unterschiedliche Wartungszyklen.

Die eigene Entwicklung zeigt, wie das praktisch aussieht. Für die Umstellung auf das GMoDG wurde ein Rechtsstandregister eingeführt, das zwischen den Ständen 2026 und 2027 umschaltet und je Fassung überlagerte Werte, unveränderte Werte, bekannte Lücken und die geltenden Ausweisbezeichnungen führt; die Rechenkerne tragen seither einen Rechtsstandstempel an jedem Ergebnis, und zuvor fest im Code stehende Primärenergiefaktoren wurden entfernt. Die umstrittene Leistungsschwelle der Gebäudeautomation wird nicht als Konstante über den Code verstreut, sondern als ein Parameter mit Herkunftsangabe geführt, und jede Ausgabe nennt die verwendete Schwelle — eine notwendige Vorsichtsmaßnahme, solange die Quellen 70 kW und 290 kW mit unterschiedlicher Rechtsgrundlage nebeneinander führen und ein dritter kursierender Wert ohne Herkunftsangabe im Umlauf ist. Ebenso werden fehlende amtliche Festlegungen als Lücke geführt statt geschätzt: Die Klassengrenzen für Nichtwohngebäude bleiben offen, und die zugehörige Funktion gibt bewusst keinen Wert zurück.

Tabelle 7.1 fasst die zehn Bausteine und die beiden wichtigsten Querschnittsfunktionen zusammen. Die Spalte „Stand" bezieht sich ausschließlich auf die eigene Plattform zum Stand August 2026 und verwendet drei Stufen: vorhanden für produktiv genutzte Funktionen, teilweise für Funktionen mit belegten Lücken, konzipiert für beschriebene, aber nicht implementierte Funktionen.

Die Tabelle zeigt ein bemerkenswert gleichmäßiges Bild: Der Rechenteil und der Qualitätsteil der Plattform sind weit entwickelt, der Dokumenten-, Rollen- und Schnittstellenteil ist es nicht. Das ist kein Zufall, sondern die Folge der Entstehungsgeschichte — die Plattform ist aus Nachweiswerkzeugen gewachsen, nicht aus einem Dokumentenmanagement. Für die EPBD-Umsetzung bedeutet das, dass die inhaltlich schwierigen Teile — Bilanzierung, Validierung, Governance — bereits stehen, während die verbindenden Teile — Rechteschicht, Registerschnittstelle, Ökobilanz aus Materialmengen — noch zu bauen sind. Kapitel 13 bewertet diesen Reifegrad im Einzelnen, Kapitel 14 leitet daraus die Entwicklungsstufen ab.

Damit besteht der digitale Gebäudepass aus drei aufeinander aufbauenden Ebenen: Das Datenmodell beschreibt das Gebäude, die Fachmodule interpretieren und berechnen es, die Anwendungen stellen die Ergebnisse den jeweiligen Nutzern bereit. Diese Trennung macht die Plattform erweiterbar. Sie erlaubt neue Fachmodule, neue Nutzergruppen und neue regulatorische Anforderungen, ohne den Gebäudedatensatz jedes Mal neu aufzubauen — und aus einer Software für energetische Nachweise wird eine langfristig tragfähige digitale Gebäudeplattform.

8 Technische Architektur und Schnittstellen

Kapitel 4 hat beschrieben, welche Daten der digitale Gebäudepass führt, Kapitel 7, welche Funktionen auf diesen Daten arbeiten. Dieses Kapitel beantwortet die dritte Frage: Wie sind Datenhaltung, Fachlogik und Außenverbindungen technisch angeordnet, damit die Plattform über Jahrzehnte tragfähig bleibt und mit Registern, Datenbanken, Planungs- und Messsystemen austauschbar wird? Beschrieben werden Schichtenmodell, Datenbankstruktur, Schnittstellenkonzept, Identifikatoren, die Anbindung an Energieausweisregister und nationale Gebäudedatenbanken sowie die Anforderungen an Langzeitarchivierung. Für jede Schnittstelle wird getrennt ausgewiesen, was heute existiert und was Zielarchitektur ist.

8.1 Anforderungen an die technische Architektur

Die technische Architektur des digitalen Gebäudepasses muss drei Anforderungen gleichzeitig erfüllen, die in gewöhnlicher Anwendungssoftware selten zusammenfallen. Sie muss Gebäudedaten dauerhaft und strukturiert speichern — dauerhaft im Sinne von Jahrzehnten, nicht von Produktzyklen. Sie muss unterschiedliche Fachmodule auf denselben Datenbestand zugreifen lassen, ohne dass jedes Modul eine eigene Kopie der Wahrheit anlegt. Und sie muss Daten kontrolliert mit externen Systemen austauschen, also mit Registern, Behörden, Kreditinstituten, Planungsbüros und Messsystemen, von denen keines dem Gebäudepass gehört und deren Datenmodelle sich unabhängig von ihm verändern.

Aus diesen drei Anforderungen folgt eine Grundentscheidung. Der Gebäudepass ist nicht als geschlossenes Einzelprogramm zu verstehen, das einen bestimmten Nachweis erzeugt, sondern als modulare, schnittstellenfähige Plattform. Der Unterschied ist nicht semantisch. Ein Einzelprogramm optimiert seine interne Datenhaltung auf das Dokument, das es ausgibt; ändert sich das Dokument, ändert sich die Datenhaltung. Eine Plattform hält die Daten unabhängig von jeder Ausgabe und erzeugt Dokumente daraus. Nur die zweite Bauform übersteht die regulatorische Änderungsgeschwindigkeit, die das Gebäudeenergierecht seit der Neufassung der EPBD und dem Inkrafttreten des Gebäudemodernisierungsgesetzes am 29. Juli 2026 kennzeichnet.

Hinzu kommt eine Anforderung, die sich aus dem Regelwerk selbst ergibt und die in Kapitel 6 bereits berührt wurde. Artikel 19 der EPBD verlangt den Energieausweis in digitaler und maschinenlesbarer Form und stellt ausdrücklich klar, dass ein gescanntes PDF diese Anforderung nicht erfüllt. Artikel 20 Absatz 8 verlangt die Übergabe des vollständigen Ausweises einschließlich aller Berechnungs-Eingangsdaten an die Datenbank nach Artikel 22. Artikel 22 Absatz 7 verlangt Interoperabilität mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern. Diese drei Vorgaben sind keine Ausgabeformalitäten. Sie sind Architekturvorgaben: Sie entscheiden darüber, ob die Daten des Gebäudepasses überhaupt in einer Form vorliegen, aus der sich ein registrierfähiger Datensatz erzeugen lässt.

8.2 Das Schichtenmodell

Die technische Grundstruktur lässt sich in fünf Ebenen gliedern. Die Gliederung ist keine Darstellungsform, sondern eine Konstruktionsregel: Jede Ebene kennt nur ihre unmittelbaren Nachbarn, und eine Änderung in einer Ebene soll keine Änderung in allen anderen erzwingen.

Die Datenebene hält die Beschreibung des Gebäudes: Identität, Geometrie, Bauteile, technische Anlagen, Nutzung, Energie- und Emissionsdaten, Dokumente und Historie. Sie enthält keine Rechenvorschrift, kein Regelwerk und kein Ausgabeformat. Was hier steht, ist im Grundsatz unabhängig davon gültig, welches Gesetz gerade in Kraft ist — ein U-Wert von 0,18 W/(m²K) bleibt derselbe Wert, gleich welcher Rechtsstand ihn bewertet. Diese Ebene ist die langlebigste der fünf und muss entsprechend konservativ gepflegt werden.

Die Logikebene enthält die Verfahren, die aus Daten Ergebnisse machen: die Bilanzierung nach DIN V 18599, Bauphysik und Heizlast, die Ökobilanz, Förder- und Wirtschaftlichkeitsrechnung sowie die Bewertung nach ESG-Kriterien. Hier liegt die höchste Änderungsfrequenz des gesamten Systems. Die Umstellung vom Gebäudeenergiegesetz auf das Gebäudemodernisierungsgesetz, die Umschaltung der Primärenergie- und Emissionsfaktoren zum Anwendungsdatum der zweiten Stufe und die Frage, ob nach der Ausgabe 2018-09 der DIN V 18599 oder nach der Technischen Spezifikation 2025-10 gerechnet wird, betreffen ausschließlich diese Ebene. Wenn sie sauber von der Datenebene getrennt ist, lässt sich ein Rechtsstand umschalten, ohne einen einzigen Gebäudedatensatz anzufassen.

Die Integrationsschicht vermittelt zwischen dem internen Datenmodell und der Außenwelt. Sie umfasst die Programmierschnittstellen, die Austauschformate XML, JSON, CSV und IFC sowie sämtliche Import- und Exportfunktionen. Ihre Aufgabe ist Übersetzung, nicht Speicherung: Sie hält keine eigenen Gebäudedaten, sondern bildet externe Strukturen auf interne ab und umgekehrt. Damit ist sie zugleich der Ort, an dem Qualitätssicherung stattfinden muss, denn jede von außen kommende Angabe ist zunächst eine Behauptung.

Die Anwendungsebene stellt dieselben Daten unterschiedlichen Nutzergruppen in unterschiedlichem Zuschnitt dar: Eigentümerportal, Fachpartnerportal, Bankenansicht, Makleransicht, Behördenzugang. Sie ist die kurzlebigste Ebene. Eine Weboberfläche, die heute als zeitgemäß gilt, wird in zehn Jahren ersetzt sein; die Gebäudedaten dahinter müssen unverändert weiterbestehen. Aus dieser Asymmetrie folgt der Grundsatz aus Abschnitt 8.14: Datenmodell und Anwendungsschicht müssen technisch getrennt sein.

Die fünfte Ebene sind die externen Systeme selbst — Energieausweisregister, nationale Gebäudedatenbanken, Förderstellen, Kreditinstitute, BIM- und Planungssysteme, Messsysteme und weitere Datenplattformen. Sie gehören nicht zur Plattform, bestimmen aber deren Anforderungen mit. Charakteristisch für sie ist, dass der Betreiber des Gebäudepasses weder ihre Verfügbarkeit noch ihren Änderungsrhythmus beeinflusst. Genau deshalb dürfen sie nie unmittelbar an den Datenkern angeschlossen werden, sondern immer nur über die Integrationsschicht.

Die Trennung der Ebenen kostet zunächst Aufwand. Sie zahlt sich in dem Moment aus, in dem eine der Ebenen sich unabhängig von den übrigen verändert — und das ist im Gebäudeenergierecht der Regelfall, nicht die Ausnahme. Die vorhandene Software folgt dieser Trennung bereits in ihrer Grundstruktur: Der Projektspeicher hält die Gebäudedaten je Projekt in einer eigenen Datei und legt Rechenergebnisse getrennt von Eingaben in einem eigenen Zweig ab, die Rechenkerne liegen als eigene Engines daneben, und eine Rechtsstands-Registry hält die Regelwerksfassungen 2026 und 2027 sowie den Normstand 2018-09 und 2025-10 umschaltbar vor. Die Anwendungsebene ist dagegen noch eng mit den Fachwerkzeugen verwoben, und eine durchgängige Integrationsschicht im obigen Sinn existiert bislang nur in Teilen.

8.3 Datenbankstruktur: Objekte, Beziehungen, Zeitreihen

Im Zentrum der Datenebene steht ein strukturierter Gebäudedatensatz, der zwischen Objektarten unterscheidet, statt alle Angaben in eine flache Merkmalsliste zu schreiben. Die Unterscheidung ist die Voraussetzung dafür, dass verschiedene Fachmodule dieselben Objekte unterschiedlich auswerten können. Sinnvoll sind mindestens die folgenden Objektarten:

• Gebäude — Gebäude-ID, Adresse, Baujahr, Gebäudetyp, Rechts- und Normstandbezug.
• Gebäudeteil — Wohnteil, Nichtwohnteil, Anbau; erforderlich, weil die EPBD Mischnutzung ausdrücklich aufgeschlüsselt verlangt.
• Geschoss — Keller, Erdgeschoss, Obergeschosse, Dachgeschoss.
• Zone — Wohnen, Büro, Verkauf, Lager; Träger des Nutzungsprofils und damit der zonenweisen Bilanz.
• Bauteil — Außenwand, Dach, Fenster, Boden, mit U-Wert, Fläche, Orientierung und Aufbau.
• Anlage — Wärmeerzeugung, Speicher, Verteilung, Übergabe, Lüftung, Kühlung, Photovoltaik.
• Dokument — Plan, Rechnung, Energieausweis, Fachunternehmererklärung, Prüfbericht.
• Berechnung — Bilanz nach DIN V 18599, Heizlast, Ökobilanz, Wirtschaftlichkeit, jeweils mit Rechtsstands- und Normstandstempel.
• Ereignis — Sanierung, Wartung, Registrierung, Eigentümerwechsel.

Damit entsteht ein objektorientiertes Gebäudemodell. Seine eigentliche Qualität liegt aber nicht in der Aufzählung der Objektarten, sondern in den Beziehungen zwischen ihnen. Ein Gebäude hat mehrere Geschosse, Zonen, Bauteile, Anlagen, Dokumente und Berechnungen — das ist trivial. Nicht trivial ist, dass ein einzelnes Bauteil gleichzeitig in mehreren Bezugssystemen steht. Ein Fenster gehört zu einer bestimmten Außenwand, liegt in einem bestimmten Geschoss, versorgt eine bestimmte Zone, trägt eine Orientierung, wird durch eine Rechnung belegt und geht in einen Ökobilanz-Datensatz ein. Erst wenn diese sechs Beziehungen gespeichert sind, kann die Heizlastrechnung raumweise auf dasselbe Fenster zugreifen wie die Bilanz zonenweise, die Ökobilanz mengenbezogen und der Wärmeschutznachweis flächenbezogen — ohne dass das Fenster viermal erfasst wird.

Diese Beziehungsschicht ist in der vorhandenen Software als eigene Datenschicht angelegt. Ein Beziehungsmodul führt den Objektgraphen mit den Kantentypen „belegt durch“, „beeinflusst“ und „ersetzt“; ein Abhängigkeitsmodul kennt die Wirkkette vom Bauteil über U-Wert und Heizlast zum Transmissionswärmeverlust und zum Primärenergiebedarf, weiter zu Wärmeschutznachweis und Energieausweis, zur Emissionsbilanz, zum Building Trust Index und bis in den Finanzierungsbericht. Die Freigabe eines einzelnen Fensterwerts löst dort dreizehn abhängige Aufgaben aus. Ein Neuberechnungsmodul bildet je Eingabesektion einen Fingerabdruck, ermittelt daraus die betroffenen Auswertungen, markiert sie als veraltet, stößt die Rechenkette an und schreibt das Ergebnis in den Prüfpfad. Die Beziehungslogik ist damit kein Konzept, sondern produktiv — wenn auch, wie Kapitel 7 dargestellt hat, noch nicht für alle Objektarten gleich vollständig verknüpft.

Eine zweite Unterscheidung ist für die Datenbankstruktur ebenso grundlegend: die Trennung zwischen Stammdaten und Zeitreihen. Ein Fenster mit einem U-Wert von 0,85 W/(m²K) ist ein Stammdatum — ein Wert, der über Jahre gilt und sich nur durch ein Ereignis ändert. Der Stromverbrauch einer Wärmepumpe im Viertelstundenraster ist eine Zeitreihe: ein Wert mit Zeitstempel, Messintervall, Einheit, Messquelle und Qualitätsstatus, der je Gebäude und Jahr Zehntausende Datenpunkte erzeugt. Beide in derselben Struktur zu speichern, führt zwangsläufig dazu, dass entweder die Stammdaten unter der Datenmenge leiden oder die Zeitreihen unter der Struktur der Stammdaten. Die Architektur benötigt deshalb mindestens zwei getrennte Speicherformen — eine für den beschreibenden Gebäudedatensatz, eine für Messwertreihen. Diese Trennung ist zugleich rechtlich sinnvoll, weil sich, wie Abschnitt 8.11 zeigt, der Datenzugang für statische und für dynamische Daten aus unterschiedlichen Rechtsakten ergibt.

8.4 Kanonisches Datenmodell statt Formularlogik

Ein zentraler Architekturgrundsatz lautet: Das Datenmodell darf nicht an ein bestimmtes Formular gekoppelt sein. Formulare ändern sich, Gebäude bleiben. Wenn der Energieausweis künftig zusätzliche Felder erhält — etwa den Lebenszyklus-Treibhausgasbericht, den das Gebäudemodernisierungsgesetz als eigenen Abschnitt des Ausweises vorsieht —, darf dafür nicht das grundlegende Gebäudemodell umgebaut werden müssen. Stattdessen werden die benötigten Angaben aus dem vorhandenen Modell zusammengestellt. Die Richtung der Ableitung ist entscheidend: Aus Gebäudedaten entsteht ein Dokument, nicht aus einem Dokument ein Gebäudedatenmodell.

Daraus folgt die Trennung zwischen internem und externem Format. Der Gebäudepass sollte ein eigenes kanonisches internes Datenmodell besitzen, aus dem sämtliche Außenformate erzeugt werden: das XML für die Ausweisregistrierung, ein JSON-Profil für eine Bankenschnittstelle, ein IFC-Export für die Fachplanung, eine CSV-Lieferung für die Statistik. Jedes dieser Formate ist eine Projektion, keine zweite Wahrheit. Der Vorteil zeigt sich, sobald ein Außenformat sich ändert: Betroffen ist dann nur die Abbildungsvorschrift in der Integrationsschicht, nicht der Datenbestand von mehreren tausend Gebäuden.

Der umgekehrte Fall — ein an das Formular gekoppeltes Datenmodell — lässt sich an der Bezugsflächenfrage gut belegen. Solange eine Software die Bezugsfläche so speichert, wie das jeweils auszufüllende Formular sie nennt, führt sie dieselbe physikalische Größe unter mehreren Namen. In der vorhandenen Software war genau das der Fall: Das Nutzungsprofil für Nichtwohngebäude hieß an vier Stellen unterschiedlich, mit der Folge, dass die zonenweise Bilanz in keinem einzigen Projekt griff. Erst die Festlegung einer kanonischen Feldadresse für das Profil und einer kanonischen Bezugsfläche nach DIN 277 — ausdrücklich nicht als Umrechnung der bisherigen Größe A_N, sondern als andere Größe, deren Fehlen die Bilanz als Lücke meldet — hat das Problem behoben. Der Vorgang ist lehrreich, weil er zeigt, dass ein kanonisches Datenmodell keine akademische Forderung ist, sondern die Bedingung dafür, dass Fachmodule überhaupt rechnen.

8.5 Programmierschnittstellen: Zugriffsebenen, Versionierung, Ereignisse

Eine Programmierschnittstelle bildet die technische Verbindung zwischen dem Gebäudepass und anderen Anwendungen. Sie unterscheidet sich von einem Dateiexport in zwei Punkten: Sie liefert Daten auf Anfrage und in definierter Struktur, und sie kann Zugriffe unterscheiden. Beides ist Voraussetzung dafür, dass Datenzugriff nicht auf Dateiebene, sondern auf Datenfeldebene gesteuert werden kann.

Eine solche Schnittstelle sollte abgestufte Zugriffsarten anbieten. Lesend sind das mindestens der Abruf freigegebener Stammdaten eines Gebäudes, der Abruf technischer Bauteildaten, der Abruf eines bestimmten Berechnungsstands und der Abruf eines freigegebenen Dokuments. Schreibend kommen die Übermittlung neuer Informationen und die Änderung eines Status hinzu, etwa eine Freigabe oder eine Aktualisierung. Für jeden dieser Zugriffe gilt ohne Ausnahme: Er ist zu authentifizieren und zu protokollieren. Das ist keine Vorsichtsmaßnahme, sondern eine Anforderung aus Anhang VI der EPBD, wonach der Urheber jeder Hinzufügung und jeder Änderung für die Behörden ermittelbar sein muss.

Die Schnittstelle selbst muss versioniert sein. Eine erste Fassung bildet die Grunddatenstruktur ab, eine zweite ergänzt neue EPBD-Felder, eine dritte zusätzliche Ökobilanzdaten. Werden alte Fassungen für eine definierte Übergangszeit weiter bedient, können angeschlossene Systeme weiterarbeiten, während der Gebäudepass sich weiterentwickelt. Ohne Versionierung tritt die typische Schwäche digitaler Schnittstellen ein: Eine Änderung im Datenmodell macht sämtliche angeschlossenen Systeme gleichzeitig unbrauchbar — und der Betreiber des Gebäudepasses wird damit erpressbar durch seine eigene Kundschaft, weil er nichts mehr ändern darf.

Langfristig sollte die Schnittstelle nicht nur abfragbar, sondern auch ereignisfähig sein. Externe Systeme können Ereignisse melden: ein Energieausweis wurde registriert, ein neuer Messwert liegt vor, ein Förderantrag wurde bewilligt, eine Wartung ist abgeschlossen. Umgekehrt kann der Gebäudepass Ereignisse ausgeben, auf die Dritte reagieren. Intern ist diese Bauform bereits umgesetzt: Ein Ereignis wie der Austausch des Wärmeerzeugers führt über die Abhängigkeitskette zur Neuberechnung der Bilanz, zur Prüfung des Ausweisstands, zur Aktualisierung des Sanierungsfahrplans und zur Neubewertung der Datenqualität, ohne dass die Fachmodule einander direkt kennen müssten. Die Ausweitung dieses Prinzips nach außen — über Ereignisbenachrichtigungen an angemeldete Fremdsysteme — steht dagegen aus.

8.6 Maschinenlesbare Datenformate

Der Gebäudepass muss Informationen in strukturierten Formaten ausgeben können. Die EPBD ist an diesem Punkt ungewöhnlich konkret: Artikel 19 verlangt den Energieausweis digital und maschinenlesbar und nennt CSV, JSON und XML als geeignete Formate; ein gescanntes PDF genügt ausdrücklich nicht, und die Papierform ist nur noch auf Wunsch bereitzustellen. Für die nationalen Datenbanken nach Artikel 22 werden dieselben Formate zuzüglich XSLT und einer digitalen Schnittstelle genannt. Dänemark und Portugal, die als Referenzen der Leitlinien angeführt werden, speichern gar keine PDF-Dateien mehr — der Ausweis wird bei Bedarf aus den Rohdaten erzeugt.

Die vier praktisch relevanten Formate haben unterschiedliche Aufgaben, die sich nicht ersetzen:

• XML — geeignet für klar definierte, schemagebundene Datenstrukturen und regulatorische Austauschprozesse; die Registrierung von Energieausweisen läuft in Deutschland über XML-Kontrolldateien.
• JSON — geeignet für Web- und Schnittstellenkommunikation, für Projektdateien und für die Übergabe an moderne Fachanwendungen.
• CSV — geeignet für tabellarische Auswertungen, Statistiklieferungen und einfache Datenübergaben ohne Schemabindung.
• IFC — geeignet für geometrische und BIM-bezogene Gebäudedaten; der zugehörige offene Austauschstandard ist DIN EN ISO 16739-1.

Eine Klarstellung ist an dieser Stelle wichtig, weil sie in der Praxis regelmäßig übergangen wird: Maschinenlesbarkeit ist nur für den Energieausweis Pflicht. Für den Renovierungspass verlangt Artikel 12 die digitale und druckfähige Form; die maschinenlesbare Ausgabe in XML ist eine Empfehlung der Kommissionsleitlinien, keine Rechtspflicht. Wer beides gleichsetzt, behauptet eine Pflicht, die es nicht gibt. Umgekehrt gilt: Ein Renovierungspass, der maschinenlesbar vorliegt, lässt sich nach Artikel 12 Absatz 7 in die Datenbank hochladen und nach Artikel 19 Absatz 14 als Quelle einer vereinfachten Ausweisaktualisierung nutzen — die technische Mehrleistung zahlt sich also aus, auch wenn sie nicht gefordert ist.

Die PDF-Ausgabe verliert damit nicht ihre Berechtigung, wechselt aber die Rolle. Sie ist das lesbare Begleitdokument für Menschen und für die Ablage; sie ist nicht mehr das Transportformat zwischen Systemen. Die vorhandene Software erzeugt PDF-Dokumente über zwei Wege — clientseitig und serverseitig — und legt sieben Dokumenttypen automatisiert an, jeweils mit einem Hash-Merker, der eine Neuerzeugung nur bei geänderter Datengrundlage auslöst. Für die maschinenlesbare Ebene stehen daneben das JSON-Projektformat mit Export und Import, CSV-Ausgaben, ZIP-Pakete für die Nachhaltigkeitsdokumentation und ein Zertifikats-Export zur Verfügung, der die gesetzlichen Pflichtangaben des Energieausweises maschinenlesbar mitführt. Eine geschlossene, dokumentierte Exportmodulfamilie mit definierten Zielformaten ist dagegen als offener Punkt geführt.

8.7 Gebäudeidentifikatoren und Zugriffsreferenzen

Ein digitaler Gebäudepass benötigt eine eindeutige Gebäudekennung. Sie muss dauerhaft, eindeutig, systemunabhängig, nicht personenbezogen und maschinenlesbar sein — und sie darf insbesondere nicht an einen Eigentümer gebunden sein. Der Grund ist einfach: Eigentümer wechseln, die Gebäudeidentität bleibt. Eine ID, die beim Verkauf verfällt, macht die gesamte Historie wertlos, denn genau an der Eigentumsschwelle ist der dokumentierte Zustand des Gebäudes am wertvollsten.

Die Gebäudekennung wird damit zum technischen Anker für Dokumente, Berechnungen, Energieausweise, Sanierungsmaßnahmen, Registereinträge und Eigentümerwechsel. Artikel 22 der EPBD verlangt eindeutige Gebäude- und Einheiten-Identifikatoren mit Geo-Referenz, datenbankübergreifend und „von Anfang an“, und Absatz 7 fordert Interoperabilität mit Kataster und Grundbuch. Die Leitlinien verweisen auf Portugal, wo bis zu elf verschiedene Identifikatoren je Gebäude geführt werden. Diese Zahl ist kein Vorbild für Komplexität, sondern eine realistische Erwartung: Kein Gebäude wird in der Praxis nur eine Kennung tragen.

Sinnvoll ist deshalb eine mehrstufige Identität, in der jede Kennung eine eigene Aufgabe hat. Die interne Gebäude-ID ist die technische Primärkennung des Systems und ändert sich nie. Die öffentliche Pass-ID dient dem Zugriff über QR-Code oder Weblink und kann bei Bedarf erneuert werden, ohne die interne Kennung zu berühren. Die externe Register-ID nimmt auf, was nationale Register an eigener Gebäudeidentifikation vergeben. Der Katasterbezug schließlich stellt die Verbindung zu Flurstück und Grundstücksreferenz her, die Artikel 22 Absatz 7 verlangt. Der Gebäudepass verbindet damit unterschiedliche Identifikationssysteme, ohne eines davon zu ersetzen.

In der vorhandenen Software existiert die interne Gebäude-ID produktiv. Sie folgt dem Muster einer Jahres- und Laufnummernkennung, wird idempotent und dauerhaft vergeben und liegt in einem eigenen, additiv angelegten Abschnitt des Projektdatensatzes zusammen mit Erstellungsdatum, Status und Version. Die Energieausweisnummer wird deterministisch aus dieser Gebäude-ID abgeleitet; sie ist ausdrücklich keine Registriernummer der amtlichen Registrierstelle, was in jeder Ausgabe kenntlich bleiben muss. Der öffentliche Pass wird als eigener Datenabzug erzeugt, der über eine Filterfunktion nur Gebäudekennwerte und keine personenbezogenen Daten übernimmt; sein Aufruf ist durch eine vierstellige PIN geschützt, mit gestaffelten Sperrzeiten nach jeweils drei Fehlversuchen. Der QR-Code wird ohne PIN gedruckt und trägt selbst keine Gebäudedaten — er ist eine Referenz auf die Pass-ID, nicht deren Inhalt. Damit kann derselbe QR-Code je nach Anmeldung unterschiedliche Ansichten öffnen; ein Eigentümer sieht andere Informationen als ein Makler oder ein Kreditinstitut. Vorausgesetzt ist dafür allerdings die abgestufte Rechteschicht, die Kapitel 9 behandelt und die derzeit als Konzept, nicht als Umsetzung vorliegt.

Ebenfalls Konzept und nicht Bestand sind die weiteren Kennungsebenen: ein regionalisiertes Identifikationsschema, eine gesonderte Passport-ID, der maschinenlesbare Zonenaufdruck einer Passkarte, die Nahfeldkommunikation für Kartenprodukte und der Katasterbezug. Für die Wallet-Ausgabe existieren die technischen Routen, die erforderlichen Zertifikate stehen aus. Diese Punkte sind in der Zielarchitektur vorgesehen; sie als vorhanden darzustellen, wäre unzutreffend.

8.8 Schnittstelle zu Energieausweisregistern

Die Registrierung von Energieausweisen ist in Deutschland bereits heute ein etablierter digitaler Prozess. Die Registrierstelle des Deutschen Instituts für Bautechnik vergibt die Registriernummern, nimmt XML-Kontrolldateien entgegen, bindet Softwareanbieter an und wickelt die elektronische Stichprobenkontrolle ab. Für die Architektur des Gebäudepasses folgt daraus eine klare Empfehlung: Das Energieausweismodul sollte technisch getrennt vom Gebäudedatenkern an die jeweilige Registerlogik angebunden werden. Der Grund ist derselbe wie bei allen externen Systemen — die Registerlogik ist national, änderungsanfällig und nicht beeinflussbar, während der Gebäudedatensatz stabil bleiben soll.

Die Prozesskette verläuft in sechs Schritten: Aus dem Gebäudedatensatz entsteht die Energieausweisberechnung, aus dieser der Ausweisdatensatz, dieser wird in den Registrierprozess gegeben, von dort kommt die Registriernummer zurück, und diese wird in den Gebäudepass zurückgespeichert. Entscheidend ist der letzte Schritt. Eine Registriernummer, die nur auf dem ausgedruckten Dokument steht, ist für das System nicht existent; sie muss als Datum im Gebäudedatensatz stehen, damit spätere Aktualisierungen, Gültigkeitsprüfungen und Datenbankmeldungen darauf aufsetzen können.

Die Registrierung selbst sollte als eigener Vorgang gespeichert werden, nicht als Feld am Ausweis. Ein Registrierungsdatensatz führt die Ausweiskennung, das Datum, den Status, die zurückgemeldete Registriernummer und den Übertragungsstatus. Damit wird auch der externe Prozess nachvollziehbar: Es ist im Nachhinein feststellbar, wann eine Übermittlung stattgefunden hat, ob sie erfolgreich war und welcher Ausweisstand übermittelt wurde. Für die Stichprobenkontrolle nach Anhang VI der EPBD ist genau diese Nachvollziehbarkeit die Voraussetzung.

Zwei Randbedingungen sind bei der Umsetzung zu beachten. Erstens verlangt Artikel 20 Absatz 8 die Übermittlung des vollständigen Ausweises einschließlich sämtlicher Berechnungs-Eingangsdaten — Gebäudekategorie, Bezugsfläche mit Aufschlüsselung bei Mischnutzung, nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Anlagentechnik disaggregierter Bedarf, Leistung und Effizienz der technischen Anlagen, installierte Leistung erneuerbarer Erzeugung sowie Flächen und U-Werte der Hauptbauteile. Ein System, das nur das Ergebnis übermittelt, erfüllt diese Anforderung nicht. Zweitens ist das Kontrolldatei-Schema für die nach dem Gebäudemodernisierungsgesetz künftig verlangte monatliche Verbrauchserfassung über vierundzwanzig Monate zum Quellenstand nicht veröffentlicht; bis dahin sind Monatswerte im bisherigen Periodenformat zu übermitteln. Die Schnittstelle muss also beide Verfahren parallel bedienen können.

8.9 Nationale Gebäudedatenbanken und Exportprofile

Artikel 22 der EPBD verpflichtet die Mitgliedstaaten, ab dem 29. Mai 2026 eine nationale Datenbank für Gebäude- und Energieperformancedaten oder einen Verbund solcher Datenbanken mit einem öffentlichen Zugang zu betreiben. Aufzunehmen sind Energieausweise, Inspektionsberichte, Renovierungspässe, Bewertungen der Intelligenzfähigkeit sowie berechneter und gemessener Verbrauch. Die Datenbank ist damit nicht nur ein Register, sondern die zentrale Datendrehscheibe der Richtlinie — an ihr hängen die Zugriffsrechte nach Artikel 16, die Meldung an das europäische Beobachtungssystem und die aggregierte Veröffentlichung.

Für Deutschland ist der Stand nüchtern zu benennen: Nach Anhang 5 der Kommissionsleitlinien existiert zum Quellenstand keine nationale Energieausweis-Datenbank, und ein deutsches Datenschema nach Artikel 22 liegt nicht vor. Der Gebäudepass kann sich deshalb heute nicht an ein verbindliches Zielschema anschließen. Er kann aber — und sollte — so gebaut werden, dass die Anbindung eine Frage der Abbildungsvorschrift bleibt und nicht eine Frage des Datenmodells. Konkret heißt das: alle in Artikel 20 Absatz 8 genannten Eingangsgrößen strukturiert vorhalten, jede davon mit Feldadresse, Einheit und Herkunft versehen und keine davon ausschließlich in einem PDF führen.

Architektonisch entscheidend ist die Trennung der Datenmengen. Der Gebäudepass enthält den vollständigen Gebäudedatensatz einschließlich interner Dokumente, Kostenangaben und Arbeitsständen. Das Register erhält ausschließlich den gesetzlich vorgesehenen Datensatz. Diese Trennung schützt die Datenhoheit des Eigentümers und vermeidet, dass Informationen übertragen werden, für deren Übermittlung es keine Rechtsgrundlage gibt.

Technisch wird die Trennung über Exportprofile hergestellt. Ein Exportprofil ist eine benannte, versionierte Feldliste, die festlegt, welche Datenfelder an welche Gegenstelle gehen. Vier Profile sind absehbar erforderlich:

• Profil Energieausweisregister — die Ausweisdaten und die vollständigen Berechnungs-Eingangsdaten nach Artikel 20 Absatz 8, nichts darüber hinaus.
• Profil Kreditinstitut — Energiekennwerte, Sanierungsbedarf, Investitionsbedarf und Datenqualität in der in Abschnitt 8.12 beschriebenen Zusammenstellung.
• Profil Makler — Energieausweis, Heizsystem, Sanierungshistorie und die vom Eigentümer freigegebenen Gebäudedaten.
• Profil Behörde — die jeweils gesetzlich benötigten Informationen, etwa für Förderstellen, Bauaufsicht oder kommunale Wärmeplanung.

Der Gewinn dieser Bauform liegt in der Steuerungsebene. Datenzugriff wird nicht mehr auf Dateiebene geregelt — „diese PDF-Datei darf die Bank sehen“ —, sondern auf Datenfeldebene. Damit lässt sich der Umfang einer Weitergabe präzise begründen, protokollieren und im Streitfall belegen. Exportprofile in diesem Sinn sind in der vorhandenen Software nicht implementiert; die Anzeige-Rollen der Kennwerte-Seite priorisieren lediglich die Darstellung. Vorhanden ist allerdings die technische Vorstufe: Der öffentliche Passabzug wird bereits über eine Filterfunktion erzeugt, die personenbezogene Daten entfernt. Sie ist der Ansatzpunkt, an dem die weiteren Profile aufsetzen können.

8.10 Verbindung zum EU Building Stock Observatory

Artikel 22 verlangt von den Mitgliedstaaten die mindestens jährliche Übertragung von Daten an das europäische Gebäudebestands-Beobachtungssystem; die zugehörigen Vorlagen sind in der Durchführungsverordnung (EU) 2025/1328 festgelegt, die am 30. Juni 2025 erlassen wurde. Zusätzlich ist mindestens zweimal jährlich eine aggregierte, anonymisierte Veröffentlichung vorzunehmen. Für Energieausweis- und Renovierungspassdaten ist diese Verordnung damit der technisch maßgebliche Rahmen der europäischen Aggregationsebene.

Daraus folgt eine Architekturregel, die auf den ersten Blick kontraintuitiv wirkt: Der Gebäudepass sollte gerade nicht unmittelbar auf die europäische Plattform zugeschnitten werden. Adressat der Meldepflicht ist der Mitgliedstaat, nicht der einzelne Datenhalter. Der sachgerechte Weg verläuft daher in einer Kaskade — vom Gebäudepass in die nationale Datenstruktur, von dort in die nationale Gebäudedatenbank und erst von dieser in die europäische Aggregation. Wer diese Zwischenstufe überspringt, baut eine Schnittstelle zu einer Gegenstelle, die seine Daten gar nicht annehmen darf, und verfehlt zugleich die nationale Umsetzungsebene, in der die eigentlichen Pflichten entstehen.

Praktisch bedeutet das für die Entwicklung: Die Vorlagen der Durchführungsverordnung sind als Zielgrößen der Datenvollständigkeit zu lesen, nicht als Exportformat. Sie geben Auskunft darüber, welche Merkmale ein Gebäudedatensatz am Ende tragen muss, damit er auf europäischer Ebene auswertbar bleibt. Der Gebäudepass sollte diese Merkmale führen; die Formatfrage entscheidet sich später und auf nationaler Ebene.

8.11 Import von BIM-, CAD- und Messdaten

Der Import ist die aufwendigste Seite jeder Integrationsschicht, weil die Datenqualität außerhalb der eigenen Kontrolle entsteht. Drei Quellgruppen sind zu unterscheiden: strukturierte Planungsmodelle, unstrukturierte Bestandsunterlagen und Messdaten.

Planungsmodelle: IFC und CAD

IFC ist die wichtigste Schnittstelle zur Bauplanung; der zugehörige Standard ist DIN EN ISO 16739-1. Ein IFC-Import sollte mindestens Gebäude, Geschosse, Räume, Flächen, Wände, Dächer, Fenster, Türen, Materialien und technische Anlagen auslesen können. Die eigentliche Arbeit liegt jedoch nicht im Lesen, sondern in der Abbildung: Die gelesenen Objekte müssen auf das interne Gebäudedatenmodell übertragen werden. Dafür benötigt das System eine eigene Mapping-Schicht, die etwa eine IFC-Wand auf den Bauteiltyp Wand, ein IFC-Fenster auf den Bauteiltyp Fenster und einen IFC-Raum auf Raum beziehungsweise Zone abbildet. Diese Abbildung muss unabhängig vom Fachmodul funktionieren — sonst entstehen so viele Mapping-Varianten, wie es Module gibt, und die Herkunft eines Werts ist nicht mehr rekonstruierbar.

In der vorhandenen Software ist IFC als Eingangsweg vorgesehen und ausdrücklich als Einbahnstraße gekennzeichnet: Es gibt einen IFC-Eingang, aber keinen IFC-Ausgang. Für Geometriedaten aus CAD-Werkzeugen existiert ein Import über XML- und JSON-Strukturen, der den Grundriss mit Geschossen, Zonen, Dächern, Öffnungen und Hüllflächen in den Projektspeicher überträgt. Der Weg zurück in die Planung — ein IFC-Export für Architektur- und TGA-Büros — ist Zielarchitektur.

Bestandsunterlagen: PDF, Scans, Fotos

Nicht jedes Gebäude besitzt ein IFC-Modell; im Bestand ist es die Ausnahme. Verarbeitet werden dort PDF-Grundrisse, gescannte Pläne, DWG- und DXF-Dateien, Fotografien und alte Berechnungen. Diese Unterlagen benötigen eigene Importwege, und sie liefern grundsätzlich keine gesicherten Werte, sondern Lesarten. Die vorhandene Software verfügt hier über eine belastbare Grundlage: Grundriss, Wärmeschutznachweis und Energieausweis werden über eine gemeinsame Ablagezone eingelesen, und die Analyse erkennt selbst, welcher Dokumenttyp vorliegt.

Für alle Importwege gilt derselbe Grundsatz: Ein Import ist immer ein Vorschlag. Jeder Import muss zwei Ebenen unterscheiden — die Quelldaten, also was tatsächlich gefunden wurde, und den interpretierten Gebäudewert, also was daraus übernommen werden soll. Wird aus einem PDF die Angabe „Dämmung 160 mm“ gelesen, so ist das Quelldatum die erkannte Textstelle; der Vorschlag lautet, der Außenwand mit einer bestimmten Kennung eine Dämmstärke von 160 mm zuzuordnen. Erst nach Prüfung und Freigabe durch eine fachlich verantwortliche Person wird der Wert Bestandteil des freigegebenen Gebäudedatensatzes. Diese Regel ist in der vorhandenen Software als Governance-Schicht implementiert: Ein Meldevorgang legt den Vorschlag im Arbeitsbereich ab und ändert den offiziellen Wert nicht, erst die Freigabe schreibt in den führenden Datenpfad. Vier Datenzustände von Entwurf über gemeldet und geprüft bis freigegeben und sechs Vertrauensstufen von unbekannt bis amtlich signiert bilden ab, wie belastbar ein Wert jeweils ist. Nur freigegebene Werte dürfen in offizielle Berichte eingehen.

Was fehlt, ist die Bequemlichkeitsschicht darüber. Ein Ein-Klick-Import, der einen kompletten Fremddatensatz mit einer einzigen Nutzeraktion übernimmt und die Zuordnungsvorschläge gebündelt zur Bestätigung vorlegt, ist als Konzept beschrieben, aber weder als Schnittstelle noch als Bedienoberfläche umgesetzt.

Messdaten und Zeitreihen

Langfristig muss die Architektur auch Betriebsdaten aufnehmen: Smart Meter, Strom- und Wärmemengenzähler, Wärmepumpen, Photovoltaik-Wechselrichter, Batteriespeicher und Gebäudeautomation. Diese Daten unterscheiden sich, wie in Abschnitt 8.3 dargestellt, strukturell von Gebäudestammdaten und gehören in eine eigene Zeitreihenstruktur.

Rechtlich ist die Abgrenzung ebenso wichtig wie technisch. Artikel 16 der EPBD erfasst statische Gebäudesystemdaten — Bauteilperformance, gebäudetechnische Dienste, die Lebensdauerprognose der Heizung, Automationssysteme, Zähler sowie Mess- und Regelgeräte und Ladepunkte — und gibt Eigentümern, Mietern und Verwaltern einen direkten und kostenlosen Zugang dazu, einschließlich der kostenlosen Weitergabe an selbst benannte Dritte. Die dynamischen Daten vernetzter Produkte fallen dagegen unter den Data Act, die Verordnung (EU) 2023/2854, und Abrechnungszähler unter die Strom- und Gasbinnenmarktvorschriften. Ein Gebäudepass, der Messdaten aufnimmt, bewegt sich damit in zwei Rechtsregimen gleichzeitig. Die technische Trennung von Stammdaten und Zeitreihen ist deshalb zugleich die Voraussetzung dafür, unterschiedliche Zugriffs- und Löschregeln überhaupt anwenden zu können.

Validierung an der Schnittstelle

Jede externe Schnittstelle benötigt Validierungsregeln, und zwar an der Schnittstelle selbst, nicht erst im Fachmodul. Liefert eine Gegenstelle für ein Fenster einen U-Wert von −0,5 W/(m²K), darf das System den Wert nicht übernehmen, weil er physikalisch unmöglich ist. Meldet ein Import für ein Einfamilienhaus eine Nutzfläche von 18.000 m², ist der Wert nicht unmöglich, aber unplausibel; er ist zu übernehmen und zu markieren, nicht stillschweigend zu verwerfen. Die Unterscheidung zwischen Ablehnung und Markierung ist wesentlich, denn ein System, das unplausible Werte einfach ausblendet, verliert genau die Fälle, die der Prüfung bedürfen. Die Integrationsschicht ist damit immer auch Qualitätssicherungsschicht. Die vorhandene Software führt hierfür einen Quellen-Abgleich mit sechs Regeln, der prüft, ob die Daten in sich stimmen, und der vier doppelt geführte Angaben — Bauweise, Kellerausbildung, Firstrichtung und Geschossanzahl — gegen die jeweils andere Quelle stellt, ohne automatisch zu überschreiben. Konflikte werden erzeugt, nicht aufgelöst; die Entscheidung bleibt beim Menschen.

8.12 Export für Behörden, Banken und Fachplaner

Auf der Ausgabeseite unterscheiden sich die Empfänger weniger in der Technik als im Umfang dessen, was sie sehen dürfen und sinnvoll verwerten können. Ein Export, der den gesamten Gebäudepass überträgt, ist für keinen der Empfänger richtig: Er überfordert die einen und verletzt bei den anderen die Zweckbindung.

Kreditinstitute benötigen einen finanzierungsrelevanten Ausschnitt. Er umfasst die Gebäudekennung, die Gebäudeart, den Status und die Klasse des Energieausweises, End- und Primärenergie, die Emissionen, das Heizsystem, den Sanierungsbedarf und den Sanierungsfahrplan, den Investitionsbedarf, die Förderfähigkeit sowie eine Kennzahl zur Datenqualität. Entscheidend ist dabei nicht die Feldliste, sondern die Ebene darunter: die Quellenangabe je Wert. Ein Kreditinstitut muss erkennen können, dass die Effizienzklasse aus einem registrierten Energieausweis stammt, die Fassadendämmung durch Rechnung und Fachunternehmererklärung belegt ist und die Sanierungskosten aus einer Kostenberechnung hervorgehen — und nicht aus einer Schätzung. Erst dadurch wird der Gebäudepass zu einem Evidenzsystem. Eine reine Kennzahlendarstellung ohne Herkunftsebene ist für die Kreditwürdigkeitsprüfung erheblich weniger wert, weil sie nicht prüffähig ist. Die vorhandene Software führt Herkunftsmetadaten je Wert und je Beziehung und zeigt sie auf der Kennwerte-Seite als Herkunftskennzeichnung an; die Weitergabe dieser Ebene über eine Schnittstelle ist Zielarchitektur.

Immobilienmakler benötigen eine deutlich reduzierte Sicht. Ein freigegebenes Verkaufsprofil umfasst Gebäudetyp, Baujahr, Fläche, Heizsystem, Energieklasse und Energieausweis sowie die letzten Sanierungen und die geplanten Maßnahmen. Interne Dokumente, Kosten- und Finanzierungsangaben sowie Eigentümerdaten bleiben geschützt. Hausverwaltungen benötigen dagegen vor allem Betriebsinformationen: Wartungszyklen, Anlagenbestand, Rechnungen, Energieverbrauch, Prüfberichte und Modernisierungshistorie; der Gebäudepass wird für sie zur technischen Verwaltungsakte. Energieberater, Architekten und TGA-Planer benötigen die umfassendste Sicht — vollständige Geometrie, Bauteile, Anlagen, Zonen, Nutzungsprofile, die Eingangsdaten der Bilanz nach DIN V 18599, sämtliche Berechnungsstände, Sanierungsvarianten und Dokumente. Der Gewinn liegt hier im Wechselfall: Ein neu beauftragter Berater kann auf den bestehenden Daten aufsetzen, statt das Gebäude vollständig neu aufzunehmen. Für Behörden schließlich gilt der Grundsatz der gesetzlich definierten Feldliste — nicht mehr und nicht weniger als das, was die jeweilige Vorschrift verlangt.

Ein praktischer Hinweis zur Ausgabeseite gehört an diese Stelle, weil er ein wiederkehrendes Muster betrifft. Automatisierte Dokumenterzeugung ist nützlich, darf aber nicht ungefragt ablaufen. In der vorhandenen Software löst bereits das Öffnen des Gebäudepasses einen automatischen Dokumentenlauf aus, der ohne Nutzeraktion PDF-Dateien erzeugt und ablegt. Das ist als Befund dokumentiert und korrekturbedürftig: Jede Erzeugung eines Dokuments, das den Datenbestand verlässt oder in ihn hineinschreibt, muss auf eine bewusste Handlung zurückführbar sein — nicht zuletzt, weil andernfalls die Zuordnung des Urhebers nach Anhang VI der EPBD ins Leere läuft.

8.13 Sicherheit, Audit Trail und Revisionssicherheit

Mit der Zahl der Schnittstellen wächst die Angriffsfläche. Sicherheit ist deshalb kein nachgelagertes Thema, sondern Bestandteil der Grundarchitektur: verschlüsselte Übertragung, verschlüsselte Speicherung sensibler Daten, Mehrfaktor-Authentifizierung, rollenbasierte Rechte, Zugriffshistorie, Protokollierung und regelmäßige Datensicherung. Kapitel 9 behandelt die datenschutzrechtliche Seite dieser Anforderungen ausführlich; hier interessiert nur ihre architektonische Konsequenz.

Die wichtigste davon ist die Trennung zwischen gebäudebezogenen und personenbezogenen Daten. Baujahr, U-Wert und Heizsystem beschreiben das Gebäude; Eigentümername, Telefonnummer und Bankverbindung beschreiben eine Person. Werden beide im selben Datensatz geführt, ist der Gebäudedatensatz beim Eigentümerwechsel nicht weitergabefähig, ohne personenbezogene Informationen mitzuführen. Werden sie getrennt oder wenigstens eindeutig klassifiziert gespeichert, kann der Gebäudedatensatz fortbestehen, während die Personendaten wechseln. Die vorhandene Software setzt diesen Grundsatz beim öffentlichen Pass bereits um, indem der veröffentlichte Abzug ausschließlich Gebäudekennwerte übernimmt.

Jede relevante Änderung benötigt einen Audit Trail: wer wann welchen Wert von welchem Ausgangswert auf welchen neuen Wert geändert hat, aus welchem Grund und mit welchem Nachweis. Ein vollständiger Eintrag lautet etwa: Datum, Benutzer, Bauteilkennung, U-Wert vorher 1,20 W/(m²K), U-Wert neu 0,20 W/(m²K), Grund Fassadensanierung, Nachweis Fachunternehmererklärung. Erst damit wird der Gebäudedatensatz revisionsfähig. Die Regel dahinter ist im Datenmodell der vorhandenen Software verbindlich formuliert: Jede Information hat genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie; jeder Wert trägt Metadaten zu Quelle, Methode, Erfasser, Datum, Prüfstatus und Version; es wird nicht überschrieben, sondern versioniert.

Revisionssicherheit bedeutet dabei ausdrücklich nicht, dass Daten unveränderlich wären. Ein Gebäudepass muss Änderungen zulassen — ein Gebäude, das saniert wird, ändert seine Kennwerte, und ein System, das dies verhindert, ist unbrauchbar. Entscheidend ist, dass alte Zustände nicht verschwinden. Die Historie bleibt erhalten, der aktuelle Gebäudestand ist lediglich die jeweils neueste Version. Auf der Ebene einzelner Werte ist dieses Prinzip in der vorhandenen Software umgesetzt. Auf der Ebene der Projektdatei arbeitet die automatische Speicherung dagegen ändernd am bestehenden Stand und legt vor jeder Änderung eine rollierende Sicherung der letzten zwanzig Fassungen an. Für den laufenden Betrieb ist das ausreichend, für eine Revisionssicherheit über Jahrzehnte nicht — hier ist der Übergang zu einer durchgängigen Versionskette erforderlich.

8.14 Langzeitarchivierung und Datenmigration

Gebäude existieren wesentlich länger als Softwareprodukte. Ein Wohngebäude, das heute einen digitalen Gebäudepass erhält, wird ihn in fünfzig Jahren noch benötigen; kein heute verwendetes Programm wird dann in seiner jetzigen Form laufen. Daraus ergeben sich Anforderungen an Datenformate, Dokumentformate, Migrationsfähigkeit, Sicherungen und Versionshistorien, die über gewöhnliche Softwarepflege hinausgehen.

Die erste Konsequenz betrifft die Formate. Proprietäre Formate allein sind für eine langfristige Architektur problematisch, weil ihre Lesbarkeit an den Fortbestand eines Anbieters gebunden ist. Der Datenbestand sollte deshalb in strukturierten, dokumentierten und offen spezifizierten Austauschformaten vorliegen — und, was ebenso wichtig ist, die Struktur selbst muss dokumentiert sein. Eine JSON-Datei ohne Feldkatalog ist in dreißig Jahren technisch lesbar und fachlich wertlos.

Die zweite Konsequenz ist die Trennung von Anwendung und Daten. Die Gebäudedaten dürfen nicht von einer bestimmten Benutzeroberfläche abhängen. Die heutige Weboberfläche kann in zehn Jahren vollständig anders aussehen; der Gebäudedatensatz muss davon unberührt bleiben. Praktisch bedeutet das, dass kein fachlich relevanter Wert ausschließlich in der Oberfläche entstehen oder gehalten werden darf und dass die Datenhaltung ohne die Anwendung les- und interpretierbar sein muss.

Die dritte Konsequenz betrifft die Migration. Jede neue Version des Datenmodells benötigt eine definierte Migrationsstrategie. Wird etwa das Heizsystem, das in einer ersten Modellfassung als einzelnes Feld geführt wurde, in einer zweiten in Erzeuger, Speicher, Verteilung und Übergabe aufgeteilt, so muss dokumentiert sein, wie die alten Angaben auf die neue Struktur abgebildet werden und was mit Informationen geschieht, die sich nicht abbilden lassen. Alte Daten dürfen nicht verloren gehen — auch nicht stillschweigend dadurch, dass sie in der neuen Struktur keinen Platz finden. Die vorhandene Software hat einen Migrationsvorgang dieser Art bereits durchlaufen: Die Umstellung vom Gebäudeenergiegesetz auf das Gebäudemodernisierungsgesetz wurde in drei Etappen mit eingefrorener Ausgangslage, automatisierten Ersetzungen und anschließender Prüfung durch die automatisierte Regressionsprüfung abgewickelt. Das Vorgehen — Baseline sichern, Ersetzung skripten, Prüfläufe grün stellen, Handkorrekturen dokumentieren — ist auf künftige Datenmodellversionen übertragbar.

8.15 Semantische Interoperabilität, Datenkatalog und Regelwerkskatalog

Die größte technische Herausforderung liegt langfristig nicht in der Berechnung, sondern in der Interoperabilität — in der Frage also, ob der Gebäudepass Daten mit anderen Systemen austauschen kann, ohne dass deren Bedeutung verloren geht. Dafür reichen technische Formate nicht aus. Es müssen auch Begriffe, Einheiten und Bedeutungen übereinstimmen.

Das klassische Beispiel ist die Fläche. System A speichert eine „Nutzfläche“, System B eine „Nettogrundfläche“, System C eine „beheizte Fläche“. Alle drei Werte stehen in Quadratmetern, alle drei sind fachlich richtig, und keine zwei bezeichnen dasselbe. Wer sie über eine Schnittstelle austauscht, ohne die Bedeutung mitzuliefern, erzeugt Zahlen, die formal korrekt und fachlich falsch sind. Dieselbe Problematik trägt die deutsche Umsetzung derzeit selbst: Die Bezugsflächen A_N und die Nettogrundfläche unterscheiden sich um eine zweistellige Prozentspanne, beide Bezüge sind zulässig, und ein Kennwert in kWh/(m²·a) ohne Angabe seines Flächenbezugs ist deshalb nicht interpretierbar.

Semantische Interoperabilität entsteht erst, wenn jedes Datenfeld eindeutig definiert ist. Ein Datenwert benötigt dafür fünf Angaben: Bezeichnung, fachliche Definition, Einheit, Berechnungsmethode und Quelle. Der Gebäudepass sollte diese Angaben nicht in der Dokumentation führen, sondern im System selbst — als zentralen Datenkatalog. Ein Katalogeintrag trägt eine stabile Feld-Kennung, die Bezeichnung, die hinterlegte fachliche Definition, die Einheit, den Datentyp, die zulässige Herkunft und eine eigene Versionsnummer. Damit wird der Datenkatalog zu einem Kernbestandteil der Plattform, nicht zu ihrer Begleitliteratur: Jede Schnittstelle, jedes Exportprofil und jede Prüfregel referenziert Katalogeinträge statt frei gewählter Feldnamen.

In der vorhandenen Software sind die Vorstufen eines solchen Katalogs angelegt. Ein Rechnerregister führt die Fachwerkzeuge mit Kennung, Version, Kategorie, Projekttypen, Schemabezug und Testfällen; für jedes dieser Werkzeuge liegt eine eigene Schemadatei vor. Ein Feldregister hält die Rollenmatrix über vierundvierzig Werkzeuge. Ein Kennwertkatalog beschreibt dreiundvierzig Kennwerte mit Erläuterung, Fachbezug und Herkunftskennzeichnung; fehlende Werte bleiben leer, statt geschätzt zu werden. Was fehlt, ist die Zusammenführung dieser Register zu einem einzigen, verbindlichen Katalog, auf den sich alle Schnittstellen beziehen.

Neben dem Datenkatalog benötigt das System einen Regelwerkskatalog. Gespeichert werden dort die Regeln des Gebäudemodernisierungsgesetzes, die Verfahren der DIN V 18599, die Förderregeln, die Prüfregeln und die Regeln der Ökobilanz — jede mit Kennung, Rechts- oder Normquelle, Gültigkeitszeitraum und Version. Nur so bleibt nachvollziehbar, warum das System zu einem bestimmten Ergebnis gekommen ist, und nur so lässt sich ein Ergebnis Jahre später reproduzieren. Auch hier existiert eine belastbare Vorstufe: Eine Rechtsstands-Registry hält die Fassungen 2026 und 2027 mit Überlagerungs- und Lückenlogik vor, jedes Rechenergebnis trägt einen Rechtsstandstempel, und offene Punkte — etwa noch nicht veröffentlichte Referenzgebäudekennwerte und Klassengrenzen — werden ausdrücklich als Lücke geführt statt mit Annahmen gefüllt. Eine Klassenzuordnung, für die die Grenzwerte fehlen, gibt bewusst kein Ergebnis zurück.

Aus Datenkatalog und Regelwerkskatalog folgt die zentrale Architekturformel des Kapitels: Daten beschreiben, was über das Gebäude bekannt ist; Regeln bestimmen, wie diese Daten zu bewerten sind; die Berechnung erzeugt daraus Ergebnisse; das Dokument gibt die Ergebnisse aus. Vier Ebenen, vier Zuständigkeiten, keine Vermischung. Diese Trennung ist die Voraussetzung dafür, dass eine Software über Jahrzehnte pflegbar bleibt.

8.16 Zielarchitektur und Stand der Schnittstellen

Die vollständige Zielarchitektur lässt sich als Kette von neun Stufen beschreiben. Am Anfang stehen die Datenquellen — IFC-Modelle, CAD-Daten, PDF-Unterlagen, Schnittstellenlieferungen, Nutzereingaben und Messsysteme. Sie münden in die Importschicht mit Mapping, gestützter Erkennung und Validierung. Deren Ergebnis geht in das kanonische Gebäudedatenmodell, auf das die Regelwerke — DIN V 18599, Gebäudemodernisierungsgesetz, Förderrecht, Ökobilanz — angewendet werden. Die Berechnungsmodule für Energie, Bauphysik, Ökobilanz und Wirtschaftlichkeit erzeugen daraus Ergebnisse, die die Qualitätssicherung auf Plausibilität, Vollständigkeit und Prüfbarkeit kontrolliert. Erst danach entstehen die Anwendungen — Energieausweis, Renovierungspass, ESG-Bewertung, Fördernachweis —, die über die Ausgabeschicht in PDF, XML, JSON, CSV oder über die Programmierschnittstelle an die externen Systeme gelangen: Register, Kreditinstitute, Behörden, Makler und Fachplaner.

Wie diese Kette im Betrieb zusammenwirkt, zeigt ein einzelner Vorgang. Ein Eigentümer lädt die Rechnung über neue Fenster hoch. Das Dokument wird gespeichert; die Dokumentenanalyse erkennt Fenstertyp und Einbaudatum; das System schlägt die Zuordnung zu den vorhandenen Fensterpositionen vor; eine fachlich verantwortliche Person bestätigt die Daten; der Gebäudedatensatz wird versioniert; die abhängigen Berechnungen werden als veraltet markiert; die Bilanz nach DIN V 18599 wird neu gerechnet; der Sanierungsfahrplan wird aktualisiert; der Status des Energieausweises wird geprüft; und die Gebäudechronik erhält ein neues Ereignis. Zehn Schritte, an denen Dokumentenablage, Erkennung, Freigabeprozess, Rechenkette und Historie beteiligt sind. Die tragenden Bausteine dieser Kette liegen in der vorhandenen Software bereits vor: Dokumentenablage, gestützte Plananalyse, Freigabe nach dem Vier-Augen-Prinzip, Abhängigkeitskette und Neuberechnungslogik sind produktiv. Teilweise umgesetzt sind die anschließenden Schritte — die automatische Prüfung des Ausweisstands und die durchgängige Fortschreibung des Sanierungsfahrplans.

Tabelle 8.1 fasst die Schnittstellen des Gebäudepasses zusammen und trennt dabei konsequent zwischen dem, was heute existiert, und dem, was Zielarchitektur ist. Die Spalte „Stand“ verwendet drei Stufen: vorhanden für produktiv genutzte Funktionen, teilweise für Funktionen, die in einer Richtung oder in Teilen bestehen, und Zielarchitektur für konzipierte, aber nicht implementierte Schnittstellen. Die Spalte „Voraussetzung“ nennt, was jeweils fehlt oder von außen geklärt sein muss.

Die Auswertung der Tabelle fällt eindeutig aus. Auf der Eingangsseite ist der Gebäudepass bereits anschlussfähig: Geometrie, Planunterlagen, Kostendaten und Projektdateien lassen sich einlesen, und die Governance-Schicht sorgt dafür, dass eingelesene Angaben Vorschläge bleiben, bis sie freigegeben sind. Auf der Ausgangsseite überwiegt dagegen die Dokumentenform. Sämtliche Schnittstellen zu externen Institutionen — Register, nationale Datenbank, europäische Aggregation, Kreditinstitute, Behörden — sind Zielarchitektur, und zwar aus zwei unterschiedlichen Gründen. Bei den Exportprofilen fehlt die eigene Umsetzung: eine offene, versionierte Service-Schnittstelle und ein definierter Formatkatalog. Bei Register und Datenbank fehlt dagegen die Gegenstelle: Ein deutsches Datenschema nach Artikel 22 existiert nicht, und die Kontrolldatei für die künftige monatliche Verbrauchserfassung ist nicht veröffentlicht. Diese beiden Ursachen sind strikt zu trennen, weil sie unterschiedliche Handlungen erfordern — die eine Entwicklungsarbeit, die andere Beobachtung und Vorbereitung.

Diese Architektur verändert die Rolle des Gebäudepasses grundlegend. Er ist dann keine Software für einen bestimmten Nachweis mehr, sondern eine Integrationsplattform für Gebäudedaten: Neue Anforderungen werden als Modul oder als Schnittstelle ergänzt, während der bestehende Gebäudedatenbestand erhalten bleibt. Regulatorische Entwicklungen lassen sich damit wesentlich schneller umsetzen, weil sie an einer Stelle eingreifen statt an allen. Der Aufwand dafür entsteht früh und der Nutzen spät — was der Grund dafür ist, dass diese Architektur in der Praxis selten gebaut und regelmäßig nachgerüstet wird. Kapitel 14 ordnet die hier beschriebenen Bausteine in eine Entwicklungsreihenfolge ein.

9 Datenschutz, Datensouveränität und Revisionssicherheit

Je vollständiger ein digitaler Gebäudepass wird, desto genauer muss geregelt sein, wer auf welche Information zugreifen darf, zu welchem Zweck und wie lange. Dieses Kapitel beschreibt die Zugangsrechte, die Artikel 16 der EPBD begründet, grenzt sie gegen die dynamischen Nutzungsdaten des EU Data Act ab und leitet daraus das Rollen-, Protokollierungs- und Aufbewahrungsmodell des Gebäudepasses ab. Es endet mit den sieben Grundsätzen, auf denen die Vertrauensarchitektur beruht, und mit einer offenen Bilanz dessen, was die vorhandene Software davon heute leistet und was Konzept geblieben ist.

9.1 Datenschutz als Bestandteil der Datenarchitektur

Ein vollständiger Gebäudedatensatz ist kein rein technischer Datenbestand. Er verbindet technische, wirtschaftliche und teilweise personenbezogene Informationen zu einem Bild, das über das Gebäude hinausreicht: Eigentümerdaten und Kontaktangaben, Rechnungen und Vertragsunterlagen, Finanzierungsinformationen, Energieverbräuche, Wartungs- und Anlagendaten, ausgeführte Sanierungsmaßnahmen, Dokumente zu Eigentümerwechseln und unter Umständen nutzerbezogene Betriebsdaten. Für sich genommen ist keine dieser Angaben besonders brisant. In der Zusammenschau ergibt sich jedoch ein wirtschaftliches und teilweise persönliches Profil, das weder in falsche Hände noch in ungeprüfte Zweitverwendungen geraten darf.

Daraus folgt eine Gestaltungsentscheidung, die früh getroffen werden muss. Datenschutz lässt sich einem gewachsenen Datenbestand nicht nachträglich überstülpen. Wenn ein System zunächst alle Informationen ungetrennt in einem Datensatz führt und erst später Zugriffsfilter davorsetzt, bleibt jede Freigabe eine Ausnahme von einem Zustand, in dem eigentlich alles für alle sichtbar wäre. Umgekehrt gilt: Wenn die Trennung von gebäudebezogenen und personenbezogenen Informationen, die Zuordnung von Quellen und die Protokollierung von Anfang an im Datenmodell angelegt sind, ist eine differenzierte Freigabe kein Sonderfall, sondern der Normalzustand. Datenschutz ist in diesem Sinn kein Zusatzmodul, sondern eine Eigenschaft des Datenmodells, wie es in Kapitel 4 beschrieben ist.

Der zweite Grund für diese frühe Festlegung ist die Lebensdauer. Ein Gebäudepass ist auf Jahrzehnte angelegt. Die Personen, die in dieser Zeit auf ihn zugreifen, wechseln mehrfach: Eigentümer, Mieter, Verwalter, Energieberater, Handwerksbetriebe, Kreditinstitute, Käufer. Ein Berechtigungsmodell, das nur den heutigen Beteiligten gerecht wird, veraltet mit der ersten Eigentumsübertragung. Das Modell muss deshalb den Wechsel selbst abbilden können und nicht nur den jeweiligen Zustand.

9.2 Trennung von Gebäude- und Personendaten

Die wichtigste Grundregel der Datenarchitektur lässt sich in einem Satz formulieren: Das Gebäude ist dauerhaft, Personen und Rollen ändern sich. Gebäudebezogene und personenbezogene Informationen sollten deshalb technisch getrennt geführt werden — nicht in getrennten Systemen, aber in getrennten Bereichen des Datenmodells, mit eigener Zugriffs- und Aufbewahrungslogik.

Der praktische Gewinn dieser Trennung zeigt sich beim Eigentümerwechsel. Weil die technische Gebäudehistorie nicht am Eigentümerkonto hängt, kann sie ohne Bruch weitergeführt werden, während die personenbezogenen Informationen des bisherigen Eigentümers gerade nicht mitwandern. Ohne diese Trennung stünde der Betreiber vor der Wahl, entweder die Gebäudehistorie mit dem Eigentümerkonto zu löschen — und damit den Zweck des Passes zu zerstören — oder personenbezogene Daten an einen Dritten weiterzureichen, für den sie nie bestimmt waren. Beide Wege wären falsch; die Trennung im Datenmodell vermeidet die Wahl.

Die Grenze verläuft dabei nicht immer scharf. Ein Wartungsprotokoll ist eine Gebäudeinformation, nennt aber einen ausführenden Betrieb und häufig eine handelnde Person. Eine Rechnung belegt eine Dämmmaßnahme und enthält zugleich Preise und Vertragspartner. Solche Dokumente sollten deshalb in zwei Schichten geführt werden: die fachliche Aussage, die dauerhaft zum Gebäude gehört — Dämmstärke, Bauteil, Datum, nachgewiesener U-Wert —, und das Belegdokument mit den darin enthaltenen personenbezogenen Angaben, das strenger geschützt und gegebenenfalls gesondert gelöscht oder geschwärzt werden kann. Das in Kapitel 4 beschriebene Verhältnis von Datensatz und Beleg über eine Kante „belegt durch" liefert dafür die technische Grundlage.

9.3 Eigentum an Gebäudedaten

Die Frage, wem Gebäudedaten „gehören", wird in der Praxis häufig gestellt und lässt sich juristisch nicht pauschal beantworten. Ein Eigentumsrecht an Daten als solchen kennt die deutsche Rechtsordnung nicht; was besteht, sind Urheber-, Vertrags-, Datenschutz- und Geschäftsgeheimnisrechte an einzelnen Inhalten, dazu vertragliche Nutzungsrechte. Für die technische Architektur ist die Eigentumsfrage deshalb wenig ergiebig. Weiter führt eine funktionale Betrachtung: Statt zu behaupten, der gesamte Datensatz gehöre einer Person, wird für jeden Datentyp geregelt, wer welche Befugnis hat.

Der Gebäudepass sollte deshalb zu jeder wesentlichen Information dokumentieren, wer sie bereitgestellt hat, wer sie erstellt oder berechnet hat, wer sie fachlich geprüft hat, wer sie verwalten darf und wer Zugriff auf sie erhalten hat. Diese fünf Angaben ersetzen die Eigentumsfrage durch eine Zuständigkeitsfrage, die technisch beantwortbar ist. Ein Energieberater bleibt Urheber der von ihm erstellten Bilanz, auch wenn der Eigentümer über deren Weitergabe entscheidet. Ein Handwerksbetrieb liefert einen Nachweis, verliert aber nicht die Verantwortung für dessen Richtigkeit. Eine Bank erhält Einsicht, ohne dadurch Verfügungsrechte zu erwerben.

Diese Betrachtung deckt sich mit dem Aufbau des Datenmodells, das ohnehin für jeden Wert Quelle, Methode, Erfasser, Datum, Prüfstatus und Version führt. Die Rechtezuordnung ist damit keine zusätzliche Struktur, sondern eine Auswertung von Metadaten, die aus fachlichen Gründen bereits vorhanden sind.

9.4 Rechte von Eigentümern, Mietern und Verwaltern nach Artikel 16 EPBD

Artikel 16 EPBD verankert erstmals einen unionsrechtlichen Anspruch auf Zugang zu Gebäudesystemdaten. Eigentümer, Mieter und Verwalter erhalten direkten und kostenlosen Zugriff auf diese Daten, ausdrücklich auch über einen Datenbank-Account. Ebenso ausdrücklich ist die Weitergabe an selbst benannte Dritte kostenlos: Wenn ein Eigentümer seinen Energieberater, seine Hausverwaltung oder ein Planungsbüro benennt, darf für diese Weitergabe kein Entgelt verlangt werden. Für andere Berechtigte — genannt sind Banken, Aggregatoren, Versorgungsunternehmen und die Statistik — dürfen die Mitgliedstaaten dagegen Gebühren festlegen.

Der Mindestumfang der zugänglich zu machenden Daten ist in Artikel 16 EPBD benannt und deutlich weiter, als der Begriff „Gebäudesystemdaten" zunächst vermuten lässt. Er umfasst die Leistungsfähigkeit der Bauteile, die gebäudetechnischen Dienste im Sinne der EPB-Systematik, die Lebensdauerprognose der Heizung, die Gebäudeautomations- und Regelungssysteme, Zähler sowie Mess- und Regelgeräte und die Ladepunkte für Elektrofahrzeuge. Die Richtlinie verknüpft diesen Datenumfang ausdrücklich mit dem digitalen Gebäudelogbuch — ein Beleg dafür, dass sie den Gebäudepass als naheliegenden Ort dieser Daten mitdenkt, ohne ihn vorzuschreiben.

Neben Artikel 16 EPBD steht die Datenbank nach Artikel 22 EPBD mit einer eigenen, davon zu unterscheidenden Zugriffsordnung, die in Kapitel 5 im Zusammenhang behandelt ist. Für das Berechtigungsmodell des Gebäudepasses sind beide Ebenen relevant, weil sie unterschiedliche Gruppen unterschiedlich stellen.

Für die Architektur des Gebäudepasses folgt daraus zweierlei. Erstens ist die Unterscheidung zwischen einem unentgeltlichen Grundzugang für die unmittelbar Beteiligten und einem regelbaren Zugang für wirtschaftlich interessierte Dritte keine Produktentscheidung, sondern eine unionsrechtliche Vorgabe, die das Berechtigungsmodell abbilden muss. Zweitens zeigt der Vergleich der beiden Artikel, dass die Rolle „Bank" nicht einheitlich zu behandeln ist: Beim Zugang zur nationalen Datenbank nach Artikel 22 EPBD zählen Finanzinstitute für ihr Portfolio zu den Stellen mit kostenlosem Zugang zum vollständigen Ausweis; beim Datenaustausch nach Artikel 16 EPBD gehören sie zu den Gruppen, für die ein Entgelt zulässig ist. Ein Berechtigungssystem, das nur eine pauschale Bankenrolle kennt, kann diesen Unterschied nicht abbilden.

Zu ergänzen ist ein Vorbehalt, der für das gesamte Kapitel gilt: Adressat aller genannten Pflichten ist der Mitgliedstaat. Erst die nationale Umsetzung — in Deutschland GEG und GMoDG — bindet Eigentümer, Aussteller und Plattformbetreiber. Die Durchführungsakte zur Interoperabilität des Datenzugriffs sind in Artikel 16 Abs. 5 EPBD mit Frist zum 31.12.2025 vorgesehen; das deutsche Datenbankschema nach Artikel 22 EPBD steht zum Bearbeitungsstand ebenso aus wie die nationale Ausgestaltung des Data Act. Der Gebäudepass muss deshalb ein Berechtigungsmodell vorhalten, das die Struktur der Richtlinie abbildet, ohne eine bereits abschließend geregelte Rechtslage zu unterstellen.

9.5 Statische Gebäudedaten und dynamische Nutzungsdaten — die Abgrenzung zum EU Data Act

Eine der praktisch folgenreichsten Abgrenzungen des gesamten Datenrechts verläuft mitten durch den Gebäudepass, und sie wird in der Diskussion häufig übersehen. Artikel 16 EPBD erfasst statische Gebäudedaten: die Eigenschaften der Bauteile, die installierte Anlagentechnik, deren Auslegung und Effizienz, die Regelungs- und Automationssysteme, die vorhandenen Zähler und Ladepunkte, die Lebensdauerprognose der Heizung. Es sind Daten, die das Gebäude und seine Ausstattung beschreiben und sich nur ändern, wenn am Gebäude etwas geändert wird.

Die dynamischen Daten vernetzter Produkte fallen dagegen nicht unter die EPBD, sondern unter den EU Data Act, die Verordnung (EU) 2023/2854, die seit dem 12.09.2025 anwendbar ist. Gemeint sind die laufenden Betriebs- und Nutzungsdaten, die ein vernetztes Gerät im Betrieb erzeugt: Betriebszustände und Laufzeiten einer Wärmepumpe, Vor- und Rücklauftemperaturen, Schaltzeiten der Regelung, Zählerstände in hoher zeitlicher Auflösung, Ladevorgänge an der Wallbox. Für Abrechnungszähler gilt zusätzlich das Regime der Strom- und Gasbinnenmarktrichtlinien.

Die Unterscheidung ist keine Formalie, denn an ihr hängen drei verschiedene Fragen. Sie entscheidet erstens darüber, gegen wen sich ein Anspruch richtet: Der Anspruch nach Artikel 16 EPBD richtet sich in der nationalen Umsetzung gegen die Stellen, die die Gebäudedaten führen; der Anspruch aus dem Data Act richtet sich gegen den Dateninhaber des vernetzten Produkts, in der Regel den Hersteller oder Betreiber der Anlage. Sie entscheidet zweitens über die Sensitivität: Ein U-Wert verrät nichts über die Bewohner, ein hochaufgelöstes Lastprofil verrät Anwesenheit, Tagesrhythmus und Nutzungsverhalten. Und sie entscheidet drittens über die Datenhaltung: Statische Daten gehören in den Gebäudedatensatz, dynamische Daten sollten dort in der Regel nur verdichtet ankommen — als Jahres- oder Monatswert, als Kennzahl, als Betriebsauffälligkeit —, nicht als vollständiger Rohdatenstrom.

Für den Gebäudepass empfiehlt sich daraus eine klare Bauregel: Er ist das Register der statischen Gebäudedaten und der aus Betriebsdaten abgeleiteten Kennwerte. Er ist nicht der Speicherort für Rohmesswerte vernetzter Produkte. Wo dynamische Daten benötigt werden — etwa für die Verbrauchsausweise, die das GMoDG ab dem Anwendungsdatum der zweiten Stufe auf eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate umstellt —, sollten sie über eine dokumentierte Schnittstelle bezogen und in der benötigten Verdichtung abgelegt werden, unter Angabe der Quelle und des Erfassungszeitraums. Diese Trennung reduziert die Datenschutzlast des Passes erheblich, ohne seinen fachlichen Nutzen zu schmälern.

9.6 Zugriff durch bevollmächtigte Dritte

Der Regelfall des Datenzugriffs im Gebäudepass ist nicht der Zugriff des Eigentümers, sondern der Zugriff eines von ihm bevollmächtigten Dritten. Der Energieberater braucht die technischen Daten, um zu rechnen. Die Bank braucht energetische Kennwerte und den Sanierungsstand, um zu finanzieren. Der Makler braucht das Verkaufsprofil, die Hausverwaltung die Betriebs- und Wartungsdaten. Jeder von ihnen braucht etwas anderes, und keiner von ihnen braucht alles.

Eine Freigabe sollte deshalb vier Angaben tragen: an wen sie geht, welchen Datenausschnitt sie umfasst, zu welchem Zweck sie erteilt wird und wie lange sie gilt. Erst diese Kombination macht aus einer Freigabe eine überprüfbare Erklärung. Der Eigentümer sollte in seiner Übersicht ohne Fachwissen erkennen können, welche Berechtigungen aktuell bestehen — etwa: Bank A, Zugriff auf Energie- und Sanierungsdaten, gültig bis zu einem bestimmten Datum; Makler B, Zugriff auf das Verkaufsprofil; Energieberater C, Zugriff auf die vollständigen technischen Daten. Diese Transparenz ist der eigentliche Kern der Datensouveränität: nicht die theoretische Möglichkeit, Zugriffe zu steuern, sondern die tatsächliche Sichtbarkeit dessen, was gerade gilt.

Die zeitliche Befristung verdient dabei besondere Aufmerksamkeit, weil sie den häufigsten Fehler der Praxis vermeidet: den vergessenen Zugang. Wenn ein Eigentümer eine Finanzierung beantragt und die Bank für die Dauer der Prüfung Zugriff auf das Finanzierungsprofil erhält, sollte dieser Zugriff nach Ablauf der vereinbarten Frist von selbst enden. Der Eigentümer muss nicht daran denken, ihn zu entziehen; er muss ihn verlängern, wenn er ihn weiter braucht. Die Leitlinien zur EPBD gehen in dieselbe Richtung, wenn sie für unabhängige Sachverständige sowie Kauf- und Mietinteressenten einen befristeten Zugang und gegebenenfalls eine reine Bildschirmansicht ohne Downloadmöglichkeit empfehlen.

Ebenso wichtig ist der Widerruf. Freiwillig erteilte Freigaben muss der Eigentümer grundsätzlich wieder entziehen können, soweit keine gesetzlichen Aufbewahrungs- oder Zugriffspflichten entgegenstehen. Der Widerruf darf jedoch nicht spurlos bleiben: Er wird protokolliert, so dass später nachvollziehbar ist, in welchem Zeitraum eine Berechtigung bestand und welche Daten in diesem Zeitraum zugänglich waren. Eine gelöschte Berechtigung ohne Protokoll wäre für den Eigentümer scheinbar sauber, aber im Streitfall wertlos.

Für Kreditinstitute empfiehlt sich ein eigenes, klar umrissenes Freigabepaket statt eines Zugriffs auf die vollständige Gebäudeakte. Ein solches Finanzierungsprofil kann den Energieausweis mit Effizienzklasse, den technischen Zustand, den Sanierungsbedarf mit der zugehörigen Kostenschätzung und eine Angabe zur Dokumentationsqualität enthalten. Alles, was für die Kreditentscheidung nicht erforderlich ist — private Notizen, vollständige Rechnungsdetails, Kontaktdaten Dritter —, bleibt außen vor. Der Vorteil liegt auf beiden Seiten: Der Eigentümer gibt nicht mehr preis als nötig, und das Institut erhält einen strukturierten, gleichförmigen Datensatz statt eines Konvoluts aus Einzeldokumenten.

9.7 DSGVO, Zweckbindung und Datenminimierung

Soweit der Gebäudepass personenbezogene Daten verarbeitet, gilt die Datenschutz-Grundverordnung unmittelbar. Die Leitlinien zur EPBD nennen für die nationalen Gebäudedatenbanken ausdrücklich die DSGVO und den Data Governance Act, dazu einen abgestuften Zugang, Privacy by design und gesicherte Backups. Diese vier Anforderungen lassen sich unmittelbar auf einen privaten Gebäudepass übertragen, und drei Grundsätze der DSGVO prägen dabei die Architektur besonders stark.

Der erste ist die Zweckbindung. Ein Datenzugriff wird nicht abstrakt erteilt, sondern für einen benannten Zweck — etwa die Prüfung einer Finanzierung, die Erstellung eines Energieausweises, die Vorbereitung eines Verkaufs. Aus einer Freigabe zur Finanzierungsprüfung folgt kein Recht zur Nutzung derselben Daten für Werbung, für die Anreicherung eigener Datenbestände oder für die Weitergabe an weitere Dritte. Der Gebäudepass sollte den Zweck deshalb nicht nur in den Nutzungsbedingungen führen, sondern als Attribut der Freigabe selbst — sichtbar für den Eigentümer, protokolliert im Zugriffsjournal und maßgeblich für den Umfang des freigegebenen Datenausschnitts.

Der zweite ist die Datenminimierung. Übertragen wird nur, was für den jeweiligen Zweck benötigt wird. Wenn eine Bank für eine erste energetische Einschätzung die Effizienzklasse, die Endenergie, das Heizsystem und den Sanierungsstatus braucht, dann sollte genau dieser Ausschnitt übertragen werden und nicht die vollständige Gebäudeakte mit Plänen, Rechnungen und Korrespondenz. Datenminimierung ist dabei nicht nur eine Rechtspflicht, sondern auch eine Vereinfachung: Kleinere, klar definierte Datenpakete sind leichter zu prüfen, leichter zu versionieren und leichter zu erklären als vollständige Akten.

Der dritte ist die Transparenz. Der Betroffene muss erkennen können, welche Daten über ihn gespeichert sind, woher sie stammen und wer sie erhalten hat. Für den Gebäudepass fällt diese Anforderung mit dem Prinzip der Datensouveränität zusammen: Die Übersicht über bestehende Freigaben, das Zugriffsprotokoll und die Herkunftskennzeichnung der Werte dienen zugleich der Bedienbarkeit und der datenschutzrechtlichen Auskunft.

Hinzu kommt eine Vorsichtsregel für automatisierte Verarbeitungen. Wo Auswertungen, Bewertungen oder Kennzahlen automatisch erzeugt werden, muss erkennbar bleiben, dass es sich um eine Berechnung und nicht um eine geprüfte Feststellung handelt, und die Berechnung muss erklärbar sein. Ein Gebäudekennwert, der ohne offengelegte Regel entsteht, wäre weder fachlich noch datenschutzrechtlich vertretbar.

9.8 Rollen- und Berechtigungssystem

Ein Gebäudedatensatz dieser Art verträgt keine Freigabe nach dem Muster „alles oder nichts". Er braucht ein Rollenmodell, das die typischen Beteiligten unterscheidet und jeder Rolle einen sachgerechten Ausschnitt zuordnet. Als Ausgangspunkt haben sich acht Rollen bewährt, die sich an den tatsächlichen Aufgaben orientieren:

• Eigentümer — weitreichende Verwaltungsrechte, insbesondere die Vergabe und den Widerruf von Freigaben.
• Energieberater — technische und energetische Bearbeitung, Berechnung, fachliche Freigabe.
• Architekt — Gebäudegeometrie, Bauteile, Planungsstände.
• TGA-Planer — Anlagentechnik, Auslegung, Hydraulik.
• Hausverwaltung — Betrieb, Wartung, Verbrauchserfassung.
• Bank — freigegebene Energie-, ESG- und Finanzierungsdaten.
• Makler — freigegebene Verkaufs- und Vermarktungsdaten.
• Behörde — die gesetzlich erforderlichen Informationen, nicht mehr.

Diese Rollen sind ein Raster, kein Rechtemodell. Das eigentliche Berechtigungssystem entsteht erst, wenn zu jeder Rolle festgelegt ist, welche Datenbereiche sie sieht, welche sie ändern darf und unter welchen Bedingungen die Zuordnung endet. Zusätzlich sollte es einen abgestuften Zugriffspfad geben, der von einer rein öffentlichen Kurzansicht über Interessenten- und Vermarktungsansichten bis zur vollen Bearbeitungsansicht des Eigentümers reicht. Ein solcher siebenstufiger Zugriffspfad — öffentlich, Interessent, Makler, Bank, Hausverwaltung, Energieberater, Eigentümer — ist für den Gebäudepass konzipiert; er ist in der vorhandenen Software jedoch nicht implementiert (Abschnitt 9.18).

Ein Rollenmodell muss außerdem zwischen Lese- und Änderungsrechten unterscheiden, und zwar feiner als in zwei Stufen. Sinnvoll ist eine Staffelung in sechs Rechte, die den fachlichen Ablauf abbildet:

• Lesen — Information ansehen, ohne sie zu verändern.
• Hochladen — ein Dokument hinzufügen, ohne damit einen Fachwert zu ändern.
• Bearbeiten — Daten im Arbeitsstand verändern.
• Prüfen — Daten fachlich kontrollieren und den Prüfstatus setzen.
• Freigeben — Daten offiziell bestätigen und für Berichte verwendbar machen.
• Löschen — Informationen entfernen beziehungsweise einen Löschprozess auslösen.

Der Nutzen dieser Staffelung liegt in der Trennung von Bearbeitung und Verantwortung. Ein Sachbearbeiter kann Daten erfassen, ohne sie freigeben zu können. Ein Handwerksbetrieb kann einen Nachweis hochladen, ohne dadurch den U-Wert eines Bauteils zu ändern. Ein Prüfer kann bestätigen, ohne selbst zu bearbeiten. Genau darauf beruht auch das Vier-Augen-Prinzip, das für besonders sensible Vorgänge sinnvoll ist: Ein Wert wird maschinell oder durch einen Bearbeiter vorgeschlagen, ein zweiter, fachlich qualifizierter Beteiligter gibt ihn frei. Bei einem Energieausweis kann dies bedeuten, dass eine Person die Erstellung übernimmt und eine zweite bestimmte Prüfparameter kontrolliert; bei einer KI-gestützten Datenerkennung, dass der erkannte Wert zunächst nur ein Vorschlag ist und erst mit der Freigabe durch den Energieberater in den maßgeblichen Datenstand übergeht.

9.9 Rechte auf Datenfeldebene und das Least-Privilege-Prinzip

Eine Zugriffskontrolle, die nur auf Dokumentebene arbeitet, greift für einen Gebäudepass zu kurz. Dokumente enthalten regelmäßig mehr, als der jeweilige Empfänger braucht; die Handwerkerrechnung, die den Dämmnachweis liefert, enthält auch Preise und Vertragspartner. Die Freigabe sollte deshalb auf der Ebene von Datenbereichen und einzelnen Feldern definierbar sein.

Das Beispiel der Bank macht den Unterschied deutlich. Sie darf für die Kreditprüfung sinnvollerweise die Effizienzklasse, die End- und Primärenergie, den Sanierungsbedarf und die geschätzten Investitionskosten sehen. Sie braucht keinen Zugriff auf private Notizen, Telefonnummern oder vollständige Rechnungsdetails. Wird die Trennung auf Feldebene geführt, kann derselbe Gebäudedatensatz ohne Kopie und ohne Doppelpflege für ganz unterschiedliche Empfänger verwendet werden — und die einzige Stelle, an der über den Umfang entschieden wird, ist die Freigabe selbst.

Ergänzend gilt das Least-Privilege-Prinzip: Jeder Beteiligte erhält nur die Rechte, die er für seine Aufgabe benötigt. Das reduziert nicht nur das Datenschutzrisiko, sondern auch drei praktische Fehlerquellen — die Fehlbedienung, die unbeabsichtigte Änderung und die unzulässige Weitergabe. Ein Makler benötigt keine Schreibrechte auf die Eingabedaten der Bilanzierung nach DIN V 18599; eine Bank benötigt keine Bearbeitungsrechte für Bauteile. Wo solche Rechte dennoch vergeben werden, entsteht kein Zusatznutzen, sondern nur die Möglichkeit eines Schadens, den niemand beabsichtigt hat.

Dasselbe Prinzip gilt innerhalb der Software für die schreibenden Werkzeuge. Sinnvoll ist eine Ordnung, in der die Erfassungswerkzeuge die führende Quelle bilden, ermittelnde Werkzeuge nur auf ausdrückliche Nutzeraktion schreiben, Rechenwerkzeuge ausschließlich in den Ergebnisbereich schreiben und Ausgabewerkzeuge wie Berichte und der Pass selbst gar nichts schreiben. Diese Ordnung ist für den vorhandenen Gebäudepass definiert, aber noch nicht technisch erzwungen; Abschnitt 9.18 benennt den Befund im Einzelnen.

9.10 Betriebs- und Messdaten, Mehrparteiengebäude

Messdaten sind der datenschutzrechtlich empfindlichste Teil des Gebäudedatensatzes, und ihre Empfindlichkeit steigt mit der zeitlichen Auflösung. Ein Jahresverbrauch sagt etwas über das Gebäude aus. Ein Viertelstundenprofil sagt etwas über die Menschen darin aus: wann sie aufstehen, wann sie das Haus verlassen, wann sie verreisen. Aus diesem Grund sollten Messdaten nach ihrer Sensitivität klassifiziert und mit abgestuften Zugriffs- und Speicherregeln versehen werden.

Die Tabelle ist zugleich eine Argumentationshilfe gegenüber der verbreiteten Annahme, mehr Daten seien immer besser. Für die energetische Bewertung eines Gebäudes bringt die Viertelstundenauflösung gegenüber dem Monatswert kaum zusätzliche Aussagekraft, erzeugt aber ein deutlich höheres Schutzbedürfnis. Die Regel lautet deshalb: so hoch aufgelöst wie fachlich nötig, so grob wie datenschutzrechtlich vertretbar — und die Verdichtung möglichst nah an der Datenquelle, nicht erst im Pass.

Eine zweite Ebene kommt bei Mehrparteiengebäuden hinzu. Hier ist konsequent zwischen der Gebäudeebene und der Ebene der Nutzungseinheit zu unterscheiden. Die Heizungsanlage, die Gebäudehülle, der Energieausweis des Gesamtgebäudes und die Wartungshistorie der Gemeinschaftsanlagen gehören zur Gebäudeebene. Der Verbrauch einer einzelnen Wohnung, die Ausstattung einer Einheit und mieterbezogene Angaben gehören zur Einheitenebene und dürfen anderen Bewohnern nicht automatisch sichtbar sein. Für das Datenmodell heißt das, dass die Einheiten eigene Identifikatoren tragen müssen — was sich mit der Anforderung aus Artikel 22 EPBD deckt, eindeutige Gebäude- und Einheiten-Identifikatoren datenbankübergreifend zu führen. Auch der Renovierungspass nach Artikel 12 EPBD gilt ausdrücklich für Gebäude und Gebäudeteile, so dass ein einzelner Wohnungseigentümer einen eigenen Pass erhalten kann, ohne Zugriff auf die Daten der übrigen Einheiten zu benötigen.

9.11 Datenschutz beim Eigentümerwechsel

Der Eigentümerwechsel ist für einen lebenslangen Gebäudepass der kritischste Vorgang, weil in ihm zwei berechtigte Ziele aufeinandertreffen: Die Gebäudehistorie soll erhalten bleiben, die personenbezogenen Daten des bisherigen Eigentümers dürfen aber nicht auf den neuen übergehen. Der Prozess selbst ist in Kapitel 10 im Zusammenhang der Lebenszyklusprozesse beschrieben; hier interessiert allein seine datenschutzrechtliche Logik.

Diese Logik folgt einer festen Reihenfolge. Mit dem bestätigten Eigentümerwechsel endet der Zugang des bisherigen Eigentümers, und mit ihm enden alle Freigaben, die er erteilt hat — auch die an Dritte, denn eine Vollmacht kann nicht länger reichen als die Berechtigung, aus der sie stammt. Die personenbezogenen Informationen des bisherigen Eigentümers werden getrennt beziehungsweise archiviert und stehen dem neuen Eigentümer nicht zur Verfügung. Der gebäudebezogene Datensatz bleibt unverändert bestehen. Der neue Eigentümer erhält anschließend eigene Berechtigungen und beginnt seinerseits mit der Vergabe von Freigaben.

Zum dauerhaften Gebäudedatensatz, der diesen Wechsel übersteht, gehören insbesondere Baujahr und Gebäudegeometrie, Bauteile und technische Anlagen, ausgestellte Energieausweise, ausgeführte Sanierungen, technische Nachweise, die Wartungshistorie, die vom bisherigen Eigentümer freigegebenen Rechnungsnachweise als Beleg der Bauteilqualität sowie die energetischen Berechnungen mit ihren Eingangsdaten. Nicht übertragen werden dagegen Kontaktdaten, Bankverbindungen, Finanzierungs- und Vertragsunterlagen sowie private Notizen. Diese Grenzziehung ist keine Frage der Bequemlichkeit: Sie ist der Grund dafür, dass die Trennung nach Abschnitt 9.2 nicht nachträglich hergestellt werden kann, sondern von Beginn an im Datenmodell angelegt sein muss.

Zu regeln ist außerdem der umgekehrte Fall — der Verlust des Zugangs. Ein Gebäudepass, der ausschließlich von einem Passwort abhängt, ist für einen Datensatz mit einer Lebensdauer von Jahrzehnten ungeeignet. Es braucht deshalb einen dokumentierten Wiederherstellungsprozess mit Identitätsprüfung, Eigentumsnachweis und administrativer Freigabe. Dieser Prozess ist zugleich ein Sicherheitsrisiko, weil er die üblichen Schutzmechanismen umgeht; er muss daher besonders streng ausgestaltet, vollständig protokolliert und in seiner Anwendung nachprüfbar sein.

9.12 Verschlüsselung und Authentifizierung

Die technischen Schutzmaßnahmen sind gegenüber den organisatorischen Regeln der vorangegangenen Abschnitte der leichtere Teil, weil für sie anerkannte Verfahren existieren. Sie sind gleichwohl unverzichtbar. Die Sicherheitsarchitektur des Gebäudepasses sollte mindestens eine verschlüsselte Übertragung aller Inhalte, eine gesicherte Authentifizierung der Zugänge, eine geschützte Speicherung der Daten und Dokumente und eine geordnete Schlüsselverwaltung umfassen. Welche Verfahren dabei im Einzelnen zum Einsatz kommen, ist bewusst nicht Gegenstand dieses Whitepapers: Kryptografische Verfahren altern, und eine Festlegung auf konkrete Algorithmen wäre in einem Dokument mit dieser Halbwertszeit unseriös. Maßgeblich ist der jeweils aktuelle Stand der Technik.

Bei der Authentifizierung sollte die Schutzstufe der Rolle folgen. Für einen reinen Lesezugriff auf einen begrenzten, personendatenfreien Ausschnitt kann ein einfacher Zugangscode angemessen sein, sofern er gegen automatisiertes Ausprobieren gesichert ist. Für Rollen, die Daten verändern, prüfen oder freigeben, sollte ein Benutzername mit Passwort nicht die einzige Schutzstufe bleiben; in Betracht kommen Mehrfaktor-Authentifizierung, zeitlich begrenzte Zugangscodes, Gerätefreigaben oder administrative Bestätigungen. Klarzustellen ist dabei, dass die EPBD selbst weder eine Zwei-Faktor-Authentifizierung noch ein bestimmtes Anmeldeverfahren vorschreibt. Diese Anforderungen ergeben sich aus der DSGVO, aus dem Stand der Technik und aus der Sorgfaltspflicht des Betreibers, nicht aus der Gebäuderichtlinie — eine Unterscheidung, die das Whitepaper an dieser Stelle bewusst offenlegt, um keine Rechtspflicht zu behaupten, die nicht besteht.

9.13 Protokollierung, Audit Trail und Revisionssicherheit

Protokollierung ist im Gebäudepass keine Sicherheitsbeigabe, sondern eine fachliche Kernfunktion. Sie beantwortet die Frage, die bei jedem späteren Streit zuerst gestellt wird: Wer hat wann was geändert, und woher stammte die Änderung? Ein Protokolleintrag sollte deshalb mindestens den Nutzer, seine Rolle, Datum und Uhrzeit, die ausgeführte Aktion und das betroffene Datenobjekt enthalten. Ein Eintrag der Form „22.08.2026, 10:17 Uhr, Nutzer Energieberater, Aktion: U-Wert Außenwand geändert, alt 1,20, neu 0,24, Quelle: Sanierungsnachweis" beantwortet die Frage vollständig — einschließlich der Herkunft des neuen Werts.

Die EPBD stützt diese Anforderung. Das Kontrollsystem nach Anhang VI verlangt, dass der Urheber jeder Hinzufügung und jeder Änderung in der Datenbank für die Behörden ermittelbar ist, und empfiehlt Plausibilitätswarnungen bereits beim Hochladen. Für einen Gebäudepass, der Daten in Register nach Artikel 22 EPBD liefern soll, ist die Protokollierung damit eine Voraussetzung der Anschlussfähigkeit und nicht nur eine Frage der inneren Ordnung.

Über das reine Zugriffsprotokoll hinaus braucht der Gebäudepass einen fachlichen Audit Trail. Er dokumentiert nicht Ereignisse, sondern die Entwicklung eines Datenobjekts: Ein Dach ist in der ersten Version ungedämmt, Quelle ist die Angabe des Eigentümers; in der zweiten Version trägt es 100 mm Dämmung nach Bauplan; in der dritten Version 180 mm, belegt durch eine Rechnung. Erst diese Kette macht nachvollziehbar, warum ein bestimmter Berechnungsstand entstanden ist — und sie macht es auch dann noch, wenn keiner der ursprünglich Beteiligten mehr erreichbar ist.

Daraus folgt der zentrale Grundsatz: Fachlich relevante Daten werden nicht still überschrieben. Wird ein U-Wert geändert, bleibt der vorherige Wert als Version erhalten. Wird eine Heizungsanlage ersetzt, verschwindet die alte Anlage nicht aus dem System, sondern wird historisiert und mit ihrem Nutzungszeitraum geführt. Was auf den ersten Blick wie überflüssiger Ballast wirkt, ist die Voraussetzung dafür, dass aus einem Datensatz eine Gebäudechronik wird — und dass ein Energieausweis aus dem Jahr 2029 im Jahr 2039 noch erklärbar ist.

Revisionssicherheit bedeutet im Kontext des Gebäudepasses damit fünf Dinge: Änderungen sind nachvollziehbar; frühere Zustände bleiben erhalten; freigegebene Berechnungen sind reproduzierbar; Dokumente bleiben einem bestimmten Berechnungsstand zugeordnet; frühere Ausgaben lassen sich rekonstruieren. Praktisch relevant wird das überall dort, wo eine Aussage später überprüft wird — bei Energieausweisen und ihrer Kontrolle nach Anhang VI EPBD, bei Fördermittelverwendungsnachweisen, bei der Kreditprüfung und bei technischen Nachweisen, die im Streitfall Bestand haben müssen.

9.14 Berechnungssnapshot, Zeitstempel und Dokumentenversionierung

Reproduzierbarkeit lässt sich nicht durch Protokolle allein herstellen, denn eine Berechnung hängt nicht nur von den Eingabedaten ab, sondern auch von der gerechneten Normfassung, dem zugrunde gelegten Rechtsstand und der verwendeten Softwareversion. Für jeden offiziell freigegebenen Berechnungsstand sollte deshalb ein Snapshot erzeugt werden, der diese Randbedingungen mit einfriert. Ein solcher Snapshot enthält sinnvollerweise die Gebäudeversion, die vollständigen Eingabedaten, die Norm- und die Rechtsstandsfassung, die Softwareversion, das Ergebnis, den Ersteller und die Freigabe.

Die Norm- und Rechtsstandsangabe ist dabei kein formaler Zusatz. Wie in Kapitel 3 dargestellt, wird öffentlich-rechtlich verbindlich nach DIN V 18599:2018-09 gerechnet, während die DIN/TS 18599:2025-10 als Technische Spezifikation nur eine Vergleichsrechnung liefert; parallel unterscheiden sich die Rechtsstände vor und nach dem Anwendungsdatum der zweiten GMoDG-Stufe unter anderem in den Primärenergie- und CO₂-Faktoren. Zwei Berechnungen desselben Gebäudes können deshalb völlig korrekt zu unterschiedlichen Ergebnissen führen. Ohne festgehaltene Norm- und Rechtsstandsangabe ist ein archiviertes Ergebnis nicht überprüfbar, sondern nur noch eine Zahl.

Jede freigegebene Version sollte zudem eindeutig mit einem Zeitpunkt verbunden sein, so dass sich feststellen lässt, welcher Datenstand zu einem bestimmten Zeitpunkt galt. Dasselbe gilt für Dokumente: Wird eine Sanierungsplanung überarbeitet, bleiben beide Fassungen erhalten, die aktuelle wird als solche gekennzeichnet, und der ursprüngliche Planungsstand geht nicht verloren. Auch hier ist der Nutzen nicht die Vollständigkeit um ihrer selbst willen, sondern die Fähigkeit, eine spätere Rückfrage zu beantworten.

Digitale Signaturen können ergänzend belegen, dass ein Daten- oder Dokumentstand nach der Freigabe nicht mehr verändert wurde — in Betracht kommen Energieausweise, technische Nachweise, freigegebene Berechnungen und Übergabedokumente. Die rechtliche Qualität einer Signatur ist dabei je Anwendungsfall zu bestimmen: Eine qualifizierte elektronische Signatur nach eIDAS hat eine andere Wirkung als ein bloßer Integritätsnachweis über einen Hashwert. Festzuhalten ist, dass die EPBD eine qualifizierte Signatur nicht verlangt. Sie ist eine Option zur Erhöhung der Beweiskraft, keine Pflicht — und im vorhandenen Gebäudepass ausdrücklich ein offener Punkt (Abschnitt 9.18).

9.15 Datensicherung, Löschung und Aufbewahrung

Ein Gebäude kann hundert Jahre und länger bestehen. Damit reichen die üblichen Sicherungsstrategien einer betrieblichen IT für einen Gebäudepass nicht aus. Erforderlich sind regelmäßige Sicherungen, geografisch getrennte Ablagen, dokumentierte Wiederanlaufprozesse und vor allem regelmäßige Wiederherstellungstests. Der letzte Punkt ist der wichtigste und der am häufigsten vernachlässigte: Ein Backup, dessen Rückspielung nie erprobt wurde, ist kein Backup, sondern eine Annahme. Die Leitlinien zur EPBD nennen Backups im Zusammenhang der Datenbanken nach Artikel 22 EPBD ausdrücklich als Bestandteil der Datenschutzanforderungen. Die Fragen der Langzeitarchivierung — Formatstabilität, Migrationspfade, Lesbarkeit nach Jahrzehnten — sind in Kapitel 8 behandelt.

Von der Sicherung zu trennen ist die Löschung, und hier zeigt sich eine Besonderheit des Gebäudepasses. Ein einfacher Befehl „gesamten Gebäudepass löschen" ist für einen lebenslangen Gebäudedatensatz keine saubere Lösung, sondern ein Problem, weil er drei völlig unterschiedliche Datenarten gleich behandelt. Personenbezogene Daten können nach Wegfall des Zwecks zu löschen oder zu anonymisieren sein. Technische Gebäudedaten bleiben für die Gebäudehistorie relevant und betreffen häufig gar keine Person mehr. Gesetzlich aufbewahrungspflichtige Unterlagen müssen für bestimmte Fristen erhalten bleiben, unabhängig vom Wunsch der Beteiligten. Der Gebäudepass braucht deshalb differenzierte Aufbewahrungsregeln je Datenart statt einer pauschalen Löschfunktion — und er muss dem Nutzer erklären können, warum eine bestimmte Information nicht gelöscht wird.

Für Statistik, Forschung und übergeordnete Bestandsanalysen ist schließlich die Anonymisierung beziehungsweise Aggregation der geeignete Weg. Statt eines konkreten Objekts wird ein Merkmalsbündel ausgewertet — Gebäudetyp, Baujahrsklasse, Effizienzklasse, Region —, aus dem sich der einzelne Eigentümer nicht mehr identifizieren lässt. Genau diese Form fordert Artikel 22 EPBD für die öffentliche Bereitstellung, die mindestens zweimal jährlich in aggregierter und anonymisierter Form zu erfolgen hat, und für den mindestens jährlichen Transfer an das EU Building Stock Observatory nach den Vorlagen der Durchführungsverordnung (EU) 2025/1328.

Damit ist zugleich die Grenze zu den staatlichen Systemen bestimmt. Ein nationaler Gebäudedatensatz bedeutet nicht, dass sämtliche Inhalte eines privaten Gebäudepasses an staatliche Stellen übertragen werden. Die Kette verläuft vielmehr vom operativen Gebäudedatensatz über einen gesetzlich definierten Exportdatensatz zur nationalen Datenbank. Nur der mittlere Teil ist Gegenstand einer Übermittlungspflicht; der vollständige Pass bleibt unter der Kontrolle der jeweils Berechtigten. Für Deutschland ist dabei zu berücksichtigen, dass eine nationale Energieausweis-Datenbank nach dem Stand der Kommissionsleitlinien noch nicht existiert und das Datenbankschema nach Artikel 22 EPBD zum Bearbeitungsstand nicht festgelegt ist. Der Exportdatensatz lässt sich daher heute vorbereiten, aber nicht abschließend definieren.

9.16 Datenqualität, Herkunft und Vertrauensmodell

Datenschutz regelt, wer eine Information sehen darf. Die Frage, ob man ihr glauben kann, ist davon unabhängig — und für die Verwendbarkeit des Gebäudepasses ebenso entscheidend. Ein Nutzer sollte deshalb zu jeder Angabe erkennen können, wie belastbar sie ist. Der Unterschied zwischen „Heizungsbaujahr 2005, Angabe des Eigentümers" und „Heizungsbaujahr 2005, durch Rechnung nachgewiesen" ist für eine Bank, einen Käufer oder einen Fachplaner mindestens so wichtig wie der Wert selbst.

Daraus folgt ein erweiterter Informationsbegriff. Eine belastbare Angabe im Gebäudepass besteht nicht aus einem Wert, sondern aus sechs Elementen: dem Wert, seiner Quelle, dem Datum, dem Qualitätsstatus, dem Prüfer und der Version. Erst diese Kombination macht aus einer Zahl eine überprüfbare Aussage. Sie ist zugleich die Grundlage für die Verantwortungsabgrenzung: Der Pass darf nicht den Eindruck erwecken, jede gespeicherte Information sei fachlich bestätigt. Zwischen ungeprüft, plausibilisiert, fachlich geprüft und offiziell freigegeben liegen erhebliche Unterschiede, und ein Energieberater muss vor einer Berechnung erkennen können, welche Daten er erneut kontrollieren muss.

Neben der Qualität der einzelnen Angabe steht die Vollständigkeit des Datensatzes. Eine Aufschlüsselung nach Bereichen — Gebäudeidentität, Geometrie, Gebäudehülle, Anlagentechnik, Dokumentation — zeigt unmittelbar, wo Informationslücken bestehen, und lenkt die Erfassung dorthin, wo sie den größten Nutzen bringt. Wichtig ist dabei, dass fehlende Werte als fehlend dargestellt werden und nicht durch Schätzungen ersetzt werden, die sich später nicht mehr als solche erkennen lassen.

Aus Qualität und Vollständigkeit lässt sich ein zusammenfassender Kennwert bilden. Der vorhandene Gebäudepass tut dies mit dem Building Trust Index, der die Datenqualität und den technischen Zustand auf einer Skala von 0 bis 100 abbildet und ausdrücklich kein Energie-, Banken- oder Bonitätsscore ist. Entscheidend für die Akzeptanz eines solchen Kennwerts ist seine Erklärbarkeit: Der Index ist aus sieben Säulen mit offengelegten Gewichten zusammengesetzt — Dokumentationsqualität und technischer Zustand mit je 20 Prozent, Energiequalität und Datenqualität mit je 15 Prozent, Wartungszustand, Sanierungsreife und Zukunftsfähigkeit mit je 10 Prozent —, und jeder einzelne Beitrag zum Ergebnis bleibt sichtbar. Ein Vertrauenskennwert, dessen Zusammensetzung nicht offengelegt wird, wäre für die Zwecke dieses Kapitels wertlos: Er würde Vertrauen beanspruchen, statt es zu begründen. Die Kalibrierung des Index an Echtprojekten ist noch nicht abgeschlossen, und die Säule Wartungszustand liefert derzeit keinen Beitrag, weil die Wartungsdokumente noch nicht angebunden sind.

Schließlich braucht auch die Plattform selbst eine Verantwortungsgrenze. Sie stellt Datenhaltung, Berechnungsfunktionen, Prüfmechanismen und Dokumentation bereit. Sie ersetzt damit keine Sachverständigenentscheidung, keine Kreditentscheidung, keine behördliche Prüfung und keine juristische Bewertung. Diese Trennung ist nicht nur haftungsrechtlich geboten, sie ist auch fachlich richtig: Ein Werkzeug kann Grundlagen liefern und Widersprüche sichtbar machen; die Verantwortung für die Entscheidung bleibt bei den Menschen, die sie treffen.

9.17 Die sieben Grundsätze der Vertrauensarchitektur

Die vorstehenden Abschnitte lassen sich auf sieben Grundsätze zurückführen. Sie sind keine Zusammenfassung im Sinne einer Wiederholung, sondern die Prüfliste, an der sich jede Entwurfsentscheidung des Gebäudepasses messen lassen muss. Wo einer dieser Grundsätze verletzt wird, entsteht kein kleiner Mangel, sondern eine Lücke, die sich durch alle darauf aufbauenden Funktionen fortpflanzt.

1. Eindeutige Gebäudeidentität

Ohne eine dauerhafte, eindeutige Kennung des Gebäudes lässt sich weder eine Historie führen noch eine Berechtigung sauber zuordnen. Die Identität muss unabhängig von Eigentümer, Adressschreibweise und Verwaltungsgrenzen bestehen und über die gesamte Lebensdauer des Gebäudes stabil bleiben; bei Mehrparteiengebäuden tritt die Kennung der einzelnen Nutzungseinheit hinzu. Artikel 22 EPBD verlangt genau dies für die nationalen Datenbanken: eindeutige Gebäude- und Einheiten-Identifikatoren, datenbankübergreifend, mit Geo-Referenz und von Anfang an vergeben, dazu Interoperabilität mit Kataster und Grundbuch. Für den Gebäudepass ist die Gebäude-Identität deshalb nicht nur eine interne Ordnungsgröße, sondern die Anschlussstelle an die staatliche Datenlandschaft.

2. Klare Eigentümer- und Nutzerrollen

Jede Person, die mit dem Gebäudedatensatz arbeitet, muss einer Rolle mit definiertem Umfang zugeordnet sein, und jede Rolle muss ein Ende haben können. Der Eigentümer vergibt und entzieht Berechtigungen, die Fachbeteiligten arbeiten in ihrem jeweiligen Ausschnitt, Dritte erhalten nur, was ihre Aufgabe erfordert. Der Grundsatz verlangt zweierlei: dass die Rollen fachlich sinnvoll geschnitten sind — nicht zu grob, sonst greift Least Privilege nicht; nicht zu fein, sonst wird die Verwaltung unbedienbar — und dass die Rollenzuordnung technisch durchgesetzt und nicht nur dokumentiert ist. Genau an dieser Stelle liegt die größte offene Baustelle des vorhandenen Systems.

3. Datenfreigabe nach Zweck

Eine Freigabe ist an einen Empfänger, einen Datenausschnitt, einen Zweck und eine Frist gebunden. Sie endet von selbst, sie ist widerruflich, und sowohl Erteilung als auch Widerruf sind protokolliert. Dieser Grundsatz verbindet die datenschutzrechtliche Zweckbindung mit der praktischen Datensouveränität: Der Eigentümer entscheidet nicht einmalig über einen Zugang, sondern über einen konkreten Vorgang. Er ist zugleich die Voraussetzung dafür, dass derselbe Gebäudedatensatz gegenüber Bank, Makler, Verwaltung und Behörde verwendet werden kann, ohne für jeden Empfänger eine eigene Kopie zu erzeugen — Kopien altern getrennt und sind die häufigste Ursache widersprüchlicher Gebäudedaten.

4. Vollständige Protokollierung

Jeder relevante Zugriff und jede wesentliche Änderung wird mit Nutzer, Rolle, Zeitpunkt, Aktion und betroffenem Objekt festgehalten. Das Protokoll dient drei Zwecken zugleich: der Nachvollziehbarkeit gegenüber dem Eigentümer, der fachlichen Rekonstruktion im Streitfall und der behördlichen Kontrolle, die Anhang VI EPBD verlangt, wenn Daten in eine Datenbank nach Artikel 22 EPBD gelangen. Ein Protokoll, das nur Anmeldungen erfasst, aber keine fachlichen Änderungen, erfüllt keinen dieser drei Zwecke.

5. Versionierung

Fachlich relevante Daten werden nicht überschrieben, sondern versioniert; frühere Zustände bleiben erhalten und bleiben zuordenbar. Damit ist der Gebäudepass in der Lage, nicht nur den heutigen Zustand des Gebäudes zu beschreiben, sondern jeden früheren — und damit auch jede Aussage, die auf einem früheren Zustand beruhte. Für freigegebene Berechnungen tritt der Snapshot mit Norm- und Rechtsstandsangabe hinzu, ohne den ein Ergebnis später nicht reproduzierbar wäre. Versionierung ist der technische Kern der Revisionssicherheit; alles andere in Abschnitt 9.13 und 9.14 baut darauf auf.

6. Qualität und Quellen

Jeder Wert trägt seine Herkunft, sein Datum, seinen Prüfstatus und seinen Prüfer mit sich. Fehlende Werte bleiben als fehlend erkennbar und werden nicht durch Schätzungen ersetzt, deren Charakter später nicht mehr ablesbar ist. Dieser Grundsatz ist die Voraussetzung dafür, dass Dritte dem Datensatz überhaupt trauen können: Eine Bank, die nicht unterscheiden kann, ob eine Angabe belegt oder behauptet ist, muss den gesamten Datensatz mit einem Sicherheitsabschlag behandeln — und der Nutzen des Passes verschwindet.

7. Datenportabilität

Der Eigentümer muss seinen fachlichen Gebäudedatensatz in einem dokumentierten, maschinenlesbaren Format ausleiten können. Ein vollständiger Export umfasst sinnvollerweise die Gebäudedaten, Bauteile und Anlagen, die Energiekennwerte, die Sanierungsereignisse, einen Dokumentenindex und die Versionshistorie. Nicht jede interne Systemfunktion muss exportierbar sein; entscheidend ist, dass der fachliche Kern erhalten bleibt und in einem anderen System weitergeführt werden kann. Dieser Grundsatz beantwortet die Frage, die jeder Eigentümer zu Recht stellt, bevor er einem System eine Jahrzehnte umfassende Datenhistorie anvertraut: Was geschieht, wenn es den Betreiber irgendwann nicht mehr gibt? Portabilität ist damit weniger ein technisches als ein vertrauensbildendes Merkmal — und sie ist der einzige der sieben Grundsätze, der sich unmittelbar gegen die wirtschaftlichen Interessen des Betreibers richtet. Genau deshalb ist er der aussagekräftigste.

9.18 Stand der Umsetzung im vorhandenen Gebäudepass

Die vorstehenden Abschnitte beschreiben das Zielbild. Für die Bewertung des vorhandenen Systems ist die Unterscheidung zwischen umgesetzten und konzipierten Funktionen entscheidend; sie wird hier offengelegt und in Kapitel 13 im Rahmen der Reifegradanalyse eingeordnet.

Umgesetzt und produktiv sind vor allem die Funktionen, die auf Datentrennung, Versionierung und Herkunft zielen. Der veröffentlichte Gebäudepass beruht auf einem Snapshot, der über eine Filterfunktion erzeugt wird und ausschließlich Gebäudekennwerte enthält — personenbezogene Daten gelangen nicht in den öffentlichen Pass. Die öffentliche Ansicht ist durch ein PIN-Gate geschützt, das nach je drei Fehlversuchen in gestaffelten Stufen von einer bis sechzig Minuten sperrt; der Demo-Pass ist schreibgeschützt. Die Gebäudeidentität wird über eine idempotente, persistente Kennung nach dem Muster DG-JJJJ-NNNNNNNN geführt. Die Governance-Schicht bildet vier Datenzustände von Entwurf über gemeldet und geprüft bis freigegeben ab, führt Vertrauensstufen von null bis fünf und setzt das Vier-Augen-Prinzip technisch um: Ein gemeldeter Wert bleibt ein Vorschlag im Arbeitsbereich und ändert den offiziellen Wert nicht; erst die Freigabe schreibt ihn in den maßgeblichen Datenpfad. Werte werden nicht überschrieben, sondern versioniert. Die Herkunft ist je Wert und je Beziehungskante als Metadatum angelegt und erscheint auf der Kennwerteseite mit ihren 43 Kennwerten als Herkunftsplakette; fehlende Werte bleiben leer statt geschätzt. Der Server sichert vor jeder Projektänderung in eine eigene Ablage mit den letzten zwanzig Ständen. Für die Portabilität existieren ein vollständiger JSON-Export und -Import sowie ein Zertifikatsexport, der die Pflichtangaben maschinenlesbar mitführt.

Nicht umgesetzt ist dagegen der Kern dieses Kapitels: die Zugriffssteuerung. Was heute existiert, sind Anzeigerollen der Kennwerteseite — alle Werte, Architekt, Makler, Hausverwaltung, TGA-Planer, Bank, Energieberater. Sie steuern die Reihenfolge und die Hervorhebung der dargestellten Kennwerte und sind damit eine Priorisierung der Darstellung, keine Rechteschicht. Das abgestufte Zugriffsmodell mit den sieben Stufen von öffentlich bis Eigentümer ist seit dem 23. August 2026 implementiert, ebenso die Durchsetzung der Rollen im laufenden Betrieb: Jeder Schreib- und Exportzugriff wird gegen das Recht der Rolle geprüft und mit Rolle, Zeitpunkt und Ergebnis protokolliert. Offen bleiben die digitale Signatur je Freigabe, die automatisierte Konfliktauflösung und eine förmliche datenschutzrechtliche Vorprüfung. Auch das feiner gegliederte Statusmodell mit neun Datenwert-Status ist Konzept; produktiv ist die einfachere Herkunftsplakette.

Auch die Durchsetzung im Inneren ist seit dem 23. August 2026 hergestellt: Die statische Auswertung von 1.258 literalen Schreibzugriffen ergab zunächst 55 Verstöße gegen die definierte Schreibordnung in 15 Werkzeugen; sie sind abgearbeitet, die Prüfung steht auf 0 und läuft täglich mit. Von den 94 Feldern des Feld-Registers werden weiterhin 35 von mehr als einem Werkzeug beschrieben — jeder Schreibvorgang ist nun aber benannt und an eine Nutzerhandlung gebunden. Die Ordnung aus führender Quelle, ermittelnden Werkzeugen, Rechenwerkzeugen und schreibfreien Ausgabewerkzeugen ist damit definiert und erzwungen; 58 Aufrufe mit dynamisch gebildeten Pfaden entziehen sich der statischen Prüfung. Offen ist ferner, dass das Öffnen des Gebäudepasses die automatische Dokumenterzeugung anstößt und dabei ohne gesonderte Nutzeraktion Dokumente erzeugt und ablegt — ein Verhalten, das unter dem Gesichtspunkt der Zweckbindung und der Datenminimierung an eine ausdrückliche Auslösung gebunden werden sollte.

9.19 Kernaussage

Der digitale Gebäudepass benötigt nicht nur eine technische Datenarchitektur, sondern eine Vertrauensarchitektur. Beide bedingen einander: Ohne belastbare Daten ist ein Zugriffsmodell wertlos, und ohne kontrollierten Zugriff wird niemand belastbare Daten einstellen. Eigentümer werden umfangreiche Gebäudeinformationen nur dann dauerhaft speichern, wenn sie sicher sein können, wer Zugriff hat, wofür die Daten verwendet werden, wann ein Zugriff endet und dass jede Änderung nachvollziehbar bleibt. Datensouveränität ist damit kein Zugeständnis an die Regulierung, sondern Bestandteil des Leistungsversprechens.

Der Gebäudepass verbindet dabei zwei Ziele, die für eine künftige digitale Gebäudeinfrastruktur gleichermaßen entscheidend sind: die dauerhafte Verfügbarkeit der Gebäudeinformation über Eigentümer- und Nutzergenerationen hinweg und die Souveränität der Menschen, die diese Daten bereitstellen und nutzen. Die sieben Grundsätze des Abschnitts 9.17 beschreiben, wie sich beides zugleich erreichen lässt. Sie sind zum Bearbeitungsstand teilweise umgesetzt und teilweise Zielbild — und die redliche Darstellung dieses Unterschieds ist selbst ein Teil der Vertrauensarchitektur, die dieses Kapitel beschreibt.

10 Prozesse über den gesamten Gebäudelebenszyklus

Der Nutzen eines digitalen Gebäudepasses entsteht nicht bei der einmaligen Erstellung, sondern über die Zeit. Dieses Kapitel verfolgt ein Gebäude durch zehn Phasen seines Lebens — von der Planung bis zum Rückbau — und beschreibt für jede Phase denselben Zusammenhang: Welches Ereignis löst sie aus, wer ist beteiligt, welche Daten werden gebraucht, was trägt der Gebäudepass bei, und was steht am Ende im Datensatz. Die Phasen sind dabei nicht frei gewählt: Die meisten von ihnen haben in der EPBD (EU) 2024/1275 einen ausdrücklichen rechtlichen Auslöser.

10.1 Der Lebenszyklus als Datenkette

Ein Gebäude wird geplant, gebaut, übergeben, betrieben, gewartet, finanziert, vermietet, verkauft, modernisiert, umgenutzt und irgendwann zurückgebaut. In der heutigen Praxis entsteht bei jedem dieser Schritte ein neuer Datenbestand: eine neue Aufnahme vor Ort, ein neuer Ordner, ein neues Rechenmodell, ein neues Dokument. Der Aufwand fällt nicht deshalb an, weil sich das Gebäude verändert hätte, sondern weil die Information über das Gebäude nach jedem Vorgang wieder zerfällt. Wer 2032 ein Haus finanzieren will, das 2026 gebaut und 2029 energetisch nachgerüstet wurde, beginnt in aller Regel bei null — obwohl jede benötigte Angabe schon zweimal erhoben worden ist.

Der Gebäudepass verfolgt ein anderes Prinzip. Das Gebäude behält einen dauerhaften Datensatz, der mit jeder Veränderung fortgeschrieben und nicht ersetzt wird. Jeder Vorgang liest aus diesem Datensatz, prüft die für ihn wesentlichen Angaben und schreibt sein Ergebnis wieder hinein. Aus einer Folge unverbundener Projekte wird eine Kette: Planungsdaten werden zu Ausführungsdaten, Ausführungsdaten zum freigegebenen Ist-Zustand, der Ist-Zustand zur Grundlage des Energieausweises, der Betrieb liefert Mess- und Wartungsdaten zurück, die Sanierungsplanung setzt darauf auf, die Ausführung erzeugt einen neuen Ist-Zustand — und der Kreis beginnt von vorn, ohne dass die vorherigen Zustände verloren gehen.

Diese Kette ist keine bloße Ordnungsidee. Die EPBD setzt an fast jedem Kettenglied einen eigenen Rechtsakt an, und sie tut dies mit Fristen, die sich über zwei Jahrzehnte erstrecken. Der Energieausweis ist höchstens zehn Jahre gültig (Artikel 19 EPBD) und wird bei Neubau, größerer Renovierung, Verkauf, Neuvermietung und Mietvertragsverlängerung fällig. Heizungs- und Klimaanlagen über 70 kW sind alle fünf Jahre, über 290 kW alle drei Jahre zu inspizieren (Artikel 23 und 24 EPBD). Neubauten öffentlicher Einrichtungen müssen ab dem 1. Januar 2028 Nullemissionsgebäude sein, alle Neubauten ab dem 1. Januar 2030 (Artikel 11 EPBD). Der Ausweis des Treibhauspotenzials über den Lebenszyklus wird ab dem 1. Januar 2028 für Neubauten über 1 000 m² und ab dem 1. Januar 2030 für alle Neubauten verlangt (Artikel 7 EPBD). Jede dieser Pflichten ist ein Termin am Gebäude, nicht am Projekt — und genau darin liegt der Unterschied zwischen einer Gebäudeakte und einem Lebenszyklusmodell.

Voraussetzung für die Kette ist eine stabile Identität. Artikel 22 EPBD verlangt eindeutige Gebäude- und Einheiten-Identifikatoren mit Geo-Referenz, datenbankübergreifend und ausdrücklich „von Anfang an"; als vorbildlich gilt Portugal mit bis zu elf verknüpften Kennungen je Objekt. Im vorhandenen Gebäudepass übernimmt diese Rolle eine persistente Gebäude-Kennung im Format DG-JJJJ-NNNNNNNN, die beim ersten Aufruf vergeben wird und danach unverändert bleibt. Sie ist der Faden, an dem sämtliche im Folgenden beschriebenen Phasen aufgereiht werden. Die in Artikel 22 Absatz 7 EPBD zusätzlich geforderte Verknüpfung mit Kataster und Grundbuch ist im vorhandenen System dagegen noch nicht hergestellt.

10.2 Neubau

Der Lebenszyklus beginnt im Regelfall nicht mit dem Gebäude, sondern mit seiner Planung. Auslöser der ersten Phase sind Entwurfs- und Genehmigungsplanung, spätestens jedoch die öffentlich-rechtlichen Nachweise: der Wärmeschutznachweis, der Nachweis der Anforderungen an Neubauten und — je nach Größe und Zeitpunkt — der Nullemissionsnachweis nach Artikel 11 EPBD sowie der Ausweis des Treibhauspotenzials nach Artikel 7 EPBD. Für die deutsche Umsetzung gelten die Nullemissionstermine 2028 für Gebäude der öffentlichen Hand und 2030 für alle Neubauten. Hinzu kommen die Solarpflicht-Staffel des Artikels 10 EPBD, die neue öffentliche Gebäude und neue Nichtwohngebäude über 250 m² ab dem 31. Dezember 2026 und alle neuen Wohngebäude ab 2029 erfasst, sowie die Pflicht aus Artikel 13 Absatz 11 EPBD, neue Wohngebäude seit dem 29. Mai 2026 mit elektronischem Monitoring, Effizienzwarnung, Steuerfunktionen und Demand-Response-Fähigkeit auszustatten.

Beteiligt sind in dieser Phase der Bauherr, der Entwurfsverfasser, die Fachplanung für Tragwerk und technische Gebäudeausrüstung, der Nachweisberechtigte für den energetischen Nachweis, die Bauleitung und die ausführenden Betriebe. Sie alle arbeiten heute mit unterschiedlichen Werkzeugen an denselben Größen: Der Architekt führt die Flächen, der TGA-Planer die Anlagenleistungen, der Energieberater die Bauteilaufbauten, der Bauleiter die tatsächlich verbauten Produkte. Vier Datenbestände, ein Gebäude.

Die benötigten Daten liegen zu diesem Zeitpunkt ohnehin vor: Grundstück und Lage, Geometrie und Flächen, Bauteilaufbauten mit ihren Wärmedurchgangskoeffizienten, Fenster mit Kennwerten und Orientierung, Anlagentechnik mit Leistungen und Effizienzangaben, Nutzungszonen und Nutzungsprofile, die energetische Bilanz, die Mengen- und Materialansätze der Ökobilanz sowie die Kosten. Der entscheidende Punkt ist, dass diese Angaben nicht nach Fertigstellung erneut erhoben werden müssen. Der ideale Ablauf führt vom Gebäudemodell in CAD oder BIM in den Gebäudepass, von dort in die energetische Berechnung, in die Nachweise und schließlich in die Bauausführung — der digitale Datensatz entsteht parallel zum realen Gebäude, nicht nachträglich.

Der Gebäudepass trägt in dieser Phase zweierlei bei. Erstens hält er den Planungsstand als eigenständigen Zustand fest: geplante Außenwand mit U = 0,18 W/(m²K), geplantes Fenster mit U_w = 0,80 W/(m²K), geplante Wärmepumpe mit 8 kW. Zweitens hält er diesen Soll-Zustand vom später ausgeführten Ist-Zustand getrennt. Diese Trennung ist keine buchhalterische Feinheit. Wird das Fenster mit U_w = 0,86 W/(m²K) eingebaut, weil die geplante Ausführung nicht lieferbar war, dann ist der Energieausweis, der auf 0,80 rechnet, schlicht falsch — und niemand bemerkt es, weil der Planungswert nach der Fertigstellung als Bestandswert weitergeführt wird. Die EPBD kennt dieselbe Unterscheidung im Übrigen ausdrücklich: Für das Treibhauspotenzial nach Anhang III EPBD ist der Bilanzstand „as-built" maßgeblich, vor Baubeginn wird geschätzt, danach bestätigt.

Am Ende der Neubauphase steht die digitale Übergabe. Artikel 13 Absatz 6 EPBD verlangt bereits heute, dass nach der Installation eines gebäudetechnischen Systems die Gesamtenergieeffizienz des veränderten Teils bewertet, dokumentiert und dem Eigentümer übergeben wird. Der Gebäudepass macht daraus mehr als eine Papierpflicht: Revisionspläne, Energieausweis, Wärmeschutznachweis, technische Datenblätter, Bedienungsanleitungen, Rechnungen, Wartungshinweise und Förderunterlagen werden nicht als Ordner übergeben, sondern als strukturierter Datensatz, in dem jedes Dokument mit den Werten verknüpft ist, die es belegt. Im Datensatz steht danach: ein freigegebener Ist-Zustand mit Bauteilen, Anlagen und Flächen; der zugehörige Planungsstand als historische Version; der Energieausweis mit genau dem Berechnungsstand, aus dem er erzeugt wurde, einschließlich Normfassung und Rechtsstand; die Ökobilanz mit ihren Modulen; und die Belegkette zu den Dokumenten.

Der vorhandene Gebäudepass deckt davon einen erheblichen Teil ab. Der CAD-Editor führt die Flächen nach DIN 277, die Rechenkerne bilanzieren nach DIN V 18599:2018-09, der Wärmeschutznachweis prüft die Bauteile gegen die Anforderungswerte der Anlage 7, der Energieausweis wird als automatisches Dokument erzeugt und trägt eine deterministisch aus der Gebäude-Kennung abgeleitete Nummer — ausdrücklich keine amtliche Registriernummer. Die Bauteilfelder sehen mit den getrennten Einträgen für Ist- und Altzustand die Grundlage für eine Zustandsführung vor. Die vollständige Trennung von Neubau-Planungszuständen und ausgeführten Zuständen ist dagegen als Entwicklungsschritt geführt und noch nicht umgesetzt; ebenso ist die Ökobilanz derzeit auf einen geschätzten Benchmark für graue Emissionen gestützt, während die Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen noch aussteht. Der Import eines Gebäudemodells über IFC ist als Eingang vorhanden, ein vollwertiger Rückweg nicht.

10.3 Bestandsaufnahme

Nicht jedes Gebäude beginnt seinen Datensatz mit der Planung. Für den weit überwiegenden Teil des Bestands beginnt er mit einer Bestandsaufnahme, und deren Auslöser ist fast immer ein Rechtsvorgang: die Ausstellung eines Energieausweises bei Verkauf, Neuvermietung oder Mietvertragsverlängerung, eine größere Renovierung — die EPBD definiert sie als Maßnahme über 25 % des Gebäudewerts oder an mehr als 25 % der Hüllfläche —, eine Energieberatung, die Aufstellung eines Renovierungspasses nach Artikel 12 EPBD oder eine anstehende Finanzierung.

Beteiligt sind der Eigentümer als Auskunftgeber und der unabhängige Experte als Aussteller. Die EPBD stellt an ihn zwei Bedingungen, die für die Datenqualität wesentlich sind: Er muss nach Artikel 25 EPBD qualifiziert oder zertifiziert sein, und er muss das Gebäude vor Ort aufnehmen — eine virtuelle Aufnahme mit Video-Sichtprüfung ist zulässig, ein Verzicht auf die Aufnahme nicht. Für den Renovierungspass geht das Audit ausdrücklich tiefer als für den Energieausweis, und es ist mindestens ein Vor-Ort-Termin verlangt. Hinzu kommen je nach Gebäude die Hausverwaltung, der Bezirksschornsteinfeger und Wartungsbetriebe als Quellen technischer Angaben.

Benötigt wird alles, was den Ist-Zustand belegt: Baupläne, frühere Energieausweise, Rechnungen und Handwerkerbelege, Produktnachweise, Fotos, Typenschilder der Anlagentechnik, Eigentümerangaben und die eigene Aufnahme vor Ort. Die eigentliche Schwierigkeit liegt nicht in der Menge, sondern in der Ungleichheit dieser Quellen. Ein typisches Bestandsgebäude hat ein bekanntes Baujahr, eine nur aus dem Bauplan ableitbare Außenwand, eine durch Rechnung dokumentierte Dachdämmung, vor Ort aufgenommene Fenster und eine Heizung, deren Daten vom Typenschild stammen. Fünf Angaben, fünf völlig verschiedene Belastbarkeiten — und in einer klassischen Berechnung stehen sie alle gleichrangig nebeneinander.

Genau hier liegt der Beitrag des Gebäudepasses. Er speichert nicht nur den Wert, sondern auch dessen Herkunft, Methode, Erfasser, Datum, Prüfstatus und Version. Eine geschätzte Dämmstärke von 80 mm erhält damit nicht denselben Rang wie 160 mm laut Rechnung und Produktnachweis. Das vorhandene System führt dafür Vertrauensstufen von 0 bis 5 — von unbekannt über Eigentümerangabe, aus Dokument erkannt und plausibilisiert bis geprüft und amtlich signiert — sowie vier Datenzustände von ENTWURF über GEMELDET und GEPRÜFT bis FREIGEGEBEN, wobei nur freigegebene Werte in offizielle Dokumente eingehen dürfen. Die Kennwerteseite zeigt zu jedem der 43 geführten Kennwerte eine Herkunftsplakette; fehlende Werte bleiben ausdrücklich leer, statt durch Annahmen ersetzt zu werden. Eine Vollständigkeitsprüfung führt 23 Pflichtfelder in acht Kategorien und benennt zu jedem fehlenden Feld den Weg zu seiner Erfassung. Widersprüche zwischen zwei Quellen werden erzeugt und angezeigt, nicht automatisch aufgelöst; für die vier doppelt geführten Angaben Bauweise, Keller, Firstrichtung und Geschosszahl gleicht der Steckbrief die jeweils andere Quelle ab, ohne etwas zu überschreiben.

Zur Beschleunigung der Aufnahme trägt die maschinelle Auswertung eingereichter Unterlagen bei: Grundriss, Wärmeschutznachweis und Energieausweis werden über eine gemeinsame Ablagezone eingelesen und maschinell zugeordnet. Für das Datenmodell gilt dabei die Regel, dass Drittsysteme und maschinelle Erkennung nur Vorschläge liefern — der Wert wird erst durch eine Freigabe verbindlich. Im Datensatz steht am Ende dieser Phase ein bewerteter Ist-Zustand: jede Angabe mit Herkunft und Vertrauensstufe, jede Lücke als Lücke sichtbar, jeder Widerspruch offen ausgewiesen. Diese Ehrlichkeit ist kein Selbstzweck. Sie ist die Voraussetzung dafür, dass die folgenden Phasen — Bewertung, Finanzierung, Sanierungsplanung — wissen, worauf sie sich stützen. Der Building Trust Index, der diese Datenqualität in eine Kennzahl übersetzt, ist in Kapitel 6 beschrieben.

10.4 Verkauf und Eigentümerwechsel

Der Verkauf ist einer der klarsten regulatorischen Auslöser des gesamten Lebenszyklus. Nach Artikel 19 EPBD ist ein gültiger Energieausweis vorzulegen, in der Verkaufsanzeige sind Effizienzindikator und Klasse anzugeben, und der Ausweis darf nicht älter als zehn Jahre sein. Der Ausweis muss digital und maschinenlesbar vorliegen — die Kommissionsleitlinien nennen CSV, JSON und XML und stellen ausdrücklich fest, dass ein eingescanntes PDF nicht genügt; eine Papierfassung ist nur auf Wunsch bereitzustellen. Liegt das Gebäude unterhalb der Klasse C, ist der Eigentümer nach Artikel 19 Absatz 13 EPBD nach fünf Jahren beziehungsweise bei Ablauf des Ausweises zur Beratung durch eine zentrale Anlaufstelle einzuladen.

Beteiligt sind Verkäufer, Kaufinteressent, Makler, finanzierende Bank, Notar und — für die Ausstellung oder Aktualisierung des Ausweises — der unabhängige Experte. Die Interessenlage ist unsymmetrisch: Der Verkäufer besitzt Unterlagen in wechselnder Vollständigkeit, der Käufer versucht den tatsächlichen Zustand zu verstehen und hat dafür weder Zeit noch Zugang. Diese Informationslücke ist der eigentliche Grund, warum technische Mängel in Immobilientransaktionen so häufig erst nach dem Kauf sichtbar werden.

Benötigt wird ein definierter Ausschnitt: Baujahr, Flächen, Heizsystem, Energieklasse und Ausweisdaten, dokumentierte Sanierungsmaßnahmen mit Nachweis, offene Instandhaltungs- und Modernisierungsbedarfe und der Qualitätsstatus der zugrunde liegenden Angaben. Der Käufer soll erkennen können, welche Maßnahmen durchgeführt wurden, welche Nachweise dazu existieren, wie aktuell der Ausweis ist, welche Schritte noch anstehen — und welche Werte lediglich geschätzt sind. Der Zugang zu privaten Unterlagen des Verkäufers gehört ausdrücklich nicht dazu.

Die EPBD hat für diesen Ausschnitt bereits eine Zugangsregel formuliert. Nach Artikel 22 EPBD erhalten Kauf- und Mietinteressenten Zugriff auf die Gebäudedaten nur mit Erlaubnis des Eigentümers; die Leitlinien empfehlen, diesen Zugriff zu befristen und gegebenenfalls auf eine reine Bildschirmansicht zu beschränken. Artikel 16 EPBD stellt klar, dass Eigentümer, Mieter und Verwalter selbst kostenlos zugreifen und den Zugriff kostenlos an von ihnen benannte Dritte weitergeben können. Der Gebäudepass bildet damit nicht eine freie Veröffentlichung ab, sondern eine befristete, zweckgebundene Freigabe durch den Eigentümer.

Im vorhandenen System existiert dafür ein Teilmechanismus: Ein Veröffentlichungsvorgang erzeugt aus dem Projekt einen bereinigten Momentaufnahme-Datensatz, der ausschließlich Gebäudekennwerte und keine personenbezogenen Daten enthält, und stellt ihn unter einer eigenen Adresse mit vierstelliger PIN bereit; wiederholte Fehleingaben führen zu gestaffelten Sperrzeiten. Ein QR-Ausdruck und ein Kartenprodukt ergänzen den Zugang, ein schreibgeschützter Demonstrationspass zeigt die Ansicht ohne Datenfreigabe. Die eigentliche Rechteschicht ist seit dem 23. August 2026 hinzugekommen: Das abgestufte Zugriffsmodell mit den Stufen von der Öffentlichkeit über Interessent, Makler, Bank, Hausverwaltung und Energieberater bis zum Eigentümer ist implementiert, sodass der Verkäufer einem Interessenten einen befristeten Einblick geben kann, ohne ihm den Eigentümerzugang zu überlassen. Die vorhandenen Rollen der Kennwerteseite steuern die Reihenfolge und Auswahl der angezeigten Werte, nicht die Berechtigung. Für den Verkaufsprozess bedeutet das, dass die Freigabe heute über die Veröffentlichung als Ganzes gesteuert wird und nicht empfängerbezogen.

Der Eigentümerwechsel selbst verändert den Datensatz weniger, als man erwarten würde — und das ist der Kern der Sache. Der Verkauf wird bestätigt, der bisherige Eigentümer wird archiviert, seine personenbezogenen Freigaben enden, die Gebäudedaten bleiben bestehen, der neue Eigentümer erhält Zugang. Der digitale Datensatz folgt dem Gebäude, nicht der Person. Damit bleibt erhalten, was in der heutigen Praxis regelmäßig verloren geht: die technische Historie über den Eigentümerwechsel hinweg. Ein Hinweis zur Klassenangabe ist an dieser Stelle angebracht: Die geschlossene Skala A bis G nach Artikel 19 Absatz 2 EPBD gilt seit dem 29. Mai 2026, wobei A dem Nullemissionsgebäude vorbehalten ist. Die deutschen Klassengrenzen für die Zwischenklassen sind zum Redaktionsstand nicht vollständig festgelegt; das vorhandene System führt diese Grenzen deshalb ausdrücklich als Lücke und gibt für Nichtwohngebäude zwischen der besten und der schlechtesten Klasse bewusst kein Ergebnis zurück, statt eine Klasse zu erfinden.

10.5 Vermietung

Die Vermietung folgt derselben Auslöserlogik wie der Verkauf, wird in der Praxis aber häufig übersehen. Die EPBD nennt neben der Neuvermietung ausdrücklich auch die Verlängerung eines Mietvertrags als Anlass für einen Energieausweis, und die Angabepflicht von Indikator und Klasse gilt in Vermietungsanzeigen ebenso wie in Verkaufsanzeigen. Für ein Mehrfamilienhaus mit regelmäßiger Fluktuation heißt das, dass der Ausweisstand nicht alle zehn Jahre, sondern faktisch fortlaufend relevant ist.

Beteiligt sind Eigentümer, Mieter, Hausverwaltung und Makler. Artikel 16 EPBD gibt dem Mieter einen eigenen, direkten und kostenlosen Zugriff auf die Gebäudesystemdaten — nicht abgeleitet vom Eigentümer, sondern als eigenes Recht. Der Mindestumfang ist dabei nicht auf den Energieausweis beschränkt: Er umfasst die Leistungsmerkmale der Bauteile, die gebäudetechnischen Dienste, die Lebensdauerprognose der Heizung, die Gebäudeautomation, die Zähler sowie Mess- und Regeleinrichtungen und die Ladepunkte.

Benötigt wird demnach ein Mieterprofil, das den energetischen Zustand, das Heizsystem, den Ausweisstand und die für den Nutzer relevanten Verbrauchsinformationen umfasst — und das Eigentümer-, Finanzierungs- und Vertragsdaten ausschließt. Ein Mieterwechsel verändert die technische Gebäudehistorie nicht; wohl aber muss er die nutzerbezogenen Verbrauchsdaten sauber trennen, damit die Verbrauchshistorie des Gebäudes erhalten bleibt, ohne dass personenbezogene Verbrauchsdaten des Vormieters weitergegeben werden. Die Abgrenzung ist rechtlich klar gezogen: Artikel 16 EPBD erfasst statische Gebäudedaten, dynamische Daten vernetzter Produkte fallen unter den Data Act (Verordnung (EU) 2023/2854), Abrechnungszähler unter die Strom- und Gasrichtlinien.

Der Gebäudepass trägt in dieser Phase vor allem eine saubere Trennebene bei: Gebäudedaten, Nutzungseinheitsdaten und personenbezogene Verbrauchsdaten sind drei verschiedene Dinge, die in der Praxis regelmäßig vermischt werden. Hinzu kommt die Verbindung zur Modernisierungsumlage: Wo eine energetische Maßnahme auf die Miete umgelegt werden soll, verlangt das GMoDG einen Nachweis der Anlageneffizienz — im vorhandenen System als eigene Prüfung mit einer Jahresarbeitszahl von mindestens 2,5 nach VDI 4650 abgebildet, wobei nur ein nach VDI 4650 ermittelter oder ein Herstellerwert den Nachweis trägt. Für die Hausverwaltung entsteht daraus eine gemeinsame technische Informationsplattform mit dem Eigentümer: Sie trägt Wartungen ein, lädt Rechnungen hoch, aktualisiert Anlagendaten und erfasst Verbrauchswerte. Dieser operative Rollenzugang setzt die Rechteschicht voraus; sie besteht seit dem 23. August 2026, und die Hausverwaltung ist darin eine eigene Rolle mit Schreibrecht auf Wartung, Dokumente und Verbrauchsdaten.

Im Datensatz steht nach dieser Phase ein freigegebenes Mieterprofil mit Ausweisbezug, eine von Personenbezügen getrennte Verbrauchshistorie und — bei Modernisierungen — der geführte Effizienznachweis mit seiner Quelle.

10.6 Finanzierung

Eine Finanzierung wird ausgelöst durch einen Kauf, eine Sanierung oder eine Umschuldung. Sie ist die erste Phase, in der ein Dritter mit eigenem Prüfinteresse auf den Gebäudedatensatz zugreift, und die EPBD hat dafür bereits eine Zugangsstufe vorgesehen: Nach Artikel 22 EPBD zählen Finanzinstitute mit Portfoliobezug zu den Empfängern, die den vollständigen Energieausweis kostenlos, maschinenlesbar und zugleich als Druckdokument erhalten. Für Zugriffe über diesen Rahmen hinaus können die Mitgliedstaaten nach Artikel 16 EPBD Entgelte festlegen. Dass die Richtlinie Banken diesen Zugang ausdrücklich einräumt, ist selbst schon eine Aussage über die Relevanz der Gebäudedaten für Kreditentscheidungen.

Beteiligt sind Eigentümer beziehungsweise Käufer, das finanzierende Institut, gegebenenfalls die Förderbank und der Energieberater als Ersteller der technischen Grundlage. Benötigt wird ein Datenpaket, das über den Energieausweis hinausgeht: Energieklasse und Kennwerte, technischer Zustand der Bauteile und Anlagen, dokumentierter Sanierungsbedarf, ein Sanierungsfahrplan mit Zeitachse, Investitionskosten, in Anspruch genommene und noch verfügbare Förderung — und der Qualitätsstatus all dieser Angaben. Die letzte Position ist die entscheidende: Eine Bank, die nicht weiß, ob eine Angabe geschätzt oder belegt ist, muss den ungünstigeren Fall unterstellen.

Der Gebäudepass trägt hier eine Übersetzungsleistung bei. Er verbindet den technischen Zustand mit der Finanzierungsentscheidung, indem er beides auf denselben Datensatz stützt, und er macht den zukünftigen Kapitalbedarf sichtbar. Denn die energetische Qualität ist nur ein Teil des Risikos; wesentlich ist ebenso, welche Investitionen in den kommenden Jahren unvermeidlich werden. Der Gebäudepass ersetzt dabei keine Immobilienbewertung — er liefert deren Eingangsdaten: technischer Zustand, Energiequalität, Sanierungshistorie, Modernisierungsbedarf und dokumentierter Investitionsbedarf. Für Versicherungen gilt dieselbe Zurückhaltung: Der Datensatz stellt Baujahr, Anlagentechnik, Modernisierungen, Wartungen und Sanierungshistorie strukturiert bereit; die Entscheidung trifft er nicht.

Im vorhandenen System existiert dafür bereits ein automatisch erzeugter Finanzierungsbericht, und die Abhängigkeitskette führt ausdrücklich vom einzelnen Bauteil über U-Wert und Heizlast, den Transmissionswärmeverlust und den Primärenergiebedarf, den Wärmeschutznachweis und den Energieausweis bis zur CO₂-Bilanz, zum Building Trust Index und zum Finanzierungsbericht. Der Trust Index liefert dabei neben dem Gesamtwert einen eigenen Risikowert, der Datenqualität, technischen Zustand und Energiequalität gewichtet zusammenführt. Zugleich sind zwei Einschränkungen zu benennen: Der Leistbarkeits-Assistent, der Varianten, Tilgungspläne und Förderdarlehen rechnet, ist bisher nicht an den gemeinsamen Projektdatenspeicher angebunden und arbeitet daher mit eigenen Eingaben; und die Marktwertermittlung liefert für Nichtwohngebäude noch keinen Ertragswert. Der maschinenlesbare Portfolioabruf durch ein Kreditinstitut über eine Programmierschnittstelle ist konzipiert, aber nicht umgesetzt.

10.7 Sanierungsplanung

Die Sanierungsplanung ist die Phase, in der aus einem dokumentierten Zustand eine Entscheidung wird. Ihre Auslöser sind vielfältig und zunehmend regulatorisch: der Ablauf eines Energieausweises, die Einladung zur Beratung bei Gebäuden unterhalb der Klasse C nach Artikel 19 Absatz 13 EPBD, ein anstehender Heizungstausch, die Bestandspfade des Artikels 9 EPBD — Wohngebäudebestand minus 16 % bis 2030 und minus 20 bis 22 % bis 2035, Nichtwohngebäude unter den Schwellenwerten von 16 % bis 2030 und 26 % bis 2033 — sowie der Renovierungspass nach Artikel 12 EPBD, dessen System die Mitgliedstaaten bis zum 29. Mai 2026 einzuführen hatten. Besondere Bedeutung hat dabei die Vorgabe, dass mindestens 55 % der bis 2030 zu erbringenden Einsparung aus den 43 % schlechtesten Gebäuden stammen müssen. Das erzeugt einen konkreten Datenbedarf: ein Kennzeichen im Datenmodell, das ein Gebäude als besonders schlecht abschneidend ausweist. Das vorhandene System führt die entsprechende deutsche Regelung mit ihren Verhältniswerten als eigenes Modul.

Beteiligt sind Eigentümer, Energieberater als qualifizierter Ersteller, Fachplaner und — bei größeren Objekten — Verwaltung und Finanzierer. Der Renovierungspass verlangt einen zertifizierten Experten, mindestens einen Vor-Ort-Besuch und ein Gesprächsangebot bei der Übergabe; er ist für den Eigentümer freiwillig, sofern der Mitgliedstaat ihn nicht verpflichtend macht.

Benötigt wird der belastbare Ist-Zustand aus Phase 10.3, ergänzt um die technischen Schwachstellen, die daraus abgeleiteten Maßnahmen, deren Kombination zu Varianten, die Energie- und Emissionswirkung jeder Variante, ihre Kosten, die zugehörige Förderung und den Zielzustand. Ein typisches Beispiel: Ein Gebäude mit Gasheizung, ungedämmter Fassade und Fenstern aus 1985 führt zu vier Varianten — nur Wärmepumpe; Wärmepumpe und Fenster; Wärmepumpe, Fenster und Fassade; Komplettsanierung mit Photovoltaik. Für jede sind Investition, Energiebedarf, Emissionen, Förderung und Wirtschaftlichkeit zu ermitteln.

Der Renovierungspass hebt diese Varianten auf eine Zeitachse. Anhang VIII EPBD schreibt dafür eine grafische Roadmap vom Ausgangs- zum Endzustand vor und verlangt je Schritt fünf Pflichtangaben: Bezeichnung und Beschreibung mit Technologie- und Materialoptionen; die Veränderung von Primär- und Endenergie in Kilowattstunden und Prozent gegenüber dem Zustand vor dem Schritt; die Veränderung der betriebsbedingten Treibhausgasemissionen; die Kostenersparnis mit offengelegten Energiepreisannahmen; und die Zielklasse des Energieausweises nach dem Schritt. Hinzu kommen die nationalen Anforderungen mit ihren Stichtagen, die Begründung der optimalen Schrittfolge zur Vermeidung von Lock-in-Effekten, Angaben zu Zirkularität und Lebenszyklus-Treibhauspotenzial sowie Förderhinweise mit Links und die Kontaktdaten der zentralen Anlaufstelle. Der Zielzustand ist dabei definiert: Nullemissionsgebäude ab dem 1. Januar 2030, davor Niedrigstenergiegebäude, ersatzweise eine Primärenergiereduktion von mindestens 60 %, wenn beides nicht erreichbar ist.

Der Beitrag des Gebäudepasses besteht darin, dass diese Zeitachse nicht als Dokument endet. Er dokumentiert anschließend, ob der Pfad tatsächlich beschritten wird — ob der für 2028 vorgesehene Heizungstausch stattgefunden hat, ob die Fenster 2030 erneuert wurden, ob die Fassade 2032 folgte. Artikel 12 Absatz 8 EPBD verankert genau diese Verbindung: Wo ein digitales Gebäudelogbuch existiert, ist der Renovierungspass darin zu speichern oder über eine eindeutige Adresse zugänglich zu machen; nach Artikel 12 Absatz 7 EPBD muss er zudem in die nationale Datenbank hochladbar sein. Und wird der Pass gemeinsam mit dem Energieausweis ausgestellt, ersetzt er nach Artikel 19 Absatz 6 EPBD dessen Modernisierungsempfehlungen.

Zum Stand der Umsetzung ist zu unterscheiden. Der individuelle Sanierungsfahrplan deutscher Prägung wird in den Kommissionsleitlinien zweimal als Vorbild genannt, ist aber kein Renovierungspass im Sinne des Artikels 12 EPBD; ob Deutschland ihn dazu erklärt, ist offen. Im vorhandenen System existieren ein Datenblatt zur Ausgabe der Fahrplandaten, Sanierungs- und Maßnahmenberichte sowie eine Sanierungskostenrechnung mit einer eigenen Spalte für Sowieso-Anteile — die allerdings in keinem der geführten Projekte tatsächlich erfasst sind. Ein förderfähiger Sanierungsfahrplan entsteht ausschließlich in der amtlichen Druckapplikation der BAFA; ein maschinelles Importformat dafür wird nicht veröffentlicht. Die durchgängige Variantenverwaltung mit Zuständen je Sanierungsstufe ist als Entwicklungsschritt geführt und noch nicht umgesetzt.

10.8 Fördermittelbeantragung

Sobald eine Maßnahme gewählt ist, beginnt der Förderprozess — und er beginnt zwingend vor der Beauftragung. Auslöser ist die Entscheidung für eine Variante, Beteiligte sind Eigentümer, Energieberater in seiner Rolle als Fachplaner und Antragsbegleiter, das Förderinstitut und die ausführenden Betriebe.

Benötigt werden Angaben, die der Datensatz überwiegend bereits enthält: Ausgangszustand, technische Beschreibung der Maßnahme, Zielzustand, Kosten und Energiekennwerte vor und nach der Maßnahme. Der wirtschaftliche Kern der Lebenszyklusidee zeigt sich hier besonders deutlich — es entfällt die erneute Erfassung von Informationen, die im Zuge der Bestandsaufnahme und der Sanierungsplanung schon zweimal erhoben wurden. Der Förderprozess selbst lässt sich als Zustandsfolge abbilden: Maßnahme gewählt, Förderfähigkeit geprüft, Programm ausgewählt, Antrag gestellt, Zusage erteilt, Ausführung erfolgt, Nachweis geführt, Auszahlung erfolgt. Aus dieser Folge entsteht über die Jahre eine Förderhistorie des Gebäudes, die bei der nächsten Maßnahme unmittelbar relevant wird, weil Höchstgrenzen und Sperrfristen an das Objekt gebunden sind.

Entscheidend ist dabei ein Punkt, der in der Praxis regelmäßig zu Streit führt: Zu jeder Förderentscheidung muss festgehalten werden, welche Förderbedingungen zu diesem Zeitpunkt galten. Förderprogramme ändern sich in kurzen Abständen, und eine 2026 zugesagte Förderung wird nicht nach den Regeln von 2029 beurteilt. Förderregeln gehören deshalb mit einem Gültigkeitsdatum versioniert, nicht als aktueller Stand geführt. Dieselbe Trennung gilt für den Rechtsstand: Das vorhandene System führt eine Registry, die zwischen dem Stand 2026 und dem Stand 2027 umschaltet, versieht jedes Rechenergebnis mit einem Rechtsstandstempel und benennt die verwendete Normfassung — verbindlich gerechnet wird DIN V 18599:2018-09, die Technische Spezifikation DIN/TS 18599:2025-10 läuft als Vergleichsrechnung mit und ist keine Grundlage öffentlich-rechtlicher Nachweise.

Der Gebäudepass trägt darüber hinaus die Förderlandschaft selbst bei: Eine gepflegte Fördermatrix, Rechner für Baukosten und Sanierungskosten, ein Assistent für die Leistbarkeit mit Varianten und Tilgungsplänen sowie ein Zinsrechner für Förderdarlehen sind vorhanden. Die Honorarzuschüsse der Energieberatung sind dabei korrekt als zwei Töpfe zu je 50 % neben den Höchstkosten von 30 000 beziehungsweise 60 000 Euro geführt, der Zuschuss für den Sanierungsfahrplan von 650 beziehungsweise 850 Euro als Höchstzuschuss und nicht als Kostengrenze. Zugleich beobachtet ein täglich laufender Monitor achtzehn amtliche Quellen auf Änderungen und meldet sie anhand eines fachlichen Fingerabdrucks, nicht anhand eines Seitentexts; er trennt dabei Veröffentlichungs-, Inkrafttretens-, Anwendungs- und Produktivdatum und gibt Vorlaufwarnungen von 180 Tagen bis zu einem Tag. Der Grundsatz dieses Monitors — die Maschine schlägt vor, der Mensch entscheidet — gilt für den Förderprozess uneingeschränkt. Was dagegen fehlt, ist die durchgängige Führung des Antragsstatus am einzelnen Gebäude: Das Fördermodul ist im Reifegrad als teilweise umgesetzt geführt, die Zustandsfolge von der Antragstellung bis zur Auszahlung ist konzipiert, aber nicht implementiert.

10.9 Ausführung und Dokumentation

Mit der Beauftragung beginnt die Phase, in der sich das Gebäude tatsächlich verändert — und damit die Phase, in der ein Gebäudedatensatz am leichtesten falsch wird. Auslöser sind Beauftragung, Baubeginn, Abnahme und Verwendungsnachweis. Beteiligt sind die ausführenden Betriebe, die Bauleitung, der Energieberater in seiner Prüf- und Bestätigungsrolle, gegebenenfalls Prüfsachverständige und der Eigentümer als Freigabeberechtigter.

Der Grund für die Fehleranfälligkeit ist banal: Ausgeführt wird selten genau das, was geplant war. Geplant sind 160 mm Fassadendämmung, ausgeführt werden 180 mm; geplant ist ein Fenster mit U_w = 0,80 W/(m²K), eingebaut wird eines mit 0,86. Beide Abweichungen sind unkritisch, solange sie dokumentiert werden, und beide werden zu einem dauerhaften Fehler, wenn der Planungswert unverändert weiterläuft. Der Gebäudepass muss deshalb in dieser Phase drei Dinge leisten: Plan und Ausführung unterscheiden, die Übernahme der ausgeführten Werte an eine fachliche Prüfung binden und den bisherigen Wert als historische Version erhalten. Aus einer alten Außenwand mit U = 1,20 W/(m²K) wird nach der Dämmung eine mit 0,20 — der alte Wert verschwindet nicht, er wird zur Vorversion.

Zu jeder ausgeführten Maßnahme gehören die Nachweise: Rechnung, Produktdatenblatt, Fotos, Fachunternehmererklärung, Abnahmeprotokoll und Förderbestätigung. Damit ist nicht nur dokumentiert, dass eine Maßnahme durchgeführt wurde, sondern auch, wie. Die EPBD knüpft an diesen Punkt eine ausdrückliche Pflicht: Nach Artikel 19 Absatz 14 EPBD müssen die Mitgliedstaaten vereinfachte Aktualisierungen des Energieausweises ermöglichen — nach einer Einzelmaßnahme, nach umgesetzten Schritten eines Renovierungspasses und über einen digitalen Zwilling beziehungsweise zertifizierte Werkzeuge. Der letzte Fall ist die ausdrückliche Rechtsgrundlage dafür, dass ein Gebäudepass als Datenquelle des Ausweises dient. Übersteigt die Maßnahme die Schwelle der größeren Renovierung, wird ohnehin ein neuer Ausweis fällig; wird ein gebäudetechnisches System installiert, greift die Bewertungs- und Übergabepflicht nach Artikel 13 Absatz 6 EPBD.

Eine abgeschlossene Maßnahme löst zudem eine Kette weiterer Vorgänge aus. Eine sanierte Fassade führt zu einer neuen Bilanz nach DIN V 18599, zu einer erneuten Prüfung der Heizlast — deren Ergebnis wiederum über die Auslegung eines künftigen Wärmeerzeugers entscheidet —, zu einem aktualisierten Energieausweis, zu einer angepassten Ökobilanz, zur Fortschreibung des Sanierungsfahrplans und zur Aktualisierung der Nachhaltigkeitsangaben. Wird die Sanierung isoliert betrachtet, bleiben all diese Folgen aus, und der Datensatz beschreibt nach kurzer Zeit ein Gebäude, das es so nicht mehr gibt.

Zwei Einschränkungen gehören dazu. Das Rollenmodell der Schreibrechte — der Steckbrief als Quelle, Erfassungswerkzeuge als Ermittler, Rechner als reine Ergebnisschreiber, Berichte und Pass als schreibfreie Ausgaben — ist seit dem 23. August 2026 technisch erzwungen; die zuvor gezählten 55 Regelverstöße in 15 Werkzeugen sind abgearbeitet, 35 Registerfelder haben weiterhin mehrere schreibende Werkzeuge. Und die automatische Dokumenterzeugung läuft heute beim bloßen Öffnen des Gebäudepasses an, ohne dass der Nutzer sie ausgelöst hätte. Beides ist bekannt und benannt; für eine Plattform, die revisionsfeste Zustände führen soll, sind es notwendige nächste Schritte.

10.10 Betrieb und Wartung

Mit der Inbetriebnahme beginnt die längste Phase des Lebenszyklus — und die einzige, die nicht durch ein einzelnes Ereignis ausgelöst wird, sondern durch wiederkehrende Termine. Die EPBD setzt hier dicht: Heizungs- und Klimaanlagen über 70 kW sind alle fünf Jahre, über 290 kW alle drei Jahre zu inspizieren (Artikel 23 und 24 EPBD); ab dem 31. Dezember 2029 sind Nichtwohngebäude über 70 kW mit Gebäudeautomation und Beleuchtungssteuerung auszurüsten; wo eine Gebäudeautomation nach Artikel 13 Absätze 10 und 11 EPBD vorhanden ist, entfällt die Inspektionspflicht. Der Energieausweis läuft nach spätestens zehn Jahren ab. Für Gebäude unterhalb der Klasse C tritt die Beratungseinladung nach fünf Jahren hinzu. Und mit dem GMoDG verändert sich die Datenanforderung an den Betrieb selbst: Der Verbrauchsausweis für Wohngebäude verlangt künftig keine drei Abrechnungsperioden mehr, sondern eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate — Anwendung ab dem 1. Januar 2027, wobei bis dahin beide Verfahren parallel bedienbar bleiben müssen. Wer diese Daten nicht laufend erhebt, kann den Ausweis zum Stichtag nicht ausstellen.

Zur Leistungsschwelle ist eine methodische Anmerkung nötig, weil in der Praxis drei Werte kursieren. Belegt sind zwei: 290 kW als Schwelle der Gebäudeautomationspflicht für Nichtwohngebäude und der dreijährigen Inspektion, 70 kW als Schwelle der fünfjährigen Inspektion und der Ausrüstungspflicht zum 31. Dezember 2029. Der ebenfalls genannte Wert von 100 kW lässt sich keiner Rechtsgrundlage zuordnen und ist deshalb nicht als geltende Schwelle verwendbar. Die richtige Konsequenz für ein Datensystem ist nicht, sich für eine Zahl zu entscheiden, sondern die Schwelle als benannten Parameter mit Herkunftsangabe zu führen und sie in jeder Ausgabe mitzunennen. Das vorhandene System tut dies — es führt die Schwelle als Parameter mit eigener Herkunftsangabe; der dort hinterlegte Zahlenwert ist an der belegten Quellenlage auszurichten.

Beteiligt sind in dieser Phase Eigentümer, Hausverwaltung, Wartungs- und Fachbetriebe, Schornsteinfeger und Inspektoren sowie — bei größeren Objekten — der Betreiber der Gebäudeautomation. Benötigt werden Wartungs- und Inspektionstermine je Anlage, Störungs- und Reparaturmeldungen, Verbrauchswerte je Energieträger und Zeitraum, Messdaten aus dem Monitoring und die Restlebensdauer der Anlagenkomponenten.

Der Beitrag des Gebäudepasses ist in dieser Phase am weitesten von der klassischen Gebäudeakte entfernt. Er ordnet alle Ereignisse demselben Anlagenobjekt zu: Inbetriebnahme 2026, Wartung 2027, Pumpentausch 2028, Regelungsoptimierung 2030 gehören zu einer Wärmepumpe, nicht in vier Ordner. Er hinterlegt Wartungszyklen als künftige Termine — nächste Wartung der Wärmepumpe 04/2028, Filterwechsel der Lüftungsanlage 10/2027, Prüfung der Brandschutzklappe 2028 — und macht aus der Dokumentation ein Betriebsinstrument. Er stellt den berechneten Bedarf dem gemessenen Verbrauch gegenüber, ohne beide gleichzusetzen: Die Abweichung ist kein Fehler, sondern ein Hinweis, der auf Nutzerverhalten, Anlagenbetrieb, Regelung, technische Störungen oder veraltete Gebäudedaten führen kann. Und er leitet aus dem Alter der Komponenten den künftigen Kapitalbedarf ab — eine 15 Jahre alte Wärmepumpe, eine 30 Jahre alte Dachabdichtung und 35 Jahre alte Fenster ergeben zusammen eine Investitionsplanung, die weit vor dem Schadensfall beginnt. Die EPBD unterstützt diese Sicht ausdrücklich: Die Lebensdauerprognose der Heizung gehört nach Artikel 16 EPBD zum Mindestumfang der weiterzugebenden Daten, und die Restlebensdauer von Heizung und Klimaanlage ist ein optionaler Ausweisindikator nach Anhang V EPBD; die Leitlinien nennen Richtwerte von 7 bis 25 Jahren für Heizungen, 20 bis 25 Jahren für Wärmepumpen und 10 bis 15 Jahren für Klimaanlagen und verlangen, bei etwa zwei Jahren Restlebensdauer fossilfreie Alternativen zu benennen.

Zur Betriebsphase gehören schließlich auch die Veränderungen, die keine energetische Sanierung sind. Eine Nutzungsänderung — aus einem Ladenlokal wird eine Wohnung, aus einem Büro eine Arztpraxis — verändert Zonierung, Nutzungsprofile, technische Anforderungen und damit die Bilanz. Ein Anbau verändert die Geometrie: 180 m² im Jahr 2026, 45 m² zusätzlich im Jahr 2032. Eine Teilung verändert die wirtschaftlichen Einheiten. All das setzt ein Datenmodell voraus, das stabile Beziehungen zwischen Gesamtgebäude, Gebäudeteilen und Nutzungseinheiten führt und jeden dieser Vorgänge als neuen Gebäudezustand ablegt, statt den alten zu überschreiben. Im vorhandenen System sind die dafür nötigen Bausteine teilweise angelegt — ein Objektgraph mit Beziehungskanten, ein raumweiser Editor, eine kanonisch geführte Bezugsfläche —, die Geometrie- und Bauteilebene ist jedoch noch nicht als eigenständige Passknoten verlinkt.

10.11 Rückbau und Kreislaufwirtschaft

Am Ende der Nutzungsdauer steht der Rückbau. Die EPBD kennt für ihn keine eigene Pflicht — wohl aber verlangt sie die Daten dafür bereits Jahrzehnte früher. Das ist der eigentlich bemerkenswerte Befund dieser letzten Phase. Der Ausweis des Treibhauspotenzials über den Lebenszyklus nach Artikel 7 und Anhang III EPBD rechnet nach EN 15978 über einen Bezugszeitraum von 50 Jahren in Kilogramm CO₂-Äquivalent je Quadratmeter Nutzfläche; zu den Pflichtmodulen gehören ausdrücklich die Module C1 bis C4 — Abbruch, Transport, Abfallbehandlung, Beseitigung — sowie die Module D1 und D2 für Nutzen und Lasten außerhalb der Systemgrenze. Wer ab 2028 für Neubauten über 1 000 m² und ab 2030 für alle Neubauten einen GWP-Ausweis erstellt, hat den Rückbau also bereits bilanziert. Die Rohdatenbasis dafür ist die Mengenaufstellung der Bauteile und Materialien, die aus einem Gebäudemodell extrahierbar ist; die Datenhierarchie führt von der Bauproduktenverordnung über Ökodesign und projektspezifische Daten zu generischen Datensätzen nach EN 15804.

Auslöser der Phase sind Abbruchentscheidung, Genehmigung und Ausschreibung des Rückbaus. Beteiligt sind Eigentümer, Rückbauplaner, Entsorgungs- und Verwertungsbetriebe, Behörden und — bei selektivem Rückbau — die Abnehmer wiederverwendbarer Bauteile. Benötigt werden Materialarten und -mengen je Bauteil, Schadstoffbefunde, die Trennbarkeit der Aufbauten, die Wiederverwendbarkeit einzelner Bauteile und die zulässigen Verwertungs- und Entsorgungswege.

Der Beitrag des Gebäudepasses liegt darin, dass diese Angaben nicht am Ende erhoben, sondern über die Jahrzehnte mitgeführt werden. Wenn Bauteile mit ihren Aufbauten, Mengen und Produktdaten im Datensatz stehen und jede Sanierung ihre Materialien nachträgt, dann beantwortet der Datensatz beim Rückbau vier Fragen ohne neue Erhebung: welche Materialien vorhanden sind, in welchen Mengen, welche Bauteile wiederverwendbar sind und welche Stoffe in welchen Weg der Verwertung gehören. Aus dem Gebäude wird damit nicht nur ein Energieverbraucher, sondern auch ein Materiallager — und der Gebäudepass die Schnittstelle zu einem Ressourcenpass. Der Renovierungspass greift diesen Gedanken bereits vorher auf: Anhang VIII EPBD verlangt Angaben zur Zirkularität der Bauprodukte und zum Treibhauspotenzial über den gesamten Lebenszyklus als Pflichtinhalt.

Bei der Einordnung ist Zurückhaltung geboten, und zwar in beide Richtungen. Rechtlich gilt: Weder ein Materialpass noch ein digitaler Produktpass sind durch die EPBD gefordert; die Zirkularitätsangaben des Renovierungspasses und die Rückbaumodule der GWP-Bilanz sind der Umfang, den die Richtlinie tatsächlich verlangt. Technisch gilt: Im vorhandenen Gebäudepass ist die Rückbau- und Kreislaufebene nicht implementiert. Die Ökobilanz stützt sich derzeit auf einen geschätzten Benchmark für graue Emissionen; die Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen, die Materialpässe, die Bauteil-Einzelpässe und der Gebäuderessourcenpass sind sämtlich als offene Entwicklungspunkte geführt. Diese Phase ist damit die einzige des gesamten Lebenszyklus, für die das Zielbild vollständig beschrieben und die Umsetzung noch nicht begonnen ist.

10.12 Der rote Faden durch alle Phasen

Zusammengenommen ergeben die zehn Phasen eine durchgehende Datenkette: Planung erzeugt Solldaten, der Bau erzeugt Istdaten, aus den Istdaten entsteht der Energieausweis, der Betrieb liefert Mess- und Wartungsdaten zurück, daraus entsteht der Sanierungsplan, aus dem Sanierungsplan folgen Förderung und Finanzierung, die Ausführung erzeugt einen neuen Ist-Zustand, Verkauf und Eigentümerwechsel geben ihn weiter, die weitere Nutzung schreibt ihn fort, und der Rückbau schließt ihn ab. Die folgende Tabelle fasst die Phasen mit ihren Auslösern, den beteiligten Rollen, dem jeweils erforderlichen Datenzugang und dem Ergebnis im Datensatz zusammen.

Zwei Lesarten dieser Tabelle sind wichtig. Erstens: Die Spalte Datenzugang beschreibt überwiegend das Zielbild. Die EPBD gibt die Zugangsstufen vor — Eigentümer, Mieter und Verwalter mit eigenem kostenlosem Zugriff, Finanzinstitute mit Portfoliozugang, Interessenten nur mit befristeter Erlaubnis des Eigentümers, Kommunen mit Gebietsdaten für die Wärmeplanung, die Öffentlichkeit nur aggregiert —, und der vorhandene Gebäudepass setzt davon bisher die Veröffentlichung eines bereinigten Momentaufnahme-Datensatzes mit PIN-Schutz um. Die abgestufte Rechteschicht ist seit dem 23. August 2026 implementiert; der Entwicklungsschritt, von dem die Phasen Verkauf, Vermietung und Finanzierung gemeinsam abhingen, ist damit getan. Was für diese Phasen noch aussteht, sind die Mieterrolle und das empfängerbezogene Freigabepaket. Zweitens: Die Spalte Auslöser zeigt, dass nur zwei der zehn Phasen — Bestandsaufnahme und Rückbau — ohne unmittelbaren EPBD-Bezug auskommen, und selbst diese beiden werden mittelbar von Ausweispflichten und Lebenszyklusbilanz getrieben. Der Lebenszyklus ist also keine freiwillige Zugabe zur Regulierung, sondern ihre eigentliche Struktur.

Der wirtschaftliche Nutzen folgt daraus unmittelbar und ist der nüchternste Teil der Argumentation: Er entsteht durch Wiederverwendung. Statt bei jedem Ereignis das Gebäude neu aufzunehmen, Pläne neu zu suchen, technische Daten neu zu erfassen und vergangene Sanierungen zu rekonstruieren, setzt jeder Vorgang auf einem vorhandenen Datensatz auf. Das reduziert Aufwand in der Energieberatung, in der Finanzierung, in der Sanierung, im Verkauf und in der Verwaltung — und es reduziert ihn nicht einmalig, sondern bei jedem weiteren Ereignis stärker. Hinzu kommt ein Effekt, der in der Betrachtung leicht übersehen wird: Ein gepflegter Gebäudepass wird mit der Zeit besser. Eine 2026 geschätzte Dachdämmung wird 2028 bei einer Bauteilöffnung dokumentiert und 2035 bei der Dachsanierung durch einen vollständig belegten neuen Aufbau ersetzt. Die Datenqualität steigt mit jedem bestätigten Wert, während sie in einer projektbezogenen Arbeitsweise mit jedem neuen Projekt auf null zurückfällt.

Damit verändert sich schließlich der Blick auf das Gebäude selbst. Heute entstehen einzelne Projekte: ein Energieausweisprojekt, ein Förderprojekt, ein Sanierungsprojekt, ein Finanzierungsprojekt. Jedes hat einen Anfang, ein Ende und einen eigenen Datenbestand. Im Gebäudepass werden aus diesen Projekten Ereignisse innerhalb eines dauerhaften Systems.

Nach mehreren Jahrzehnten zeigt ein solcher Datensatz eine geschlossene Chronik: Neubau, Erweiterung der Photovoltaikanlage, Ersatz der Wärmepumpe, Fenstersanierung, Eigentümerwechsel, Anbau, Dachsanierung, erneuter Eigentümerwechsel — und zu jedem dieser Ereignisse einen dokumentierten technischen Zustand mit seiner Herkunft. Genau darin liegt die Idee eines lebenslangen Gebäudepasses: Das Gebäude wird nicht bei jedem neuen Vorgang erneut digitalisiert, sondern sein digitaler Datensatz wächst mit ihm. Die Geschichte des Gebäudes bleibt erhalten, während sich das Gebäude verändert. Welchen konkreten Nutzen daraus die einzelnen Beteiligten ziehen — Eigentümer, Energieberater, Planer, Verwaltungen, Banken, Versicherer, Makler, Kommunen und Forschung —, behandelt Kapitel 11.

11 Nutzen des digitalen Gebäudepasses für die einzelnen Zielgruppen

Die Kapitel 4 bis 10 haben beschrieben, welche Daten der digitale Gebäudepass führt, welche Funktionen auf ihnen arbeiten und in welche Prozesse er eingebettet ist. Dieses Kapitel wechselt die Perspektive und fragt für zehn Zielgruppen einzeln: Woran scheitert die Arbeit mit Gebäudedaten heute, was ändert der Gebäudepass daran, welchen Ausschnitt der Daten sieht die jeweilige Gruppe — und welchen ausdrücklich nicht —, und woran lässt sich der Nutzen messen. Der Aufbau ist für alle zehn Abschnitte gleich, damit die Gruppen vergleichbar bleiben.

11.1 Ein Datenkern, unterschiedliche Sichten

Der Nutzen eines Gebäudedatensatzes entsteht nicht durch seinen Umfang. Ein Archiv aus dreihundert eingescannten Seiten enthält viele Informationen und hilft trotzdem niemandem, weil keine der Angaben adressierbar, prüfbar oder wiederverwendbar ist. Der Mehrwert entsteht erst dadurch, dass verschiedene Beteiligte auf denselben, qualitätsgesicherten Datenbestand zugreifen, ohne dass jede Gruppe das Gebäude erneut aufnimmt. Genau darin liegt der ökonomische Kern des Konzepts: Die Erfassung eines Bestandsgebäudes ist der teuerste Einzelschritt in nahezu jeder energetischen Dienstleistung, und sie wird heute im Lebenszyklus eines Gebäudes vielfach wiederholt — vom Energieberater, vom Architekten, vom TGA-Planer, vom Makler, von der Bank, von der Hausverwaltung, jeweils mit eigenem Formular und eigenem Ergebnis.

Daraus folgt, dass der Gebäudepass keine einheitliche Oberfläche für alle Nutzer sein kann. Ein Eigentümer, der wissen will, ob sich der Austausch der Fenster lohnt, und ein TGA-Planer, der eine Wärmepumpe auslegt, benötigen aus demselben Datenbestand völlig verschiedene Ausschnitte in völlig verschiedener Aufbereitung. Der Pass ist deshalb als gemeinsamer Datenkern mit unterschiedlichen Nutzerperspektiven zu verstehen, nicht als gemeinsamer Bildschirm. Kapitel 5 hat diese Abstufung als Rollen- und Sichtenkonzept eingeführt, Kapitel 9 behandelt die zugehörige Rechte- und Datenschutzschicht. Für dieses Kapitel gilt die dort getroffene Feststellung fort: Im vorhandenen System existiert die Darstellungsebene dieser Abstufung — die Kennwerteseite bietet Rollenansichten für Architekten, Makler, Hausverwaltungen, TGA-Planer, Banken und Energieberater —, sie ist eine Priorisierung der Darstellung und keine Rechteschicht — diese liegt seit dem 23. August 2026 als eigene Ebene darunter. Das abgestufte Zugriffsmodell mit eigener Rechtezuweisung je Rolle ist seit dem 23. August 2026 umgesetzt. Alle Aussagen dieses Kapitels über den Zugriffsumfang einer Zielgruppe sind daher als Sollvorgabe zu lesen, nicht als beschreibende Aussage über den heutigen Stand.

Ein zweiter Grundsatz trennt die Datenhaltung von ihrer Deutung. Der Gebäudepass speichert möglichst objektive Gebäudedaten; die Interpretation leisten die Nutzer für ihre jeweilige Aufgabe. Eine Außenwand mit einem U-Wert von 1,2 W/(m²K) ist für den Energieberater eine energetische Schwachstelle, für den Eigentümer ein Sanierungskandidat mit noch unbekannten Kosten, für die Bank ein künftiger Investitionsbedarf im Beleihungsobjekt und für den Makler ein Merkmal des energetischen Zustands, das in der Verkaufsdarstellung anzugeben ist. Der gespeicherte Wert ist in allen vier Fällen identisch; verschieden ist allein, welche Schlussfolgerung daraus gezogen wird. Diese Trennung ist mehr als eine begriffliche Feinheit — sie ist die Voraussetzung dafür, dass ein Datensatz überhaupt von mehreren Parteien gleichzeitig genutzt werden kann, ohne dass die Bewertung der einen Partei die Daten der anderen verfälscht.

Bemerkenswert ist schließlich, wie ähnlich die Ausgangsprobleme der Zielgruppen trotz ihrer sehr verschiedenen Aufgaben sind. Nahezu alle berichten von denselben fünf Störungen: Daten fehlen; vorhandene Angaben widersprechen einander; Dokumente sind veraltet, ohne dass es ihnen anzusehen wäre; die Veränderungsgeschichte des Gebäudes ist nicht rekonstruierbar; und dieselben Angaben werden immer wieder neu erhoben. Der Gebäudepass setzt an allen fünf Punkten gleichzeitig an, weil sie technisch derselbe Mangel sind — das Fehlen einer führenden, versionierten und mit Herkunftsangaben versehenen Quelle. Die folgenden Abschnitte beschreiben, was das je Zielgruppe konkret bedeutet.

11.2 Der Building Trust Index als gemeinsame Bezugsgröße

Sobald mehrere Parteien denselben Datenbestand nutzen, wird eine Frage gruppenübergreifend wichtig: Wie belastbar ist das, was hier steht? Ein U-Wert aus einem geprüften Wärmeschutznachweis und eine mündliche Erinnerung des Eigentümers an „ungefähr zehn Zentimeter Dämmung" sind formal beide ein Zahlenwert im selben Feld, dürfen aber nicht dieselbe Vertrauensstufe besitzen. Kapitel 4 hat dafür die Vertrauensstufen 0 bis 5 und die vier Datenzustände Entwurf, Gemeldet, Geprüft und Freigegeben eingeführt. Diese Angaben stehen je Wert und sind für die fachliche Arbeit unverzichtbar — für eine schnelle Einordnung des gesamten Gebäudes sind sie zu kleinteilig. Der Building Trust Index verdichtet sie zu einer Kennzahl auf der Skala 0 bis 100.

Der Index bewertet ausdrücklich nicht den Eigentümer, sondern die Qualität und Vertrauenswürdigkeit der Gebäudedaten sowie den technischen Zustand des Gebäudes. Er setzt sich aus sieben gewichteten Säulen zusammen, die jeweils selbst auf der Skala 0 bis 100 geführt werden:

• Dokumentationsqualität (20 %) — wie vollständig die Pflichtangaben belegt sind und wie viele Werte über eine Belegkante mit einem Dokument verknüpft sind.
• Technischer Zustand (20 %) — abgeleitet aus Baujahr und dokumentierten Maßnahmen.
• Energiequalität (15 %) — abgeleitet aus der berechneten Effizienzklasse.
• Wartungszustand (10 %) — Wartungs- und Prüfnachweise der technischen Anlagen.
• Sanierungsreife (10 %) — wie weit ein abgestimmter Maßnahmenpfad vorliegt.
• Datenqualität (15 %) — mittlere Vertrauensstufe der geführten Werte, Anteil freigegebener Werte, Abzug für offene Aufgaben.
• Zukunftsfähigkeit (10 %) — Photovoltaik, Wallbox, intelligentes Messsystem, Energiemanagement.

Aus den Säulen bilden sich drei zusammenfassende Größen und ein Risikowert: Trust aus Datenqualität und Dokumentation, Health aus technischem Zustand, Energiequalität und Wartung, Future aus Zukunftsfähigkeit und Sanierungsreife sowie ein Risikowert, der aus den Gegenwerten von Datenqualität, Technik und Energiequalität gebildet wird und bei dem ein kleiner Zahlenwert das günstigere Ergebnis ist. Der Gesamtwert wird mit einer Ampel hinterlegt — ab 90 „exzellent", ab 80 „sehr gut", ab 70 „gut", ab 60 „Verbesserungsbedarf", darunter „Handlungsbedarf". Die Passkarte verwendet zusätzlich eine Statusbezeichnung, die die Aussage bewusst auf die Dokumentation bezieht: 90 bis 100 verifiziert, 75 bis 89 vertrauenswürdig, 60 bis 74 teilweise dokumentiert, 40 bis 59 wesentliche Lücken, 0 bis 39 ungeprüft. Damit ist auch die wichtigste Lesehilfe formuliert: Ein niedriger Wert bedeutet nicht automatisch ein schlechtes Gebäude, sondern zunächst ein schlecht belegtes Gebäude.

Das Regelwerk ist offen und erklärbar angelegt. Jeder Beitrag zu jeder Säule wird mit Vorzeichen, Punktzahl und Bezeichnung mitgeführt, so dass sich zu jedem Punktwert die Frage beantworten lässt, woraus er entstanden ist. Der Index arbeitet zweistufig: Die erste Stufe beschreibt den objektiven Status, die zweite ermittelt ein Potenzial, also Maßnahmen mit geschätzter Punktwirkung — Fassade und Dach, Heizung, Fenster, Photovoltaik — und, bei einer Datenqualität unter 80, den Hinweis, vorhandene Werte zu prüfen und freizugeben. Diese zweite Stufe ist der Grund, warum der Index für den Eigentümer handhabbar ist: Er zeigt nicht nur einen Zustand, sondern den nächsten wirksamen Schritt, und er macht sichtbar, dass ein Teil der Verbesserung ohne jede Bauleistung erreichbar ist, nämlich durch das Prüfen und Freigeben bereits vorhandener Angaben.

11.3 Eigentümer

Für Eigentümer beginnt das Problem nicht bei der Energieeffizienz, sondern bei sehr einfachen Fragen, die sich im Bestand oft nicht beantworten lassen: Wann wurde das Dach gedämmt und mit welcher Stärke? Welche Fenster wurden eingebaut und welchen U-Wert haben sie? Wie alt ist der Wärmeerzeuger? Wo liegt die Rechnung? Welcher Energieausweis ist der aktuelle, und wann läuft er ab? Welche Förderung wurde bereits in Anspruch genommen — und schließt sie eine spätere aus? Die Antworten existieren meist, aber verteilt auf Ordner, Rechnungen, Pläne, E-Mail-Postfächer und Erinnerungen. Bei einem Eigentümerwechsel, nach einem Wasserschaden oder nach dem Tod des bisherigen Eigentümers geht ein erheblicher Teil dieses Wissens vollständig verloren. Das Gebäude steht dann technisch wieder am Anfang, obwohl an ihm über Jahrzehnte gearbeitet wurde.

Der Gebäudepass ändert daran zunächst das Ablageprinzip: Aus einer Sammlung von Dokumenten wird eine strukturierte Gebäudechronik, in der jedes Ereignis — Fenstertausch, Heizungserneuerung, Dachdämmung, Photovoltaikanlage — mit technischen Daten, Kosten, Rechnung, Förderbescheid und energetischer Auswirkung hinterlegt ist. Weil jede Änderung eine neue Version erzeugt und nichts überschrieben wird, bleibt zusätzlich nachvollziehbar, wie sich das Gebäude verändert hat und nicht nur, wie es heute ist. Der zweite Schritt richtet den Blick nach vorn: Aus Anlagenaltern, Restlebensdauern und dem Maßnahmenpfad des Renovierungspasses lässt sich ein zeitlich geordneter Investitionsbedarf ableiten, so dass der Eigentümer nicht erst bei einem Defekt erfährt, dass eine Ausgabe ansteht. Und der dritte Schritt macht aus der Beratung eine Entscheidung: Werden mehrere Sanierungsvarianten mit Investitionskosten, Förderung, Energieeinsparung, CO₂-Wirkung und Betriebskosten nebeneinandergestellt, wird die Wahl zwischen „nur Wärmepumpe", „Wärmepumpe und Fenster" und „Wärmepumpe, Fassade und Photovoltaik" vergleichbar. Hier ist Zurückhaltung geboten: Ein Wirtschaftlichkeits- und Leistbarkeitsassistent mit Varianten, Ampel und Tilgungsplan für Bank- und Förderdarlehen liegt vor, arbeitet derzeit aber noch ohne Anbindung an den Projektdatenbestand; die Variantenrechnung als integrierter Bestandteil des Passes ist konzipiert und noch nicht umgesetzt. Ebenso ist die im Bedienkonzept beschriebene Assistenzansicht für Laien — mit den fünf Zuständen einer Angabe, dem stets erlaubten „Weiß ich nicht" und einem einzigen Hauptbutton — Vorgabe und nicht Ist-Stand; die heutige Oberfläche ist die Fachansicht.

Der Eigentümer sieht als einziger Beteiligter den vollständigen Datensatz seines Gebäudes: alle technischen Angaben, alle Dokumente, alle Kosten- und Förderdaten, dazu die Herkunft jedes Wertes, seinen Prüfstatus und die offenen Widersprüche. Er sieht insbesondere auch, was fehlt — das ist der eigentliche Unterschied zur Ordnerablage, die nur zeigt, was vorhanden ist. Nicht sichtbar sind ihm die Daten anderer Gebäude, und aus der Rolle folgt keine fachliche Befugnis: Eine Angabe des Eigentümers ist im Datenmodell eine Meldung, die als Vorschlag im Arbeitsbereich landet; in den offiziellen Datenpfad gelangt sie erst über eine fachliche Freigabe. Das ist keine Entmündigung, sondern die Bedingung dafür, dass Dritte den Angaben überhaupt trauen können. Rechtlich ist die Position des Eigentümers ohnehin die stärkste: Artikel 16 EPBD gibt Eigentümern, Mietern und Verwaltern direkten und kostenlosen Zugang zu den Gebäudesystemdaten und stellt die Weitergabe an selbst benannte Dritte ausdrücklich kostenlos; für andere Berechtigte dürfen die Mitgliedstaaten Entgelte festlegen.

Messbar wird der Nutzen für den Eigentümer an drei Größen, die das System selbst führt. Erstens am Vollständigkeitsgrad: Der Pass prüft 23 Pflichtfelder in acht Kategorien, führt sie mit Priorität und Sprungziel und weist je Fachbereich einen Datenanteil in Prozent aus. Zweitens am Building Trust Index und seiner Säule Datenqualität, an der sich ablesen lässt, wie viel Vertrauenswürdigkeit allein durch Prüfen und Freigeben vorhandener Werte gewonnen werden kann. Drittens an der Zahl der offenen Konflikte und veralteten Ergebnisse, die das System als Aufgaben führt. Das sind bewusst keine Einsparversprechen: Was der Pass messbar macht, ist der Zustand der eigenen Datengrundlage — die Energieeinsparung ergibt sich aus der Sanierung, nicht aus ihrer Dokumentation.

11.4 Energieberater

Für Energieberater ist die Ausgangslage betriebswirtschaftlich zugespitzt. Eine Beratung beginnt heute regelmäßig mit Datenaufnahme, Aufmaß, Plansuche, Bauteilerfassung und Anlagenaufnahme — Tätigkeiten, die den größten Zeitanteil binden, den geringsten fachlichen Anspruch tragen und beim nächsten Auftrag am selben Gebäude vollständig wiederholt werden. Kommt der Eigentümer nach fünf Jahren mit einer neuen Frage zurück, oder wechselt er den Berater, beginnt die Aufnahme von vorn. Hinzu kommt ein Dokumentationsproblem: Nach Projektende liegt das Ergebnis als Bericht vor, das Modell dahinter aber meist als Datei in einer Programmversion, die in einigen Jahren nicht mehr verfügbar sein wird. Der fachliche Wert der Arbeit verfällt schneller als das Gebäude.

Der Gebäudepass verschiebt den Prozess von der Neuerfassung zum Weiterarbeiten: Statt Aufnahme, Berechnung, Bericht und Projektende steht am Anfang ein vorhandener Gebäudedatensatz, der geprüft, aktualisiert und weitergerechnet wird. Damit verlagert sich der Aufwand von der Erfassung auf die Beratung — also auf den Teil der Leistung, der fachlich anspruchsvoll und wirtschaftlich tragfähig ist. Voraussetzung dafür ist, dass jeder Wert seine Herkunft mitführt: Steht neben dem U-Wert der Außenwand von 0,24 W/(m²K) die Quelle „Wärmeschutznachweis" und der Status „fachlich geprüft", muss diese Frage nicht bei jedem Auftrag neu geklärt werden. Der zweite Effekt ist die Qualitätssicherung. Wenn eine Rechnung 160 mm Dämmstärke belegt, das Datenmodell aber 100 mm führt, oder wenn einer berechneten Heizlast von 5,5 kW eine installierte Wärmepumpenleistung von 18 kW gegenübersteht, erzeugt das System einen Konflikt beziehungsweise einen Prüfhinweis, statt einen der Werte stillschweigend zu überschreiben. Im vorhandenen System ist diese Trennung konsequent umgesetzt: Ein Abgleich prüft die Daten auf innere Widersprüche, ein zweiter Prüfmechanismus überwacht den Programmcode; automatisch überschrieben wird in beiden Fällen nichts.

Der Energieberater sieht den vollständigen technischen Datensatz einschließlich Geometrie, Bauteilen, Anlagen, Nutzungsprofilen, Verbrauchshistorie, Nachweisen und der vollständigen Herkunfts- und Versionsinformation — er ist die Rolle, die den Datenbestand fachlich verantwortet und deshalb auch seine Schwächen sehen muss. Nicht Bestandteil dieser Rolle sind die Finanzierungs- und Vertragsdaten des Eigentümers, personenbezogene Verbrauchsdaten einzelner Mieter und, bei fremden Gebäuden, jeder Zugriff ohne Auftrag: Artikel 22 EPBD ordnet unabhängige Experten ausdrücklich der Zugriffsstufe zu, die nur mit Erlaubnis des Eigentümers geöffnet wird. Fachlich bedeutsam ist außerdem, dass der Pass die Berechnung nicht ersetzt. Er liefert die Gebäudedaten, die Methodik liefert DIN V 18599; verbindlich gerechnet wird nach der Ausgabe 2018-09, während die Technische Spezifikation 2025-10 nur als Vergleichsrechnung mitlaufen darf. Jede Ausgabe muss die gerechnete Normfassung benennen — eine Anforderung, die ohne saubere Datenherkunft nicht erfüllbar ist.

Messbar wird der Nutzen an der Zeit bis zur ersten belastbaren Berechnung, am Anteil der Werte, die aus dem Bestand übernommen statt neu erhoben werden, und an der Zahl der Konflikte, die vor der Ausstellung eines Dokuments bereinigt wurden. Für die Belastbarkeit der Rechenkerne selbst existiert ein eigener, harter Maßstab: Die Validierungsfälle nach DIN V 18599 werden mit einer Toleranzvorgabe von einem Prozent geführt; zum Stand 17.08.2026 lagen bei 34 Fällen und 964 geprüften Größen keine Werte außerhalb der Toleranz, die Wärmepumpenfälle als Teilabnahme. Das ist keine Aussage über die Qualität einer einzelnen Beratung, aber eine überprüfbare Aussage über das Werkzeug, mit dem sie erstellt wird.

11.5 Architekten und TGA-Planer

Architekten arbeiten im Bestand regelmäßig gegen eine widersprüchliche Planlage. Es existieren Genehmigungspläne, Ausführungspläne, Bestandspläne und nachträgliche Handeintragungen, ohne dass erkennbar wäre, welcher Stand gilt, welche Änderung tatsächlich gebaut wurde und welcher Umbau nie dokumentiert wurde. Die Folge sind Aufmaßfahrten, Bauteilöffnungen und Annahmen, die erst auf der Baustelle korrigiert werden. Der Gebäudepass ändert daran vor allem eines: Er beantwortet die Frage nach dem gültigen Stand, weil jede Angabe eine führende Quelle, einen Gültigkeitsstatus und eine Historie besitzt. Ein Architekt erkennt damit, welcher Plan aktuell ist, welche Änderungen dokumentiert sind und welche Bauteile nachträglich verändert wurden — und, was ebenso wichtig ist, an welchen Stellen die Dokumentation eine Lücke hat, die vor Planungsbeginn zu schließen ist. Für die Flächen- und Geometrieseite liegt eine belastbare Grundlage vor: Flächen werden nach DIN 277 geführt, Raumflächen polygongenau statt über Umgrenzungsformeln ermittelt; Wohnfläche und die energetische Bezugsfläche werden bewusst nicht aus dem Grundriss abgeleitet, weil sie anderen Definitionen folgen. Für digital dokumentierte Bestände und Neubauten kann IFC als offener Austauschstandard die Verbindung zur Planung herstellen; im vorhandenen System ist IFC als Eingangsweg gekennzeichnet, ein entsprechender Ausgang fehlt, und die Verknüpfung von Geometrie und Bauteilen als eigene Knoten des Passes ist erst teilweise hergestellt.

TGA-Planer stehen vor dem verwandten, aber schärferen Problem, dass sie ihre Auslegung auf Größen stützen müssen, die im Bestand selten vorliegen: Heizlast und Kühllast, tatsächlich installierte Heizflächen, Systemtemperaturen, Verteilungsverluste, Warmwasserbedarf, Nutzungszeiten und realer Verbrauch. Fehlen sie, wird nach Faustwerten ausgelegt — mit dem bekannten Ergebnis überdimensionierter Erzeuger, die im Teillastbetrieb takten und die erwarteten Effizienzwerte nicht erreichen. Beim Einbau einer Wärmepumpe entscheidet genau diese Datenlage über den Projekterfolg. Die EPBD greift den Punkt auf: Die Niedertemperaturfähigkeit des Verteilsystems ist eine Pflichtangabe des Energieausweises, und die Kommissionsleitlinien definieren sie über eine Auslegungstemperatur von höchstens 45 °C beziehungsweise einen saisonalen Wert von höchstens 42 °C, ermittelt in vier Schritten von der Heizlast über die Heizkörperleistung und den Volumenstrom zur Systemtemperatur. Damit wird aus einer Planerfrage eine Datenanforderung, die der Gebäudepass bedienen kann. Im vorhandenen System liegen die dafür nötigen Rechenwege vor: raumweise Heizlast einschließlich Trinkwarmwasser, Kühllast, eine Erzeugerauslegung, die Heizlast, Trinkwarmwasser und Sonderverbraucher zusammenführt, sowie eine Kostenermittlung nach Gewerken. Nach der Inbetriebnahme können Verbrauchsdaten ergänzt werden, so dass sich Auslegung und Betrieb vergleichen lassen; eine automatische Anbindung von Betriebsdaten aus Anlagen und Zählern gehört jedoch zu den offenen Punkten und ist nicht umgesetzt.

Beide Planergruppen sehen den technischen Ausschnitt des Datensatzes: Architekten Geometrie, Flächen, Bauteilaufbauten, Pläne, Materialien und Umbauhistorie; TGA-Planer Anlagenbestand, Lasten, Verteilung, Übergabe, Systemtemperaturen, Nutzungsprofile und Verbrauch. Beide benötigen die Herkunftsangaben, weil sich daran entscheidet, ob ein Wert planungssicher ist oder vor Ort verifiziert werden muss. Nicht Bestandteil ihrer Sicht sind die Finanzierungs- und Kaufpreisdaten des Eigentümers, personenbezogene Verbrauchs- und Mieterdaten sowie diejenigen Kostenkalkulationen, die dem Eigentümer und seinen wirtschaftlichen Beratern vorbehalten bleiben. Für die Anlagentechnik ist zusätzlich Artikel 13 Absatz 6 EPBD zu beachten: Nach der Installation eines gebäudetechnischen Systems ist die Gesamtenergieeffizienz des veränderten Teils zu bewerten, zu dokumentieren und dem Eigentümer zu übergeben — ein Vorgang, der ohne strukturierte Ablage regelmäßig folgenlos bleibt und im Gebäudepass genau dorthin gehört, wo er später wieder gefunden wird.

Messbar wird der Nutzen an der Zahl der Bauteil- und Anlagenangaben, die mit einem Beleg verknüpft sind, an der Differenz zwischen angenommenen und nach Aufmaß bestätigten Werten und — für die TGA — an der Abweichung zwischen ausgelegter und gemessener Leistung nach der ersten Heizperiode. Auch hier gilt die Zurückhaltung: Der Pass verkürzt keine Planungszeit von selbst. Er verhindert, dass dieselbe Information dreimal beschafft und in drei Werkzeugen unterschiedlich gepflegt wird.

11.6 Hausverwaltungen

Hausverwaltungen führen den Gebäudebestand operativ und haben deshalb ein anderes Problem als alle bisher genannten Gruppen: nicht die einmalige Erfassung, sondern die dauerhafte Nachweisführung. Wartungsintervalle, wiederkehrende Prüfungen, Schornsteinfegertermine, Trinkwasseruntersuchungen, Aufzugsprüfungen, Rechnungen, Verbrauchsabrechnungen und Modernisierungsbeschlüsse müssen jederzeit belegbar sein — und werden in der Praxis über Kalender, Ordner, Verwaltersoftware und E-Mail verteilt geführt. Bei einem Verwalterwechsel ist der Übergabestand regelmäßig unvollständig, weil ein Teil des Wissens an Personen und nicht an das Objekt gebunden war. Für den Eigentümer entsteht daraus die unangenehme Lage, dass er über den technischen Zustand seines Gebäudes weniger weiß als sein Dienstleister.

Der Gebäudepass kann Teile der klassischen technischen Objektakte übernehmen und dabei zwei Dinge ändern. Erstens bleibt die Akte am Gebäude und nicht beim Verwalter: Wechselt die Verwaltung, bleibt der Datenbestand bestehen, und der Übergabeaufwand reduziert sich auf die Rechtezuweisung. Zweitens arbeiten Eigentümer und Verwaltung auf demselben Bestand statt auf zwei Ausschnitten, die auseinanderlaufen. Die Verwaltung ergänzt die operativen Informationen — durchgeführte Wartungen, Prüfergebnisse, Reparaturen, Verbrauchsablesungen —, der Eigentümer behält die Gesamtübersicht, und beide sehen denselben Stand. Hier ist der Entwicklungsstand allerdings deutlich zu benennen: Die Wartungs- und Inspektionsseite ist im vorhandenen System der am wenigsten ausgebaute Bereich. Dass die Säule Wartungszustand des Building Trust Index auf null steht, solange Dokumente und Wartungen nicht mit den Anlagenobjekten verknüpft sind, ist kein Rechenfehler, sondern die ehrliche Abbildung dieser Lücke. Die Voraussetzungen — Objektgraph, Belegkanten, Versionierung, Dokumentenerkennung — liegen vor; die Verknüpfung ist herzustellen.

Die Verwaltung sieht den operativen Ausschnitt: technische Anlagen mit ihren Kennwerten, Wartungs- und Prüftermine, Verbrauchs- und Abrechnungsdaten, Instandhaltungsdokumente und den Maßnahmenstand. Sie sieht ausdrücklich nicht die wirtschaftlichen Daten des Eigentümers — Kaufpreis, Finanzierung, Beleihung, Marktwerteinschätzung — und keine personenbezogenen Daten über den für die Abrechnung erforderlichen Umfang hinaus. Umgekehrt sieht der Eigentümer die Betriebsdokumentation, ohne in die operativen Abläufe eingreifen zu müssen. Regulatorisch relevant ist für diese Gruppe der Zusammenhang zwischen Inspektion und Gebäudeautomation: Nach Artikel 23 und 24 EPBD sind Heizungs- und Klimaanlagen oberhalb von 70 kW alle fünf Jahre und oberhalb von 290 kW alle drei Jahre zu inspizieren; wo Gebäudeautomation nach Artikel 13 vorhanden ist, entfällt diese Inspektionspflicht. Welche Leistungsschwelle im Einzelfall gilt, ist nicht durchgängig geklärt — die Quellenlage führt 70 und 290 kW mit Belegstelle, eine dritte kursierende Zahl von 100 kW ohne Rechtsgrundlage. Für die Praxis folgt daraus die Arbeitsregel, die Schwelle nicht als Konstante zu behandeln, sondern als Parameter mit Herkunftsangabe zu führen und in jeder Ausgabe zu benennen.

Messbar wird der Nutzen an der Termintreue: Anteil der fristgerecht durchgeführten Wartungen und Prüfungen, Zahl der überfälligen Nachweise, Vollständigkeit der Anlagendokumentation je Objekt. Das sind Kennzahlen, die eine Verwaltung ohnehin gegenüber dem Eigentümer verantwortet und die heute meist nur stichprobenhaft belegbar sind. Sobald Wartungsdokumente an das jeweilige Anlagenobjekt gebunden sind, wird der Nachweis zum Nebenprodukt des Betriebs statt zu einer eigenen Recherche.

11.7 Banken

Für Kreditinstitute hat der Gebäudepass eine andere Qualität als für die übrigen Gruppen, weil hier nicht eine Arbeitserleichterung, sondern eine aufsichtsrechtlich getriebene Datenanforderung dahintersteht. Klima- und Umweltrisiken werden zunehmend in Kreditvergabe, Risikomanagement, Portfoliosteuerung und Offenlegung einbezogen, und die Immobilie ist bei den meisten Instituten die größte Sicherheitenklasse. Das übliche Datenfundament dafür — der Energieausweis — trägt diese Last nur begrenzt. Er liefert eine Klasse und Kennwerte, beantwortet aber nicht, warum ein Gebäude in dieser Klasse steht, wie es verbessert werden kann, was die Verbesserung kostet und wann sie fällig wird. Für eine Kreditlaufzeit von zwanzig oder dreißig Jahren ist eine Momentaufnahme ohne Pfad wenig wert. Hinzu kommt ein Qualitätsproblem, das in der Kreditpraxis selten adressiert wird: Ob eine Angabe zur Dachdämmung aus einer Rechnung mit Produktdatenblatt stammt oder aus der Erinnerung des Eigentümers, ist im heutigen Datenfluss zur Bank nicht unterscheidbar. Beide erreichen die Bank als Zahl.

Der Gebäudepass ändert daran zweierlei. Erstens bildet er statt eines statischen Labels eine Kette ab: aktueller Zustand, identifizierte energetische Schwachstelle, zugeordnete Maßnahme, Kosten, Förderung, resultierender Zielzustand. Aus dem Label wird ein Transformationspfad, der sich in die Größen übersetzen lässt, mit denen ein Kreditinstitut ohnehin arbeitet — Investitionsbedarf im Zeitverlauf, Auswirkungen auf Betriebskosten und Mieterträge, Bewertungsrelevanz, Anschlussfinanzierungsbedarf, Vertragsbedingungen. Der Gebäudepass trifft dabei keine Kreditentscheidung und soll sie nicht treffen; er verbessert die technische Datengrundlage, auf der sie getroffen wird. Zweitens macht er die Datenqualität selbst zur Information. Der Building Trust Index und insbesondere seine Säulen Datenqualität und Dokumentationsqualität liefern eine strukturierte Antwort auf die Frage, wie belastbar die gelieferten Kennwerte sind. Auch hier ist die Abgrenzung aus Abschnitt 11.2 einzuhalten: Der Index ersetzt weder Bonitätsprüfung noch Wertermittlung. Im vorhandenen System endet die Wirkkette technisch folgerichtig genau an dieser Stelle — vom Bauteil über U-Wert und Heizlast zu Transmissionswärmeverlust und Primärenergiebedarf, weiter zu Nachweis und Ausweis, zur CO₂-Bilanz, zum Building Trust Index und bis in einen automatisch erzeugten Finanzierungsbericht, der bei geänderter Datengrundlage neu erstellt wird.

Der Zugriffsumfang der Banken ist von allen Zielgruppen am klarsten geregelt. Artikel 22 EPBD nennt Finanzinstitute ausdrücklich als eigene Zugriffsstufe: Für die Gebäude ihres Portfolios erhalten sie den vollständigen Energieausweis kostenlos, maschinenlesbar und zusätzlich als Druckdokument — und der vollständige Ausweis umfasst nach Artikel 20 Absatz 8 EPBD auch die Berechnungseingangsdaten, also Gebäudekategorie, Bezugsfläche, den nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Gebäudetechnik disaggregierten Bedarf, Leistung und Effizienz der Anlagentechnik, die Leistung der Erzeugungsanlagen für erneuerbare Energie sowie Flächen und U-Werte der Hauptbauteile. Nicht Bestandteil dieser Stufe sind personenbezogene Daten der Bewohner, mieterbezogene Verbrauchsdaten, Rechnungs- und Dokumentenbestände mit Personenbezug und alle Angaben, die über den Ausweis und die zugehörigen Rohdaten hinausgehen und der Zustimmung des Eigentümers bedürfen. Für die darüber hinausgehenden Gebäudesystemdaten nach Artikel 16 EPBD gilt zudem, dass die Mitgliedstaaten für Banken — anders als für Eigentümer, Mieter und Verwalter — Entgelte festlegen dürfen. Praktisch wichtig ist ein Vorbehalt: Deutschland verfügt nach dem Anhang der Kommissionsleitlinien noch über keine nationale Energieausweis-Datenbank, und das deutsche Schema nach Artikel 22 existiert zum Quellenstand nicht. Der Portfoliozugang der Institute ist damit Rechtslage, aber noch keine Infrastruktur. In dieser Lücke kann ein Gebäudepass die Rolle der Datenquelle übernehmen — mit Einwilligung des Eigentümers und ohne den Anspruch, die amtliche Datenbank zu ersetzen.

Messbar wird der Nutzen an Größen, die ein Institut selbst führen kann: Anteil der Kreditobjekte mit vorliegendem, gültigem und maschinenlesbarem Energieausweis; Anteil der Objekte mit dokumentiertem Maßnahmenpfad; durchschnittliche Vertrauensstufe der energetischen Kennwerte im Portfolio; Anteil der Objekte, die unter die Worst-Performing-Kategorien fallen. Diese Kennzahlen sind unmittelbar berichtsfähig und hängen nicht davon ab, ob man den einzelnen Kennwerten eine bestimmte Risikowirkung zuschreibt. Was der Gebäudepass beiträgt, ist nicht eine bessere Risikoeinschätzung, sondern eine überprüfbare Aussage darüber, worauf sie sich stützt.

11.8 Versicherungen

Versicherer beurteilen Gebäude überwiegend anhand weniger Merkmale — Baujahr, Bauart, Nutzung, Lage, gegebenenfalls Vorschäden. Der tatsächliche technische Zustand fließt kaum ein, weil er nicht belegbar ist. Zwei äußerlich vergleichbare Gebäude, von denen eines seine Elektroanlage vor drei Jahren erneuert und seine Heizung regelmäßig gewartet hat, während beim anderen seit dreißig Jahren nichts dokumentiert ist, sind aus Sicht der Antragsdaten identisch. Im Schadenfall wird der Unterschied dann rückwirkend rekonstruiert, oft strittig und regelmäßig zulasten des Versicherungsnehmers, der seine Instandhaltung nicht nachweisen kann. Hinzu kommen neue Anlagen — Photovoltaik, Batteriespeicher, Wärmepumpe, Ladeinfrastruktur —, die im Bestand vorhanden sind, ohne dass Umfang und Ausführung dem Versicherer bekannt wären.

Ein Gebäudepass verändert daran nicht die Tarifierung, sondern die Beweislage. Ein Gebäude mit nachvollziehbarer Wartungs- und Modernisierungshistorie lässt sich beurteilen; ein Gebäude mit unbekanntem technischen Zustand nicht. Wenn dokumentiert ist, wann die Heizung gewartet, das Dach saniert, die Elektroanlage erneuert und die Trinkwasserinstallation geprüft wurde, und wenn diese Angaben mit Belegen verknüpft sind, entsteht eine technische Historie, die sowohl bei der Antragstellung als auch im Schadenfall verwendbar ist. Hier ist die Entwicklungslage besonders deutlich zu benennen: Ein Versicherungsmodul ist im internen Pflichtenheft als offener Punkt geführt und nicht umgesetzt; die Wartungsdokumentation ist, wie in Abschnitt 11.6 beschrieben, noch nicht mit den Anlagenobjekten verknüpft. Der Nutzen für diese Zielgruppe ist damit konzeptionell gut begründet, aber technisch der am weitesten entfernte in diesem Kapitel. Auch inhaltlich ist Zurückhaltung angebracht: Der Gebäudepass ersetzt weder Risikoprüfung noch Tarifierung noch Schadenregulierung. Er liefert Belege, keine Bewertungen.

Der Zugriffsumfang wäre entsprechend eng zu fassen: Baujahr, Bauart und Konstruktion, technische Anlagen mit Baujahr und Leistung, Wartungs- und Prüfnachweise, Sanierungshistorie sowie besondere Anlagen wie Photovoltaik oder Speicher. Ausdrücklich nicht dazu gehören Energiekostendaten, Finanzierungs- und Beleihungsdaten, Marktwerteinschätzungen, personenbezogene Angaben zu Bewohnern und der vollständige Dokumentenbestand. Da Versicherer in Artikel 22 EPBD nicht als eigene Zugriffsstufe genannt sind, ist ihr Zugang nicht regulatorisch vorgezeichnet, sondern beruht vollständig auf einer ausdrücklichen, zweckgebundenen und befristeten Einwilligung des Eigentümers. Das ist ein Unterschied zur Bankenrolle, der nicht verwischt werden sollte.

Messbar wäre der Nutzen an der Vollständigkeit der Wartungs- und Prüfnachweise über einen definierten Zeitraum, am Anteil der Anlagen mit dokumentiertem Baujahr und dokumentierter letzter Wartung und an der Zeit, die im Schadenfall bis zur Vorlage der relevanten Nachweise vergeht. Solange die Wartungsdaten nicht strukturiert geführt werden, bleiben diese Kennzahlen jedoch eine Zielbeschreibung.

11.9 Immobilienmakler

Im Verkaufs- und Vermietungsprozess entsteht der Informationsbedarf schlagartig und unter Zeitdruck. Liegt ein gültiger Energieausweis vor? Wann wurde saniert und was genau? Welche Heizung ist eingebaut, wie alt ist sie, ist sie nach den geltenden Anforderungen weiterbetriebsfähig? Welche Dämmung wurde ausgeführt? Der Makler trägt diese Angaben beim Verkäufer zusammen, erhält sie in unterschiedlicher Qualität und haftet zugleich für ihre Richtigkeit in der Vermarktung. Die regulatorische Verschärfung erhöht den Druck: Nach Artikel 19 EPBD löst nicht nur der Verkauf, sondern auch die Neuvermietung und sogar die Verlängerung eines Mietvertrags die Ausweispflicht aus, und in Anzeigen sind Indikator und Effizienzklasse anzugeben. Der Ausweis ist maximal zehn Jahre gültig, muss digital und maschinenlesbar vorliegen — ein eingescanntes PDF genügt ausdrücklich nicht.

Der Gebäudepass kann für diesen Vorgang ein freigegebenes Verkaufsprofil bereitstellen, das Gebäudetyp, Baujahr, Wohn- beziehungsweise Nutzfläche, Effizienzklasse, Energieausweis, Heizsystem, Sanierungshistorie und dokumentierte Modernisierungen enthält — nicht als Behauptung, sondern mit Herkunftsangabe. Der Unterschied ist im Ergebnis erheblich. „Die Fenster wurden irgendwann vor etwa zehn Jahren erneuert" und „Fenstertausch 2018, U-Wert 0,9 W/(m²K), Rechnung und Produktnachweis vorhanden" sind zwei Aussagen über dieselbe Tatsache mit völlig verschiedener Belastbarkeit; nur die zweite trägt in einer Kaufverhandlung und im Streitfall. Für Käufer und Mietinteressenten sinkt damit die Informationsasymmetrie, die den Immobilienmarkt strukturell prägt: Sie können den energetischen Zustand, die Modernisierungshistorie, den verbleibenden Sanierungsbedarf und — über die Dokumentationssäule des Index — die Qualität der Dokumentation selbst einschätzen. Im vorhandenen System ist die technische Grundlage dafür vorhanden: Ein veröffentlichter Pass wird als Momentaufnahme ohne personenbezogene Daten abgelegt, über eine eindeutige Gebäude-ID adressiert und durch eine vierstellige PIN mit gestaffelter Sperre nach Fehlversuchen geschützt; ein QR-Ausdruck und ein Kartenprodukt ergänzen ihn. Die im Bedienkonzept vorgesehenen Freigabepakete je Empfängertyp — also ein eigener Zuschnitt für den Makler, für den Kaufinteressenten, für die Bank — sind konzipiert und noch nicht umgesetzt.

Der Makler sieht ausschließlich das freigegebene Teilpaket. Nicht dazu gehören Rechnungen und Förderbescheide, interne Kostenkalkulationen, Finanzierungs- und Bankunterlagen, nicht freigegebene Entwurfswerte und alle Angaben mit Personenbezug. Artikel 22 EPBD ordnet Kauf- und Mietinteressenten der Zugriffsstufe zu, die nur mit Erlaubnis des Eigentümers geöffnet wird, und empfiehlt ausdrücklich eine Befristung sowie gegebenenfalls eine reine Bildschirmansicht ohne Download. Diese Empfehlung ist für die Praxis wichtiger, als sie klingt: Ein einmal heruntergeladener vollständiger Datensatz lässt sich nicht zurückholen, eine befristete Ansicht schon. Für den Datenbestand bedeutet das, dass die Veröffentlichung ein eigener, dokumentierter Vorgang sein muss — mit Zeitpunkt, Umfang, Empfänger und Ablauf.

Messbar wird der Nutzen an der Zeit von der Beauftragung bis zur vollständigen Objektunterlage, am Anteil der Vermarktungsangaben, die mit einem Beleg unterlegt sind, und an der Zahl der Nachforderungen von Interessenten und finanzierenden Banken. Für den Verkäufer wird zusätzlich messbar, welche Angaben fehlen, bevor der Interessent danach fragt — was in der Sache der wesentliche Vorteil ist.

11.10 Kommunen

Kommunen sind in doppelter Rolle betroffen. Sie besitzen selbst umfangreiche Gebäudebestände — Schulen, Verwaltungsgebäude, Sporthallen, Kindertagesstätten, Feuerwehrhäuser —, die überwiegend älter sind, in unterschiedlichen Ämtern verwaltet werden und deren Zustand oft nur anlassbezogen erhoben wird. Und sie sind zugleich Trägerin der kommunalen Wärmeplanung, für die sie Aussagen über den Gebäudebestand im Gebiet benötigt, der ihr nicht gehört. In beiden Rollen scheitert die Arbeit heute regelmäßig an derselben Stelle: Es existiert keine einheitliche, aktuelle und vergleichbare Datengrundlage, sondern eine Sammlung von Einzelgutachten unterschiedlichen Alters. Haushaltsmittel werden damit auf Basis von Dringlichkeitsmeldungen statt auf Basis eines geordneten Vergleichs verteilt.

Der Gebäudepass kann für die eigenen Liegenschaften das leisten, was für ein einzelnes Wohngebäude beschrieben wurde, nur mit dem entscheidenden Zusatz der Vergleichbarkeit: Wenn alle kommunalen Gebäude nach demselben Verfahren, mit denselben Kennwerten und mit ausgewiesener Datenqualität geführt werden, lassen sie sich nach technischen und energetischen Kriterien priorisieren statt nach Meldungslage. Der regulatorische Druck ist dabei erheblich und terminiert: Ab dem 01.01.2028 müssen Neubauten öffentlicher Einrichtungen Nullemissionsgebäude sein; die Solarpflicht greift für neue öffentliche Gebäude bereits ab dem 31.12.2026 und erfasst den öffentlichen Bestand gestaffelt ab 2 000 m² zum 31.12.2027, ab 750 m² zum 31.12.2028 und ab 250 m² zum 31.12.2030; für alle Gebäude öffentlicher Stellen besteht ohnehin Ausweispflicht. Diese Fristen sind ohne belastbaren Bestandsüberblick nicht planbar, weil schon die Frage, wie viele Gebäude in welche Flächenschwelle fallen, eine Datenauswertung voraussetzt.

Für die Wärmeplanung sieht die EPBD einen eigenen Zugang vor: Artikel 22 EPBD weist Kommunen Gebietsdaten einschließlich einer GIS-Anbindung zu — also aggregierte, raumbezogene Auswertungen des Bestands, nicht gebäudescharfe Einzeldatensätze fremder Eigentümer. Diese Trennung ist die entscheidende Datenschutzlinie dieses Abschnitts: Gebäudescharf und vollständig sieht die Kommune ausschließlich ihre eigenen Liegenschaften, in denen sie selbst Eigentümerin ist; für den übrigen Bestand sieht sie Gebietsdaten mit Geo-Referenz. Nicht Bestandteil des kommunalen Zugangs sind personenbezogene Daten, Eigentümerangaben, Dokumentenbestände privater Gebäude und Verbrauchsdaten einzelner Haushalte. Im vorhandenen System sind die dafür nötigen Bausteine unterschiedlich weit: Eine eindeutige, persistente Gebäude-ID wird vergeben, ein Katasterbezug und eine GIS-Schnittstelle fehlen und sind als offene Punkte geführt. Artikel 22 Absatz 7 EPBD verlangt ausdrücklich Interoperabilität mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern; das ist für kommunale Anwendungen die technisch wichtigste Anforderung des gesamten Artikels.

Messbar wird der Nutzen an der Abdeckung: Anteil der eigenen Liegenschaften mit vollständigem Datensatz und gültigem Ausweis, Anteil mit dokumentiertem Maßnahmenpfad, aggregierter Investitionsbedarf je Haushaltsjahr, Zahl der Gebäude oberhalb der jeweiligen Solar- und Ausweisschwellen. Für die Wärmeplanung wird messbar, welcher Anteil des Gebietsbestands überhaupt mit belastbaren Daten hinterlegt ist — eine Kennzahl, die die Belastbarkeit jeder darauf aufbauenden Planung offenlegt und heute meist unbekannt ist.

11.11 Wohnungsunternehmen

Bei mehreren hundert oder mehreren tausend Gebäuden ändert sich die Aufgabe qualitativ. Eine Dokumentenablage, die für ein Einfamilienhaus ausreicht, wird im Portfolio wertlos, weil niemand tausend Ordner liest. Benötigt werden strukturierte, vergleichbare Merkmale je Objekt — Effizienzklassen, Heizsysteme, Sanierungsstände, Investitionsbedarf, Emissionen —, die sich aggregieren und filtern lassen. Wohnungsunternehmen sind zugleich diejenige Gruppe, die den regulatorischen Bestandspfad unmittelbar spürt: Artikel 9 EPBD verlangt für den Wohngebäudebestand eine Reduktion des durchschnittlichen Primärenergieverbrauchs um 16 % bis 2030 gegenüber 2020 und um 20 bis 22 % bis 2035, wobei mindestens 55 % der bis 2030 zu erbringenden Minderung aus den 43 % schlechtesten Gebäuden stammen müssen. Diese Vorgabe ist der Grund, warum ein Portfolio ohne ein Kennzeichen für die energetisch schlechtesten Objekte nicht steuerbar ist — die Verpflichtung richtet sich nicht auf den Durchschnitt allein, sondern auf einen bestimmten Teil des Bestands.

Der Gebäudepass verschiebt die Portfolioarbeit damit von der Objektbetrachtung zur Bestandssteuerung. Aus einer Verteilung der Effizienzklassen über den Bestand lassen sich Sanierungsprioritäten ableiten; aus den objektbezogenen Maßnahmenpfaden lässt sich ein zeitlich geordneter Investitionsbedarf aggregieren, der die technische Planung mit der Mittelfristplanung verbindet. Der Wert liegt weniger im einzelnen Kennwert als in der Vergleichbarkeit: Erst wenn alle Objekte nach demselben Verfahren, mit derselben Bezugsfläche und mit ausgewiesener Datenqualität gerechnet sind, ist eine Rangfolge belastbar. Genau hier liegt auch eine der praktisch folgenreichsten Umstellungen der deutschen Umsetzung: Die kanonische Bezugsfläche ist die Nutzfläche nach DIN 277 und nicht mehr die bisherige Größe A_N; beide sind ausdrücklich nicht ineinander umrechenbar, sondern verschiedene Größen. Wer ein Portfolio mit gemischten Bezugsflächen vergleicht, vergleicht nicht. Im vorhandenen System ist diese Umstellung vollzogen, die Prüfung nach der Worst-First-Systematik mit den Schwellenwerten des 3,50-Fachen ab 2030 und des 2,95-Fachen ab 2033 ist umgesetzt; eine Aggregationsebene über mehrere Objekte hinweg — also die eigentliche Portfolioansicht — ist konzipiert und nicht umgesetzt. Der Datenbestand ist projektweise organisiert.

Ein Wohnungsunternehmen sieht seinen eigenen Bestand vollständig, benötigt dafür aber eine Rechteordnung nach innen: Die Objektbetreuung sieht andere Felder als das Portfoliomanagement, die Technik andere als der Einkauf. Nicht Bestandteil des Zugangs sind fremde Bestände, personenbezogene Mieterdaten über den betriebsnotwendigen Umfang hinaus und wohnungsbezogene Verbrauchsdaten außerhalb der Abrechnung. Für die Bilanzierung im Portfolio ist zusätzlich zu beachten, dass aggregierte Kennzahlen ihre Herkunft mitführen müssen — eine Portfoliokennzahl, die zur Hälfte auf geprüften und zur Hälfte auf geschätzten Werten beruht, ist ohne diesen Hinweis irreführend, gerade weil sie so einfach aussieht.

Messbar wird der Nutzen an der Datenabdeckung des Portfolios, am Anteil der Objekte mit freigegebenen statt geschätzten Kennwerten, an der Zahl der Objekte in den Worst-Performing-Kategorien und an der Genauigkeit, mit der der Investitionsbedarf der nächsten fünf Jahre vorhergesagt wird. Der letzte Punkt ist der wirtschaftlich bedeutsamste: Ein Investitionsplan, der sich auf dokumentierte Anlagenalter und dokumentierte Bauteilzustände stützt, ist überprüfbar; ein Plan aus Erfahrungswerten ist es nicht.

11.12 Forschung und Statistik

Forschung zum Gebäudebestand arbeitet heute überwiegend mit Stichproben, Einzelstudien und Registerauszügen, die weder einheitlich erhoben noch fortschreibbar sind. Grundlegende Fragen bleiben deshalb schlecht beantwortbar: Welche Einsparung erreichen Sanierungsmaßnahmen tatsächlich im Betrieb, und wie groß ist die Abweichung zwischen berechnetem Bedarf und gemessenem Verbrauch? Welche Jahresarbeitszahlen erreichen Wärmepumpen im Bestand unter realen Bedingungen? Welche Baualtersklassen und Gebäudetypologien tragen den größten Anteil an den Emissionen? Für die amtliche Statistik kommt hinzu, dass die Datenlage für die europäische Berichterstattung heterogen ist. Die EPBD adressiert das ausdrücklich: Artikel 22 EPBD verlangt einen mindestens jährlichen Transfer an das europäische Building Stock Observatory nach den Vorlagen der Durchführungsverordnung (EU) 2025/1328 sowie eine mindestens halbjährliche aggregierte und anonymisierte Veröffentlichung; Forschung erhält Zugang auf Anfrage.

Ein strukturierter Gebäudedatensatz ändert daran die Ausgangslage, weil die Auswertung nicht mehr aus Einzelstudien rekonstruiert werden muss, sondern aus laufend geführten, gleich strukturierten Datensätzen entsteht. Entscheidend ist dabei weniger die Menge als die Mitführung der Metadaten: Ein Datensatz, der zu jedem Wert Herkunft, Methode, Erfassungsdatum und Prüfstatus trägt, erlaubt es, Auswertungen auf geprüfte Werte zu beschränken oder die Ergebnisunsicherheit auszuweisen — beides ist mit anonymisierten Kennwertlisten ohne Metadaten nicht möglich. Für die Bewertung von Sanierungswirkungen ist zusätzlich wertvoll, dass Zustände versioniert vorliegen: Der Vergleich von Vorher- und Nachher-Zustand desselben Gebäudes ist methodisch etwas anderes als der Vergleich zweier Gebäude. Ebenso gehört zur wissenschaftlichen Verwertbarkeit die Offenlegung der Rechengrundlage — welche Normfassung gerechnet wurde, mit welchen Primärenergie- und Emissionsfaktoren und nach welchem Rechtsstand.

Für statistische Zwecke muss die einzelne Immobilie in aller Regel nicht identifizierbar sein. Ausreichend sind Merkmale wie Region, Baualtersklasse, Gebäudetyp, Effizienzklasse, Heizsystem, Flächenklasse und Sanierungsstand. Ausdrücklich nicht Bestandteil des Forschungszugangs sind Adresse und Geokoordinate in gebäudescharfer Auflösung, die Gebäude-ID, Eigentümer- und Bewohnerangaben, Dokumente sowie Kosten- und Finanzierungsdaten. Diese Trennung ist keine Formalie: Bei kleinen Auswertungsgebieten kann bereits die Kombination weniger Merkmale ein Gebäude identifizieren, weshalb Mindestfallzahlen je Auswertungszelle festzulegen sind. Der Rechtsrahmen dafür ergibt sich aus der Datenschutz-Grundverordnung und dem Data Governance Act; die EPBD selbst verlangt abgestuften Zugang, Datenschutz durch Technikgestaltung und die Ermittelbarkeit des Urhebers jeder Änderung für die zuständigen Behörden.

Messbar wird der Nutzen an der Zahl auswertbarer, vollständiger Datensätze je Gebäudetyp und Region, am Anteil der Werte mit dokumentierter Herkunft und Prüfstatus, an der Zahl der Objekte mit Vorher-Nachher-Paaren zu einer Maßnahme und an der Verfügbarkeit gemessener Verbrauchsdaten neben den berechneten Bedarfswerten. Die deutsche Ausgangslage ist dabei nüchtern zu beschreiben: Eine nationale Energieausweis-Datenbank existiert nach dem Stand der Kommissionsunterlagen nicht, das Schema nach Artikel 22 EPBD ist offen. Bis dahin ist jede Auswertung auf freiwillig bereitgestellte, dezentral geführte Bestände angewiesen.

11.13 Weitere Beteiligte

Neben den zehn Hauptzielgruppen entsteht Nutzen für weitere Beteiligte, die im Gebäudelebenszyklus nach Kapitel 10 an definierten Stellen auftreten. Käufer und Mietinteressenten sind hier zuerst zu nennen, weil sie die einzige Gruppe sind, deren Informationsnachteil strukturell ist: Sie entscheiden über die größte Investition ihres Lebens auf Grundlage von Angaben, die die Gegenseite auswählt. Der freigegebene Datensatz mit Herkunftsangaben verringert diesen Nachteil, ohne den Verkäufer zu einer vollständigen Offenlegung zu zwingen — die Freigabe bleibt seine Entscheidung, aber ihr Umfang wird sichtbar.

Handwerksbetriebe benötigen einen eng umrissenen, maßnahmenbezogenen Ausschnitt: Ein Heizungsbauer braucht Heizlast, bestehendes System, Heizflächen und Systemtemperaturen, ein Fensterbauer Abmessungen, Bestandssituation und Anschlussdetails. Liegen diese Angaben belegt vor, verbessern sich Angebotsqualität und Ausführungsplanung, und die Zahl der Nachträge aus unerwarteten Vorfundsituationen sinkt. Förderstellen benötigen die vollständige Prozesskette aus Ausgangszustand, geplanter Maßnahme, technischem Nachweis, ausgeführtem Zustand und Rechnungsinformationen — genau die Kette, die der Gebäudepass ohnehin führt und die heute in getrennten Anträgen mehrfach zusammengestellt wird. Für den individuellen Sanierungsfahrplan ist dabei eine Grenze zu beachten: Ein förderfähiger iSFP entsteht ausschließlich in der amtlichen Druckapplikation der BAFA, die kein maschinelles Importformat veröffentlicht; der Gebäudepass kann die Daten aufbereiten, nicht aber das amtliche Dokument erzeugen.

Behörden schließlich benötigen keinen umfassenden Zugang, sondern einen genau definierten Pflichtdatensatz. Das Grundprinzip lautet: Die Behörde erhält den erforderlichen Datensatz, nicht automatisch den vollständigen Gebäudepass. Im vorhandenen System sind die Pflichtangaben des § 85 GMoDG als eigene, maschinenlesbare Struktur geführt und werden im Export mitgegeben. Produkthersteller können langfristig über eine Produktkennung technische Daten — Leistung, Effizienz, Kältemittel, Datenblatt — bereitstellen und damit manuelle Eingaben ersetzen; eine entsprechende Schnittstelle, auch zur europäischen Produktdatenbank EPREL, ist in der eigenen Planung als offener Punkt geführt und nicht umgesetzt.

11.14 Netzwerkeffekt, Grenzen und Übersicht

Über alle Zielgruppen hinweg wirkt ein Effekt, der den Wert des Datenbestands mit seiner Nutzung verknüpft. Je häufiger ein Gebäudepass im Zuge realer Vorgänge — Beratung, Sanierung, Wartung, Verkauf, Finanzierung — aktualisiert wird, desto vollständiger wird der Datensatz; je vollständiger er ist, desto mehr Anwendungen lassen sich darauf stützen; und je mehr Anwendungen ihn nutzen, desto häufiger wird er aktualisiert. Dieser Kreislauf ist der eigentliche Grund, warum ein gemeinsamer Datenkern einer Sammlung getrennter Fachdatenbanken überlegen ist: In getrennten Beständen erzeugt jede Nutzung Aufwand, im gemeinsamen Bestand erzeugt jede Nutzung zusätzlich Wert. Derselbe Mechanismus erklärt auch den Unterschied zwischen Dokumentenwert und Datenwert. Ein einzelner Energieausweis hat einen fest umrissenen Informationswert für einen Anlass. Derselbe Datensatz, aus dem er erzeugt wurde, trägt gleichzeitig die Energieberatung, den Förderantrag, die Finanzierung, die Sanierungsplanung, den Verkauf und die Verwaltung.

Der Effekt hat allerdings zwei Voraussetzungen, die nicht von selbst eintreten. Die erste ist die Rechteschicht: Ohne durchgesetzte Rollen und protokollierte Freigaben lässt sich ein gemeinsamer Datenbestand nicht mehreren Parteien öffnen, ohne den Datenschutz zu verletzen — genau diese Schicht ist am 23. August 2026 gebaut worden und trägt seither. Die zweite ist die Datenpflege: Ein Datensatz, der nicht aktualisiert wird, veraltet schneller, als er Nutzen stiftet, und ein veralteter Wert mit hoher Vertrauensstufe ist gefährlicher als ein fehlender Wert. Deshalb gehören die Kennzeichnung veralteter Ergebnisse, die automatische Neuberechnung abhängiger Größen und die Konflikterzeugung statt stiller Überschreibung zu den Kernfunktionen und nicht zum Beiwerk. Der dritte, oft übersehene Punkt ist die Erwartungssteuerung: Der Gebäudepass senkt keine Energiekosten, verbessert keine Bonität und erhöht keinen Verkehrswert. Er verbessert die Grundlage, auf der über all das entschieden wird — nicht mehr, aber auch nicht weniger.

Die folgende Übersicht fasst die Zielgruppen dieses Kapitels zusammen. Sie nennt je Gruppe den Kernnutzen, die dafür benötigten Daten, den vorgesehenen Zugriffsumfang und die Voraussetzung, die für diesen Zugriff erfüllt sein muss. Die Spalte „Voraussetzung" ist dabei die wichtigste: Sie unterscheidet die Zeilen, die heute bereits tragen, von denen, die eine noch nicht vorhandene Rechte-, Schnittstellen- oder Registerfunktion benötigen.

Die Tabelle zeigt zweierlei. Erstens unterscheiden sich die Zielgruppen weniger im benötigten Datenmodell als im Ausschnitt und in der Aufbereitung — die Spalte „Benötigte Daten" enthält durchweg Teilmengen desselben Bestands, nicht verschiedene Bestände. Das bestätigt die Ausgangsthese dieses Kapitels: Es sind keine getrennten Gebäudedatenbanken je Nutzergruppe erforderlich. Zweitens fällt auf, dass in der Spalte „Voraussetzung" fast durchgängig dieselben drei Bedingungen wiederkehren — eine durchgesetzte Rechteschicht, eine belastbare Schnittstelle nach außen und ein nationales Register, an das angeschlossen werden kann. Die inhaltliche Arbeit an den Zielgruppen ist damit weiter fortgeschritten als die infrastrukturelle. Kapitel 12 ordnet diesen Befund den einzelnen EPBD-Anforderungen zu, Kapitel 13 bewertet den Reifegrad, und Kapitel 14 leitet daraus die Entwicklungsschritte ab.

Zusammenfassend lässt sich der strategische Wert des digitalen Gebäudepasses nicht aus dem Nutzen einer einzelnen Zielgruppe ableiten. Der Eigentümer nutzt ihn zur Entscheidung, der Energieberater zur Berechnung, der Architekt und der TGA-Planer zur Planung, die Hausverwaltung zum Betrieb, die Bank zur Risikobeurteilung, der Versicherer zur Zustandsbeurteilung, der Makler zur Transaktion, die Kommune zur Priorisierung, das Wohnungsunternehmen zur Portfoliosteuerung und die Forschung zur Auswertung. Der Wert entsteht daraus, dass sie alle auf denselben versionierten, mit Herkunftsangaben versehenen und qualitätsgesicherten Gebäudedatenbestand zugreifen — und dass jede Nutzung diesen Bestand verbessert, statt ihn zu duplizieren. In diesem Sinn ist der Gebäudepass weniger ein Produkt als eine gemeinsame Informationsinfrastruktur rund um die Immobilie.

12 EPBD-Anforderungsmatrix für den digitalen Gebäudepass

Dieses Kapitel führt zusammen, was die vorangegangenen Kapitel getrennt behandelt haben: die Anforderungen der Richtlinie (EU) 2024/1275 auf der einen, die Datenstruktur und die Funktionen des digitalen Gebäudepasses auf der anderen Seite. Es beantwortet für jeden einschlägigen Artikel und jeden einschlägigen Anhang der Richtlinie dieselben acht Fragen: Was wird verlangt, welche Gebäudedaten setzt das voraus, welche Funktion des Gebäudepasses bedient es, wie weit ist diese Funktion, worauf beruht die Pflicht und bis wann gilt sie, was fehlt noch, und über welche Schnittstelle verlässt das Ergebnis das System. Die Matrix ist damit kein Überblick, sondern ein Arbeitsdokument — sie soll unbequem sein, wo der Entwicklungsstand hinter der Anforderung zurückbleibt.

12.1 Aufbau, Statusskala und Lesart der Matrix

Eine Anforderungsmatrix ist nur so belastbar wie die Regeln, nach denen sie ausgefüllt wird. Drei Festlegungen bestimmen deshalb die folgenden fünf Tabellen. Erstens stammen sämtliche Artikel, Anhänge, Fristen und Rechtsgrundlagen aus der konsolidierten Fassung der Richtlinie und den zugehörigen Rechtsakten — der Delegierten Verordnung (EU) 2026/52 zum Anhang III, der Durchführungsverordnung (EU) 2025/1328 zum Datentransfer und den Kommissions-Leitlinien C/2025/6438 — sowie aus dem deutschen Gebäudemodernisierungsgesetz. Zweitens stammt die Statusbewertung ausschließlich aus dem dokumentierten Stand der eigenen Entwicklung; wo ein Beleg fehlt, wird der niedrigere Status vergeben, nicht der wohlwollendere. Drittens werden vier Daten strikt getrennt: Veröffentlichung, Inkrafttreten, Anwendung und Produktivsetzung. Ein veröffentlichter Rechtsakt ist keine anwendbare Pflicht, und eine anwendbare Pflicht ist noch keine produktive Funktion.

Der Rohentwurf dieses Kapitels arbeitete mit einem sechsstufigen Reifegradmodell von „nicht vorhanden" bis „vollständig integriert". Ein solches Modell beschreibt technische Entwicklungstiefe, beantwortet aber nicht die Frage, die ein Prüfer, eine Bank oder ein Ministerium stellt: Ist die Anforderung erfüllt oder nicht, und wenn nicht — woran liegt es. Die Matrix verwendet deshalb eine fünfwertige Statusskala, die den Grund der Nichterfüllung mitführt:

• erfüllt — die Anforderung ist im vollen Umfang der Rechtsnorm umgesetzt, belegt und geprüft. Dieser Status wird nur vergeben, wenn kein Bestandteil der Anforderung aussteht.
• teilweise — wesentliche Bestandteile sind umgesetzt und produktiv, einzelne Felder, Formate oder Prüfschritte fehlen. Dies ist der Regelfall bei Funktionen, die fachlich vorhanden, aber noch nicht auf die Formulierung der Richtlinie abgebildet sind.
• konzipiert — die Anforderung ist fachlich durchdrungen und in Pflichtenheft, Datenmodell oder Leitfaden beschrieben, aber nicht implementiert.
• offen — weder Datenstruktur noch Funktion vorhanden; die Umsetzung liegt vollständig in eigener Hand.
• extern blockiert — die Umsetzung hängt an einer noch nicht veröffentlichten nationalen Spezifikation. Der Entwicklungsaufwand ist erst bestimmbar, wenn diese Spezifikation vorliegt; eigene Vorleistungen können die Blockade nicht auflösen.

Die Trennung zwischen „offen" und „extern blockiert" ist die eigentliche Arbeitsleistung dieser Matrix. „Offen" bezeichnet Rückstand, der geplant und abgearbeitet werden kann. „Extern blockiert" bezeichnet Rückstand, der nicht durch mehr Entwicklungsleistung verschwindet — hier ist die richtige Reaktion, die Datenstruktur so vorzubereiten, dass die spätere Spezifikation nur noch abgebildet werden muss, und die Wartezeit nicht als eigenes Versäumnis auszuweisen. Wer beides vermischt, plant entweder Ressourcen für unlösbare Aufgaben ein oder verdeckt echten Rückstand hinter dem Verweis auf den Gesetzgeber.

Die Spalte „Schnittstelle" nennt den Weg, auf dem das Ergebnis den Gebäudepass verlässt oder Daten in ihn hineingelangen. Sie ist bewusst technisch gehalten, weil sich an ihr entscheidet, ob eine Anforderung überhaupt nachweisbar erfüllt werden kann: Eine Berechnung, deren Ergebnis nur auf dem Bildschirm erscheint, erfüllt keine Registerpflicht. Wo die Schnittstelle „intern" lautet, verbleibt das Ergebnis vorerst im System. Wo sie „noch nicht definiert" lautet, ist die Zielschnittstelle Gegenstand einer ausstehenden externen Festlegung.

Die Matrix ist nach fünf Anforderungsbereichen gegliedert, die den Aufbau der Richtlinie nachzeichnen: Energieausweis und Register (Artikel 19 bis 22 mit den Anhängen V und VI), Renovierungspass und Sanierung (Artikel 9 und 12 mit Anhang VIII), Anlagen, Automation und Betrieb (Artikel 10, 13, 14, 15, 23 und 24), Lebenszyklus und Emissionen (Artikel 7 und 11 mit Anhang III) sowie Daten, Zugriff und Fristen (Artikel 16, 22 und 35). Mehrere Artikel erscheinen mehrfach, weil sie mehrere trennbare Pflichten enthalten; Artikel 19 etwa regelt Skala, Inhalt, Empfehlungen, Aktualisierung, Gültigkeit und Form in einem einzigen Artikel, und diese sechs Pflichten haben sehr unterschiedliche Umsetzungsstände. Eine Zeile je Artikel wäre deshalb nicht präziser, sondern unbrauchbar.

12.2 Energieausweis und Register

Der Energieausweis ist die am dichtesten geregelte Funktion der gesamten Richtlinie und zugleich diejenige, für die der Gebäudepass die größte fachliche Vorleistung mitbringt. Die Berechnungskerne nach DIN V 18599 sind vorhanden und gegen 34 Validierungsfälle mit 964 Einzelgrößen ohne Toleranzüberschreitung geprüft; der Bedarfsausweis wird bei vollständigem Energiekern automatisch als Dokument erzeugt und bei geänderter Endenergie neu versioniert. Genau deshalb ist dieser Bereich der aufschlussreichste: Wo eine Anforderung hier nicht erfüllt ist, liegt es fast nie an fehlender Rechenfähigkeit, sondern an fehlenden Feldern, fehlenden Formaten und fehlenden Registern. Drei Befunde prägen den Bereich. Der Ausweis des Gebäudepasses arbeitet mit der deutschen Klassenlogik von A+ bis H, während Artikel 19 Absatz 2 seit dem 29.05.2026 eine geschlossene Skala von A bis G verlangt, bei der A für das Nullemissionsgebäude reserviert ist — ein Gebäude mit Gaskessel, das rechnerisch A erreicht, wird auf B eingestuft. Die Ausweisnummer ist eine deterministisch aus der Gebäude-ID abgeleitete interne Kennung und ausdrücklich keine amtliche Registriernummer. Und für Nichtwohngebäude sind die deutschen Klassengrenzen B bis F noch nicht veröffentlicht; die Klassenfunktion gibt zwischen A und G bewusst keinen Wert zurück, statt eine Zahl zu erfinden. Diese Zurückhaltung ist fachlich richtig und schlägt in der Matrix trotzdem als Blockade zu Buche.

Die Auswertung dieser 21 Zeilen ergibt ein klares Muster: elf Zeilen stehen auf „teilweise", fünf auf „offen", vier auf „extern blockiert", eine auf „konzipiert" — keine einzige auf „erfüllt". Das ist bemerkenswert, weil gerade der Energieausweis die technisch reifste Funktion des Gebäudepasses ist. Der Grund liegt nicht in der Rechenkette, sondern in ihrer Peripherie. Vollständigkeit setzt in diesem Bereich fast immer etwas voraus, das nicht berechnet, sondern vereinbart wird: eine Klassengrenze, ein Ausweismuster, eine Registriernummer, ein Übergabeprofil. Von den vier extern blockierten Zeilen führen drei auf dieselbe Wurzel — das Fehlen einer nationalen Ausweis- und Registerspezifikation. Die vierte, die Klassenskala für Nichtwohngebäude, wirkt darüber hinaus in den Renovierungspass hinein, weil dessen Anhang VIII für jeden Sanierungsschritt eine Zielklasse verlangt.

Für die Entwicklungsplanung folgt daraus eine unbequeme, aber nützliche Reihenfolge. Die fünf offenen Zeilen — Demand-Response- und Niedertemperaturkennzeichen, das Vier-Schritt-Verfahren zur Niedertemperatur-Eignung, die Restlebensdauer, die Ausweismetadaten und die One-Stop-Shop-Einladung — liegen vollständig in eigener Hand und sind ohne jede externe Vorgabe umsetzbar. Sie sind zugleich Voraussetzung dafür, dass der Ausweisdatensatz überhaupt die Felder enthält, die ein künftiges Registerschema abfragen wird. Wer stattdessen auf die Veröffentlichung des Schemas wartet, verliert die Vorlaufzeit zweimal: einmal beim Warten und einmal bei der dann erforderlichen Nacherfassung im Bestand.

12.3 Renovierungspass und Sanierung

Der Renovierungspass nach Artikel 12 ist die Anforderung mit der größten Feldtiefe und zugleich diejenige mit der klarsten Struktur: Anhang VIII listet in Nummer 1 zehn Pflichtbestandteile, von denen einer — Buchstabe e — noch einmal fünf Pflichtfelder je Sanierungsschritt enthält. Diese Kleinteiligkeit ist der Grund, warum die Zeilen dieser Tabelle enger geschnitten sind als in den übrigen Bereichen: Ein pauschales „Sanierungsmodul teilweise vorhanden" verdeckt genau die Felder, an denen die Umsetzung scheitert. Der Gebäudepass bringt für diesen Bereich erhebliche Vorleistung mit — Bilanzierung des Ist-Zustands, Sanierungs-Baukosten mit einer eigenen Spalte für Sowieso-Anteile, Wirtschaftlichkeits- und Förderrechner, Maßnahmen- und Finanzierungsbericht aus dem Dokumentengenerator sowie ein iSFP-Datenblatt als Ausgabe. Zwei Abgrenzungen sind dabei strikt einzuhalten. Erstens ist der individuelle Sanierungsfahrplan kein Renovierungspass im Sinne des Artikels 12; die Kommissions-Leitlinien nennen ihn zweimal als Best-Practice-Vorbild, nicht als Umsetzung, und ob Deutschland ihn formal zum Renovierungspass erklärt, ist nicht entschieden. Nicht abgedeckt sind insbesondere die Änderung der operativen Treibhausgase je Schritt, Zirkularität und Whole-Life-Carbon sowie die Liste der nationalen Stichtage. Zweitens entsteht ein förderfähiger Sanierungsfahrplan ausschließlich in der amtlichen Druckapplikation; das eigene Ausgabe-Datenblatt trägt diesen Vermerk, und ein maschinelles Importformat wird von amtlicher Seite nicht veröffentlicht. Der Renovierungspass ist deshalb als eigenständiges Feldmodell nach Anhang VIII zu bauen und nicht als Erweiterung des Sanierungsfahrplans.

Diese 21 Zeilen ergeben eine Verteilung von einer Zeile „erfüllt", 13 Zeilen „teilweise", zwei „konzipiert", zwei „offen" und drei „extern blockiert". Der Renovierungspass ist damit der Bereich mit dem höchsten Anteil angefangener, aber unvollendeter Umsetzung — und zugleich der einzige Bereich mit einer vollständig erfüllten Zeile. Diese Kombination ist charakteristisch: Die Bilanzierung des Ist-Zustands nach Anhang VIII Nummer 1 Buchstabe a ist geprüft, versioniert und mit Normstandstempel versehen; alles, was darüber hinaus verlangt wird, betrifft nicht die Rechnung, sondern die Struktur des Ergebnisses. Anhang VIII verlangt einen Pfad aus benannten Schritten mit je fünf Pflichtfeldern. Der Gebäudepass führt heute Maßnahmen und Kosten, aber keine versionierten Zwischenzustände — und ohne solche Zwischenzustände lässt sich die geforderte Änderung „gegenüber dem Zustand vor dem Schritt" nicht ausweisen, sondern nur die Differenz zum Ausgangszustand.

Der kritische Pfad dieses Bereichs führt deshalb nicht über neue Rechenverfahren, sondern über ein Datenobjekt: den versionierten Gebäudezustand. Aus ihm folgen unmittelbar sieben Zeilen — Roadmap, Änderung der Energie, Änderung der Emissionen, Kostenersparnis, Zielklasse, Zielzustandsprüfung und Renovierungshistorie. Diese Investition ist auch deshalb vorrangig, weil sie den in Kapitel 11 beschriebenen Vergleich zwischen geplantem Renovierungspfad und tatsächlich durchgeführter Sanierung überhaupt erst ermöglicht. Die drei extern blockierten Zeilen dagegen — Zielklasse für Nichtwohngebäude, Upload in die Datenbank, Mindeststandards für Nichtwohngebäude — sind mit Vorleistung nicht zu beschleunigen; für sie ist die richtige Vorbereitung, die betroffenen Felder anzulegen und leer zu lassen, statt sie mit Behelfswerten zu füllen.

12.4 Anlagen, Automation und Betrieb

Dieser Bereich unterscheidet sich grundlegend von den beiden vorangegangenen. Ausweis und Renovierungspass beschreiben ein Gebäude zu einem Stichtag; Artikel 13, 14, 15, 23 und 24 beschreiben seinen laufenden Betrieb. Der Gebäudepass ist heute ein Planungs- und Nachweiswerkzeug und kein Betriebssystem: Er kennt Anlagen als Auslegungsobjekte mit Leistung, Effizienz und Jahresarbeitszahl, aber nicht als Geräte mit Wartungsterminen, Inspektionsberichten, Störmeldungen und Messwerten. Dieser Bruch ist im Vertrauensindex unmittelbar sichtbar: Die Säule Wartungszustand geht mit zehn Prozent in die Gesamtbewertung ein und liefert derzeit strukturbedingt null Punkte, weil Dokumente und Wartungen nicht verdrahtet sind. Ein Gebäude kann in dieser Systematik also keine gute Bewertung erreichen, gleich wie sorgfältig es gewartet wird — nicht weil die Bewertung streng wäre, sondern weil die Datenquelle fehlt. Hinzu kommt eine Besonderheit, die Kapitel 8 bereits regulatorisch behandelt hat: Die Leistungsschwelle, ab der Pflichten zur Gebäudeautomation und zur Inspektion greifen, ist in den Quellen umstritten, und die eigene Implementierung führt hier einen Wert, der zu prüfen ist.

Von den elf Zeilen dieses Bereichs stehen vier auf „teilweise", fünf auf „offen", eine auf „konzipiert" und eine auf „extern blockiert" — es ist damit der Bereich mit dem höchsten Anteil vollständig offener Anforderungen. Die Ursache ist einheitlich und deshalb gut adressierbar: Es fehlt kein Rechenverfahren, sondern eine Objektklasse. Solange Anlagen ausschließlich als Auslegungsgrößen geführt werden, lassen sich Inspektionen, Wartungen, Systembewertungen nach Einbau, Restlebensdauern und Monitoringdaten nirgends ablegen. Fünf der elf Zeilen — Inspektion Heizung, Inspektion Klima, Systembewertung nach Einbau, Restlebensdauer und Wartungshistorie — hängen an genau einem Datenobjekt: einem Anlagenereignis mit Datum, Ergebnis, Prüfer und Belegverweis. Die dafür notwendigen Bausteine sind vorhanden, denn die Beleg-Beziehung zwischen Dokument und Datensatz und die Versionierung der Werte gehören bereits zum Datenmodell; verbunden sind sie mit den Anlagen noch nicht.

Die einzige extern blockierte Zeile ist die Bewertung der Intelligenzfähigkeit nach Artikel 15 — und sie ist zugleich die Zeile, bei der Zurückhaltung die wirtschaftlich richtige Entscheidung ist. Eine Pflicht entsteht erst durch einen delegierten Rechtsakt, der bis zum 30.06.2027 zu erlassen ist, und dann ausschließlich für Nichtwohngebäude über 290 kW. Bis dahin bleibt der Indikator im Ausweis ein Feld ohne Inhaltspflicht. Eine eigene Bewertungslogik jetzt zu entwickeln, hieße, eine Systematik zu erfinden, die später durch eine amtliche ersetzt würde. Sinnvoll ist allein, die Merkmale — Automationsumfang, Regelungsfunktionen, Zähler, steuerbare Verbraucher, Speicher, Ladeinfrastruktur — strukturiert zu erfassen, damit die spätere Bewertung darauf zugreifen kann. Dasselbe gilt für den Abgleich zwischen berechnetem Bedarf und gemessenem Verbrauch, der in mehreren Kapiteln dieses Whitepapers als Zielbild erscheint: Er setzt das Messdatenmodell aus Artikel 13 Absatz 11 voraus und ist ohne dieses nicht erreichbar.

12.5 Lebenszyklus und Emissionen

Mit Artikel 7 und dem in der Fassung der Delegierten Verordnung (EU) 2026/52 gefassten Anhang III tritt eine Größe in den Energieausweis, die bisher nicht Gegenstand der Gebäudeenergiebilanz war: das Treibhauspotenzial über den gesamten Lebenszyklus. Die Systemgrenzen sind eng gefasst — Bewertung nach EN 15978, Bezugszeitraum 50 Jahre, Einheit Kilogramm CO₂-Äquivalent je Quadratmeter Nutzfläche nach internationalem Flächenstandard, Bilanzstand nach Fertigstellung, mit Schätzung vor Baubeginn und Bestätigung danach. Pflicht sind die Module A1 bis A5, B1 bis B4, B6 sowie C1 bis C4, D1 und D2; im Ausweis ist je Phasengruppe getrennt auszuweisen. Der Gebäudepass bringt hier eine wichtige strukturelle Vorleistung mit, die leicht übersehen wird: Er führt drei getrennte Emissionsdarstellungen — die Emissionen aus dem Ausweis, die automatisch ermittelte Betriebsbilanz und die Ökobilanz — und bildet ausdrücklich keinen zusammengeführten Gesamtwert; ein eigener Prüffall des Funktionswächters sichert diese Trennung ab. Das entspricht genau der Trennung, die Anhang V zwischen operativen Emissionen und Treibhauspotenzial verlangt. Was fehlt, ist der Inhalt der dritten Darstellung: Für die grauen Emissionen setzt das Nachhaltigkeitsmodul heute einen geschätzten Vergleichswert von 500 kg/m² an, und die echte Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen ist im Entwicklungsleitfaden ausdrücklich als offen geführt — ebenso die Unterscheidung der Bilanzlogik zwischen Neubau und Sanierung.

Die 13 Zeilen dieses Bereichs verteilen sich auf vier „teilweise", sechs „offen" und drei „extern blockiert" — keine erfüllte Zeile, und zugleich der Bereich mit dem klarsten Zeitdruck. Die Pflicht zur Ausweisung des Treibhauspotenzials für Neubauten über 1 000 m² beginnt am 01.01.2028; das sind vom Stand dieses Whitepapers aus rund 16 Monate. Anders als bei Register und Klassenskala liegt die dafür entscheidende Arbeit nicht bei nationalen Stellen: Systemgrenzen, Bezugszeitraum, Pflichtmodule, Einheit und Datenhierarchie stehen in Anhang III bereits fest, und die Leitlinien enthalten mit dem Standard-Gebäudedokument sogar eine maschinenlesbare Feldliste. Blockiert sind nur die Grenzwerte selbst — und die entscheiden über Einhaltung, nicht über Berechenbarkeit. Der Nachweis lässt sich also vollständig aufbauen, bevor bekannt ist, welcher Wert einzuhalten sein wird.

Die kritische Abhängigkeit ist dabei die Materialaufstellung. Ohne Mengen je Material bleibt jede Lebenszyklusbilanz ein Vergleichswert, und ein geschätzter Benchmark von 500 kg/m² erfüllt keine Nachweispflicht — er ist als Orientierungsgröße redlich, solange er als solche gekennzeichnet ist, aber er ist kein Ergebnis. Die Geometrie- und Bauteildaten des Gebäudepasses reichen für eine Ableitung grundsätzlich aus; der Import von Bauwerksmodellen ist vorhanden, allerdings ausdrücklich als Eingang ohne Ausgang gekennzeichnet. Der Weg von der vorhandenen Geometrie über eine Materialaufstellung zu einer modulgegliederten Bilanz ist damit die zentrale Entwicklungsaufgabe dieses Bereichs — und sie zahlt zugleich auf zwei Zeilen des Renovierungspasses ein, weil Anhang VIII Zirkularität und Whole-Life-Carbon auf derselben Datengrundlage verlangt.

12.6 Daten, Zugriff und Fristen

Der letzte Bereich der Matrix betrifft nicht mehr den Inhalt der Gebäudedaten, sondern ihren Umgang: wer sie bekommt, in welcher Form sie das System verlassen, wer eine Änderung zu verantworten hat und ab wann eine Pflicht überhaupt gilt. Hier liegen zwei sehr ungleiche Befunde nebeneinander. Auf der einen Seite steht die stärkste dokumentierte Vorleistung des gesamten Systems: eine Governance-Schicht mit Vertrauensstufen, vier Datenzuständen von Entwurf bis Freigegeben, Wertversionierung und einem Vier-Augen-Prinzip, bei dem eine Meldung den offiziellen Wert nicht verändert und erst die Freigabe in den führenden Pfad schreibt; dazu die Herkunftskennzeichnung je Wert, ein Objektgraph mit Belegbeziehungen, eine Neuberechnungslogik, die betroffene Ergebnisse als veraltet markiert, und eine Norm- und Rechtsstandregistry, die jedem Ergebnis einen Stempel mitgibt. Auf der anderen Seite stand hier lange die größte Lücke: ein abgestuftes Zugriffsrollenmodell, das nach eigener Dokumentation nicht existierte. Was es gab, waren Anzeigerollen der Kennwerteseite, die die Reihenfolge der dargestellten Werte für Architekten, Makler, Hausverwaltungen, Fachplaner, Banken und Energieberater priorisieren — eine Darstellungshilfe, ausdrücklich keine Rechteschicht. Artikel 16 und Artikel 22 verlangen aber genau eine Rechteschicht, und zwar mit unterschiedlichen Stufen für Eigentümer, Mieter, Verwalter, Finanzinstitute, unabhängige Fachleute, Kauf- und Mietinteressenten, Kommunen, Öffentlichkeit und Forschung. Sie ist am 23. August 2026 gebaut worden: zehn Rollen auf einer siebenstufigen Leseleiter, getrennte Rechte für Schreiben, Melden, Freigeben und Exportieren, Sichtbarkeit bis auf die Feldebene, befristete und widerrufbare Zugänge, vollständiges Zugriffsprotokoll. Von den in den Artikeln genannten Adressaten fehlen noch der Mieter, die Kommune und die Forschung; die beiden letzten setzen ohnehin die nationale Datenbank voraus.

Diese 16 Zeilen verteilen sich auf eine erfüllte Zeile, acht „teilweise", fünf „offen" und zwei „extern blockiert". Die einzige erfüllte Zeile ist die Nachvollziehbarkeit der Berechnungsgrundlage — und sie verdient Beachtung, weil sie zeigt, wie eine vollständig erfüllte Anforderung aussieht: nicht als große Funktion, sondern als konsequent durchgehaltene Kleinigkeit. Jedes Ergebnis trägt einen Stempel mit Normfassung und Rechtsstand; die Registry unterscheidet Überlagerung, Unverändertes und Lücke; hartkodierte Faktoren wurden entfernt; die Entscheidung, verbindlich nach der Ausgabe 2018 zu rechnen und die Ausgabe 2025 als Vergleich mitzuführen, ist umgesetzt statt nur beschlossen. Genau diese Bauweise — ein Parameter mit Herkunft statt einer verstreuten Konstante — ist das Muster, das den übrigen Zeilen der Matrix fehlt.

Die schwerste Lücke des Bereichs hing lange an einer einzigen Schicht: einem durchgesetzten Rollen- und Freigabemodell. Sieben Zeilen dieser Tabelle — Weitergabe an Dritte, Zugriffsstufen, Portfoliozugang der Finanzinstitute, Gebietsdaten der Kommunen, Datenschutzvorprüfung, Ermittelbarkeit des Urhebers und der Mindestumfang nach Artikel 16 — waren davon abhängig. Diese Schicht ist seit dem 23. August 2026 gebaut, und die Feststellung, sie sei nicht extern blockiert, hat sich damit bestätigt: Kein Ministerium, kein Rechtsakt und keine Norm hat sie aufgehalten. Vier der sieben Zeilen hängen nicht mehr an ihr: der direkte Zugang nach Artikel 16, die Weitergabe an selbst benannte Dritte, die abgestuften Zugriffsstufen und der Portfoliozugang der Finanzinstitute laufen jetzt über befristete, widerrufbare und protokollierte Rollenzugänge. Sie stehen deshalb auf teilweise und nicht auf erfüllt, weil ihnen je ein eigener Rest fehlt, der mit der Rechteschicht nichts zu tun hat — die Mieterrolle, das empfängerbezogene Freigabepaket, die Anbindung an die nationale Datenbank und die Portfoliosicht über mehrere Gebäude. Das Vier-Augen-Prinzip der Governance-Schicht ist keine bloße Verabredung mehr, weil das Freigaberecht ein eigenes, vergebbares Recht ist. Die verbleibenden drei Zeilen sind keine Codefragen: Datenschutzvorprüfung, Zweckbindung der Freigabe und Gebietsdaten der Kommunen verlangen dokumentarische und organisatorische Arbeit, und sie sind damit der neue Schwerpunkt dieses Bereichs.

12.7 Auswertung der Matrix

Die fünf Tabellen enthalten zusammen 82 Anforderungszeilen. Ihre Verteilung auf die Statusskala lautet: zwei Zeilen erfüllt, 40 Zeilen teilweise, vier Zeilen konzipiert, 23 Zeilen offen und 13 Zeilen extern blockiert. In Anteilen sind das rund zwei Prozent erfüllt, 49 Prozent teilweise, fünf Prozent konzipiert, 28 Prozent offen und 16 Prozent extern blockiert. Nach Bereichen verteilt: Energieausweis und Register 21 Zeilen ohne erfüllte Zeile, Renovierungspass und Sanierung 21 Zeilen mit einer erfüllten, Anlagen und Betrieb elf Zeilen, Lebenszyklus und Emissionen 13 Zeilen und Daten, Zugriff und Fristen 16 Zeilen mit einer erfüllten.

Diese Zahlen sind zunächst zu deuten, bevor sie verwendet werden. Ein Anteil von zwei Prozent erfüllter Zeilen wirkt vernichtend und ist es nicht. Er misst nicht, wie viel Software vorhanden ist, sondern wie viele Anforderungen der Richtlinie in ihrem vollen Wortlaut abgeschlossen sind. Der Status „erfüllt" wurde nach der eingangs festgelegten Regel nur vergeben, wenn kein Bestandteil einer Anforderung aussteht — und die Anforderungen der EPBD enthalten fast durchweg einen Bestandteil, der nicht in einer Berechnung besteht, sondern in einem Format, einem Register, einer Rolle oder einer Frist. Aussagekräftiger als die Zahl der erfüllten Zeilen ist deshalb der Anteil von 49 Prozent „teilweise": In knapp der Hälfte aller Anforderungen ist die fachliche Substanz vorhanden und arbeitet produktiv, und es fehlt der Abschluss. Nur 23 von 82 Anforderungen berühren einen Bereich, in dem gar nichts vorliegt.

Die kritischen Pfade lassen sich aus den Abhängigkeiten zwischen den Zeilen ablesen, nicht aus ihrer Anzahl. Fünf Pfade bündeln den überwiegenden Teil des Entwicklungsbedarfs. Erstens das durchgesetzte Rollen- und Freigabemodell: Es entscheidet über sieben Zeilen der fünften Tabelle und wirkt zusätzlich auf die Nachweisbarkeit des Kontrollsystems nach Anhang VI. Zweitens der versionierte Gebäudezustand: Aus ihm folgen sieben Zeilen des Renovierungspasses, weil Anhang VIII sämtliche Änderungen gegenüber dem Zustand vor dem jeweiligen Schritt verlangt und nicht gegenüber dem Ausgangszustand. Drittens das Anlagenereignis mit Datum, Ergebnis, Prüfer und Belegverweis: Es löst fünf Zeilen der dritten Tabelle und macht zugleich die Wartungssäule des Vertrauensindex überhaupt erst bewertbar, die bislang strukturbedingt null Punkte liefert. Viertens die Materialaufstellung: Sie trägt vier Zeilen der vierten Tabelle und zwei weitere des Renovierungspasses und steht unter dem engsten Zeitdruck, weil die Nachweispflicht für das Treibhauspotenzial am 01.01.2028 beginnt. Fünftens das Übergabeprofil für Registerrohdaten: Es ist die aufwandsärmste der fünf Aufgaben, weil sämtliche verlangten Größen bereits im kanonischen Datensatz liegen und nur zusammengestellt werden müssen.

Ausdrücklich nicht in eigener Hand liegen 13 Zeilen. Sie verteilen sich auf vier Ursachen, die sich nicht gegenseitig ersetzen. Die erste und folgenreichste ist die fehlende Klassenskala für Nichtwohngebäude: Sie blockiert unmittelbar die Klassenermittlung, mittelbar die Zielklasse je Sanierungsschritt und die Prüfung gegen die nationalen Mindeststandards. Die eigene Software reagiert darauf richtig, indem die Klassenfunktion zwischen A und G bewusst keinen Wert liefert, statt eine plausible Zahl zu erfinden — die Lücke ist in der Registry als solche geführt. Die zweite Ursache ist die fehlende nationale Gebäudedatenbank; Deutschland führt nach Anhang 5 der Kommissions-Leitlinien bislang keine Ausweisdatenbank, weshalb Registrierung, Upload des Renovierungspasses und die Weitergabe an das europäische Beobachtungssystem gleichermaßen ohne Ziel bleiben. Die dritte Ursache ist die noch nicht veröffentlichte Detailspezifikation der deutschen Umsetzung — amtliches Ausweismuster, Registriernummer, Datenformat des Lebenszyklusberichts, Nachweis für Nullemissionsgebäude, Kontrolldateischema für Monatswerte. Die vierte Ursache liegt auf europäischer Ebene: die Durchführungsakte zur Interoperabilität des Datenzugriffs, deren Frist bereits am 31.12.2025 abgelaufen ist, und der delegierte Rechtsakt zur Intelligenzfähigkeit, der bis zum 30.06.2027 zu erlassen ist.

Für alle vier Ursachen gilt dieselbe Handlungsregel, und sie ist das praktische Ergebnis dieser Matrix: Vorbereiten, nicht ersetzen. Die betroffenen Felder werden angelegt und bleiben leer; die Schwellenwerte werden als benannte Parameter mit Herkunftsangabe geführt und nicht als Konstanten verstreut; jede Ausgabe nennt die verwendete Grundlage. Wo diese Regel eingehalten wurde, ist die spätere Anbindung eine Konfigurationsaufgabe. Wo sie verletzt wurde, entsteht der Fall, den das Modul zur Gebäudeautomation zeigt: ein Parameter mit korrekter Architektur, aber einem Wert ohne nachgewiesene Rechtsgrundlage. Ein solcher Wert ist gefährlicher als eine leere Stelle, weil er nicht als Lücke sichtbar ist.

12.8 Von der Matrix zum Pflichtenheft

Eine Matrix, die in einem Whitepaper steht, veraltet mit dem ersten veröffentlichten Rechtsakt. Ihr Nutzen entsteht erst, wenn sie aus dem Dokument in das System wandert und dort gepflegt wird. Jede der 82 Zeilen lässt sich unmittelbar in einen Eintrag mit fester Struktur überführen: Anforderungskennung, Rechtsquelle mit Fassung, Gültig-ab-Datum, betroffene Datenfelder, betroffene Module, Prüffall, Status und Datum der letzten Bewertung. Ein Eintrag zum Renovierungspass etwa führt als Rechtsquelle Anhang VIII Nummer 1 Buchstabe e, als betroffene Felder die Zwischenzustände und die fünf Schrittfelder, als betroffenes Modul die Renovierungspass-Engine, als Status „teilweise" und als Prüffall ein Testgebäude mit hinterlegtem Sollpfad. Damit wird aus einer Statusangabe eine Behauptung, die ein Testlauf bestätigen oder widerlegen kann.

Der Aufwand dafür ist geringer, als es zunächst wirkt, weil die tragenden Bausteine bereits existieren. Das Rechnerregister führt bereits Kennung, Version, Route, Kategorie, Projekttypen, Schemata und Testfälle je Rechner; der Funktionswächter prüft täglich fast fünfhundert Bedingungen und archiviert die Ergebnisse; der Monitor für EPBD und nationale Umsetzung beobachtet achtzehn amtliche Quellen und trennt bereits Veröffentlichungs-, Inkrafttretens-, Anwendungs- und Produktivdatum. Was fehlt, ist die Verbindung dieser drei Bestände: Eine Anforderung, die der Monitor als geändert meldet, sollte die betroffenen Felder, Module und Prüffälle unmittelbar benennen, und ein Prüffall, der rot wird, sollte die Anforderung nennen, die dadurch nicht mehr erfüllt ist. Erst diese Verbindung macht regulatorische Wartung planbar: Bei einer Gesetzesänderung ist dann ohne Suche erkennbar, welche Felder betroffen sind, welche Module geändert werden müssen, welche Dokumente neu zu erzeugen und welche Prüffälle erneut zu durchlaufen sind.

Für eine spätere Prüfung durch Dritte — sei es eine Anerkennungsstelle nach Artikel 19 Absatz 14 Buchstabe c, eine Kontrollstelle nach Anhang VI oder ein Finanzinstitut, das die Datenqualität seines Portfolios beurteilt — verändert das die Fragestellung grundlegend. Die Frage lautet dann nicht mehr, ob die Software einen Renovierungspass erzeugen kann, sondern welche Anforderungen mit welchen Feldern in welcher Softwareversion umgesetzt sind und welche Prüffälle das belegen. Dieselbe Struktur trägt die Kommunikation nach außen: Gegenüber Behörden und Verbänden ist eine Matrix, die eigene Lücken benennt, belastbarer als eine Konformitätsbehauptung, die bei der ersten Nachfrage zerfällt.

Der wichtigste Befund dieses Kapitels ist deshalb kein Einzelposten, sondern eine Verschiebung der Entwicklungsaufgabe. In der bisherigen Phase lautete die Leitfrage, welche Berechnung noch fehlt. Die Matrix zeigt, dass diese Frage weitgehend beantwortet ist: Die Rechenkerne sind vorhanden, validiert und mit Norm- und Rechtsstand versehen. Die Leitfrage der nächsten Phase lautet, wie die vorhandenen Daten und Ergebnisse so bereitgestellt werden, dass andere Systeme sie eindeutig verstehen, dass Rollen sie kontrolliert erreichen und dass jede Angabe ihre Herkunft, ihre Rechtsgrundlage und ihren Prüfstand mitführt. Der Schwerpunkt verlagert sich damit von der Funktionsentwicklung zur Interoperabilität — und die Anforderungsmatrix ist das Instrument, mit dem sich dieser Weg Zeile für Zeile abarbeiten und jederzeit belegen lässt.

13 Reifegradanalyse des vorhandenen digitalen Gebäudepasses

Die EPBD-Anforderungsmatrix in Kapitel 12 beschreibt, was ein digitaler Gebäudepass leisten muss. Dieses Kapitel kehrt die Blickrichtung um und prüft, was die vorhandene Software heute tatsächlich leistet. Grundlage ist ausschließlich der dokumentierte Entwicklungsstand — Prüfprotokolle, Testergebnisse, Auditzahlen und die selbst geführte Lückenliste. Wo eine Funktion belegt ist, wird sie benannt; wo sie fehlt, wird sie als fehlend benannt. Ein Reifegrad ist in diesem Kapitel eine Aussage über den technischen Zustand, nicht über eine regulatorische Konformität.

13.1 Zweck der Reifegradanalyse und ihre Beweislage

Reifegradaussagen über die eigene Software sind der Teil eines Whitepapers, in dem die Versuchung zur Beschönigung am größten ist. Sie sind zugleich der Teil, der von außen am ehesten überprüft wird — von einer Bank, die wissen will, worauf sie ihre Kreditentscheidung stützt, von einer Behörde, die eine Registerschnittstelle erwägt, oder von einer Prüfinstitution, die ein Berechnungsverfahren abnehmen soll. Eine geschönte Reifegradanalyse hält der ersten dieser Prüfungen nicht stand und beschädigt anschließend auch die Aussagen, die zutreffend waren. Dieses Kapitel ist deshalb bewusst als der nüchternste Teil des Whitepapers angelegt.

Die Analyse beantwortet vier Fragen: Welche Funktionen sind vorhanden und durch Prüfnachweise belegt? Welche Funktionen existieren in Teilen, tragen aber noch keinen durchgängigen Arbeitsweg? Welche Funktionen fehlen vollständig? Und welche der fehlenden Funktionen kann die Entwicklung selbst schließen, welche hängen an externen Spezifikationen, die zum Stand August 2026 nicht veröffentlicht sind?

Die letzte Unterscheidung ist keine Ausrede, sondern eine sachliche Notwendigkeit. Für die Anbindung an eine nationale Gebäudedatenbank nach Artikel 22 EPBD existiert in Deutschland zum Quellenstand kein Schema — die Leitlinien der Kommission führen Deutschland bei den nationalen Ausweisdatenbanken mit „n/a". Eine Software kann diese Schnittstelle deshalb vorbereiten, aber nicht fertigstellen. Ebenso ist das amtliche Ausweismuster nach § 85 Abs. 3 GMoDG und das Datenformat nach § 88b GMoDG offen. Beides ist kein Entwicklungsrückstand der Plattform, sondern ein Zustand des Rechtsrahmens. Umgekehrt wäre es unredlich, unter Verweis auf offene Spezifikationen auch jene Lücken zu entschuldigen, die intern zu schließen wären — die Durchsetzung der Schreibrechte, den Renovierungspass, die Ökobilanz aus Materialmengen. Beide Gruppen werden in diesem Kapitel getrennt geführt.

Die Beweislage ist dabei ungewöhnlich gut dokumentiert, und das ist selbst ein Befund. Der Entwicklungsstand stützt sich nicht auf Selbsteinschätzungen, sondern auf drei laufende Nachweisquellen: den Funktions-Wächter, der den Programmcode statisch, über HTTP und im Headless-Browser prüft und dessen Läufe archiviert werden; den Quellen-Abgleich, der die Daten in den Projekten auf innere Widersprüche prüft; und die Validierungsfälle nach DIN V 18599, die die Rechenkerne gegen fremde Sollwerte stellen. Wo dieses Kapitel eine Zahl nennt, stammt sie aus einem dieser Protokolle oder aus einem datierten Audit.

13.2 Bewertungsmaßstab: fünf Reifestufen

Für die Bewertung wird eine fünfstufige Skala verwendet, die auf einen einzigen Prüfsatz zurückgeht: Kann eine Fachperson diese Funktion heute in einem realen Projekt verwenden, und ist das Ergebnis nachweislich geprüft? Die Skala verdichtet das in Kapitel 12 für die Anforderungsmatrix verwendete Modell auf die Ebene der Software.

• Stufe 0 — nicht vorhanden. Es existiert weder ein Datenfeld noch eine Rechenvorschrift noch eine Ausgabe. Die Anforderung ist allenfalls als Thema benannt.
• Stufe 1 — konzeptionell festgelegt. Die Funktion ist fachlich beschrieben und in Pflichtenheft, Datenmodell oder Zielspezifikation verbindlich festgelegt, aber nicht implementiert. Ein Anwender merkt von ihr nichts.
• Stufe 2 — teilweise umgesetzt. Datenstrukturen oder einzelne Teilfunktionen existieren im Programm, ergeben aber noch keinen durchgängigen Arbeitsweg vom Eingabedatum bis zur Ausgabe.
• Stufe 3 — produktiv nutzbar. Die Funktion wird im Regelbetrieb verwendet und liefert verwertbare Ergebnisse, ist aber entweder nicht systematisch durch Testfälle abgesichert oder in wesentlichen Teilen noch nicht an externe Vorgaben angepasst.
• Stufe 4 — produktiv und geprüft. Die Funktion ist im Einsatz, versioniert und durch automatisierte Prüfungen oder fachliche Validierungsfälle abgesichert; Abweichungen fallen auf, bevor sie in ein Dokument gelangen.

Zwei Einschränkungen gehören zur Skala. Erstens sagt Stufe 4 nichts über die rechtliche Anerkennung aus. Eine Berechnung kann gegen fremde Sollwerte validiert und dennoch nicht Teil eines amtlich registrierten Nachweises sein; eine Schnittstelle kann stabil laufen und trotzdem an kein Register angeschlossen sein. Technische Reife und amtliche Integration sind zwei verschiedene Achsen, und dieses Whitepaper hält sie durchgängig auseinander. Zweitens wird der Reifegrad je Funktionsbereich vergeben, nicht je Modul. Ein Modul kann in einem Teil Stufe 4 erreichen und in einem anderen Stufe 1 — der Energieausweis ist dafür das deutlichste Beispiel: die Bilanzierung dahinter ist validiert, die Ausweisverwaltung darüber ist es nicht.

13.3 Reifegradübersicht

Tabelle 13.1 bewertet die Funktionsbereiche der Plattform. Die Spalte „Belegter Ist-Stand" nennt jeweils den Nachweis, auf den sich die Stufe stützt; die letzte Spalte benennt, was zur nächsten Stufe fehlt. Bereiche, deren Fertigstellung an externen Spezifikationen hängt, sind in der letzten Spalte ausdrücklich als extern abhängig gekennzeichnet.

Die Verteilung ist aufschlussreicher als jeder Mittelwert. Sie ist nicht zufällig, sondern folgt der Entstehungsgeschichte: Die Plattform ist aus Nachweiswerkzeugen für die Energieberatung gewachsen. Alles, was zum Rechnen, Prüfen und Dokumentieren gehört, hat viele Jahre Reifung hinter sich und ist mit Prüfnachweisen unterlegt. Alles, was zum Teilen, Anschließen und Verwalten gehört — Rollen, Schnittstellen, Register, Betriebsdaten — ist jung oder nicht vorhanden. Eine Durchschnittsbildung über diese Tabelle wäre deshalb irreführend; sie würde zwei Systemteile mit sehr verschiedener Geschichte zu einer Zahl verrühren. Aussagekräftig ist stattdessen die Gruppenbildung: Der Rechen- und Nachweiskern liegt auf Stufe 4, die datenhaltende und dokumentierende Mittelschicht auf Stufe 3, die regulatorischen Erweiterungen auf Stufe 1 bis 2, und die Betriebs- und Gebäudeautomationsebene beginnt gerade erst.

13.4 Bereits abgedeckte Funktionen

Vier Bereiche verdienen die Einstufung als produktiv und geprüft. Sie werden hier nicht aufgezählt, um die Bilanz zu verbessern, sondern weil sie die Grundlage sind, auf der die fehlenden Teile überhaupt sinnvoll aufgesetzt werden können.

Der Rechenkern

Die energetische Bilanzierung nach DIN V 18599 ist der am gründlichsten überprüfte Teil der Plattform. Die Rechenkerne sind gegen 34 Validierungsfälle geprüft, die eine unabhängige Stelle mit Sollwerten vorgibt; dabei wurden 964 Einzelgrößen verglichen, und keine lag außerhalb der geforderten Toleranz von einem Prozent. Ergänzend liegen acht interne Testgebäude mit eingefrorenen Sollwerten vor, die bei jeder Programmänderung erneut gerechnet werden. Der zugehörige Prüfbericht führt die Prüfsummen der sechs Rechenkerne mit, sodass sich nachträglich feststellen lässt, ob ein Ergebnis mit dem geprüften Programmstand erzeugt wurde. Für den Vergleich mit einer Ausweisberechnung eines Dritten ist das die entscheidende Eigenschaft: Nicht die Behauptung „nach DIN V 18599 gerechnet" trägt, sondern die Angabe, welche Fassung mit welchem Programmstand gerechnet wurde.

Zwei Einschränkungen gehören unmittelbar dazu. Die Wärmepumpenfälle sind als Teilabnahme geführt, weil das dafür erforderliche Bilanzierungsverfahren auf Basis von Stundenwerten nicht umgesetzt ist — die benötigten Testreferenzjahr-Stundenwerte liegen nicht vor. Und im monatlichen Bilanzmodul sind drei fachliche Schwachstellen im Programmtext kommentiert und damit bekannt, aber nicht beseitigt. Beides wird hier genannt, weil ein Prüfnachweis nur so viel wert ist wie die Offenlegung seiner Grenzen.

Die Qualitätssicherung

Der zweite belastbare Bereich ist die automatisierte Qualitätssicherung, und sie ist der eigentliche Unterschied zu einer gewöhnlichen Fachsoftware. Der Funktions-Wächter prüft den Programmbestand auf drei Ebenen: statisch im Quelltext, über HTTP gegen den laufenden Dienst und im Headless-Browser gegen die tatsächlich ausgelieferten Oberflächen. Er ist von 116 auf 499 Prüfungen gewachsen, läuft täglich in den frühen Morgenstunden sowie unmittelbar nach jedem Serverstart, und seine Läufe werden archiviert. Der dokumentierte Sollstand vom 17. August 2026 weist 493 von 495 Prüfungen grün aus; die beiden roten Befunde sind bekannte Dateneigenheiten einzelner Live-Projekte und keine Regression der Software.

Daneben steht der Quellen-Abgleich, der eine andere Frage stellt. Der Wächter prüft, ob das Programm richtig arbeitet; der Quellen-Abgleich prüft, ob die Daten eines Projekts in sich stimmen. Er arbeitet mit einem festen Regelsatz, meldet nur neue Widersprüche und — das ist die wichtigere Entwurfsentscheidung — er korrigiert nichts automatisch. Vier doppelt geführte Angaben, darunter Bauweise und Kellerausbildung, werden gegen die jeweils andere Quelle gestellt und dem Bearbeiter als Konflikt vorgelegt. Diese Haltung, Widersprüche zu erzeugen statt sie stillschweigend aufzulösen, ist die Voraussetzung dafür, dass ein Gebäudedatensatz später von Dritten verwendet werden kann, ohne dass unbemerkt eine Angabe überschrieben wurde.

Die Dokumentenerzeugung

Der dritte Bereich ist die automatische Erzeugung von Dokumenten aus dem Datensatz. Sieben Dokumenttypen entstehen ohne separate Eingabe: Bedarfsausweis, Wärmeschutznachweis, Grundriss, Hydraulikabgleich, Heiz- und Kühllastbericht, Maßnahmenbericht und Finanzierungsbericht. Jedes Dokument trägt einen Merker über die Datengrundlage, aus der es erzeugt wurde; ändert sich diese Grundlage nicht, entsteht keine neue Fassung. Die Berichtsengine ist zudem so ausgelegt, dass sie fehlende Angaben nicht ersetzt: Ein nicht geführter Nachweis erscheint als „Nachweis nicht geführt", nicht als plausibel aussehender Zahlenwert. Dieselbe Regel gilt auf der Kennwertseite, wo fehlende Werte grau bleiben statt geschätzt zu werden.

Dieser Punkt wirkt technisch nebensächlich und ist es nicht. Die zentrale Schwäche verbreiteter Gebäudedatensammlungen ist nicht die fehlende Angabe, sondern die stillschweigend ergänzte. Ein System, das aus einer unbekannten Fensterqualität einen Erfahrungswert macht und diesen anschließend ohne Kennzeichnung in eine Bilanz und von dort in einen Bankreport trägt, erzeugt eine Scheingenauigkeit, die niemand mehr zurückverfolgen kann. Die Entscheidung, in diesem Fall lieber eine Lücke auszuweisen, ist die Grundlage jeder späteren Prüfbarkeit.

Die Datenherkunft

Der vierte Bereich ist die Herkunftskennzeichnung. Das Datenmodell fordert für jede Information eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie; fünfzehn Konsistenzregeln setzen das aus. Umgesetzt und im Betrieb sind der Objektgraph mit den Belegkanten zwischen Dokument und Datensatz, die Governance-Schicht mit vier Datenzuständen von Entwurf über Gemeldet und Geprüft bis Freigegeben, die sechsstufige Vertrauensskala von unbekannt bis amtlich signiert sowie die Trennung von Meldung und Freigabe nach dem Vier-Augen-Prinzip: Eine Meldung erzeugt einen Vorschlag im Arbeitsbereich und verändert den offiziellen Wert gerade nicht. Hinzu kommt die Abhängigkeitskette, die nach einer Freigabe automatisch ermittelt, welche Berechnungen und Dokumente nun veraltet sind — eine freigegebene Fensteränderung erzeugt dreizehn Folgeaufgaben.

Auf dieser Schicht setzt der Building Trust Index auf, der Datenqualität und Gebäudezustand in sieben gewichteten Säulen bewertet und dabei jeden einzelnen Punktbeitrag ausweist. Er bewertet ausdrücklich nicht den Eigentümer und ist kein Bonitätsmaß; er bewertet, wie gut ein Gebäude dokumentiert und wie belastbar diese Dokumentation ist. Das ist genau die Information, die ein Dritter braucht, um zu entscheiden, wie weit er einem Datensatz trauen kann.

13.5 Teilweise abgedeckte Anforderungen

Die mittlere Gruppe ist die schwierigste, weil hier der Abstand zwischen dem, was ein Anwender sieht, und dem, was regulatorisch verlangt wird, am leichtesten übersehen wird. Fünf Bereiche stehen exemplarisch dafür.

Der Energieausweis. Aus dem Gebäudedatensatz entsteht ein Bedarfsausweis, der automatisch als PDF abgelegt und bei geänderter Endenergie neu erzeugt wird; die Passkachel warnt, wenn das abgelegte Dokument von den aktuellen Daten abweicht. Die Klassenzuordnung ist implementiert, ebenso ein deterministisch aus der Gebäudekennung abgeleiteter Ausweisschlüssel. Dieser Schlüssel ist ausdrücklich keine amtliche Registriernummer, und die Software kennzeichnet ihn auch so. Offen bleiben die Verwaltung der Ausweisarten, die Gültigkeitsdauer, die Registriernummer und die getrennte Ausweisung der Emissionen aus dem Ausweis. Hinzu kommt, dass die Titelseitenangaben nach Anhang V EPBD über den heutigen Umfang hinausgehen — verlangt werden unter anderem der Anteil erneuerbarer Energie vor Ort, die Demand-Response-Fähigkeit und die Niedertemperatureignung des Verteilsystems. Der Ausweis ist damit fachlich weit, als regulatorisches Instrument aber unvollständig.

Die Rechts- und Normstandsführung. Die Umstellung auf das neue Recht ist in zwölf Bausteinen abgeschlossen und mit einem eigenen Wächterlauf abgesichert; ein Registrierungsmodul führt den Rechtsstand als umschaltbaren Parameter, und jedes Ergebnis trägt einen Rechtsstandsstempel. Der Wert dieser Konstruktion zeigt sich an einem Detail: Hartcodierte Primärenergiefaktoren wurden entfernt und durch Registrywerte ersetzt, sodass ein Faktorwechsel nicht mehr an mehreren Stellen im Programm nachgezogen werden muss. Zugleich sind zwei Lücken ausdrücklich als solche geführt: die Referenzgebäude-Kennwerte und die Klassengrenzen der mittleren Effizienzklassen für Nichtwohngebäude. Die Klassenfunktion gibt zwischen der besten und der schlechtesten Klasse bewusst keinen Wert zurück, statt zu raten. Diese Entscheidung ist richtig, macht aber sichtbar, dass die vollständige Ausweisfähigkeit nach neuem Recht an einer externen Veröffentlichung hängt.

Dieselbe Trennschärfe gilt für die Normfassung. Verbindlich gerechnet wird die Ausgabe 2018-09, weil das Gesetz sie in Bezug nimmt; die technische Spezifikation von 2025 läuft als Vergleichsrechnung mit und ist keine Grundlage für öffentlich-rechtliche Nachweise. Damit diese Unterscheidung außerhalb der Software erhalten bleibt, muss jede Ausgabe die gerechnete Fassung benennen. Perspektivisch sollte das System nicht nur die Norm speichern, sondern das Quadrupel aus Normfassung, Rechtsstand, Berechnungsmodus und Softwarestand — nur dann lässt sich ein Ergebnis Jahre später eindeutig reproduzieren.

Der Datenimport. Geometrie und Bauteile lassen sich aus dem CAD-Modell übernehmen, ein IFC-Eingang existiert, und die Auswertung von Grundrissen, Wärmeschutznachweisen und Energieausweisen erfolgt über eine gemeinsame Ablagezone, in der die Auswertung selbst erkennt, welche Art von Dokument vorliegt. Das ist ein erheblicher Erfassungsvorteil und zugleich der Punkt, an dem die Governance-Schicht ihre eigentliche Aufgabe bekommt: Maschinell erkannte Werte dürfen Vorschläge sein, nicht Wahrheiten. Das Datenmodell sieht genau das vor — Drittsysteme liefern Vorschläge —, doch der verbindliche Prüf- und Freigabeweg für Importbefunde ist noch nicht durchgesetzt. Solange das so ist, hängt die Datenqualität an der Sorgfalt des Bearbeiters statt an einer Regel.

Die Ökobilanz. Für den Nachweiskontext rechnet die Plattform einen projektspezifischen Anforderungswert gegen eine amtlich verifizierte Wertetabelle, und die Ökobilanzkachel ist im Pass aktiv. Der betriebsbezogene Teil der Bilanz ist vorhanden. Der Anteil grauer Emissionen wird jedoch bislang über einen geschätzten Pauschalwert je Quadratmeter abgebildet — eine Größenordnung, kein Nachweis. Für die Anforderungen des Artikels 7 EPBD und des Anhangs III genügt das nicht: Verlangt sind Modulwerte über einen Betrachtungszeitraum von fünfzig Jahren, gestützt auf Materialmengen und Umweltproduktdeklarationen. Der Weg dorthin führt über das Bauteil- und Mengenmodell, das aus dem CAD-Bestand grundsätzlich ableitbar wäre; die Verknüpfung Bauteil zu Material zu Deklaration existiert aber nicht.

Der Sanierungsteil. Maßnahmen, Kosten und Berichte sind vorhanden, ein Datenblatt zum Sanierungsfahrplan wird als reine Ausgabe erzeugt. Es ist kein förderfähiger Sanierungsfahrplan — ein solcher entsteht ausschließlich in der amtlichen Druckapplikation, für die kein maschinelles Importformat veröffentlicht ist. Diese Abgrenzung ist unbequem, aber notwendig; ein anderslautender Eindruck wäre gegenüber Eigentümern und Förderstellen nicht haltbar. Eine praktische Lücke kommt hinzu: Sowieso-Anteile an Sanierungskosten sind zwar als Erfassungsfeld vorgesehen, aber in keinem der geführten Projekte tatsächlich erfasst. Für Wirtschaftlichkeitsaussagen im Sinne des Anhangs VIII EPBD, der je Schritt eine Kostenersparnis mit offengelegten Annahmen verlangt, ist genau dieser Anteil entscheidend.

13.6 Noch fehlende Funktionen

Fünf Funktionen fehlen so weit, dass sie nicht als teilweise vorhanden beschrieben werden können. Sie sind hier in der Reihenfolge ihrer Tragweite dargestellt.

Die Rollen- und Rechteschicht. Dies ist die größte Einzellücke, und sie wird häufig unterschätzt, weil eine Rollenauswahl in der Oberfläche existiert. Diese Auswahl steuert jedoch ausschließlich die Darstellung: Sie ordnet die 43 Kennwerte je nach Sicht — Architekt, Makler, Hausverwaltung, TGA-Planer, Bank, Energieberater — anders an und hebt die jeweils wichtigsten hervor. Sie entscheidet nicht darüber, wer etwas sehen oder ändern darf. Das abgestufte Zugriffsmodell vom öffentlichen Betrachter bis zum Eigentümer war in der Zielspezifikation beschrieben und dort ausdrücklich als noch nicht vorhanden gekennzeichnet; seit dem 23. August 2026 ist es umgesetzt. Es fehlen damit sämtliche Bestandteile, die aus einer Anzeige eine Rechteschicht machen: Rechte auf Feldebene, zeitlich befristete Zugriffe, Zweckbindung, Widerruf und ein Freigabepaket je Empfänger.

Die Folgen reichen über den Komfort hinaus. Artikel 16 EPBD verlangt, dass Eigentümer, Mieter und Verwalter unmittelbaren Zugang zu den Gebäudesystemdaten erhalten und diesen Zugang an selbst benannte Dritte weitergeben können. Diese äußere Seite ist seit dem 23. August 2026 abgebildet: Der Eigentümer gibt je Empfänger einen eigenen, befristeten und jederzeit widerrufbaren Zugang, dessen Umfang die Rolle bestimmt und dessen Nutzung protokolliert wird. Die innere Seite derselben Lücke besteht dagegen fort. Das Schreibrollenmodell, das festlegt, welches Werkzeug welche Felder überhaupt beschreiben darf, ist definiert, maschinell prüfbar und seit dem 23. August 2026 erzwungen. Die 55 Verstöße in 15 Werkzeugen, gezählt bei rund 1.260 wörtlichen Schreibzugriffen, sind abgearbeitet; das Prinzip der einen führenden Quelle ist damit vom Vorsatz zur geprüften Eigenschaft geworden. Es ist zweierlei zu unterscheiden: Die Rechteschicht am Pass regelt, wer von außen schreiben darf; dieses Modell regelt, welches Werkzeug im Inneren zuständig ist. Vollständig ist das Innere noch nicht — 35 Registerfelder werden von mehreren Werkzeugen beschrieben, dynamisch gebildete Schreibpfade werden nicht erfasst, und 25 Werkzeuge tragen keine Rollenzuweisung.

Der Renovierungspass nach Anhang VIII. Die fachlichen Bestandteile sind da — Maßnahmen, Kosten, Varianten, Berichte —, das Feldmodell ist es nicht. Anhang VIII EPBD verlangt eine grafische Roadmap vom Ausgangs- zum Zielzustand, eine Begründung der optimalen Schrittfolge zur Vermeidung von Lock-in-Effekten, die Liste der nationalen Anforderungen mit ihren Stichtagen und je Schritt fünf Pflichtangaben: Bezeichnung mit Technologieoptionen, Veränderung von Primär- und Endenergie in Kilowattstunden und Prozent, Veränderung der betriebsbedingten Treibhausgase, Kostenersparnis mit offengelegten Energiepreisannahmen und die erreichte Ausweisklasse nach dem Schritt. Von diesen fünf Feldern ist die Emissionsveränderung je Schritt heute nicht strukturiert vorhanden, und die Klassenangabe je Zwischenzustand setzt eine Bewertung voraus, die für Nichtwohngebäude an den fehlenden Klassengrenzen scheitert. Hinzu kommen die Zirkularitäts- und Whole-Life-Carbon-Angaben nach Anhang VIII Nr. 1 Buchst. h, für die kein Datenfeld existiert. Der Renovierungspass ist damit der Bereich mit dem größten Abstand zwischen vorhandener Fachkompetenz und geforderter Datenstruktur.

Die Ökobilanz aus Umweltproduktdeklarationen. Der Übergang vom Pauschalwert zur Mengenrechnung ist keine Verfeinerung, sondern ein Wechsel der Kategorie. Er erfordert ein Bauteil- und Materialmodell, Lebensdauern und Austauschzyklen, eine Anbindung an Datensätze nach EN 15804 sowie eine getrennte Bilanzlogik für Neubau und Sanierung. Erst danach lassen sich die nach Anhang III geforderten Modulwerte ausweisen. Da die Ausweispflicht für das Treibhauspotenzial erst 2028 für große Neubauten und 2030 für alle Neubauten greift, besteht hier zeitlicher Spielraum — aber keiner für die Behauptung, die Funktion sei bereits vorhanden.

Betriebsdaten und Zeitreihen. Die Plattform dokumentiert und berechnet den Gebäudezustand; sie beobachtet ihn nicht. Eine Verbrauchshistorie mit Auswertung existiert, und der Umschalter zwischen dem bisherigen Dreijahresverfahren und der künftig geforderten monatlichen Erfassung über 24 Monate ist bereits angelegt — ein gutes Beispiel für vorausschauende Umsetzung, denn § 80 GMoDG verlangt diese Erfassung ab 2027, und bis dahin müssen beide Verfahren parallel bedienbar bleiben. Was fehlt, ist die Ebene darunter: eine Zeitreihenhaltung, der Import von Zähler-, Wärmemengen-, Photovoltaik- und Wärmepumpendaten und der systematische Abgleich zwischen berechnetem Bedarf und gemessenem Verbrauch. Auch die betriebsbezogene Emissionsbilanz stützt sich heute auf Pauschalen statt auf Messwerte. Ohne diese Ebene bleibt der Begriff des digitalen Zwillings eine Metapher; die Richtlinie verlangt ihn allerdings auch nicht, sie nennt ihn in Artikel 19 EPBD lediglich als zulässigen Kanal für vereinfachte Ausweisaktualisierungen.

Zirkularität und Materialpässe. Für Bauteil-Einzelpässe, einen Gebäuderessourcenpass und Zirkularitätskennwerte existieren weder Datenfelder noch Regeln; sie sind ausschließlich als Vorhaben benannt. Das ist die einzige Position der Tabelle 13.1 auf Stufe 0, und sie steht dort zu Recht.

Ergänzend fehlen mehrere Bausteine, die nicht regulatorisch getrieben sind, aber die Nutzbarkeit prägen: das Gebäude-Cockpit, die Ereigniszeitleiste, ein Risikomodul sowie der in der Oberflächenkonzeption beschriebene Assistenzmodus für Eigentümer. Das heutige Werkzeug ist eine Fachansicht; die einfache, geführte Sicht für Laien existiert nicht. Für die Marktstrategie in Kapitel 15 ist das relevanter, als es hier zunächst wirkt — sie entscheidet darüber, ob ein Eigentümer den Pass ohne Fachbegleitung fortschreiben kann.

13.7 Fehlende Schnittstellen

Schnittstellen verdienen eine eigene Betrachtung, weil sie die Funktionsgruppe sind, in der eine hohe interne Reife am wenigsten hilft. Ein validierter Rechenkern nützt einem Register nichts, solange dessen Daten nicht in der erwarteten Form ankommen. Tabelle 13.2 stellt den Stand zusammen und trennt dabei, was intern zu leisten wäre, von dem, was auf eine externe Veröffentlichung wartet.

Die Tabelle zeigt eine Aufteilung, die für die Roadmap in Kapitel 14 entscheidend ist: Fünf der elf Schnittstellenlücken sind intern zu schließen und hängen an keiner fremden Entscheidung. Sie sollten deshalb zuerst angegangen werden — nicht weil sie regulatorisch dringender wären, sondern weil sie die einzigen sind, deren Fertigstellung planbar ist. Für die extern abhängigen Positionen ist die richtige Vorbereitung nicht das Warten, sondern die saubere Trennung von Datenhaltung und Ausgabeformat: Wer seine Pflichtangaben strukturiert und maschinenlesbar vorhält, kann ein später veröffentlichtes Format nachbilden, ohne den Datenbestand anzufassen. Genau das leistet der vorhandene Zertifikatsexport, der die gesetzlichen Pflichtangaben bereits maschinenlesbar mitführt.

13.8 Rechtliche und technische Risiken

Eine Reifegradanalyse, die nur Lücken auflistet, ist unvollständig. Manche Befunde sind keine fehlenden Funktionen, sondern Eigenschaften des vorhandenen Systems, die unter bestimmten Umständen schaden können. Tabelle 13.3 führt sie zusammen; sie ist bewusst als Risikoliste und nicht als Mängelliste formuliert, weil ein Teil der Punkte durch organisatorische Regeln beherrschbar ist.

Zwei Punkte dieser Liste verdienen Hervorhebung, weil sie unmittelbar handlungsleitend sind. Der erste ist die ungefragte Dokumentenerzeugung. Sie ist kein Schönheitsfehler: Ein System, das ohne Zutun des Bearbeiters Nachweisdokumente erzeugt und ablegt, verletzt genau das Prinzip, das die Governance-Schicht ansonsten konsequent verfolgt — dass eine Änderung des offiziellen Datenbestands eine bewusste Handlung mit zurechenbarem Urheber ist. Der Widerspruch zwischen einem Vier-Augen-Freigabeprozess auf der einen und einer automatischen Dokumentenablage auf der anderen Seite sollte zugunsten des Freigabeprozesses aufgelöst werden.

Der zweite ist die Konformitätsfrage. Es ist verlockend, aus einer hohen technischen Reife eine regulatorische Aussage abzuleiten. Diese Verlockung ist zu meiden, solange das amtliche Ausweismuster, das Datenformat, das Datenbankschema und die Klassengrenzen nicht veröffentlicht sind. Belastbar ist die Aussage, dass die Plattform die zugrunde liegenden Daten strukturiert, geprüft und maschinenlesbar vorhält und dass sie an veröffentlichte Spezifikationen angeschlossen werden kann. Nicht belastbar ist jede Prozentangabe einer EPBD-Erfüllung.

13.9 Gesamtbewertung

Die Reifegradanalyse ergibt ein Bild mit klarer Kontur. Der digitale Gebäudepass ist kein frühes Konzeptvorhaben; er ist eine im Einsatz befindliche Fachplattform mit einem geprüften Rechen- und Nachweiskern, die 96 reale Projekte über 74 Werkzeuge auf einem gemeinsamen Datenbestand führt. Er ist zugleich noch keine interoperable Dateninfrastruktur, weil ihm die Schichten fehlen, die eine Plattform nach außen anschlussfähig machen: eine Rechteschicht, eine dokumentierte Dienstschnittstelle und eine Registerbindung.

Damit lässt sich der Zustand in drei Ebenen zusammenfassen. Die Kernplattform — Datenhaltung, Bilanzierung, Nachweisführung, Qualitätssicherung, Dokumentenerzeugung — liegt auf Stufe 4 und ist mit Prüfnachweisen belegt. Die regulatorischen Erweiterungen — Renovierungspass nach Anhang VIII, Rechteschicht, Registeranbindung, Lebenszyklusbilanz aus Materialmengen — liegen auf Stufe 1 bis 2. Die Betriebs- und Gebäudeautomationsebene — Zeitreihen, Messdaten, Smart Readiness — beginnt erst. Diese Staffelung ist die eigentliche Aussage des Kapitels, und sie ist ehrlicher als jeder Mittelwert.

Für die Einordnung nach außen folgt daraus eine unterschiedliche Perspektive je nach Adressat. Für einen Eigentümer ist der Pass bereits heute nutzbar: Gebäudechronik, Dokumentenablage, Energieausweis, Sanierungsvarianten, Förderung und Wirtschaftlichkeit liegen vor, und keine der offenen EPBD-Funktionen ist Voraussetzung dafür, dass dieser Nutzen entsteht. Für eine Bank ist die Lage zweigeteilt: Energiekennwerte und technischer Zustand sind belastbar unterlegt, ein standardisierter Datensatz aus Transformationsaufwand, Sanierungspfad und Datenqualitätsangabe ist es nicht — das ist die nächste Ausbaustufe. Für eine Prüfinstitution ist die Ausgangslage günstig, weil dokumentiertes Datenmodell, dokumentierte Rechenverfahren, Testfälle, Regressionsprüfungen und Versionierung vorliegen; was fehlt, ist der formalisierte Prüfpfad mit Signatur. Für eine politische Institution schließlich gilt die Trennung, die dieses Kapitel durchgängig verfolgt: technische Bereitschaft in weiten Teilen, amtliche Integration in keinem Teil.

Aus der Analyse folgt auch, was nicht Vorrang haben sollte. Weitere isolierte Berechnungsverfahren zu ergänzen, während Interoperabilität und Rollen offen sind, würde die vorhandene Schieflage vertiefen. Die Plattform verfügt über umfangreiche Rechenkompetenz; ihr fehlt die Anschlussfähigkeit. Ebenso sollte jede Erweiterung demselben Weg folgen — vom Datenfeld über den Datenkatalog, die Regel, das Modul und die Schnittstelle bis zum Testfall —, statt für jede neue Anforderung eine Sonderlösung einzubauen. Andernfalls entsteht genau die technische Schuld, die sich in den 49 gezählten Verstößen gegen das Schreibrollenmodell bereits abzeichnet.

Der langfristige Wert dieser Plattform wird nicht durch die Zahl ihrer Funktionen bestimmt, sondern durch die Verlässlichkeit ihrer Daten. Ein System mit hundert Berechnungen auf ungesicherten Eingangsdaten hat begrenzten Wert; ein System mit dokumentierten, versionierten und geprüften Daten kann viele Anwendungen zuverlässig versorgen. Mit wachsender Lebensdauer entsteht daraus eine eigene Qualität: Ein Gebäude mit vollständiger Historie, geprüften technischen Daten, dokumentierten Sanierungen und nachvollziehbaren Berechnungen besitzt einen deutlich besseren Informationsstand als ein vergleichbares Gebäude ohne Dokumentation. Dass sich dieser Informationswert unmittelbar im Marktwert niederschlägt, ist damit nicht behauptet — das wäre gesondert zu untersuchen.

Die Analyse markiert damit einen Wendepunkt in der Entwicklungsaufgabe. Die erste Phase beantwortete die Frage, ob sich ein Gebäude vollständig digital berechnen und dokumentieren lässt; für die wesentlichen Bereiche ist sie mit Ja beantwortet und mit Prüfnachweisen unterlegt. Die zweite Phase beantwortet eine andere Frage: ob andere Systeme diesen Gebäudedatensatz eindeutig verstehen, prüfen und weiterverwenden können. Aus dieser Frage ergibt sich unmittelbar die Reihenfolge der Entwicklungsroadmap in Kapitel 14 — Datenmodell, EPBD-Zuordnung, Renovierungspass, Rollen und Rechte, Schnittstellen, Lebenszyklusdaten, Banken- und ESG-Profil, Betriebsdaten. Die Aufgabe besteht nicht darin, die Plattform neu zu erfinden, sondern darin, einen vorhandenen und geprüften Kern zu standardisieren, zu formalisieren und zu öffnen.

14 Entwicklungsroadmap

Die Reifegradanalyse in Kapitel 13 hat gezeigt, dass der digitale Gebäudepass über einen belastbaren Rechen- und Datenkern verfügt, während die verbindenden Teile — Rechteschicht, Exportprofile, Registeranbindung, Ökobilanz aus Materialmengen — noch fehlen. Dieses Kapitel ordnet die daraus folgende Weiterentwicklung in sieben aufeinander aufbauende Stufen. Die Reihenfolge ergibt sich nicht aus Wunschterminen, sondern aus zwei harten Randbedingungen: der fachlichen Abhängigkeit der Module untereinander und den regulatorischen Fristen von 2027 bis 2030. Wo eine Stufe von einer noch nicht veröffentlichten staatlichen Spezifikation abhängt, wird das ausdrücklich benannt — sie kann dann vorbereitet, aber nicht abgeschlossen werden.

14.1 Ordnungsprinzip: Abhängigkeit vor Wunschtermin

Eine Entwicklungsroadmap für eine regulatorisch getriebene Software steht vor einer besonderen Schwierigkeit. Sie kann sich nicht an dem orientieren, was am dringendsten gewünscht wird, und auch nicht allein an dem, was am schnellsten sichtbaren Nutzen erzeugt. Sie muss zwei Ordnungen gleichzeitig bedienen: die technische Abhängigkeitsordnung, die festlegt, welches Modul auf welchem aufsetzt, und die regulatorische Fristenordnung, die festlegt, wann eine Funktion spätestens arbeitsfähig sein muss. Wo beide Ordnungen zusammenfallen, ist die Reihenfolge unstrittig. Wo sie auseinanderfallen, gilt die Abhängigkeitsordnung — denn eine Funktion, die auf einem unfertigen Datenmodell aufsetzt, ist zum Fristtermin zwar vorhanden, aber nicht belastbar und muss anschließend erneut umgebaut werden.

Die fachliche Abhängigkeitskette des Gebäudepasses verläuft in sieben Schritten: vom formalisierten Datenmodell über die regulatorische Zuordnung der Datenfelder zu den Anwendungen, von dort zu den Schnittstellen, zur Rechteschicht, zur wirtschaftlich-ökologischen Bewertungsebene, zu den Betriebsdaten und schließlich zur externen Registerintegration. Diese Kette ist nicht willkürlich. Jeder Schritt verwendet Ergebnisse des vorangehenden: Ein Renovierungspass braucht definierte Gebäudedaten, ein Exportprofil braucht einen stabilen Feldkatalog, eine Bankensicht braucht ein Exportprofil, eine Registerübertragung braucht sowohl den Feldkatalog als auch die Rechte- und Freigabelogik. Wird ein Schritt übersprungen, entsteht kein Zeitgewinn, sondern eine spätere Nacharbeit an mehreren Stellen gleichzeitig.

Der Startpunkt jeder Stufe ist dabei nicht ein leeres Blatt. Die vorhandene Plattform umfasst nach dem Audit vom 10.08.2026 74 Werkzeuge, 64 Register-Felder und 96 Projekte; die Rechenkerne folgen DIN V 18599:2018-09, die Qualitätssicherung ist mit dem Funktions-Wächter auf 499 Prüfungen gewachsen, und mit den Etappen der GMoDG-Migration ist der Rechtsstandwechsel 2026 ⇄ 2027 bereits als umschaltbare Registry angelegt. Jede der folgenden Stufen beginnt deshalb mit einer knappen Bestandsaufnahme des tatsächlich Vorhandenen und beschreibt anschließend Ziel, Arbeitspakete, Voraussetzungen, externe Abhängigkeit und Abschlusskriterium.

Drei Reihenfolgen fassen dieses Prinzip zusammen: Datenstruktur vor Oberfläche, Definition vor Berechnung, kanonisches Datenmodell vor externem Format. Wer sie einhält, baut eine Funktion einmal; wer sie umkehrt, baut sie zweimal.

14.2 Der regulatorische Taktgeber und die externen Blocker

Die zweite Ordnung der Roadmap ergibt sich aus dem Fristenkalender der EPBD und der deutschen Umsetzung. Die allgemeine Umsetzungsfrist des Artikels 35 EPBD lief am 29.05.2026 ab; mit ihr wurden auf Mitgliedstaatsebene das Renovierungspass-System nach Artikel 12, die Ausweisskala A–G nach Artikel 19 Absatz 2, die nationale Gebäudedatenbank nach Artikel 22, das Kontrollsystem nach Anhang VI und der Datenzugang nach Artikel 16 fällig. Für die Softwareentwicklung bedeutet das nicht, dass alles bereits umsetzbar wäre, sondern das Gegenteil: Die europäische Ebene hat geliefert, die deutsche Ausführungsebene an mehreren Stellen noch nicht. Das GMoDG ist am 28.07.2026 verkündet worden (BGBl. 2026 I Nr. 226); die Artikel 1, 5, 6 und 8 gelten seit dem 29.07.2026, während Artikel 2 — die eigentliche EPBD-Umsetzung — sechs Monate nach Verkündung in Kraft tritt. Sekundärquellen nennen dafür den 01.01.2027; rechnerisch ergäbe die Sechsmonatsfrist den 28.01.2027. Dieses Kapitel führt den früheren Termin, den 01.01.2027, ausdrücklich mit Vorbehalt und nicht als gesicherte Tatsache.

Für die Stufenplanung sind vor allem sechs Zeitmarken maßgeblich. Zum 01.01.2027 werden die geänderten Rechenregeln und Ausweisvorschriften des GMoDG anwendbar, darunter die Verbrauchserfassung nach § 80 GMoDG mit mindestens monatlicher, nach Energieträgern differenzierter Erfassung über 24 Monate anstelle der bisherigen drei Abrechnungsperioden; zum selben Termin ist der GWP-Grenzwert-Fahrplan der Mitgliedstaaten nach Artikel 7 Absatz 5 EPBD fällig. Bis zum 30.06.2027 soll der delegierte Rechtsakt zur SRI-Pflicht ergehen, die anschließend nur Nichtwohngebäude über 290 kW betrifft. Zum 01.01.2028 gilt die GWP-Ausweispflicht für Neubauten über 1 000 m² nach Artikel 7 Absatz 2, und Neubauten öffentlicher Einrichtungen müssen Nullemissionsgebäude sein. Zum 31.12.2029 sind Gebäudeautomation und Beleuchtungssteuerung für Nichtwohngebäude über 70 kW verlangt, und der spätestmögliche Aufschub für die Ausweis-Neuskalierung endet. Zum 01.01.2030 gelten die GWP-Ausweispflicht für alle Neubauten, die Nullemissionsanforderung für alle Neubauten und die ersten Zielwerte des Wohnbestandspfads nach Artikel 9 Absatz 2. Fortlaufend gilt schließlich die Übertragung an das EU Building Stock Observatory mindestens einmal jährlich nach Artikel 22, mit den Vorlagen der Durchführungsverordnung (EU) 2025/1328.

Diesen Terminen steht eine Liste von Spezifikationen gegenüber, die zum Quellenstand nicht veröffentlicht sind. Sie entscheidet darüber, welche Stufe abgeschlossen und welche nur vorbereitet werden kann. Offen sind insbesondere:

• Das deutsche Datenbankschema nach Artikel 22. Deutschland verfügt nach Annex 5 der Kommissions-Leitlinien über keine nationale Energieausweis-Datenbank; der Eintrag lautet „n/a". Ein Schema, gegen das ein Register-Connector entwickelt werden könnte, existiert damit nicht.
• Das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG. Solange es fehlt, lässt sich der Ausweis inhaltlich, aber nicht layoutverbindlich erzeugen.
• Das Datenformat nach § 88b GMoDG für den Lebenszyklus-Treibhausgasbericht im Ausweis („Abschnitt 8"). Die europäische Systemgrenze ist über Artikel 7 und Anhang III in der Fassung der Delegierten Verordnung (EU) 2026/52 definiert, das deutsche Austauschformat nicht.
• Die Klassenskala und die Klassengrenzen B–F für Nichtwohngebäude nach Anlage 10a sowie die Referenzgebäude-Kennwerte der Anlagen 1 und 2. In der Plattform sind beide bereits als ausgewiesene Lücke geführt: Die Klassenfunktion für Nichtwohngebäude gibt zwischen A und G bewusst keinen Wert zurück, statt einen zu erfinden.
• Das SRI-Schema sowie das DIBt-Kontrolldatei-Schema für Monatswerte, ohne das die neue 24-Monats-Erfassung nur im bisherigen Periodenformat übergeben werden kann.
• Der Status des iSFP als Renovierungspass im Sinne des Artikels 12 — die Strukturfrage zwischen einem Anhang-VIII-Feldmodell mit iSFP-Darstellung und einem förmlichen BAFA-Layout ist ausdrücklich nicht entschieden.

Aus dieser Gegenüberstellung folgt die Arbeitsregel dieses Kapitels, die den drei Verbindlichkeitsstufen des EPBD-Monitors entspricht: Liegen Recht und Spezifikation vor, ist eine Funktion umsetzbar und wird terminiert. Liegt das Recht vor, die Spezifikation aber nicht, ist die Funktion blockiert — sie wird bis zur Schnittstellenkante gebaut und dort angehalten. Ist eine Anforderung nur angekündigt, wird keine Pflicht behauptet und kein Termin gesetzt. Diese Dreiteilung ist keine theoretische Vorsichtsmaßnahme, sondern verhindert den teuersten Fehler regulatorischer Softwareentwicklung: gegen eine vermutete Spezifikation zu entwickeln und den Aufwand nach deren Veröffentlichung zu verlieren.

14.3 Stufe 1 — EPBD-Basisdatenmodell

Ausgangslage. Der Datenkern ist weiter entwickelt, als es die Bezeichnung „Stufe 1" vermuten lässt. Die verbindlichen Regeln des Datenmodells sind formuliert — jede Information hat genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie —, und die dazugehörigen Schichten sind deployt: eine Beziehungs-Engine mit dem Objektgraphen und den Kanten „belegt durch", „beeinflusst" und „ersetzt"; eine Governance-Engine mit den vier Datenzuständen Entwurf, gemeldet, geprüft und freigegeben, den Vertrauensstufen 0 bis 5 und einem Vier-Augen-Verfahren, bei dem ein Melde-Vorgang den offiziellen Wert nicht verändert und erst die Freigabe in den Pfad der führenden Quelle schreibt; eine Abhängigkeits-Engine, die die Wirkkette vom Bauteil über U-Wert und Heizlast bis zu Ausweis, CO₂-Bilanz, Building Trust Index und Finanzierungsbericht kennt; und eine Neuberechnungs-Engine, die über einen Fingerabdruck je Eingabesektion feststellt, welche Auswertungen veraltet sind. Auch die kanonische Bezugsfläche ist entschieden und migriert. Was fehlt, ist nicht die Mechanik, sondern die vollständige, geschlossene Beschreibung des Feldbestands.

Ziel. Am Ende der ersten Stufe existiert ein vollständiger, versionierter Datenkatalog, in dem jedes für die EPBD und das GMoDG relevante Datenfeld eindeutig definiert ist und in dem für jedes Feld nachvollziehbar ist, welche Rechtsnorm es fordert, welche Berechnung es verwendet und welches Exportprofil es ausgibt. Dieser Katalog ist die gemeinsame Sprache aller folgenden Stufen.

Arbeitspakete. Die Stufe zerfällt in fünf Pakete:

• Feldkatalog. Für jedes Datenfeld werden eindeutige Feld-Kennung, Bezeichnung, fachliche Definition, Datentyp, Einheit, zulässiger Wertebereich, führende Quelle, Vertrauensstufe, Version, Gültigkeitszeitraum und Beziehung zu anderen Objekten festgelegt. Ein Beispiel für den Zuschnitt: Der U-Wert der Außenwand trägt neben Bezeichnung und Einheit die Angabe, ob er berechnet, aus einem Nachweis übernommen oder geschätzt ist, welche Vertrauensstufe daraus folgt und in welchen Anwendungen — Bilanzierung nach DIN V 18599, Heizlast, Wärmeschutznachweis, Energieausweis, Sanierungsplanung — er verwendet wird. Erst diese Rückwärtsverkettung erlaubt die Frage, welche Auswertungen eine Wertänderung berührt.
• Regulatorisches Mapping. Jedes Feld erhält eine Zuordnung zu den Anforderungen, die es bedient: Anhang V EPBD für die Pflichtangaben des Ausweises, Anhang VIII für den Renovierungspass, Artikel 20 Absatz 8 für die Rohdaten der Registrierung, Anhang III für die GWP-Module, dazu die Paragraphen des GMoDG. Der Ansatz existiert bereits punktuell — die Pflichtangaben nach § 85 werden maschinenlesbar geführt und im Zertifikatsexport mitgegeben —, ist aber noch nicht flächendeckend.
• Normstand-Kennzeichnung. Jedes berechnete Feld führt die gerechnete Normfassung mit. Verbindlich gerechnet wird DIN V 18599:2018-09; DIN/TS 18599:2025-10 ist eine Technische Spezifikation und keine Grundlage des GEG, ihre Ergebnisse sind Vergleichsrechnung. Die Registry für beide Fassungen ist vorhanden, die Durchreichung der Fassungsangabe an jede Ausgabe ist zu vervollständigen.
• Bereinigung der Mehrfachschreiber. Das Rollenmodell der Schreibrechte — Steckbrief als Quelle, CAD und Import als Ermittler, Rechenwerkzeuge ausschließlich auf den Ergebnispfaden, Berichte und Pass ohne Schreibrecht — ist beschrieben und seit dem 23. August 2026 erzwungen. Die 55 Verstöße in 15 Werkzeugen, gezählt bei 1 258 literalen Schreibzugriffen, sind am 23. August 2026 bereinigt worden; die Prüfung ist seither erzwingend. Die Aussage „genau eine führende Quelle" hat damit eine Durchsetzung — vollständig wird sie erst, wenn auch die 35 Registerfelder mit mehreren Schreibern und die 58 dynamisch gebildeten Schreibpfade aufgelöst sind.
• Konsolidierung der Faktortabellen. Eigene Faktortabellen in der CO₂-Bilanz, im Renovierungspass-Modul und in der Anlagentechnik gehören an die zentrale Rechtsstand-Registry, damit ein Faktorwechsel — etwa der Übergang des Primärenergiefaktors Strom von 1,8 auf 1,5 und des CO₂-Faktors von 560 auf 100 g zum Rechtsstand 2027 — an einer Stelle erfolgt.

Voraussetzungen. Keine externen. Die Stufe verwendet ausschließlich vorhandene Daten, vorhandene Engines und die bereits abgeschlossenen Migrationsetappen. Erforderlich ist Entwicklungszeit, keine staatliche Vorleistung.

Abhängigkeit von externen Spezifikationen. Gering, aber nicht null: Für die Klassengrenzen B–F bei Nichtwohngebäuden und für die Referenzgebäude-Kennwerte der Anlagen 1 und 2 kann der Katalog die Felder anlegen und als Lücke kennzeichnen, aber nicht befüllen. Die derzeitige Praxis, in diesem Bereich bewusst keinen Wert zurückzugeben, ist beizubehalten.

Abschlusskriterium. Jedes Feld, das in einem offiziellen Dokument, einem Exportprofil oder einer Registerübertragung erscheinen kann, ist im Katalog mit Definition, Herkunft, Vertrauensstufe, Normfassung und regulatorischer Zuordnung beschrieben; für jedes dieser Felder existiert genau ein schreibender Zugriffspfad, und der Funktions-Wächter prüft diese Eindeutigkeit automatisch.

14.4 Stufe 2 — Energieausweis und Renovierungspass

Ausgangslage. Der Energieausweis ist die am weitesten entwickelte Anwendung. Im Gebäudepass ist die Ausweiskachel produktiv, ein Bedarfsausweis wird bei vollständigem Energiekern automatisch als Dokument erzeugt, eine neue Version entsteht bei geänderter Endenergie, und die Kachel warnt bei Abweichungen zwischen abgelegtem Dokument und aktuellen Daten. Die interne Ausweisnummer ist deterministisch aus der Gebäude-Kennung abgeleitet und ausdrücklich keine Registriernummer des DIBt. Für die Verbrauchsseite existiert bereits ein Umschalter zwischen dem bisherigen Verfahren mit drei Abrechnungsperioden und der 24-Monats-Erfassung nach GMoDG. Der Renovierungspass steht dagegen deutlich weiter hinten: Ein Modul existiert, führt aber eigene Faktortabellen, und im Anforderungsprofil des EPBD-Monitors ist das Renovierungspass- und iSFP-Modul als Priorität 1 geführt.

Ziel. Beide Instrumente werden vollständig gegen ihre europäischen Anhänge geführt: der Ausweis gegen Anhang V, der Renovierungspass gegen Anhang VIII. Der Renovierungspass wird dabei nicht als Nebenprodukt des Ausweises behandelt, sondern als eigenständiges Instrument mit eigenem Datensatz, eigener Erhebungstiefe und eigener Freigabelogik.

Arbeitspakete. Auf der Ausweisseite ist der Feldbestand des Anhangs V vollständig zu bedienen: Effizienzklasse, Primär- und Endenergie je Energieträger in kWh/(m²·a) und absolut, Anteil erneuerbarer Energie am Standort, operative Treibhausgasemissionen in kg CO₂eq/(m²·a) und, sofern verfügbar, der GWP-Wert in kg CO₂eq/m². Hinzu kommen der Energiebedarf je System, die Angaben zur Demand-Response-Fähigkeit und zur Niedertemperaturfähigkeit des Verteilsystems jeweils als Ja-Nein-Feld, die Kontaktdaten der zentralen Anlaufstelle und die Referenzwerte. Die Niedertemperatur-Eignung folgt der Definition der Leitlinien mit einer Auslegungstemperatur von höchstens 45 °C beziehungsweise einer saisonalen Temperatur von höchstens 42 °C und dem vierschrittigen Verfahren von der Heizlast über die Heizkörperleistung und den Volumenstrom zur Systemtemperatur — ein Verfahren, dessen erste Schritte die vorhandene raumweise Heizlastrechnung bereits liefert. Ergänzt wird die Restlebensdauer der Wärmeerzeugung, für die die Leitlinien Richtwerte von 7 bis 25 Jahren für Heizungen, 20 bis 25 Jahren für Wärmepumpen und 10 bis 15 Jahren für Klimaanlagen nennen und bei etwa zwei verbleibenden Jahren die Nennung fossilfreier Alternativen verlangen.

Auf der Renovierungspass-Seite sind die Pflichtinhalte des Anhangs VIII abzubilden. Dazu gehören die aktuelle Gesamtenergieeffizienz mindestens als Primärenergiekennwert im Ist-Zustand, eine grafische Roadmap von der Ausgangslage zum Endzustand mit Maßnahmen, Kosten, Einsparung und Klassensprung je Schritt, die nationalen Anforderungen einschließlich ihrer Stichtage, die Begründung der optimalen Schrittfolge zur Vermeidung von Lock-in-Effekten sowie je Schritt fünf Pflichtfelder: Bezeichnung und Beschreibung mit Technologie- und Materialoptionen, die Veränderung von Primär- und Endenergie in Kilowattstunden und Prozent gegenüber dem Zustand vor dem Schritt, die Veränderung der operativen Treibhausgase, die Kostenersparnis mit offengelegten Energiepreisannahmen und die Zielklasse nach dem Schritt. Hinzu kommen die Anschlussoption an Fernwärme oder Fernkälte, der Anteil erneuerbarer Energie und des Eigenverbrauchs nach der Renovierung, Angaben zu Zirkularität, Whole-Life-Carbon und Zusatznutzen sowie Fördermittel mit Verweisen und Kontaktdaten der Anlaufstellen. Der Zielzustand ist dabei nicht frei wählbar: Er lautet Niedrigstenergiegebäude vor dem 01.01.2030 und Nullemissionsgebäude ab dem 01.01.2030, mit einer Rückfallschwelle von mindestens 60 % Primärenergiereduktion, wenn dieser Zielzustand nicht erreichbar ist.

Der Renovierungspfad selbst wird damit nicht als frei gewählte Jahresliste gebaut, sondern als Kette von Zwischenzuständen, die jeweils vollständig berechenbar sind und an die maßgeblichen Stichtage gebunden werden — an die Nullemissionsschwelle 2030, an die Stufen der Solarpflicht zwischen 2026 und 2030, an die Anforderungen an schlechteste Bestandsgebäude sowie an die Erneuerbaren-Staffel des GMoDG. Für das Datenmodell folgt daraus ein standardisierter Maßnahmendatensatz mit Kennung, betroffenem Bauteil oder System, Ausgangs- und Zielzustand, geplantem Jahr, Investitionskosten, Energie- und Emissionseinsparung, Förderbezug und Status. Die dafür nötige Kostenseite ist mit den vorhandenen Baukosten- und Sanierungskostenwerkzeugen angelegt; offen ist dort die Erfassung der Sowieso-Anteile, die in keinem Projekt bisher gepflegt sind und ohne die eine belastbare Mehrkostenrechnung nicht möglich ist.

Ein drittes Arbeitspaket betrifft die Abgrenzung zum iSFP. Die Software muss drei Ebenen sauber unterscheiden: den iSFP als bestehendes deutsches Beratungs- und Förderinstrument, den Renovierungspass als europäisch definiertes Instrument nach Artikel 12 und Anhang VIII und den Gebäudepass als übergeordnete Lebenszyklusplattform. Der iSFP wird in der Renovierungspass-Leitlinie (Annex 4 der Kommissionsmitteilung C/2025/6438 vom 18.12.2025) zweimal als Vorbild guter Praxis genannt — für die Einseiten-Grafik und für die Förderhinweise je Schritt —, er ist damit aber gerade kein Renovierungspass im Sinne des Artikels 12. Nicht abgedeckt sind insbesondere die Veränderung der operativen Treibhausgase je Schritt, die Angaben zu Zirkularität und Whole-Life-Carbon sowie die Stichtagsliste. Die Plattform erzeugt heute ein iSFP-Datenblatt als reine Ausgabe; ein förderfähiger iSFP entsteht ausschließlich in der amtlichen BAFA-Druckapplikation, für die kein maschinelles Importformat veröffentlicht ist. Der iSFP kann deshalb verknüpft, aber nicht gleichgesetzt werden.

Voraussetzungen. Der Feldkatalog aus Stufe 1, insbesondere die Trennung der Energiekennwerte je Energieträger und die Herkunftskennzeichnung; ferner die Konsolidierung der Faktortabellen, weil Ausweis und Renovierungspass sonst unterschiedliche Emissionsfaktoren verwenden.

Abhängigkeit von externen Spezifikationen. Geteilt. Der Renovierungspass ist europäisch vollständig spezifiziert und damit ohne staatliche Vorleistung baubar — Anhang VIII lässt keine wesentliche Frage offen. Der Energieausweis ist inhaltlich ebenfalls spezifiziert, in der deutschen Ausprägung aber an drei Stellen blockiert: am amtlichen Ausweismuster nach § 85 Absatz 3, an der Klassenskala für Nichtwohngebäude und an der Registriernummer, die eine Anbindung an ein Register voraussetzt, das es noch nicht gibt. Bis zum Anwendungsbeginn des GMoDG-Artikels 2 müssen zudem beide Verbrauchsverfahren — drei Abrechnungsperioden und 24-Monats-Erfassung — parallel bedienbar bleiben; der dafür nötige Umschalter existiert bereits.

Abschlusskriterium. Ein Renovierungspass, der alle Pflichtfelder des Anhangs VIII aus dem Gebäudedatensatz erzeugt, digital und druckfähig ausgibt und über eine eindeutige Adresse im Pass zugänglich ist — Artikel 12 Absatz 8 verlangt genau das, wo ein digitales Gebäudelogbuch vorhanden ist, und der Pass erfüllt die Logbuchdefinition des Artikels 2 Nummer 41. Für den Ausweis: alle Angaben des Anhangs V liegen als geprüfte Felder vor, der Ausweis ist ohne das amtliche Muster inhaltlich vollständig erzeugbar, und die Stelle, an der das Muster einzusetzen ist, ist als benannte Schnittstelle isoliert.

14.5 Stufe 3 — Maschinenlesbarkeit und Exportprofile

Ausgangslage. Der Bestand an Schnittstellen ist heterogener, als es die Rede von einer „vorhandenen API" nahelegt. Real vorhanden sind ein JSON-Projektformat mit Export und Import, ein CAD-Import über JSON und XML, PDF-Erzeugung, eine KI-gestützte Plan- und Dokumentenanalyse über einen gemeinsamen Eingang, ein BKI-Import mit Zertifikatsexport, CSV- und ZIP-Ausgaben sowie einzelne HTTP-Endpunkte für Projekte, Passveröffentlichung und den öffentlichen Passabruf. Die Pass-Artefakte im XML- und IFC-Format werden von einem Wächter-Check geprüft; der Zertifikatsexport trägt die Pflichtangaben nach § 85 maschinenlesbar. IFC ist dabei ausdrücklich als Eingang ohne Ausgang gekennzeichnet. Nicht vorhanden ist die dokumentierte Service-API des Pflichtenhefts, ebenso wenig die Service-Trennung nach Rechnern, Agenten und Wächter oder ein geschlossenes Modul für weitere Exportformate; diese Punkte sind als offen geführt.

Ziel. Aus einer Sammlung gewachsener Endpunkte wird eine versionierte Schnittstellenschicht mit definierten Exportprofilen, die auf dem kanonischen Datenmodell aufsetzen und dieses nach außen übersetzen, ohne es zu verändern.

Arbeitspakete. Kern der Stufe ist die Übersetzungsarchitektur: internes Datenmodell, Mapping, externes Format. Das interne Modell bleibt stabil, während je Empfänger ein Profil definiert wird — Energieausweis, Renovierungspass, Bank, Makler, Behörde, Statistik. Jedes Profil legt fest, welche Felder es enthält, in welcher Einheit, mit welcher Herkunftsangabe und mit welcher Mindestvertrauensstufe. Die Formate folgen den Leitlinien: CSV, JSON und XML sind maschinenlesbar, ein gescanntes PDF genügt ausdrücklich nicht. Für den Ausweis ist Maschinenlesbarkeit Pflicht; für den Renovierungspass ist sie Empfehlung, nicht Pflicht — verlangt sind dort digitale und druckfähige Form. Diese Unterscheidung ist einzuhalten, damit die Roadmap keine Pflicht behauptet, die es nicht gibt.

• API-Versionierung von Beginn an. Jede Schnittstelle wird unter einer expliziten Version geführt, damit spätere Änderungen bestehende Integrationen nicht brechen. Das ist bei einer Plattform, deren Rechtsgrundlage sich in bekannten Abständen ändert, keine Vorsichtsmaßnahme, sondern Voraussetzung.
• Rohdatenhaltung nach Artikel 20 Absatz 8. Die Registrierung eines Ausweises verlangt den vollständigen Ausweis einschließlich aller Berechnungs-Eingangsdaten. Die Auslegung nennt als Mindestumfang Gebäudekategorie, Bezugsfläche mit Aufschlüsselung bei Mischnutzung, den nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Anlagentechnik disaggregierten Bedarf, Leistung und Effizienz der technischen Anlagen, die Leistung der Erneuerbaren-Erzeugung sowie Flächen und U-Werte der Hauptbauteile. Diese Daten liegen im Gebäudepass bereits vor; sie sind lediglich als geschlossenes Exportpaket zusammenzufassen. Das Vorbild ist ausdrücklich vorhanden: Dänemark und Portugal speichern keine PDF-Dokumente, sondern erzeugen den Ausweis aus den Rohdaten.
• Testkonnektor statt Vorwegnahme. Solange verbindliche staatliche Schnittstellen fehlen, arbeitet die Plattform gegen einen simulierten Empfänger. Damit lassen sich Exportpaket, Authentifizierung, Fehlerbehandlung und Protokollierung vollständig entwickeln und prüfen, ohne die reale Schnittstelle zu erfinden. Wird das Schema veröffentlicht, ist nur der Connector anzupassen.
• Hygiene der Dokumenterzeugung. Das Öffnen des Gebäudepasses löst heute über den automatischen Dokumentenlauf ungefragt die Erzeugung und den Upload von PDF-Dokumenten aus, ohne dass der Nutzer sie angefordert hätte. Vor der Öffnung nach außen ist dieses Verhalten auf eine ausdrückliche Nutzeraktion umzustellen — sonst erzeugt jede spätere Rollen- und Freigabelogik Dokumente, deren Entstehung niemand veranlasst hat.
• IFC-Ausgang. Der bislang einseitige BIM-Weg wird um einen Ausgang ergänzt, soweit die Bauteil- und Mengendaten dies tragen. Diese Arbeit zahlt unmittelbar auf Stufe 5 ein, weil die Rohdatenbasis der Ökobilanz die Massenermittlung ist.

Voraussetzungen. Der stabile Feldkatalog aus Stufe 1 — ein Exportprofil auf einem beweglichen Feldbestand ist wertlos — sowie die inhaltliche Vollständigkeit der beiden Fachinstrumente aus Stufe 2.

Abhängigkeit von externen Spezifikationen. Für die internen Profile keine. Für die Ausgabe an staatliche Empfänger vollständig: Das Datenformat nach § 88b und das DIBt-Kontrolldatei-Schema für Monatswerte sind nicht veröffentlicht; bis dahin sind Monatszeilen im bisherigen Periodenformat zu übergeben.

Abschlusskriterium. Jedes Exportprofil erzeugt aus dem kanonischen Datenmodell eine maschinenlesbare Ausgabe mit Feldherkunft, Vertrauensstufe, Normfassung und Rechtsstand; der Testkonnektor durchläuft den vollständigen Übertragungsweg einschließlich Fehlerfällen; die Schnittstellendokumentation ist versioniert und wird vom Funktions-Wächter gegen den tatsächlichen Feldbestand geprüft.

14.6 Stufe 4 — Rollen für Banken, Makler und Hausverwaltungen

Ausgangslage. Hier ist die Differenz zwischen Anschein und Wirklichkeit am größten und muss deutlich benannt werden. Vorhanden sind ein öffentlicher Passzugang über eine Kennung mit vierstelliger PIN, gestaffelter Sperre nach je drei Fehlversuchen und QR-Druck ohne PIN, ein schreibgeschützter Demonstrationspass sowie Anzeige-Rollen auf der Kennwerte-Seite — alle Werte, Architekt, Makler, Hausverwaltung, TGA-Planer, Bank, Energieberater — mit eigener Gruppenreihenfolge und Priorisierung. Diese Anzeige-Rollen steuern die Darstellung, sie sind keine Rechteschicht. Das abgestufte Zugriffsrollenmodell von der Öffentlichkeit über Interessenten, Makler, Bank, Hausverwaltung und Energieberater bis zum Eigentümer ist seit dem 23. August 2026 vorhanden, ebenso die Durchsetzung der Rollen; diese Stufe ist damit im Kern erreicht. Offen bleiben die Konfliktauflösung, digitale Signaturen je Freigabe und die datenschutzrechtliche Vorprüfung. Der Snapshot des öffentlichen Passes wird immerhin bereits um personenbezogene Daten bereinigt.

Ziel. Aus einer Fachanwendung mit einem öffentlichen Ausschnitt wird eine Plattform mit abgestuften, protokollierten und zeitlich begrenzten Zugriffsrechten, die der Eigentümer selbst vergibt.

Arbeitspakete. Die Rechteschicht wird nicht als Sichtfilter, sondern auf Datenbereichsebene gebaut: Ein Recht gilt für eine Menge von Feldern, nicht für eine Seite. Der Eigentümer erhält die Gesamtübersicht, die Gebäudechronik, die Dokumente, die Sanierungsplanung und die Freigabeverwaltung, mit der er steuert, wer welchen Ausschnitt wie lange sieht. Der Energieberater erhält die volle fachliche Tiefe einschließlich Berechnungsmodulen, Datenqualitätsinformationen und Bearbeitungsrechten. Die Bankensicht bleibt bewusst schmal und standardisiert: Effizienzklasse, End- und Primärenergie, Emissionen, Sanierungsbedarf, Investitionsbedarf, Förderfähigkeit und — als eigenständige Angabe — die Datenqualität. Die Rechtsgrundlage dafür ist keine Marktkonvention, sondern Artikel 22, der Finanzinstituten den kostenlosen, maschinenlesbaren und zugleich druckbaren Zugriff auf den vollständigen Ausweis auf Portfolioebene zuweist, und Artikel 16, der für andere Berechtigte als Eigentümer, Mieter und Verwalter Gebühren zulässt. Die Maklersicht umfasst Ausweis, Baujahr, Wärmeerzeugung, Sanierungshistorie und die ausdrücklich freigegebenen Gebäudedaten; Rechnungen und Finanzierungsdaten bleiben verborgen. Die Hausverwaltung erhält die technische Objektakte mit Anlagen, Wartung, Prüfungen, Verbrauch und Modernisierungshistorie.

Drei Punkte sind dabei nicht verhandelbar. Erstens sind Freigaben zeitlich zu befristen; die Leitlinien empfehlen für Experten und Kauf- oder Mietinteressenten ausdrücklich befristeten Zugang, gegebenenfalls als reine Bildschirmansicht. Zweitens verlangt das Kontrollsystem nach Anhang VI, dass der Urheber jeder Hinzufügung und jeder Änderung für die Behörden ermittelbar bleibt — die Governance-Schicht des Gebäudepasses liefert diese Nachweiskette bereits, sie muss lediglich in die Zugriffsprotokollierung verlängert werden. Drittens ist die datenschutzrechtliche Vorprüfung nachzuholen, bevor Dritten Zugriff eingeräumt wird; Datenschutz-Grundverordnung und Data Governance Act verlangen abgestuften Zugang und Datenschutz durch Technikgestaltung. Kapitel 9 behandelt diesen Komplex im Einzelnen.

Voraussetzungen. Die Exportprofile aus Stufe 3 — eine Rolle ist technisch nichts anderes als ein Profil mit Zugriffsregel — sowie die bereinigten Schreibpfade aus Stufe 1, weil sonst nicht sicher entschieden werden kann, welcher Wert überhaupt freigegeben wird.

Abhängigkeit von externen Spezifikationen. Keine. Diese Stufe ist vollständig aus eigener Kraft umsetzbar und gleichzeitig diejenige mit dem größten Marktnutzen. Sie sollte deshalb nicht hinter die blockierten Stufen zurückgestellt werden.

Abschlusskriterium. Sieben Rollen mit erzwungenen Rechten auf Datenbereichsebene, vom Eigentümer vergebene und befristete Freigabepakete je Empfängertyp, vollständige Zugriffsprotokollierung mit ermittelbarem Urheber jeder Änderung, dokumentierte Datenschutz-Vorprüfung — und ein automatischer Prüffall, der nachweist, dass keine Rolle Felder sieht, die ihr Profil nicht enthält.

14.7 Stufe 5 — Lebenszyklus-GWP, ESG-Kennzahlen und Finanzierungsevidenz

Ausgangslage. Die Ökobilanz ist der Bereich mit der größten Lücke zwischen Anzeige und Substanz. Im Pass ist eine LCA-Kachel aktiv, und für Nichtwohngebäude wird der projektspezifische QNG-Anforderungswert gegen eine amtlich verifizierte Wertetabelle gerechnet. Der Ökobilanz-Agent selbst ist jedoch nur teilweise umgesetzt: Er bildet heute den Betrieb ab und setzt für die grauen Emissionen einen geschätzten Benchmark von 500 kg/m² an. Offen sind die echte Berechnung aus Bauteilflächen, Materialmengen und EPD-Datensätzen sowie die Unterscheidung zwischen Neubau- und Sanierungs-Bilanzlogik. Bemerkenswert und ausdrücklich richtig ist die vorhandene Trennung der drei CO₂-Karten — Ausweis, Betriebsbilanz und Ökobilanz — ohne zusammengeführten Gesamtwert, abgesichert durch einen eigenen Prüffall. Auf der Finanzierungsseite existieren ein Leistbarkeits-Check mit Varianten und Tilgungsplan, eine Förder-Matrix und ein automatisch erzeugter Finanzierungsbericht; der Leistbarkeits-Check ist allerdings bislang nicht an den Projektspeicher angebunden.

Ziel. Der Gebäudepass liefert den Lebenszyklus-Treibhausgaswert nach den europäisch festgelegten Systemgrenzen, stellt daraus und aus den Betriebsdaten transparente Einzelindikatoren bereit und fasst sie zu einem nachvollziehbaren Evidenzpaket für Finanzierungsentscheidungen zusammen.

Arbeitspakete. Die Ökobilanz folgt Artikel 7 und Anhang III in der Fassung der Delegierten Verordnung (EU) 2026/52: Systemgrenzen nach EN 15978, Bezugszeitraum 50 Jahre, Einheit kg CO₂eq je Quadratmeter Nutzfläche nach IPMS, Bilanzstand „as built" mit Schätzung vor Baubeginn und Bestätigung danach. Pflichtmodule sind A1–A5, B1–B4, B6 sowie C1–C4, D1 und D2; B5, B7 und B8 sind optional. Im Ausweis erfolgt die Ausweisung je Phasengruppe zuzüglich Gesamtwert. Die Datenhierarchie ist ebenfalls vorgegeben: Bauprodukte-Verordnung vor Ökodesign, dann projekt- und produktspezifische Daten, dann generische Daten nach EN 15804 mit der Ökobaudat als Fast-Track und zuletzt Vorgabewerte. Der geschätzte Pauschalwert für graue Emissionen wird damit ersetzt — nicht durch einen anderen Pauschalwert, sondern durch eine Massenermittlung aus dem Bauteilmodell. Annex 13 der Leitlinien liefert dafür bereits ein maschinenlesbares Standard-Gebäudedokument mit Projektkennung, Typologie, Bewertungstyp, Flächen, Geokoordinaten, GWP je Modul, biogenem Kohlenstoff, einer Datenqualitätsmetrik und dem Photovoltaik-Szenario; dieses Feldmodell ist die naheliegende Zielstruktur des LCA-Exports.

Für die ESG-Ebene gilt die Regel, die die Plattform bei den CO₂-Karten bereits befolgt: keine Zusammenführung zu einem undurchsichtigen Gesamtwert. Bereitgestellt werden transparente Teilinformationen — Energie mit Klasse sowie End- und Primärenergie, Emissionen mit betrieblicher Bilanz und Lebenszykluswert, Transformation mit Sanierungsfahrplan und Investitionsbedarf, Datenqualität mit Vollständigkeit und Nachweisgüte. Banken und Investoren verarbeiten diese Angaben nach ihren eigenen Modellen weiter; die Plattform liefert Belege, keine Bewertung. Der Building Trust Index ist dafür der passende Rahmen, weil er ausdrücklich kein Energie-, Banken- oder Bonitätsscore ist, sondern Datenqualität und technischen Zustand bewertet, und weil jeder Punktbeitrag seiner sieben Säulen einzeln nachvollziehbar bleibt. Zwei Einschränkungen sind mitzuführen: Die Wartungssäule steht bei null, solange Dokumente und Wartungen nicht verdrahtet sind, und die Kalibrierung mit Echtprojekten steht aus.

Das Evidenzpaket für die Finanzierungsseite fasst diese Bestandteile zusammen: Gebäudeidentität, Ausweis, technischer Zustand, Investitionsbedarf, Renovierungspfad, Emissionen und Datenqualität. Es ist kein neues Dokument, sondern ein Exportprofil aus Stufe 3 mit einer Zugriffsregel aus Stufe 4 — was zeigt, warum diese Stufe hinter jenen liegt. Vorbereitend anzubinden ist der Leistbarkeits-Check an den Projektspeicher, damit die Wirtschaftlichkeitsrechnung dieselben Gebäudedaten verwendet wie die Bilanzierung.

Voraussetzungen. Bauteil- und Mengendaten in ausreichender Tiefe, also die Verknüpfung von Geometrie und Bauteilen als Passknoten, die bislang nur teilweise besteht; ferner die Exportprofile und die Rechteschicht der vorangehenden Stufen.

Abhängigkeit von externen Spezifikationen. Teilweise. Die europäische Berechnungsvorgabe liegt vollständig vor und ist damit sofort umsetzbar. Nicht vorhanden sind das deutsche Datenformat nach § 88b für den Lebenszyklusbericht im Ausweis und die nationalen GWP-Grenzwerte; der Fahrplan der Mitgliedstaaten ist zum 01.01.2027 fällig, erste Grenzwerte spätestens zum 01.01.2030, anschließend degressiv. Die Berechnung ist also baubar, die Bewertung gegen einen Grenzwert noch nicht. Für den Bestand besteht ohnehin keine GWP-Pflicht; sie entsteht lediglich mittelbar bei einer Sanierung auf die freiwillige Klasse A+.

Abschlusskriterium. Ein aus Materialmengen und EPD-Datensätzen berechneter Lebenszykluswert je Pflichtmodul, getrennt nach Neubau- und Sanierungslogik, mit ausgewiesener Datenqualität und Datenhierarchiestufe je Position; ein ESG-Export ohne aggregierten Gesamtscore; ein Evidenzpaket, das ausschließlich freigegebene Werte enthält. Zeitlicher Anker ist der 01.01.2028 für Neubauten über 1 000 m², der 01.01.2030 für alle Neubauten.

14.8 Stufe 6 — Digitaler Zwilling und Betriebsdaten

Ausgangslage. Die Plattform bildet bislang berechnete und ereignisbezogene Zustände ab. Eine Verbrauchshistorie existiert und wird im Pass aus der ausgewerteten Historie dargestellt, nicht aus der Rechen-Engine; Anlagenmerkmale wie Photovoltaik-Bestand, Wallbox, Smart Meter und Energiemanagement fließen bereits in die Zukunftsfähigkeitssäule des Building Trust Index ein. Was fehlt, ist die Zeitreihenebene: Betriebsdaten sind keine Stammdaten, sie brauchen eine eigene Speicherstruktur mit Zeitstempel, Messstelle, Einheit, Messverfahren und Datenqualität. Beim CO₂-Agenten ist genau das als offener Punkt vermerkt — gemessener Verbrauch und Photovoltaik-Ertragsdaten statt Pauschalen.

Ziel. Das berechnete Gebäude wird mit dem betriebenen Gebäude verbunden, sodass Abweichungen zwischen Bedarf und Verbrauch systematisch erkennbar werden und der Pass von einer einmaligen Planungsdokumentation zu einem fortlaufenden Qualitätsprozess wird.

Arbeitspakete. Erforderlich sind ein Zeitreihenspeicher für Strom- und Wärmemengen, Photovoltaik-Ertrag, Vorlauf- und Raumtemperaturen; ein Importweg für Messdaten aus Zählern, Wechselrichtern, Wärmepumpen, Speichern und Gebäudeautomation; und ein Soll-Ist-Abgleich, der den nach DIN V 18599 berechneten Bedarf dem gemessenen Verbrauch gegenüberstellt. Dieser Abgleich ist fachlich anspruchsvoller, als er wirkt, weil Bedarf und Verbrauch unterschiedliche Randbedingungen haben — Nutzung, Klima, Innentemperatur. Jede Abweichungsmeldung muss deshalb die Vergleichsbasis offenlegen und die gerechnete Normfassung benennen. Ein Beispiel für den Nutzen: Liegt die gemessene Jahresarbeitszahl einer Wärmepumpe deutlich unter dem nach VDI 4650 ausgelegten Wert, erzeugt das System keinen Fehler, sondern einen Prüfhinweis zur Betriebsoptimierung — und dokumentiert ihn in der Gebäudechronik.

In derselben Stufe werden die Smart-Readiness-nahen Daten erfasst: Gebäudeautomation, Energiemanagement, Speicher, steuerbare Lasten und Ladeinfrastruktur. Dabei ist die rechtliche Lage genau abzubilden. Artikel 13 Absatz 11 verlangt seit dem 29.05.2026 für neue Wohngebäude und für Wohngebäude bei größerer Renovierung ein elektronisches Monitoring mit Effizienzwarnung, Steuerfunktionen und Demand-Response-Fähigkeit, mit möglicher Ausnahme für Einfamilienhäuser; wo Gebäudeautomation nach diesen Absätzen vorhanden ist, entfällt die Inspektionspflicht nach den Artikeln 23 und 24. Der Smart Readiness Indicator dagegen ist bislang kein Pflichtinhalt: Die Kommission berichtet bis zum 30.06.2026, eine Pflicht entsteht erst durch delegierten Rechtsakt bis zum 30.06.2027 und dann nur für Nichtwohngebäude über 290 kW. Im Ausweis ist der SRI derzeit ein Feld „Ja/Nein zuzüglich Wert" — ein Platzhalter, kein Rechenmodul. Die Roadmap sollte diesen Platzhalter genau so behandeln.

Voraussetzungen. Ein stabiler Kennwertkatalog, weil ein Soll-Ist-Vergleich zwei sauber definierte Größen braucht; die Rechteschicht, weil Betriebsdaten personenbeziehbar sind und der Zugriff darauf enger zu fassen ist als der auf Gebäudestammdaten.

Abhängigkeit von externen Spezifikationen. Mittel. Das deutsche SRI-Schema ist offen; die Abgrenzung zwischen statischen Gebäudesystemdaten nach Artikel 16 und dynamischen Daten vernetzter Produkte, die unter den Data Act (Verordnung (EU) 2023/2854, anwendbar seit dem 12.09.2025) fallen, ist in der deutschen Umsetzung ebenfalls als offener Punkt geführt. Abrechnungszähler unterliegen ohnehin den Strom- und Gasrichtlinien. Der Zeitreihenspeicher und der Soll-Ist-Abgleich sind davon unabhängig baubar; die SRI-Bewertung ist es nicht.

Abschlusskriterium. Messdaten werden regelmäßig importiert, mit Herkunft und Qualität versehen und dem berechneten Bedarf gegenübergestellt; Abweichungen oberhalb definierter Schwellen erzeugen nachvollziehbare Prüfhinweise; die Smart-Readiness-Felder sind erfasst und als Feld ohne Bewertungspflicht gekennzeichnet. Zeitlicher Anker ist der 31.12.2029 für die Automationspflicht bei Nichtwohngebäuden über 70 kW.

14.9 Stufe 7 — Nationale und europäische Registeranbindung

Ausgangslage. Die Plattform besitzt eine eigene, idempotente und dauerhafte Gebäudekennung im Format DG-JJJJ-NNNNNNNN sowie eine deterministisch abgeleitete interne Ausweisnummer, die ausdrücklich keine DIBt-Nummer ist. Ein Push-Endpunkt für Projektdaten existiert. Nicht vorhanden sind der Katasterbezug, die konzipierten Kennungsschemata der Passkarte, NFC und maschinenlesbare Zone; die Wallet-Routen für Apple und Google existieren, die Zertifikate stehen aus. Auf der Gegenseite fehlt der Empfänger: Deutschland hat nach Annex 5 der Leitlinien keine nationale Energieausweis-Datenbank.

Ziel. Der Gebäudepass ist anschlussfähig an die künftige nationale Dateninfrastruktur — mit einem eigenen Connector je externem System, der ausschließlich auf standardisierten internen Exportprofilen aufsetzt, sodass das interne Datenmodell von den externen Systemen unabhängig bleibt.

Arbeitspakete. Zu bauen sind eine Connector-Architektur mit getrennten Adaptern für Ausweisregister, nationale Gebäudedatenbank und Förderstellen; ein Identifikatoren-Mapping, das die interne Gebäudekennung mit den künftigen amtlichen Kennungen verbindet — Artikel 22 verlangt eindeutige Gebäude- und Einheiten-Kennungen mit Geobezug, datenbankübergreifend und „von Anfang an", sowie nach Absatz 7 Interoperabilität mit Kataster und Grundbuch und mit digitalen Gebäudelogbüchern; eine vollständige Übertragungsprotokollierung, die dem Kontrollsystem nach Anhang VI genügt; und die Zuordnung der Zugriffsstufen: Eigentümer, Mieter und Verwalter sowie Finanzinstitute auf Portfolioebene erhalten den vollständigen Ausweis kostenlos in maschinenlesbarer und druckbarer Form, unabhängige Experten und Kauf- oder Mietinteressenten nur mit Erlaubnis des Eigentümers, Kommunen Gebietsdaten mit Geoinformationsbezug für die Wärmeplanung, die Öffentlichkeit aggregierte und anonymisierte Auswertungen mindestens zweimal jährlich, die Forschung auf Anfrage.

Für die europäische Ebene folgt daraus eine wichtige Einschränkung des Anspruchs. Die Übertragung an das EU Building Stock Observatory erfolgt nach Artikel 22 mindestens jährlich über die nationale Gebäudedatenbank und mit den Vorlagen der Durchführungsverordnung (EU) 2025/1328. Eine unmittelbare europäische Anbindung eines einzelnen privatwirtschaftlichen Gebäudepasses ist damit nicht das Ziel und wäre auch nicht der vorgesehene Weg. Maßgeblich ist die Anschlussfähigkeit an die jeweilige nationale Dateninfrastruktur — und die europäische Interoperabilität ergibt sich daraus, dass alle nationalen Datenbanken dieselben Vorlagen bedienen.

Voraussetzungen. Alle vorangehenden Stufen. Ohne Feldkatalog fehlt die Zuordnung, ohne Exportprofil das Übertragungspaket, ohne Rechteschicht die Freigabe — diese Voraussetzung ist seit dem 23. August 2026 erfüllt —, ohne Rohdatenhaltung die von Artikel 20 Absatz 8 geforderte Vollständigkeit.

Abhängigkeit von externen Spezifikationen. Vollständig. Diese Stufe ist die einzige, deren Abschluss nicht in der eigenen Hand liegt.

Abschlusskriterium. Zweistufig, und diese Zweistufigkeit ist der eigentliche Punkt. Vorbereitungskriterium, ohne externe Spezifikation erreichbar: Das vollständige Rohdatenpaket nach Artikel 20 Absatz 8 wird erzeugt, gegen den Testkonnektor übertragen, protokolliert und quittiert; die Gebäudekennung ist geobezogen und für ein amtliches Mapping vorbereitet. Abschlusskriterium, erst nach Veröffentlichung erreichbar: Ein produktiver Connector überträgt Ausweise und Renovierungspässe in das nationale Register, erhält eine amtliche Registriernummer zurück und schreibt sie in den Gebäudedatensatz.

14.10 Querschnitt: Prüfung, Compliance und Regulatory Watch

Neben den sieben Fachstufen läuft ein Querschnittsstrang, der bereits mit Stufe 1 beginnt und nicht endet. Auch hier ist der Ausgangspunkt besser als üblich. Der Funktions-Wächter ist von 116 auf 499 Prüfungen gewachsen; im Sollstand vom 17.08.2026 waren 493 von 495 Prüfungen grün, wobei die beiden roten bekannte Datenbefunde in Live-Projekten sind und keine Regression. Er läuft nächtlich, zusätzlich als Schnellprüfung nach jedem Serverstart, und archiviert seine Läufe. Ergänzend prüft ein Quellen-Abgleich mit sechs Regeln die inneren Widersprüche der Daten, während der Wächter den Code prüft; überschrieben wird dabei nichts automatisch. Die Validierungsfälle nach DIN V 18599 umfassen zum Stand 17.08.2026 34 Fälle mit 964 geprüften Größen, von denen keine außerhalb der Ein-Prozent-Toleranz liegt, mit Teilabnahme für die Wärmepumpenfälle und einem Prüfbericht, der die Prüfsummen der sechs Rechenkerne trägt. Eine Testgebäudebibliothek ist damit bereits vorhanden — acht Testgebäude mit eingefrorenen Sollwerten.

Zu ergänzen ist die regulatorische Rückverfolgbarkeit: Jede neue Funktion erhält eine Anforderungskennung, einen Testfall, ein erwartetes Ergebnis, eine Softwareversion und einen Regressionstest. Der Nutzen zeigt sich bei Rechtsänderungen. Ändert sich etwa ein Primärenergiefaktor, muss das System selbst feststellen können, welche Testfälle erneut laufen müssen — betroffen wären Ausweis, Bilanzierung, Förderprüfung und Sanierungsvarianten. Der bereits vollzogene Faktorwechsel zum Rechtsstand 2027 zeigt den Umfang: Strom von 1,8 auf 1,5, Kohlendioxid von 560 auf 100 Gramm, Holz von 0,2 auf 0,7, Fernwärme von 1,3 auf 0,7. Ohne automatische Betroffenheitsanalyse ist bei jeder solchen Änderung offen, welche Ergebnisse noch gelten.

Die Beobachtung der Rechtslage ist dabei kein zu planendes Vorhaben mehr, sondern ein laufender Betrieb: Ein EPBD- und GMoDG-Monitor überwacht 18 amtliche Quellen, läuft täglich, verfügt über ein eigenes Dashboard und schlägt seit dem 12.08.2026 nicht mehr am Seitentext-Hash, sondern am fachlichen Fingerabdruck an. Sein Anforderungsprofil enthält acht Statusklassen, dreizehn Pflichtfelder je überwachter Funktion, gestaffelte Vorlaufwarnungen von 180 Tagen bis zu einem Tag, die Dreiteilung der Verbindlichkeit und die Trennung von Veröffentlichungs-, Inkrafttretens-, Anwendungs- und Produktivdatum. Der Leitsatz dieses Verfahrens — die Maschine schlägt vor, der Mensch entscheidet — gilt für die gesamte Roadmap. Zu ergänzen ist die Rückverkettung: Von der erkannten Änderung über die Anforderungskennung zu den betroffenen Datenfeldern, den betroffenen Berechnungen, der Softwareänderung, den Testfällen, der Freigabe und der neuen Version. Erst diese Kette macht regulatorische Wartung revisionsfähig.

14.11 Parallelisierbarkeit, Meilensteine und Grenzen der Gleichzeitigkeit

Die Stufenfolge beschreibt Abhängigkeiten, keine strenge zeitliche Serialisierung. Vier Arbeitsstränge lassen sich weitgehend nebeneinander führen: ein regulatorischer Strang mit Anforderungs-Mapping, Renovierungspass und Registervorbereitung; ein Datenstrang mit Feldkatalog, Datenqualität und Versionierung; ein Marktstrang mit Rollen, Freigaben und Empfängerprofilen; und ein technischer Strang mit Schnittstellen, BIM-Anbindung und Betriebsdaten. Die Stränge treffen sich an definierten Punkten, an denen ein Zwischenergebnis des einen die Voraussetzung des anderen ist.

Zwei Abhängigkeiten dürfen dabei nicht aufgelöst werden. Ein Bankenexport darf erst standardisiert werden, wenn der zugrunde liegende Feldkatalog stabil ist — sonst entsteht eine Außenwirkung auf einem beweglichen Fundament, und jede spätere Definitionsänderung wird zu einer Änderung mit Vertragsfolgen. Und ein Renovierungspass darf nicht endgültig ausprogrammiert werden, bevor sein Datenmodell vollständig definiert ist, weil die Pflichtfelder des Anhangs VIII sonst als Anzeigelogik statt als Datensatz entstehen und für Export und Register nicht verfügbar sind.

Über die Stufen hinweg lassen sich fünf strategische Meilensteine benennen. Der erste ist das formalisierte Gebäudemodell: Jedes relevante Gebäudedatum besitzt eine eindeutige Definition, eine Herkunft und genau einen schreibenden Zugriffspfad. Der zweite ist ein EPBD-tauglicher Kern aus Datenmodell, Ausweis, Renovierungspass, Versionierung, maschinenlesbaren Ausgaben und Anforderungsmatrix — wobei dieser Begriff ein interner Entwicklungsbegriff ist und keine amtliche Bestätigung; eine EPBD-Konformität kann erst behauptet werden, wenn die nationalen Ausführungsregelungen, Datenstandards und Prüfprozesse feststehen. Der dritte Meilenstein ist erreicht, wenn Eigentümer, Berater, Banken, Makler und Verwaltungen mit unterschiedlichen Rechten auf denselben Gebäudedatensatz zugreifen; erst dann ist aus der Fachsoftware eine Plattform geworden. Der vierte ist die Integration realer Betriebsdaten, die den Begriff des digitalen Zwillings technisch trägt statt ihn nur zu verwenden. Der fünfte ist die Verbindung zur öffentlichen Dateninfrastruktur — der einzige Meilenstein, dessen Eintritt nicht in der eigenen Hand liegt.

14.12 Übersicht der Stufen und Priorisierung

Die folgende Tabelle fasst die sieben Stufen zusammen. Die Spalte „externer Blocker" ist dabei die wichtigste: Sie trennt das, was terminiert werden kann, von dem, was nur vorbereitet werden kann. Die Spalte „zeitlicher Anker" nennt die regulatorische Frist, an der sich die Stufe ausrichtet — nicht ein internes Wunschdatum.

Die Tabelle macht eine Asymmetrie sichtbar, die für die Priorisierung entscheidend ist: Von sieben Stufen sind nur zwei — Stufe 2 in ihrem Ausweisteil und Stufe 7 vollständig — wirklich von staatlichen Vorleistungen abhängig. Alles andere ist Eigenarbeit. Das ist eine gute Nachricht und zugleich eine Verpflichtung, weil sich die Verzögerung der übrigen Stufen nicht mit fehlenden Spezifikationen begründen lässt.

Daraus folgt die Priorisierung. Sofort und ohne jede externe Spezifikation gebaut werden können: der vollständige Feldkatalog mit Herkunft, Vertrauensstufe und Versionierung einschließlich der Bereinigung der 46 mehrfach beschriebenen Profilfelder; der Renovierungspass nach Anhang VIII, der europäisch vollständig spezifiziert ist und für den kein deutsches Ausführungsdokument abgewartet werden muss; die Rollen- und Rechteschicht mit eigentümergesteuerten, befristeten Freigaben, die den größten unmittelbaren Marktnutzen trägt und regulatorisch bereits seit dem 29.05.2026 unterlegt ist; das kanonische Datenmodell mit den Exportprofilen und der API-Versionierung; die vollständige Rohdatenhaltung nach Artikel 20 Absatz 8, die unabhängig vom Übertragungsweg ist und den Weg der Länder mit registerbasierter Ausweiserzeugung nachvollzieht; die Ökobilanz nach EN 15978 mit den Pflichtmodulen des Anhangs III, deren Berechnungsvorgabe seit der Delegierten Verordnung (EU) 2026/52 feststeht; der Zeitreihenspeicher mit Soll-Ist-Abgleich; sowie der Ausbau von Prüfinfrastruktur und Anforderungsverfolgung. Diese Arbeiten machen den überwiegenden Teil der Roadmap aus.

Nur vorbereitet, nicht abgeschlossen werden können: die amtliche Ausweisausgabe, die auf das Muster nach § 85 Absatz 3 wartet; die Klassenbildung für Nichtwohngebäude, die ohne die Klassengrenzen der Anlage 10a bewusst offen bleibt; der Lebenszyklusbericht im Ausweis, dem das Format nach § 88b fehlt; die SRI-Bewertung, deren Pflicht erst mit dem delegierten Rechtsakt und dann nur für Nichtwohngebäude über 290 kW entsteht; und die Registeranbindung insgesamt, für die in Deutschland weder Datenbank noch Schema existieren. Für diese fünf Punkte gilt dieselbe Regel: bis zur Schnittstellenkante bauen, die Kante klar benennen, den Testkonnektor als Ersatz verwenden und keinen Termin zusagen.

Die Roadmap endet damit nicht mit einem Zustand, sondern mit einem Verfahren. Gebäuderecht, Normen, Förderprogramme und technische Standards ändern sich in bekannten Abständen; die 2027 wirksam werdenden Faktoren und die Fristen bis 2030 sind nur der derzeit sichtbare Ausschnitt. Der strategische Vorteil einer nach Abhängigkeiten geordneten Entwicklung liegt genau darin, dass die Software nicht von einzelnen Rechtsänderungen getrieben wird, sondern eine stabile Plattform bildet, an die neue Anforderungen angebunden werden. Verdichtet lautet die Entwicklungsstrategie: vom fachlich vollständigen Gebäudemodell über standardisierte Anwendungen und abgestufte Rollen hin zu einer Plattform, die anschlussfähig ist, sobald die nationale Dateninfrastruktur entsteht. Eine grundlegende Neuentwicklung ist dafür nicht erforderlich — die technische Basis besteht. Erforderlich ist die Disziplin, die Reihenfolge einzuhalten und die Lücken als Lücken auszuweisen, statt sie zu füllen. Kapitel 16 beschreibt, wie diese Stufen in einem Pilotprojekt erprobt werden; Kapitel 17 behandelt die Risiken, die aus der Abhängigkeit von staatlichen Schnittstellen folgen.

15 Geschäftsmodell und Marktstrategie

Die Roadmap in Kapitel 14 beschreibt, was zu entwickeln ist. Dieses Kapitel beschreibt, wovon diese Entwicklung getragen werden soll. Es ordnet die Erlösquellen eines Gebäudedatenplattform-Modells, benennt für jede die Frage, wer zahlt und wofür, und prüft jede Erlösquelle an einer Grenze, die häufig übersehen wird: Artikel 16 EPBD stellt den Zugang zu den eigenen Gebäudedaten für Eigentümer, Mieter und Verwalter kostenfrei. Ein Geschäftsmodell, das genau diesen Zugang in Rechnung stellt, ist nicht tragfähig. Das Kapitel nennt keine Preise, keine Marktvolumina und keine Umsatzprognosen; die genannten Strukturen sind Modellannahmen, die mit Pilotdaten zu prüfen sind.

15.1 Ausgangspunkt: eine Plattform, kein Einzelprodukt

Der digitale Gebäudepass ist, wie die Kapitel 6 bis 8 zeigen, technisch keine einzelne Anwendung, sondern eine Datenschicht, auf der mehrere Anwendungen aufsetzen. Diese Eigenschaft hat unmittelbare wirtschaftliche Folgen. Bei einem Einzelprodukt lautet die Geschäftsmodellfrage schlicht, zu welchem Preis es wie oft verkauft wird. Bei einer Plattform lautet sie anders: Wie entsteht aus einem dauerhaft gepflegten Gebäudedatensatz ein wirtschaftlich tragfähiges Gefüge, in dem mehrere Nutzergruppen unterschiedliche Leistungen beziehen, ohne dass jede Gruppe für dieselbe Erfassungsarbeit erneut bezahlt?

Die Whitepaper-Gliederung nennt für dieses Gefüge sechs Bausteine: die Lizenz pro Gebäude, Partnerzugänge, Gebühren für Dokumente und Aktualisierungen, White-Label-Lösungen, Kooperationen mit Banken und Verbänden sowie die europäische Skalierung. Diese sechs Bausteine sind keine Alternativen, zwischen denen zu wählen wäre. Sie beschreiben unterschiedliche Ebenen desselben Modells: eine Ebene des einzelnen Gebäudes, eine Ebene der fachlichen Dienstleistung und eine Ebene der Plattform selbst. Erst ihre Kombination ergibt ein Modell, das nicht an einer einzigen Erlösquelle hängt.

Zwei Vorbemerkungen sind dabei erforderlich, damit das Kapitel nicht mehr behauptet, als belegbar ist. Erstens ist die Marktseite dieses Modells nicht quantifiziert. Es liegen weder eigene Marktforschungsdaten noch belastbare Preisbeobachtungen vor; jede Zahl, die hier genannt würde, wäre eine Setzung. Das Kapitel beschreibt deshalb Strukturen — welche Bezugsgröße für welche Leistung sinnvoll ist, wer sie trägt und welche Voraussetzung sie hat —, nicht Beträge. Zweitens ist die technische Seite unterschiedlich weit entwickelt. Einige der beschriebenen Erlösquellen setzen auf Funktionen auf, die produktiv sind; andere setzen auf Funktionen auf, die nach dem Entwicklungsstand in Kapitel 13 als Konzept geführt werden. Wo das der Fall ist, wird es im Text benannt und nicht durch die Beschreibung des Geschäftsmodells überdeckt.

15.2 Die rechtliche Grundbedingung: Artikel 16 EPBD

Vor jeder Überlegung zu Erlösquellen steht eine Regel, die den Zuschnitt des gesamten Modells bestimmt. Artikel 16 EPBD verlangt, dass Eigentümer, Mieter und Verwalter direkten und kostenlosen Zugang zu den Daten der Gebäudesysteme erhalten — auch über ein Konto in der nationalen Datenbank. Ebenso kostenlos ist die Weitergabe dieser Daten an Dritte, die diese Berechtigten selbst benennen. Erst gegenüber anderen Berechtigten — genannt sind Banken, Aggregatoren, Versorger und die Statistik — dürfen die Mitgliedstaaten Entgelte festlegen. Der Mindestumfang der Datenaustauschpflicht ist dabei nicht schmal: Er umfasst die Leistung der Bauteile, die gebäudetechnischen Dienste, die Lebensdauerprognose der Heizung, die Gebäudeautomation, Zähler, Mess- und Regelgeräte sowie Ladepunkte, und er ist im Richtlinientext ausdrücklich mit dem digitalen Gebäudelogbuch verknüpft.

Eine zweite Regel wirkt in dieselbe Richtung. Nach Artikel 22 EPBD erhalten aus der nationalen Gebäudedatenbank nicht nur Eigentümer, Mieter und Verwalter den vollständigen Energieausweis kostenlos, maschinenlesbar und zugleich als Druckdokument, sondern auf Portfolioebene auch Finanzinstitute. Für unabhängige Experten sowie Kauf- und Mietinteressenten ist der Zugang an die Erlaubnis des Eigentümers gebunden und wird als befristeter, gegebenenfalls auf die Bildschirmansicht beschränkter Zugriff empfohlen. Kommunen erhalten Gebietsdaten samt Geo-Referenz für die Wärmeplanung, die Öffentlichkeit erhält mindestens zweimal jährlich aggregierte und anonymisierte Daten, die Forschung erhält Daten auf Anfrage.

Adressat beider Regeln ist der Mitgliedstaat, nicht der private Plattformbetreiber; die Richtlinie erzeugt keine unmittelbare Pflicht für Private. Für das Geschäftsmodell ist das jedoch kein Freibrief, sondern das Gegenteil: Sobald die nationale Umsetzung diese Zugänge herstellt, existiert für den Eigentümer ein kostenfreier gesetzlicher Kanal zu seinen eigenen Gebäudedaten und zu seinem vollständigen Energieausweis. Ein privates Angebot, das denselben Zugang bepreist, konkurriert dann nicht mit anderen Anbietern, sondern mit einer unentgeltlichen staatlichen Leistung. Es kommt hinzu, dass der Gebäudepass sich nach dem eigenen EPBD-Anforderungskatalog als digitales Gebäudelogbuch im Sinne des Artikels 2 Nummer 41 EPBD versteht. Wer diese Rolle beansprucht, kann den Anspruch nicht auf die Vorteile beschränken: Artikel 12 Absatz 8 EPBD verlangt, dass ein Renovierungspass dort, wo ein Logbuch existiert, in diesem gespeichert oder über eine eindeutige Adresse zugänglich gemacht wird, und Artikel 22 Absatz 7 verlangt Interoperabilität des Registers mit Kataster, Grundbuch und digitalen Gebäudelogbüchern.

Aus dieser Grenze folgt eine Trennlinie, die sich durch das ganze Kapitel zieht: Speicherung und Zugang sind kein Produkt, Arbeit und Nachweisqualität sind es. Diese Trennlinie ist nicht nur rechtlich, sondern auch wirtschaftlich die richtige. Die Speicherung strukturierter Gebäudedaten ist der billigste Teil des Systems; die Herstellung ihrer Belastbarkeit ist der teuerste. Ein Modell, das die Grenze umgekehrt zieht — Zugang teuer, Qualität kostenlos —, würde genau den Teil verkaufen, der kaum Kosten verursacht, und genau den Teil verschenken, der die Kosten treibt. Abschnitt 15.10 kommt darauf zurück.

15.3 Der Vermögenswert ist der Datensatz, nicht das Dokument

Ein Energieausweis nach heutigem Verständnis ist ein abgeschlossenes Produkt. Er wird erstellt, ausgegeben und ist längstens zehn Jahre gültig (Artikel 19 EPBD). Was von ihm bleibt, ist ein Dokument; die Eingangsdaten, aus denen er gerechnet wurde, verbleiben in aller Regel beim Aussteller, in dessen Software und in dessen Projektablage. Wird zwei Jahre später eine Heizungsplanung, eine Förderberatung oder eine Finanzierungsanfrage bearbeitet, beginnt die Datenerfassung erneut.

Der Gebäudepass kehrt diese Reihenfolge um. Der Vermögenswert ist der dauerhaft gepflegte, strukturierte Gebäudedatensatz; das Dokument ist dessen Ausgabe. Diese Umkehrung ist kein rhetorisches Bild, sondern in der Richtlinie angelegt: Artikel 20 Absatz 8 EPBD verlangt, dass der Ausweis vollständig einschließlich aller Berechnungs-Eingangsdaten registriert wird, und in Dänemark und Portugal wird das Ausweisdokument gar nicht mehr gespeichert, sondern jeweils aus den Rohdaten erzeugt. Artikel 19 Absatz 14 Buchstabe c EPBD erklärt darüber hinaus die vereinfachte Aktualisierung des Ausweises über einen digitalen Zwilling oder zertifizierte Werkzeuge ausdrücklich für zulässig — das ist die Rechtsgrundlage dafür, dass ein gepflegter Gebäudedatensatz als Quelle des Ausweises dient.

Wirtschaftlich bedeutet das: Derselbe Datenbestand trägt über Jahre unterschiedliche Vorgänge — Energieausweis, Wärmeschutznachweis, Sanierungsplanung, Fördermittelantrag, Finanzierung, Verkauf, Vermietung, Verwaltung, technische Nachweise. Jeder dieser Vorgänge kostet in der klassischen Projektlogik eine eigene Bestandsaufnahme. Im Plattformmodell kostet er die Differenz: die Fortschreibung dessen, was sich seit dem letzten Vorgang geändert hat, und die fachliche Arbeit des Vorgangs selbst. Der wiederkehrende Nutzen entsteht nicht dadurch, dass Daten aufbewahrt werden, sondern dadurch, dass sie beim nächsten Anlass ohne Neuaufnahme verwendbar sind.

Damit verschiebt sich auch die Zeitachse der Kundenbeziehung. Die klassische Energieberatung folgt der Kette Auftrag, Berechnung, Bericht, Rechnung, Abschluss; die Beziehung endet mit dem Abschlussbericht. Der Gebäudepass folgt der Kette Gebäude anlegen, Daten erfassen, Pass aktivieren, fortschreiben, weitere Vorgänge anschließen. Ein Beratungsverhältnis, das 2026 mit einer Erstberatung beginnt, kann 2028 den Heizungstausch, 2030 die Fenster und 2032 die Fassade begleiten — nicht weil ein Vertrag es vorschreibt, sondern weil der Datenbestand jeden dieser Schritte billiger macht als einen Neubeginn. Diese Verschiebung ist der eigentliche Kern des Geschäftsmodells; alle folgenden Bausteine sind Ausprägungen davon.

15.4 Lizenz pro Gebäude: die kleinste wirtschaftliche Einheit

Als Grundbaustein bietet sich eine Nutzungslizenz je Gebäude an. Sie bepreist nicht die einzelne Datei, die einzelne Berechnung oder den einzelnen Abruf, sondern die dauerhafte Führung eines Gebäudedatensatzes: Stammdaten und Gebäudekennwerte, Dokumentenablage, Chronik, Aktualisierungshistorie und die Zugänge, über die der Pass sichtbar gemacht wird. Das Gebäude wird damit zur kleinsten wirtschaftlichen Einheit der Plattform — eine Bezugsgröße, die für alle Zielgruppen dieselbe ist und die sich sowohl im Einzelfall als auch im Bestand skalieren lässt.

Diese Bezugsgröße ist bereits technisch verankert. Der Gebäudepass vergibt eine persistente, idempotent erzeugte Gebäudekennung nach dem Muster DG-JJJJ-NNNNNNNN, die in einer eigenen, additiven Sektion des Projektdatensatzes zusammen mit Erstellungsdatum, Status und Version geführt wird. Die Veröffentlichung erzeugt einen bereinigten Momentaufnahme-Datensatz, der ausschließlich Gebäudekennwerte und keine personenbezogenen Daten enthält, und stellt ihn über eine öffentliche Passadresse mit vierstelliger Zugangsnummer bereit; gestaffelte Sperrzeiten nach jeweils drei Fehlversuchen sichern diesen Zugang ab, ein QR-Ausdruck und ein Kartenprodukt ergänzen ihn. Für die wirtschaftliche Modellierung heißt das: Die Einheit, die lizenziert würde, existiert bereits als technisches Objekt mit stabiler Kennung.

Bei der Ausgestaltung ist die Grenze aus Abschnitt 15.2 einzuhalten. Eine Gebäudelizenz darf nicht so konstruiert sein, dass mit ihrem Ende der Zugang des Eigentümers zu seinen eigenen Daten erlischt. Tragfähig ist die umgekehrte Konstruktion: Die Lizenz trägt die aktive Führung des Passes — Fortschreibung, Neuberechnung, Dokumenterzeugung, Freigabeverwaltung, Bereitstellung für Dritte —, während der Bestand der Daten und ihre Ausleitung in einem offenen Format dem Eigentümer unentziehbar bleiben. Der vorhandene JSON-Export des Projektformats ist dafür die technische Grundlage; er ist im Sinne dieses Modells kein Zusatzmerkmal, sondern eine Bedingung der Zulässigkeit.

Innerhalb dieser Konstruktion sind Leistungsstufen denkbar. Eine Basisstufe würde Gebäudedaten, Dokumentenablage, Energieausweis-Kennwerte und Chronik umfassen; eine Fachstufe zusätzlich Sanierungsplanung, Variantenvergleich, Fördermittel- und Wirtschaftlichkeitsbetrachtung; eine Bestandsstufe die Auswertung über mehrere Gebäude hinweg für Hausverwaltungen, Wohnungsunternehmen, Kommunen und Banken. Diese Staffelung ist eine Modellannahme, keine Beobachtung: Welche Funktionen die Zahlungsbereitschaft tatsächlich tragen, lässt sich erst im Pilotbetrieb nach Kapitel 16 feststellen. Belegbar ist nur die technische Anschlussfähigkeit — die Kennwerteseite des Passes führt bereits 43 Kennwerte mit Erklärtext, Fachbezug und Herkunftsplakette und blendet Anzeigeprofile für Architekten, Makler, Hausverwaltung, TGA-Planung, Bank und Energieberatung ein. Diese Profile sind allerdings eine Priorisierung der Darstellung und keine Rechteschicht; darauf kommt Abschnitt 15.6 zurück.

15.5 Ersterfassung, Fortschreibung und Dokumente

Wirtschaftlich sind zwei Leistungen sauber zu trennen, die technisch ineinander übergehen. Die initiale Digitalisierung ist die Erstaufnahme eines Gebäudes: Import und Auswertung vorhandener Unterlagen, Analyse von Plänen, Strukturierung der Daten in das Datenmodell, Plausibilisierung und, wo erforderlich, die Aufnahme vor Ort. Sie ist aufwandsgetrieben und hängt vom Zustand der vorhandenen Unterlagen ab, nicht von der Größe des Gebäudes allein. Die laufende Fortschreibung erfasst spätere Veränderungen — eine neue Heizung, eine Sanierungsmaßnahme, ein Eigentümerwechsel, ein neuer Energieausweis — und ist der Teil, der den Datensatz über die Jahre wertvoll hält.

Aus dieser Trennung folgt eine Kombination aus einmaliger und wiederkehrender Leistung, die zur Struktur der Regulierung passt. Artikel 19 Absatz 14 EPBD macht vereinfachte Aktualisierungen des Ausweises zur Pflicht der Mitgliedstaaten — nach einer Einzelmaßnahme, nach umgesetzten Schritten eines Renovierungspasses und über digitale Werkzeuge. Fortschreibung ist damit kein Zusatzwunsch, sondern der von der Richtlinie vorgesehene Regelfall. Ob eine Aktualisierung in einer laufenden Lizenz enthalten ist oder als eigene Leistung abgerechnet wird, ist eine Frage der Kundengruppe: Für Einzeleigentümer ist die anlassbezogene Abrechnung verständlicher, für Bestandshalter mit vielen Gebäuden ist die Pauschale kalkulierbarer.

Dokumente bleiben daneben ein sinnvoller Erlösbaustein — Energieausweis, Wärmeschutznachweis, Renovierungspass beziehungsweise Sanierungsfahrplan, Ökobilanzbericht, Bankenbericht. Der Unterschied zum klassischen Modell liegt nicht darin, dass diese Dokumente kostenlos würden, sondern darin, dass sie nicht mehr bei null beginnen. In der Plattform werden derzeit sieben Dokumente automatisch aus dem Datenbestand erzeugt: Bedarfsausweis, Wärmeschutznachweis, Grundriss, hydraulischer Abgleich, Heiz- und Kühllastbericht, Maßnahmenbericht und Finanzierungsbericht, jeweils mit einem Merker auf die Datengrundlage, sodass eine Neuerzeugung nur bei geänderten Daten erfolgt.

Gerade diese Automatik verlangt beim Geschäftsmodell Vorsicht. Der Entwicklungsstand hält fest, dass das Öffnen des Gebäudepasses den automatischen Dokumentenlauf auslöst und dabei ungefragt Dokumente erzeugt und ablegt. Solange das so ist, wäre eine Abrechnung je erzeugtem Dokument nicht vertretbar, weil sie Vorgänge bepreisen würde, die der Nutzer nicht ausgelöst hat. Eine dokumentenbezogene Bepreisung setzt deshalb voraus, dass die Erzeugung an eine bewusste Nutzeraktion gebunden wird — technisch eine kleine, wirtschaftlich eine notwendige Änderung.

Ebenso ist die rechtliche Reichweite der einzelnen Dokumente zu beachten, damit das Angebot nicht mehr verspricht, als es leisten darf. Der Energieausweis ist nach Artikel 19 und Artikel 25 EPBD von einem unabhängigen Experten auszustellen, ein Vor-Ort-Besuch ist erforderlich, virtuell nur mit Video-Sichtprüfung; die Registrierung erfolgt über die Datenbank nach Artikel 22 EPBD. Die im Pass geführte Ausweisnummer ist deterministisch aus der Gebäudekennung abgeleitet und ausdrücklich keine Registriernummer des Deutschen Instituts für Bautechnik. Für den geförderten individuellen Sanierungsfahrplan gilt, dass ein förderfähiges Dokument ausschließlich in der amtlichen Druckapplikation der BAFA entsteht; das Datenblatt der Plattform ist eine Ausgabe, kein Ersatz. Und der Ökobilanzbericht arbeitet derzeit für die grauen Emissionen mit einem geschätzten Vergleichswert, nicht mit einer Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen. Diese drei Punkte sind keine Randnotizen: Sie entscheiden darüber, welches Dokument als Nachweis verkauft werden darf und welches nur als Arbeitsstand.

15.6 Partnerzugänge: die Plattform als Arbeitsmittel der Fachpartner

Der wirksamste Skalierungshebel liegt nicht im Direktvertrieb an Eigentümer, sondern in Zugängen für Fachpartner: Energieberater, Architekten, Ingenieurbüros, Fachplanung der technischen Gebäudeausrüstung, Hausverwaltungen und Immobilienmakler. Diese Partner legen Gebäude selbst an, erfassen Daten und arbeiten in ihren eigenen Aufträgen mit der Plattform. Der Gebäudepass wird damit weniger ein Produkt, das man einem Eigentümer verkauft, als ein Werkzeug, das ein Fachpartner ohnehin benutzt und dessen Nebenprodukt der Pass ist.

Energieberater sind dabei die naheliegendste Gruppe. Sie haben Zugang zu Gebäude und Eigentümer, sie erheben die relevanten Daten in ihren Aufträgen ohnehin, und sie sind nach Artikel 25 EPBD die Personengruppe, die den Ausweis überhaupt ausstellen darf. Ein Partnerzugang, der es erlaubt, Gebäude anzulegen, Daten zu erfassen, Ausweise und Nachweise zu erzeugen, Sanierungsvarianten zu rechnen und Förderunterlagen zu verwalten, verändert dabei auch das Beratungsmodell: Der Berater hinterlässt seinem Kunden nicht nur einen Bericht, sondern einen weiterverwendbaren Datensatz — und bleibt damit für die folgenden Schritte der naheliegende Ansprechpartner.

Immobilienmakler erreichen einen anderen Punkt im Gebäudelebenszyklus, nämlich den Verkauf, der ohnehin einen Energieausweis auslöst und in dem die Pflichtangabe von Effizienzindikator und Klasse in der Anzeige verlangt ist. Für den Makler liegt der Nutzen weniger in der Energieberechnung als in der Verlässlichkeit der Angaben: weniger Rückfragen, belegte statt behaupteter Gebäudedaten, schneller verfügbare Energieinformationen und eine strukturierte Übergabe an den Käufer. Der Gebäudepass wirkt hier nicht als technisches Energieprodukt, sondern als Nachweisinstrument in der Transaktion. Zu beachten ist allerdings die Zugangsregel des Artikels 22 EPBD: Kauf- und Mietinteressenten erhalten Daten nur mit Erlaubnis des Eigentümers, empfohlen befristet und gegebenenfalls nur zur Bildschirmansicht. Ein Verkaufsprofil, das über den freigegebenen Umfang hinausgeht, ist deshalb kein Produktmerkmal, sondern ein Fehler.

Hausverwaltungen haben den längsten Anwendungsfall, weil sie Gebäude dauerhaft betreuen. Für sie bündelt der Pass technische Dokumentation, Wartung, Verbrauch, Modernisierung und Energieausweis an einer Stelle; die wirtschaftliche Bezugsgröße ist dann nicht das einzelne Gebäude, sondern der Bestand. Eine Portfoliolizenz nach Zahl der Gebäude, Zahl der Einheiten und Funktionsumfang bildet das ab. Für Wohnungsunternehmen tritt die bestandsweite Auswertung hinzu — Verteilung der Effizienzklassen, Heizungsbestand, Sanierungsstatus, Investitionsplanung, Emissionsentwicklung —, die durch den Bestandspfad des Artikels 9 EPBD zusätzlich an Bedeutung gewinnt: Von der Minderung um 16 Prozent bis 2030 müssen mindestens 55 Prozent aus den 43 Prozent schlechtesten Gebäuden kommen, was ein Kennzeichen für besonders schlecht abschneidende Gebäude im Datenmodell voraussetzt. Für Kommunen gilt dasselbe Muster mit anderem Bestand — Schulen, Sporthallen, Verwaltungsgebäude, Kindertagesstätten —, wobei die kommunale Nachfrage sich mit einer kostenfreien Leistung überschneiden kann, denn Gebietsdaten mit Geo-Referenz für die Wärmeplanung erhalten Kommunen nach Artikel 22 EPBD aus der nationalen Datenbank.

Ein Punkt darf bei alledem nicht überspielt werden. Partnerzugänge, Bestandslizenzen und Freigabepakete setzen eine belastbare Rechteschicht voraus — die ist seit dem 23. August 2026 vorhanden, das empfängerbezogene Freigabepaket dagegen noch nicht. Was existiert, sind Anzeigeprofile der Kennwerteseite, die die Reihenfolge und Auswahl der dargestellten Größen je Zielgruppe steuern. Das abgestufte Zugriffsrollenmodell von der Öffentlichkeit bis zum Eigentümer ist seit dem 23. August 2026 vorhanden und durchgesetzt. Das Schreibrollenmodell der Werkzeuge im Inneren ist seit dem 23. August 2026 ebenfalls erzwungen; die 55 Verstöße in 15 Werkzeugen sind abgearbeitet, 35 Registerfelder haben weiterhin mehrere schreibende Werkzeuge. Solange das so bleibt, sind Partner- und Portfoliozugänge konzipiert, aber nicht verkaufbar. Sie sind damit nicht eine Frage des Vertriebs, sondern eine Frage der Stufe 4 der Roadmap in Kapitel 14.

15.7 Banken: Berechtigte, Vertriebskanal und Grenze

Banken sind aus zwei Gründen eine besondere Zielgruppe. Erstens werden Energie- und Nachhaltigkeitsdaten für die Kreditwürdigkeitsbeurteilung und für das eigene Berichtswesen zunehmend relevant, was den Bedarf an strukturierten, nachvollziehbaren Gebäudedaten erhöht. Zweitens berühren Banken einen Moment im Gebäudelebenszyklus, in dem Datenlücken unmittelbar Kosten verursachen: den Finanzierungsantrag.

Für die Bank ist der vollständige Gebäudepass dabei nicht das richtige Produkt. Sinnvoller ist ein standardisiertes, klar abgegrenztes Gebäudeprofil, das die für die Kreditentscheidung relevanten Größen bündelt: Energieausweis und Effizienzklasse, technischer Zustand, Sanierungsbedarf, Investitionsbedarf, Transformationspfad und — als eigenständige Angabe — die Qualität der zugrunde liegenden Daten. Genau diese Kombination aus Ausweis, verifizierten Gebäudedaten, Investitionsfahrplan und Emissionsinformationen ist es, die auf Bankenseite nachgefragt wird. Damit kann sich auch die Reihenfolge des Vertriebs umkehren: Statt den Pass dem Eigentümer anzubieten und zu hoffen, dass die Bank ihn akzeptiert, veranlasst der Finanzierungsprozess seine Erstellung — eine Kreditanfrage stößt auf fehlende Gebäudedaten, der Pass wird angelegt, ein technischer Nachweisdatensatz entsteht, und die Bank erhält das vom Eigentümer freigegebene Profil.

Für die Erlösseite ergeben sich daraus Einzelabruf, nutzungsabhängige Schnittstellenentgelte, Portfolioverträge für definierte Kreditbestände und die Bereitstellung unter der Marke des Instituts. Drei Grenzen sind dabei einzuhalten, und sie sind enger, als die Aufzählung vermuten lässt.

• Die kostenfreie staatliche Leistung. Nach Artikel 22 EPBD erhalten Finanzinstitute den vollständigen Energieausweis auf Portfolioebene kostenlos aus der nationalen Datenbank. Entgeltfähig ist folglich nicht der Ausweis, sondern ausschließlich die darüber hinausgehende Aufbereitung — Zusammenführung, Prüfung, Investitionsfahrplan, Zeitreihe, Datenqualitätsaussage. Artikel 16 EPBD erlaubt Entgelte gegenüber Banken für die Gebäudesystemdaten; ein Modell, das dem Institut den Ausweis verkauft, den es ohnehin unentgeltlich bekommt, trägt nicht.
• Die Freigabe des Eigentümers. Die Weitergabe an die Bank ist ein vom Berechtigten benannter Dritter im Sinne des Artikels 16 EPBD; sie ist gegenüber dem Eigentümer kostenlos und ohne seine Freigabe unzulässig. Das Bankenprofil ist deshalb kein Datenprodukt der Plattform, sondern ein Freigabepaket des Eigentümers.
• Die Abgrenzung des Building Trust Index. Der in der Plattform umgesetzte Index bewertet auf einer Skala von 0 bis 100 die Qualität und Belastbarkeit der Gebäudedaten sowie den technischen Zustand über sieben gewichtete Säulen mit nachvollziehbaren Einzelbeiträgen. Er ist ausdrücklich kein Energie-Score, kein Bankenscore und kein Bonitätsscore, und er bewertet nicht den Eigentümer. Als Kennzeichen der Datenqualität ist er für Banken wertvoll; als Bonitätsmerkmal vermarktet, wäre er sachlich falsch und rechtlich heikel. Hinzu kommt, dass eine Säule — der Wartungszustand — derzeit null beiträgt, solange Dokumente und Wartungen nicht verknüpft sind, und dass die Kalibrierung an Echtprojekten aussteht.

Für Versicherungen gilt eine verwandte, aber vorsichtigere Überlegung. Denkbar ist die Bereitstellung strukturierter technischer Angaben zu Gebäudezustand, Sanierungshistorie und Wartung. Eine Wirkung auf die Tarifierung sollte das Geschäftsmodell dagegen nicht unterstellen — dafür fehlt jede belastbare Grundlage, und eine solche Zusage wäre eine Aussage über das Produkt eines Dritten.

Schließlich ist die technische Voraussetzung zu benennen: Ein Modell aus Einzelabruf, Schnittstellenentgelt und Portfoliovertrag setzt eine dokumentierte Dienstschnittstelle voraus. Diese ist nach dem Entwicklungsstand offen — die Service-Programmierschnittstelle des Pflichtenhefts ist als Roadmap-Punkt geführt, die Trennung in Rechner-, Agenten- und Wächterdienste steht aus. Vorhanden sind projektbezogene Endpunkte, die Veröffentlichungsroute des Passes und ein maschinenlesbarer Zertifikatsexport, der die Pflichtangaben nach § 85 GMoDG trägt. Der Weg von dort zu einem entgeltfähigen Datendienst ist beschrieben, aber nicht gegangen.

15.8 White Label, Verbände und externe Qualitätssicherung

Ein weiterer Skalierungsweg besteht darin, die Technologie anderen Marktteilnehmern unter deren Marke bereitzustellen. In Betracht kommen Banken, Versicherungen, größere Hausverwaltungen, Verbände, Energieberaternetzwerke und Immobilienplattformen. Der fachliche Kern — Datenmodell, Rechenkerne, Dokumenterzeugung, Governance — bleibt identisch; Oberfläche, Benennung und Ausgabelayout werden angepasst. Der wirtschaftliche Reiz liegt in der Arbeitsteilung: Der Partner bringt Kundenzugang, Marke, Vertrieb und Vertrauen mit, die Plattform bringt Technologie, Datenmodell, Berechnung und Dokumentation. Die Notwendigkeit, jede Zielgruppe selbst zu akquirieren, sinkt entsprechend.

Die Voraussetzungen sind allerdings nicht trivial und heute nicht erfüllt. Ein White-Label-Betrieb verlangt Mandantenfähigkeit, saubere Trennung von Marke und Layout, ein Vertragswerk zur Auftragsverarbeitung nach der Datenschutz-Grundverordnung und eine klare Zuordnung der fachlichen Verantwortung — denn die Verantwortung für einen Energieausweis bleibt bei der ausstellenden Person und wandert nicht mit dem Logo. Ebenso bleibt die Grenze aus Abschnitt 15.2 bestehen: Auch unter fremder Marke darf der Zugang des Eigentümers zu seinen Daten nicht bepreist und nicht eingeschränkt werden.

Verbände übernehmen eine andere Rolle. Sie haben Zugang zu Energieberatern, Architekten, der Immobilienwirtschaft und den Wohnungsunternehmen, und sie können Verbreitung über gemeinsame Standards, Pilotprojekte, Schulung und Qualitätssicherung beschleunigen — Wege, die kein Direktvertrieb in vergleichbarer Zeit erreicht. Eine Verbandskooperation ist deshalb weniger ein Erlöskanal als ein Zugangskanal; ihr wirtschaftlicher Wert liegt in der Senkung der Akquisitionskosten und in der Legitimation.

Damit verbunden ist die Frage der externen Qualitätssicherung, die für die Marktakzeptanz wichtiger werden dürfte als der Funktionsumfang. Prüfinstitutionen und Gütegemeinschaften arbeiten mit Softwarevergleichen, definierten Prüffällen, reproduzierbaren Berechnungen und Anforderungen an die Datenqualität. Hier ist ein realer Vorsprung belegt: Die Validierungsfälle nach DIN V 18599 sind zum Stand 17.08.2026 mit 34 Fällen und 964 geprüften Größen ohne Überschreitung der Ein-Prozent-Toleranz dokumentiert, die Wärmepumpenfälle als Teilabnahme; ein Prüfbericht mit Prüfsummen der sechs Rechenkerne liegt vor, acht Testgebäude mit eingefrorenen Sollwerten sichern die Reproduzierbarkeit, und der Funktions-Wächter ist auf 499 Prüfungen gewachsen. Das ist ein Argument, das ein Wettbewerber nicht behaupten, sondern nur nacharbeiten kann.

Zugleich gilt die Regel des Kapitels 2 unverändert: Eine Zertifizierung darf nur behauptet werden, wenn sie erteilt wurde. Mögliche künftige Nachweise zu Berechnungsqualität, Informationssicherheit, Prozessqualität und Schnittstellen sind als angestrebt und nicht als vorhanden zu bezeichnen. Zur Redlichkeit gehört auch, dass der genannte Prüfbericht in fünf Feldern noch Platzhalter trägt und dass die Wallet-Routen zwar existieren, die zugehörigen Zertifikate aber ausstehen.

15.9 Kostenloser Einstieg, aber kein kostenloses Vollprodukt

Ein vollständig kostenloser Gebäudepass würde die Verbreitung erhöhen und dauerhaft Kosten für Speicherung, Sicherheit, Unterstützung und Weiterentwicklung erzeugen, denen keine Erlöse gegenüberstehen. Eine begrenzte kostenlose Einstiegsebene ist dagegen sinnvoll und im vorliegenden System bereits angelegt: ein Basisprofil des Gebäudes, eine kleine Zahl von Dokumenten und der öffentliche Zugang über QR-Code und Passadresse, der ohnehin ohne personenbezogene Daten arbeitet. Weitergehende Funktionen — Fachberechnungen, Varianten, Freigabepakete, Bestandsauswertung, Schnittstellen — sind kostenpflichtig.

Diese Abgrenzung ist mit der Regel aus Abschnitt 15.2 vereinbar, weil sie nicht den Zugang, sondern den Leistungsumfang staffelt. Der Eigentümer sieht seine Daten und kann sie ausleiten; was Geld kostet, ist die Arbeit, die auf diesen Daten geleistet wird. Sie ist zugleich das Gegenteil einer Freemium-Logik, die auf Datensammlung setzt: Der Nutzen der Plattform soll nicht daraus entstehen, möglichst viele Daten zu halten, sondern daraus, dass vorhandene Daten standardisiert wiederverwendbar sind.

15.10 Der eigentliche Kostenblock: Datenqualität

Die Kalkulation eines solchen Modells scheitert erfahrungsgemäß nicht an den Erlösen, sondern an einer Fehleinschätzung der Kosten. Der wertvollste Teil eines Gebäudepasses ist zugleich der teuerste — und das ist nicht die Speicherung, sondern die Qualitätssicherung: Dokumentenanalyse, Plausibilisierung, fachliche Prüfung und Fortschreibung. Ein Modell, das den Preis an Speicherkosten orientiert, unterschätzt den Aufwand systematisch, weil es die Position streicht, die den Unterschied zwischen einem Datenhaufen und einem Nachweis ausmacht.

Der Hebel gegen diese Kosten ist die Automatisierung der Ersterfassung. Je mehr Angaben automatisch aus Plänen, Energieausweisen, Nachweisen, Rechnungen und Bauwerksmodellen übernommen werden können, desto geringer werden die Grenzkosten je zusätzlichem Gebäude. Vorhanden ist dafür eine Plan- und Dokumentenanalyse über eine gemeinsame Ablagezone, in die Grundriss, Wärmeschutznachweis und Energieausweis eingestellt werden und in der die Erkennung selbst bestimmt, welcher Dokumenttyp vorliegt; hinzu kommen der Import von Bauwerksmodellen im IFC-Format, der Import aus Baukostendaten und der Datenaustausch über JSON, CSV und XML. Der IFC-Weg ist dabei ausdrücklich als Eingang ohne Ausgang gekennzeichnet — er nimmt Modelle auf, gibt aber keine aus. Automatisierung ist damit nicht nur eine technische Funktion, sondern ein Bestandteil des Geschäftsmodells: Sie bestimmt, ab welcher Bestandsgröße die Bearbeitung wirtschaftlich wird.

Die Gegenregel lautet, dass Skalierung nicht bedeuten darf, ungeprüfte Daten in großer Zahl zu übernehmen. Das Modell muss deshalb zwischen automatischer Erfassung und qualifizierter Freigabe unterscheiden — und diese Unterscheidung ist im System bereits angelegt, nicht erst zu erfinden. Der Gebäudepass führt vier Datenzustände von Entwurf über gemeldet und geprüft bis freigegeben, wobei nur freigegebene Werte in offizielle Berichte gelangen dürfen; er führt sechs Vertrauensstufen von unbekannt über Eigentümerangabe, aus Dokument erkannt, plausibilisiert und geprüft bis amtlich signiert; und er trennt im Vier-Augen-Verfahren die Meldung eines Vorschlags von der Freigabe, die erst den führenden Wert verändert.

Damit wird Datenqualität selbst zu einem unterscheidbaren Leistungsmerkmal — von automatisch importierten Rohdaten über plausibilisierte und fachlich geprüfte Bestände bis zum förmlichen Nachweis durch eine berechtigte Person, soweit dieser erforderlich ist. Und damit wird auch die fachliche Prüfung zu einem eigenständigen Erlösbaustein: Datenprüfung, Planprüfung, Fachfreigabe und Fortschreibung sind Leistungen, die eine Person erbringt und verantwortet. Der Datenspeicher bleibt davon getrennt; eine Plattform, die Speicherung anbietet, übernimmt damit noch keine fachliche Verantwortung, und eine, die Freigaben verkauft, muss sie tragen. Diese Trennung ist zugleich die Antwort auf die Haftungsfrage, die Kapitel 17 vertieft.

15.11 Positionierung

Die Positionierung sollte weder zu eng noch zu abstrakt ansetzen. „Ein digitaler Energieausweis" beschreibt einen Bruchteil des Funktionsumfangs und ordnet das Angebot einem Markt zu, in dem der Preis die einzige Unterscheidung ist. „Digitaler Zwilling" wiederum ist für den überwiegenden Teil der Eigentümer ein Begriff ohne Anschauung — und er ist, wie Kapitel 2 festhält, auch regulatorisch kein Pflichtbegriff, sondern erscheint in Artikel 19 Absatz 14 EPBD lediglich als zulässiger Kanal für vereinfachte Ausweisaktualisierungen.

Tragfähiger ist eine einfache Beschreibung: die digitale Akte und Chronik eines Gebäudes, in der Energie, Sanierung und Nachweise an einer Stelle geführt werden. Für fachliche Zielgruppen kann diese Beschreibung technisch erweitert werden, ohne dass sich das Produkt ändert. Die Nutzenkommunikation unterscheidet sich nach Zielgruppe — für Eigentümer die Übersicht über das eigene Haus, für Energieberater die einmalige Erfassung mit dauerhafter Weiterverwendung, für Makler nachgewiesene statt behaupteter Gebäudeangaben, für Hausverwaltungen die technische Gebäudeakte mit Historie, für Banken strukturierte Energie-, Investitions- und Nachweisdaten. Diese Unterscheidung ist keine Werbefrage, sondern eine Frage der Auffindbarkeit: Dieselben Kennwerte sind für verschiedene Zielgruppen unterschiedlich wichtig, und die Anzeigeprofile der Kennwerteseite bilden diese Reihenfolge bereits ab.

15.12 Die fünf Markteintrittspfade

Ein Plattformmodell mit sechs Erlösbausteinen und ebenso vielen Zielgruppen lässt sich nicht in allen Märkten gleichzeitig eröffnen. Sinnvoll ist eine gestaffelte Erschließung in fünf Pfaden, deren Reihenfolge sich aus zwei Kriterien ergibt: aus den Kosten der Datenerfassung im jeweiligen Kanal und aus den technischen Voraussetzungen, die der Kanal verlangt. Beide Kriterien führen zu derselben Reihung.

Pfad 1 — Energieberater und bestehende Gebäudeprojekte. Fachpartner haben den entscheidenden Vorteil, dass sie das Gebäude kennen und die Daten in ihren Aufträgen ohnehin erheben. Die Kosten der Ersterfassung, der teuerste Posten des Modells, sinken damit auf die Differenz zwischen dem, was der Auftrag verlangt, und dem, was der Pass zusätzlich braucht. Der Pass entsteht als Nebenprodukt eines ohnehin stattfindenden Vorgangs — eines Energieausweises, eines Sanierungsfahrplans, einer Förderberatung, eines Wärmeschutznachweises. Technisch verlangt dieser Pfad am wenigsten: Er läuft auf der vorhandenen Fachansicht mit Anmeldung und benötigt weder Rechteschicht noch Dienstschnittstelle. Hinzu kommt der Bestand an bereits digitalisierten Projekten — nach dem Audit vom 10.08.2026 sind 96 Projekte in der Plattform geführt —, aus dem sich Pässe ohne neue Erfassung erzeugen lassen. Dieser Pfad ist damit sofort gangbar.

Pfad 2 — Immobilienmakler und Hausverwaltungen. Der zweite Pfad erschließt die beiden Berufsgruppen, die den Pass nicht erzeugen, aber dauerhaft nutzen: Makler im Verkaufsvorgang, Hausverwaltungen im laufenden Betrieb. Er setzt auf Pfad 1 auf, weil er Gebäude voraussetzt, die bereits erfasst sind. Technisch verlangt er den ersten Ausbauschritt: Freigabepakete je Empfänger und eine Mehrgebäudeansicht. Wirtschaftlich verlagert er die Bezugsgröße vom einzelnen Gebäude zum Bestand und erzeugt damit die ersten planbaren wiederkehrenden Erlöse.

Pfad 3 — Banken und größere Bestände. Der dritte Pfad verlangt das standardisierte Gebäudeprofil aus Abschnitt 15.7 und damit die vollständige Freigabelogik, eine belastbare Datenqualitätsaussage und eine dokumentierte Schnittstelle. Er ist der erste Pfad, der ohne die Roadmap-Stufen zur Rechteschicht und zur Programmierschnittstelle nicht funktioniert. Sein Reiz liegt darin, dass er die Erstellung des Passes an einen Anlass koppelt, in dem der Datenbedarf zwingend ist und die Zahlungsbereitschaft nicht beim Eigentümer allein liegt.

Pfad 4 — Verbände und White-Label-Partner. Der vierte Pfad multipliziert die vorangehenden, statt neue Endkunden zu adressieren. Er verlangt Mandantenfähigkeit, ein Vertragswerk und eine belegbare Qualitätsaussage — Verbände und Institute übernehmen keine Technologie unter eigener Marke, deren Rechenqualität sie nicht nachweisen können. Deshalb steht er hinter dem Aufbau der Prüf- und Validierungsbasis und nicht davor.

Pfad 5 — europäische Partner. Der fünfte Pfad überträgt das Modell auf weitere Mitgliedstaaten und setzt die Trennung von Plattformkern und nationalen Regelmodulen voraus, die Abschnitt 15.13 beschreibt. Er ist der einzige Pfad, dessen Voraussetzungen nicht nur intern liegen: Er hängt vom Stand der nationalen EPBD-Umsetzung im Zielland ab.

Diese Reihenfolge ist eine begründete Modellannahme, kein Plan mit Terminen. Welcher Pfad tatsächlich zuerst trägt, welche Leistungen in ihm bezahlt werden und in welchem Verhältnis Ersterfassung und Fortschreibung stehen, ist mit Pilotdaten nach Kapitel 16 zu prüfen. Belegbar ist an dieser Stelle allein die Abhängigkeitsordnung: Pfad 1 verlangt nichts, was fehlt; Pfad 2 und 3 verlangen die Rechteschicht, die seit dem 23. August 2026 steht; Pfad 3 verlangt zusätzlich die Schnittstelle; Pfad 4 verlangt Mandantenfähigkeit und Qualitätsnachweis; Pfad 5 verlangt die Modultrennung.

Die Pfade schließen einander nicht aus, sondern greifen ineinander. Sobald ein Gebäudedatensatz vorhanden ist, entstehen entlang des Lebenszyklus weitere Leistungen — vom Energieausweis über die Sanierungsanalyse, die Förderung und die Wirtschaftlichkeitsbetrachtung bis zur Finanzierung und zur Umsetzungsbegleitung. Ebenso lassen sich Partnerleistungen verbinden: Der Energieberater erstellt die energetische Planung, der Makler nutzt die freigegebenen Verkaufsangaben, die Bank erhält das Finanzierungsprofil, die Hausverwaltung pflegt später die Wartungsinformationen — alle auf demselben Datensatz, ohne dass ein einzelner Anbieter sämtliche Leistungen selbst erbringen müsste. Voraussetzung bleibt in jedem dieser Fälle die Freigabe durch den Berechtigten.

15.13 Europäische Skalierung: Kern und Regelmodule

Die Architektur des Gebäudepasses ist nicht auf Deutschland beschränkt, weil ein erheblicher Teil der Daten international gleich ist: Gebäudegeometrie, Bauteile, Anlagentechnik, Energie- und Materialangaben. Unterschiedlich sind die Regeln, die auf diese Daten angewendet werden — Rechtsvorschriften, Berechnungsverfahren, Förderprogramme, Ausweisformen und Register. Daraus folgt eine Zweiteilung: ein gemeinsamer Gebäudedatenkern und länderspezifische Regelmodule. Für Deutschland sind das GMoDG und die DIN V 18599 in der Fassung 2018-09 das Regelmodul, für andere Mitgliedstaaten deren nationales Energiegesetz und Rechenverfahren.

Diese Trennung ist im vorhandenen System nicht bloß eine Absichtserklärung, sondern in kleinerem Maßstab bereits erprobt. Die GMoDG-Migration hat den Rechtsstand als umschaltbare Registry angelegt, die zwischen den Ständen 2026 und 2027 unterscheidet, Überlagerungen, unveränderte Größen und Lücken kennt und jedes Rechenergebnis mit einem Rechtsstandstempel versieht; hartcodierte Faktoren wurden dabei entfernt. Wer zwei Rechtsstände desselben Landes sauber trennt, hat das Muster, das für zwei Länder erforderlich ist — nicht die fertige Umsetzung, aber die Struktur.

Die EPBD schafft für diese Skalierung den gemeinsamen Rahmen. Das bedeutet nicht, dass alle Mitgliedstaaten dieselbe Software erhielten; es bedeutet, dass bestimmte Grundelemente vergleichbar werden: Energieausweise mit geschlossener Skala A–G und den Pflichtangaben des Anhangs V, Renovierungspässe mit den Pflichtfeldern des Anhangs VIII, nationale Gebäudedatenbanken nach Artikel 22 mit dem jährlichen Transfer an das Building Stock Observatory nach den Vorlagen der Durchführungsverordnung (EU) 2025/1328, sowie Lebenszyklusdaten nach Artikel 7 und Anhang III in der Fassung der Delegierten Verordnung (EU) 2026/52. Damit entsteht perspektivisch ein Markt für interoperable Gebäudedatenplattformen — perspektivisch, weil die nationalen Ausführungsbestimmungen die eigentliche Arbeit bestimmen.

Eine Expansion sollte deshalb mit wenigen Ländern beginnen. Als Auswahlkriterien kommen der Stand der EPBD-Umsetzung, der Digitalisierungsgrad, die Verfügbarkeit von Gebäudedaten, die Marktgröße und ein vorhandenes Partnernetz in Betracht. Eine konkrete Länderauswahl wird hier nicht getroffen; sie setzt eine eigene Markt- und Regulierungsanalyse voraus, die nicht vorliegt. Zu beachten ist überdies, dass der Vorsprung eines Landes bei der Umsetzung nicht automatisch ein leichter Markt ist: Wo eine nationale Datenbank mit eigenem Portal bereits arbeitet und Ausweise aus Rohdaten erzeugt werden, ist ein Teil dessen, was die Plattform anbietet, staatlich abgedeckt — Dänemark und Portugal sind dafür die genannten Beispiele. In Deutschland ist die Lage umgekehrt: Nach Annex 5 der Kommissions-Leitlinien besteht hier noch keine nationale Ausweisdatenbank, der Eintrag lautet „n/a". Das eröffnet einen Handlungsspielraum und erzeugt zugleich das Risiko, dass die spätere staatliche Lösung Anforderungen setzt, die eine Nacharbeit verlangen.

15.14 Wiederkehrende Erlöse, Netzwerkeffekt und Bindung

Strategisch bedeutsam sind an diesem Modell vor allem die wiederkehrenden Anteile: jährliche Gebäudelizenzen, Partnerabonnements, Portfolioverträge und nutzungsabhängige Schnittstellenentgelte. Sie unterscheiden ein Plattformunternehmen von einer projektbezogenen Energieberatung, weil sie den Umsatz eines Jahres nicht vollständig neu erarbeiten müssen. Diese Aussage ist eine strukturelle, keine quantitative — welcher Anteil wiederkehrend wird, ist ohne Pilotdaten nicht seriös zu beziffern.

Ein Netzwerkeffekt ist im Modell angelegt: Je mehr Fachpartner mit der Plattform arbeiten, desto leichter lassen sich Pässe fortschreiben; je mehr fortgeschriebene Pässe existieren, desto interessanter wird die Plattform für weitere Marktteilnehmer. Dieser Effekt sollte allerdings nicht auf möglichst umfangreicher Datensammlung beruhen, sondern auf der standardisierten Wiederverwendbarkeit der Daten. Der Unterschied ist erheblich: Das eine Modell wird mit wachsendem Bestand rechtlich und wirtschaftlich riskanter, das andere wird mit wachsendem Bestand nützlicher.

Mit der Zeit entsteht daraus eine Eintrittsbarriere eigener Art. Ein Pass, der über zehn Jahre Sanierungen, Berechnungen, Dokumente und Wartungen gesammelt hat, trägt einen Informationswert, den ein neuer Anbieter erst rekonstruieren müsste. Diese Bindung ist wirtschaftlich erwünscht und wird zum Problem, sobald sie technisch erzwungen wird. Die Auflösung liegt in der Datenportabilität: Der Nutzer muss seinen Bestand jederzeit in einem offenen Format ausleiten können. Bindung soll aus Nutzwert entstehen, nicht aus Ausleitungshürden — und dies ist zugleich die Bedingung dafür, dass das Modell mit Artikel 16 EPBD und den Anforderungen des Kapitels 9 vereinbar bleibt.

Denn das ganze Modell ruht auf einer Voraussetzung, die keine technische ist. Ein Gebäudepass, der über Jahrzehnte geführt wird, funktioniert nur, wenn die Beteiligten der Plattform vertrauen: Datenkontrolle beim Berechtigten, Nachvollziehbarkeit jeder Änderung, saubere Rollen und Rechte, Portabilität und Sicherheit. Ohne diese Voraussetzungen entsteht kein langfristiger Datenbestand — und ohne langfristigen Datenbestand entsteht kein Geschäftsmodell, sondern nur ein weiteres Werkzeug für Einzelaufträge.

15.15 Marktentwicklung in drei Phasen und ihre Kennzahlen

Die Markterschließung lässt sich zu drei Phasen zusammenfassen, die den fünf Pfaden übergeordnet sind. In der ersten Phase geht es darum, den Pass zu etablieren: Adressaten sind Eigentümer, Energieberater und Makler, Ziel ist eine ausreichende Zahl qualitativ belastbarer Gebäudedatensätze. In der zweiten Phase wird die Plattform geöffnet: Adressaten sind Hausverwaltungen, Wohnungsunternehmen und Banken, Ziel ist die Mehrfachnutzung vorhandener Daten. In der dritten Phase wird sie an Infrastruktur angebunden: Adressaten sind Register, Verbände, öffentliche Systeme und europäische Partner, Ziel sind Interoperabilität und Skalierung. Die dritte Phase ist dabei die einzige, deren Zeitpunkt nicht selbst bestimmt werden kann — sie hängt daran, wann das deutsche Datenbankschema nach Artikel 22 EPBD vorliegt.

Für jede Phase sollten messbare Größen festgelegt werden, damit die Entwicklung nicht an Erzählungen, sondern an Beobachtungen geprüft wird. In Betracht kommen die Zahl aktiver Gebäudepässe, die Aktualisierungsrate, die Vollständigkeit der Daten, die Zahl der Fachpartner, die Zahl der Dokumente je Gebäude, die Zahl der Schnittstellenabrufe und der Anteil wiederkehrender Erlöse. Für die Datenvollständigkeit existiert bereits ein belastbarer Bezug: Die Vollständigkeitsprüfung des Passes führt 23 Pflichtfelder in acht Kategorien, jeweils mit Priorität und Verweis auf das zuständige Werkzeug.

Unter diesen Größen ist eine entscheidend, und sie ist nicht die naheliegende. Nicht die Zahl der erstellten Gebäudepässe misst den Wert der Plattform, sondern die Zahl der tatsächlich fortgeführten. Der Wert entsteht durch Fortschreibung; ein einmal angelegter und nie wieder verwendeter Pass ist wirtschaftlich ein abgeschlossenes Einzelprojekt und trägt weder wiederkehrende Erlöse noch den beschriebenen Netzwerkeffekt. Eine Marktstrategie, die auf Erstanlagen optimiert, optimiert deshalb auf die falsche Größe.

15.16 Übersicht der Erlösquellen und ihrer Grenzen

Die folgende Übersicht fasst die Erlösquellen zusammen und stellt jeder von ihnen zwei Angaben gegenüber, die im Geschäftsmodell häufig fehlen: die rechtliche Grenze, die den Erlös begrenzt oder ausschließt, und die technische oder organisatorische Voraussetzung, ohne die er nicht entsteht. Die Bezugsgröße benennt, woran sich die Leistung bemisst; ein Preis wird nicht genannt.

Die Übersicht zeigt drei Muster. Erstens verteilen sich die Erlöse auf drei Ebenen — das einzelne Gebäude, die fachliche Leistung und die Plattform —, sodass keine Abhängigkeit von einer einzigen Quelle entsteht. Zweitens verläuft die rechtliche Grenze bei nahezu jeder Quelle an derselben Stelle: Der Zugang zu den eigenen Daten ist nicht entgeltfähig, die Arbeit an diesen Daten ist es; und wo der Staat eine Leistung kostenfrei erbringt — den vollständigen Ausweis für Berechtigte und Finanzinstitute, Gebietsdaten für Kommunen —, bleibt nur die darüber hinausgehende Aufbereitung. Drittens fällt auf, dass die Voraussetzungen der ertragreicheren Quellen fast durchweg dieselben zwei Bausteine nennen: die Rechteschicht und die Dienstschnittstelle. Beide sind derzeit Konzept. Die Reihenfolge der Markterschließung ist damit nicht vorrangig eine Vertriebsentscheidung, sondern eine Folge des Entwicklungsstands.

15.17 Kernaussage

Der digitale Gebäudepass sollte wirtschaftlich nicht als einzelnes Dokument vermarktet werden. Sein Wert entsteht aus der dauerhaften Nutzbarkeit eines gepflegten Gebäudedatensatzes, und das Geschäftsmodell kann deshalb auf mehreren Ebenen zugleich aufbauen: Lizenz je Gebäude, Fach- und Partnerzugänge, Dokumente und Fortschreibungen, Bestands- und Bankenlösungen, Schnittstellen und White Label sowie mittelfristig die europäische Skalierung. Die strategische Veränderung gegenüber der klassischen Energieberatung liegt darin, dass aus einem einmaligen Nachweis- oder Beratungsauftrag eine dauerhafte Beziehung zum Gebäude wird.

Zwei Bedingungen entscheiden darüber, ob dieses Modell trägt. Die erste ist rechtlich: Der Zugang der Eigentümer, Mieter und Verwalter zu ihren eigenen Gebäudedaten ist nach Artikel 16 EPBD kostenfrei, ebenso die Weitergabe an von ihnen benannte Dritte; entgeltfähig ist die Leistung, nicht der Zugang. Ein Modell, das diese Grenze überschreitet, ist nicht nur rechtlich angreifbar, sondern konkurriert mit einer unentgeltlichen staatlichen Leistung — und verliert. Die zweite ist wirtschaftlich: Der teuerste Teil des Systems ist die Herstellung belastbarer Datenqualität, nicht deren Speicherung. Wer beide Bedingungen beachtet, bepreist das Richtige. Wer sie vertauscht, verkauft das Billige und verschenkt das Teure.

Unter diesen Bedingungen kann der Gebäudepass mehr sein als ein technisches Werkzeug zur Umsetzung der EPBD. Er kann die Grundlage eines tragfähigen Modells für Gebäudedaten, Energieberatung, Immobilienwirtschaft und Finanzierung bilden — vorausgesetzt, die dafür erforderlichen Bausteine werden in der Reihenfolge gebaut, die Kapitel 14 beschreibt, und die Annahmen dieses Kapitels werden im Pilotbetrieb nach Kapitel 16 überprüft, statt fortgeschrieben zu werden.

16 Pilotprojekt zur Einführung des digitalen Gebäudepasses

Die Reifegradanalyse in Kapitel 13 und die Entwicklungsroadmap in Kapitel 14 beschreiben, was der digitale Gebäudepass heute leistet und in welcher Reihenfolge die fehlenden Teile entstehen sollen. Beides sind Aussagen über die Software. Dieses Kapitel beschreibt den Schritt, der aus einer Aussage über die Software eine Aussage über die Wirklichkeit macht: ein Pilotprojekt an realen Gebäuden mit realen Unterlagen, realen Bearbeitern und realen Partnern. Der Pilot beginnt dabei nicht bei null — er setzt auf 96 vorhandenen Projekten, 74 Werkzeugen, acht Testgebäuden, 34 Validierungsfällen und einem Funktions-Wächter mit 499 Prüfungen auf. Beschrieben werden deshalb keine Absichten, sondern Arbeitspakete mit Ergebnis, Kennzahl und einer ausdrücklichen Angabe, welche davon heute durchführbar sind und welche an noch fehlenden staatlichen Spezifikationen hängen.

16.1 Zielsetzung des Piloten

Ein Pilotprojekt hat drei mögliche Zwecke, die häufig verwechselt werden. Der erste ist die Demonstration: Man zeigt einem Publikum, dass eine Funktion existiert. Der zweite ist der Nachweis: Man belegt, dass eine Funktion unter definierten Bedingungen ein richtiges Ergebnis liefert. Der dritte ist die Messung: Man ermittelt, mit welchem Aufwand, welcher Trefferquote und welcher Fehlerhäufigkeit eine Funktion in der Praxis arbeitet. Der hier beschriebene Pilot verfolgt ausschließlich den dritten Zweck. Die Demonstration ist entbehrlich, weil die Werkzeuge produktiv erreichbar sind; der reine Rechennachweis ist zu einem erheblichen Teil bereits geführt, weil die Validierungsfälle nach DIN V 18599 mit 34 Fällen und 964 geprüften Größen vorliegen und keine Größe außerhalb der Ein-Prozent-Toleranz der Gütegemeinschaft liegt.

Was diese Nachweise nicht enthalten, ist die Aussage über den Weg vom Gebäude zu den Eingabedaten. Ein Validierungsfall beginnt mit einem vollständigen, widerspruchsfreien Datensatz. Ein reales Gebäude beginnt mit einem Ordner, in dem ein Grundriss von 1994, ein Energieausweis von 2018, drei Handwerkerrechnungen ohne technische Angaben und eine Fotoserie liegen. Zwischen diesen beiden Ausgangslagen liegt der eigentliche Gegenstand des Piloten. Er beantwortet nicht die Frage „rechnet die Bilanz richtig", sondern die Fragen: Wie viel eines realen Gebäudes lässt sich aus vorhandenen Unterlagen automatisch gewinnen, wie viel davon ist fachlich haltbar, wie lange dauert die Lücke bis zum freigegebenen Datensatz, und welche Datenlage erlaubt am Ende welche Aussage.

Daraus folgt eine für den Zuschnitt des Piloten wichtige Einschränkung: Der Pilot ist keine Konformitätsprüfung. Er kann nicht zeigen, dass der Gebäudepass die Anforderungen der EPBD erfüllt, weil ein Teil der dafür nötigen nationalen Festlegungen zum Quellenstand nicht existiert — Deutschland verfügt nach Annex 5 der Kommissions-Leitlinien über keine nationale Energieausweis-Datenbank, das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG ist offen, ebenso das Datenformat nach § 88b GMoDG und die Klassenskala für Nichtwohngebäude. Was der Pilot zeigen kann, ist etwas anderes und Belastbareres: dass die Daten, die diese künftigen Spezifikationen verlangen werden, strukturiert, mit Herkunft und mit Freigabestatus vorliegen, und dass sie sich maschinenlesbar ausgeben lassen, sobald ein Zielschema vorliegt.

Der Pilot verfolgt daher fünf Messziele. Erstens die Automatisierbarkeit: Welcher Anteil der benötigten Felder entsteht aus vorhandenen Dokumenten ohne manuelle Eingabe, und welcher Anteil davon hält der fachlichen Prüfung stand. Zweitens die Datenqualität im Sinne des Datenmodells aus Kapitel 4: Anteil freigegebener Werte, mittlere Vertrauensstufe, Anteil belegter Werte. Drittens den Aufwand: Zeitbedarf je Gebäude, getrennt nach Erfassung, Prüfung, Berechnung und Dokumenterzeugung. Viertens die Belastbarkeit der Ergebnisse: Abweichung zwischen berechnetem Bedarf und gemessenem Verbrauch, Abweichung gegenüber Referenzberechnungen, Reproduzierbarkeit nach Änderungen. Fünftens die Anschlussfähigkeit: Welche Felder verlangen externe Partner tatsächlich, welche fehlen ihnen, und welche Exportprofile sind maschinell valide.

16.2 Ausgangsstand — worauf der Pilot aufsetzt

Ein Pilot, der bei null beginnt, misst in den ersten Monaten vor allem sich selbst. Das ist hier nicht nötig, weil ein erheblicher Teil der Infrastruktur produktiv ist und weil bereits ein Datenbestand existiert, aus dem sich ein Ausgangswert ohne jede Neuaufnahme ermitteln lässt. Das Audit vom 10.08.2026 weist 74 Werkzeuge, 64 Register-Felder und 96 Projekte im ProjektStore aus. Diese 96 Projekte sind keine Testdatensätze, sondern reale Bearbeitungen. Sie enthalten damit bereits die Antwort auf eine der zentralen Pilotfragen — welche Felder in der Praxis regelmäßig gefüllt werden und welche regelmäßig leer bleiben —, und diese Antwort ist auswertbar, bevor das erste Pilotgebäude aufgenommen wird.

Ebenso vorhanden ist das Referenzgleis für die Berechnung. Acht Testgebäude mit den Kennungen N1 bis N3 und S1 bis S5 tragen eingefrorene Sollwerte auf Stufe R mit einer Toleranz von einem Prozent; dazu kommen die 34 Validierungsfälle mit 964 Größen und der Prüfbericht mit den SHA-256-Summen der sechs Rechenkerne. Der Funktions-Wächter prüft den Code statisch, über HTTP und headless; er ist von 116 auf 499 Prüfungen gewachsen, der Sollstand vom 17.08.2026 weist 493 von 495 grün aus, wobei die beiden roten Befunde bekannte Datenprobleme in Live-Projekten sind und keine Regression darstellen. Ein täglicher Lauf um 06:45 und ein Archiv der Läufe existieren. Für den Piloten bedeutet das: Jede Abweichung, die während der Pilotlaufzeit an einem Pilotgebäude auftritt, lässt sich gegen einen bekannten Sollstand halten, und es ist unterscheidbar, ob ein auffälliges Ergebnis ein Datenproblem des konkreten Gebäudes oder eine Regression der Software ist. Diese Unterscheidung ist der häufigste Grund, warum Pilotprojekte ohne Regressionsanker unbrauchbare Ergebnisse liefern.

Ebenfalls produktiv ist die Datenschicht, auf der alle Qualitätskennzahlen des Piloten beruhen. Die Governance-Engine führt die vier Datenzustände Entwurf, gemeldet, geprüft und freigegeben sowie die Vertrauensstufen 0 bis 5, und sie erzwingt das Vier-Augen-Prinzip: Ein Melde-Vorgang legt einen Vorschlag im Arbeitsbereich ab und verändert den offiziellen Wert nicht; erst die Freigabe schreibt in den Pfad der führenden Quelle. Die Beziehungs-Engine hält den Objektgraphen mit den Kanten „belegt durch", „beeinflusst" und „ersetzt", die Abhängigkeits-Engine kennt die Wirkkette vom Bauteil über U-Wert und Heizlast bis zu Wärmeschutznachweis, Ausweis, CO₂-Bilanz, Building Trust Index und Finanzierungsbericht, und die Neuberechnungs-Engine erkennt über einen Fingerabdruck je Eingabesektion, welche Auswertungen nach einer Änderung veraltet sind. Zwei der im Piloten geforderten Kennzahlen — der Anteil freigegebener Werte und die mittlere Vertrauensstufe — sind damit keine gesondert zu erhebenden Größen, sondern bereits maschinell auswertbar: Der Building Trust Index verwendet sie in seiner Säule Datenqualität, in der die mittlere Vertrauensstufe mit dem Faktor 16 und der Anteil freigegebener Werte mit dem Faktor 20 eingehen, vermindert um offene Aufgaben mit dem Faktor 2.

Der Vollständigkeit halber gehört zum Ausgangsstand auch, was nicht vorhanden ist, weil es den Zuschnitt des Piloten unmittelbar bestimmt. Das abgestufte Zugriffs-Rollenmodell besteht seit dem 23. August 2026 und kann im Piloten mitgeprüft werden; daneben stehen unverändert die Anzeige-Rollen der Kennwerte-Seite — Alle Werte, Architekt, Makler, Hausverwaltung, TGA-Planer, Bank, Energieberater —, die die Reihenfolge und Hervorhebung der 43 Kennwerte steuern, aber keine Rechteschicht bilden. Der Assistent-Modus „Einfach" des UI-Konzepts existiert nicht; das heutige Werkzeug ist die Fach- und Betreiberansicht. Die Service-API nach § 25 des Pflichtenhefts, die geschlossenen Exportformate nach § 28 und der Ein-Klick-Import stehen als offene Roadmap-Punkte. Diese drei Lücken sind der Grund, warum der Pilot in Stufen zerfällt und warum der marktseitige Teil erst nach einer klar benannten Vorarbeit beginnen kann (Abschnitt 16.14).

16.3 Gebäudeauswahl und Pilotumfang

Ein einzelnes Einfamilienhaus ist als Pilotgegenstand ungeeignet, und zwar nicht wegen mangelnder Repräsentativität, sondern weil es die kritischen Codepfade nicht berührt. Ein freistehendes Wohngebäude mit einer Nutzung, einer Zone und einer Wärmeerzeugung durchläuft die Bilanz auf dem am besten geprüften Weg. Erst ein Mehrfamilienhaus mit gemischter Warmwasserbereitung, ein Nichtwohngebäude mit zonenweiser Bilanzierung und ein gemischt genutztes Gebäude mit zwei Regelwerken in einem Objekt erzeugen die Fälle, an denen sich Datenmodell und Rechenkern tatsächlich bewähren müssen. Der Auswahl liegen deshalb zwei Dimensionen zugrunde: der Gebäudetyp, der bestimmt, welche Berechnungslogik geprüft wird, und die Ausgangsdatenlage, die bestimmt, welche Erfassungslogik geprüft wird.

In der Typdimension sind fünf Gruppen zu besetzen. Das Einfamilienhaus im Bestand ist der Referenzfall mit der höchsten Fallzahl in der Praxis und dem einfachsten Datenmodell; es liefert den Bezugswert für Zeitbedarf und Automatisierungsquote, gegen den alle anderen Typen gemessen werden. Das Mehrfamilienhaus bringt Wohnungsteilung, gemeinschaftliche Anlagentechnik, Verbrauchsdaten aus der Heizkostenabrechnung und den Bezug zu Mietverhältnissen ein; es ist zugleich der Fall, in dem der Renovierungspass für einzelne Gebäudeteile relevant wird, weil Artikel 12 EPBD ausdrücklich für alle Gebäude und Gebäudeteile gilt. Das Nichtwohngebäude — im Regelfall ein Bürogebäude — prüft die zonenweise Bilanz, die Nutzungsprofile und die Beleuchtung; es ist der technisch anspruchsvollste Fall und zugleich der, in dem der Pilot auf eine bekannte Lücke stößt. Das öffentliche Gebäude, etwa eine Schule oder eine Sporthalle, bringt Sondernutzungen, hohe Belegungsdichten und den regulatorischen Bezug zu den Vorbildpflichten öffentlicher Stellen ein. Das gemischt genutzte Gebäude schließlich ist der Härtefall der Bezugsfläche: Hier muss die Aufteilung nach Nutzungen belastbar sein, weil Artikel 20 Absatz 8 EPBD die Bezugsfläche bei Mischnutzung ausdrücklich aufgeschlüsselt verlangt.

Ergänzend gehört mindestens ein Neubau in die Auswahl, und zwar aus einem anderen Grund als die Bestandsgebäude. Beim Bestandsgebäude wird geprüft, ob sich ein Datensatz aus unvollständigen Altunterlagen rekonstruieren lässt. Beim Neubau wird geprüft, ob der Gebäudepass bereits während der Planung entsteht, also aus CAD-Geometrie, IFC-Modell, Wärmeschutznachweis und TGA-Planung gespeist wird, statt nachträglich aus Dokumenten. Das ist der ungleich günstigere Fall, weil die Daten strukturiert am Anfang stehen; er ist zugleich der Fall, für den die Plattform den IFC-Weg bereits vorsieht. Dabei ist eine Einschränkung zu beachten und im Pilotbericht zu benennen: Der IFC-Pfad ist als Eingang ohne Ausgang angelegt, das Modell kann eingelesen, aber nicht in gleicher Form zurückgegeben werden. Für den Piloten ist das ausreichend, für einen Planungsprozess mit Rückkopplung in das Fachmodell nicht.

Die zweite Dimension ist die Ausgangsdatenlage. Sie wird in drei Klassen geführt, weil sie den Zeitbedarf stärker bestimmt als der Gebäudetyp. Klasse A umfasst gut dokumentierte Gebäude mit aktuellen Plänen, vorhandenem Energieausweis, technischen Datenblättern und nachvollziehbaren Rechnungen. Klasse B beschreibt den Regelfall: teilweise vorhandene Pläne, einzelne Rechnungen, ältere Energieinformationen, unvollständige Angaben zur Anlagentechnik. Klasse C steht für den schwierigen Bestand mit wenigen Unterlagen, undokumentierten Sanierungen und einer Datenbasis, die überwiegend aus der Vor-Ort-Aufnahme stammt. Jede Klasse muss in jeder relevanten Typgruppe besetzt sein, sonst ist die gemessene Automatisierungsquote nicht interpretierbar: Eine hohe Quote in einem reinen Klasse-A-Portfolio sagt über die Praxistauglichkeit wenig aus.

Für den Umfang gilt eine Staffelung statt einer einzigen Zahl. Die erste Stufe umfasst zehn Gebäude und dient der Technik; sie prüft Datenmodell, Import und Berechnung und kann mit überschaubarem Aufwand mehrfach durchlaufen werden, wenn die ersten Ergebnisse Korrekturen erzwingen. Die zweite Stufe erweitert auf etwa zwanzig Gebäude und nimmt Renovierungspass, Historie und Förderlogik hinzu. Die dritte Stufe zielt auf rund vierzig Gebäude und öffnet den Piloten für Partner — Banken, Makler, Hausverwaltungen. Eine vierte Stufe mit einem größeren Portfolio dient allein der Automatisierung und dem Zeitverhalten und ist erst sinnvoll, wenn die Ergebnisse der dritten Stufe stabil sind. Ein aussagekräftiger Zuschnitt der dritten Stufe verteilt die vierzig Gebäude etwa auf zehn Einfamilienhäuser, zehn Mehrfamilienhäuser, zehn Nichtwohngebäude einschließlich der öffentlichen Gebäude, fünf gemischt genutzte Gebäude und fünf Neubauten. Diese Verteilung ist ein Planungsansatz und keine statistische Stichprobe; sie ist nach der Verfügbarkeit realer Projekte und der Bereitschaft der Eigentümer anzupassen. Statistische Repräsentativität für den deutschen Gebäudebestand ist ausdrücklich nicht das Ziel — angestrebt wird die Abdeckung möglichst vieler technischer und organisatorischer Sonderfälle.

Eine organisatorische Voraussetzung ist der Auswahl vorgelagert: Jedes Pilotgebäude braucht eine dokumentierte Einwilligung des Eigentümers, die den Zweck, den Umfang der verarbeiteten Daten, die Weitergabe an Pilotpartner, die Dauer und den Widerruf regelt. Da der Pilot personenbezogene Daten berührt — Verbrauchsabrechnungen, Eigentümerangaben, im Mehrfamilienhaus auch Mieterbezüge —, ist die Datenschutz-Vorprüfung nicht ein Ergebnis des Piloten, sondern seine Bedingung. Sie ist im Datenmodell ausdrücklich als offener Punkt geführt und muss vor der ersten Aufnahme abgeschlossen sein.

16.4 Ausgangsdaten und Eingangsinventar

Der erste Messpunkt des Piloten liegt vor jeder Verarbeitung. Für jedes Gebäude wird festgehalten, welche Unterlagen zu Beginn tatsächlich vorhanden waren, in welcher Form und in welcher Qualität. Dieser Ausgangswert ist deshalb wichtig, weil jede spätere Quote — Erkennungsquote, Übernahmequote, Vollständigkeit — ohne ihn nicht interpretierbar ist. Eine Automatisierungsquote von 70 Prozent bedeutet etwas völlig anderes, wenn sie auf einem vollständigen Planungsordner beruht, als wenn sie auf drei Fotos und einem alten Ausweis beruht.

Das Eingangsinventar erfasst je Gebäude die üblichen Unterlagenarten: Grundrisse, Schnitte, Ansichten, Lageplan, vorhandener Energieausweis mit Ausstellungsdatum, Wärmeschutznachweis, Heizlastberechnung, Anlagenschemata, technische Datenblätter der Erzeuger, Wartungsprotokolle, Handwerkerrechnungen zu Sanierungsmaßnahmen, Förderbescheide, Verbrauchsabrechnungen und Fotodokumentation. Zu jeder Unterlagenart werden vier Angaben festgehalten: ob sie vorhanden ist, in welcher Form sie vorliegt — Papier, gescanntes Bild, durchsuchbares PDF, natives Format —, auf welchen Stand sie sich bezieht und ob sie mit anderen Unterlagen desselben Gebäudes im Widerspruch steht. Die dritte Angabe ist die praktisch folgenreichste: Ein Grundriss aus dem Baujahr, der drei Umbauten nicht enthält, ist nicht ein Dokument geringer Qualität, sondern ein Dokument mit falschem Gültigkeitsbezug — ein Unterschied, den das Datenmodell mit dem Gültigkeitsstatus je Wert bereits abbilden kann.

Aus dem Inventar entstehen zwei Zahlen je Gebäude. Die Dokumentabdeckung gibt an, welcher Anteil der als relevant definierten Unterlagenarten überhaupt vorliegt. Die Ausgangsvollständigkeit gibt an, welcher Anteil der Pflichtfelder sich allein durch Lesen der vorhandenen Unterlagen ohne Ortsbegehung besetzen ließe. Beide werden vor der Verarbeitung geschätzt und nach der Verarbeitung gegen das tatsächliche Ergebnis gehalten; die Differenz zwischen erwarteter und erreichter Besetzung ist eine der aufschlussreichsten Größen des gesamten Piloten, weil sie zeigt, wie viel Information in vorhandenen Dokumenten steckt, die heute nicht gehoben wird.

Die Bezugsgröße für die Vollständigkeit ist dabei nicht frei zu wählen. Der Gebäudepass führt in der Vollständigkeitskachel 23 Pflichtfelder in acht Kategorien, jeweils mit Priorität und mit einem Verweis auf das Werkzeug, in dem das Feld zu ergänzen ist. Diese 23 Felder sind der maßgebliche Katalog für die Kennzahl Datenvollständigkeit, und die Kennzahl wird — das ist die entscheidende methodische Festlegung — je Pflichtfeld über alle Pilotgebäude ausgewiesen, nicht als Mittelwert je Gebäude. Ein Mittelwert von 92 Prozent verbirgt, dass ein einzelnes Feld in 80 Prozent der Gebäude fehlt; genau dieses Feld ist aber der Grund, warum ein Dokument nicht erzeugt werden kann. Die feldweise Auswertung führt unmittelbar zu einer Arbeitsliste, der Mittelwert führt zu nichts.

Der Ausgangswert lässt sich zudem ohne jedes neue Gebäude gewinnen. Eine Vorauswertung der 96 vorhandenen Projekte liefert für jedes der 23 Pflichtfelder die heutige Belegungsquote, dazu über den Quellen-Abgleich mit seinen sechs Regeln und über den Steckbrief-Abgleich der vier doppelt geführten Felder — Bauweise, Kellerausführung, Firstrichtung, Geschosszahl — eine Konflikthäufigkeit. Diese Nullmessung ist heute durchführbar, verursacht keinen Erfassungsaufwand und liefert den Vergleichsmaßstab, gegen den die Pilotgebäude gemessen werden. Sie sollte deshalb das erste Arbeitspaket des Piloten sein und nicht das letzte.

16.5 Digitalisierung der vorhandenen Unterlagen

Die Digitalisierung ist im Pilotkontext kein Selbstzweck und auch keine reine Archivierungsaufgabe. Sie hat ein definiertes Ziel: Jedes Dokument muss so vorliegen, dass es erstens maschinell auswertbar ist und zweitens als Beleg an einen Datenwert gebunden werden kann. Die zweite Anforderung ist die anspruchsvollere. Ein gescanntes PDF im Ordner ist digitalisiert; ein Wärmeschutznachweis, aus dem der U-Wert der Außenwand entnommen und über die Kante „belegt durch" mit dem Bauteil verknüpft ist, ist eingebunden. Nur die zweite Form trägt die Vertrauensstufe „aus Dokument erkannt" und nur sie erlaubt später die Frage, worauf ein Wert beruht.

Für den Piloten ergibt sich daraus eine dreistufige Aufbereitung. In der ersten Stufe wird alles erfasst, was vorliegt, unabhängig von der Qualität — auch das unleserliche Fax und die handschriftliche Notiz, weil das Fehlen einer Information ein Befund ist und der Pilot Befunde sammelt. In der zweiten Stufe wird jedes Dokument einer Dokumentart und einem Gültigkeitszeitraum zugeordnet; erst diese Zuordnung erlaubt die spätere Auflösung von Widersprüchen, weil bei zwei sich widersprechenden Quellen die jüngere mit dem passenderen Gültigkeitsbezug vorgeht. In der dritten Stufe erfolgt die inhaltliche Auswertung.

Für die inhaltliche Auswertung existiert die Plan- und Dokumentenanalyse über eine gemeinsame Ablagezone: Grundriss, Wärmeschutznachweis und Energieausweis werden über denselben Weg eingereicht, und die Erkennung bestimmt selbst, welcher Dokumenttyp vorliegt. Für den Piloten ist dieser eine Weg ein Vorteil, weil er die Bearbeiter nicht zwingt, vorab zu klassifizieren, und weil eine Fehlklassifikation dadurch selbst zu einem messbaren Befund wird — sie erscheint als Fehlerklasse und nicht als Bedienfehler. Ergänzend stehen der CAD-Import über JSON und XML, der IFC-Eingang, der Import von Kostendaten und die klassische Übernahme aus Fremdformaten zur Verfügung.

Ein Punkt ist vor Beginn des Piloten zwingend zu klären, weil er sonst die Messung verfälscht: Das Öffnen des Gebäudepasses löst heute einen automatischen Dokumentenlauf aus, der ungefragt PDF-Dokumente erzeugt und ablegt, ohne dass eine Nutzeraktion vorausgeht. Für den regulären Betrieb ist das eine Komfortfunktion mit fragwürdiger Nebenwirkung; für einen Piloten, der Zeitbedarf, Dokumentversionen und Auslöser von Berechnungen misst, ist es eine Fehlerquelle, die jede Zeitmessung und jede Versionszählung unbrauchbar machen kann. Der automatische Lauf gehört deshalb vor Pilotbeginn hinter eine ausdrückliche Nutzeraktion (Abschnitt 16.14).

16.6 Datenimport und Übernahmequoten

Der Import ist die Stelle, an der der Pilot seine wirtschaftlich wichtigste Zahl erzeugt. Denn die Frage, ob sich ein Gebäudepass rechnet, entscheidet sich nicht an der Rechenqualität, sondern daran, wie viel Handarbeit die Datenaufnahme kostet. Deshalb wird die Automatisierung nicht als eine Zahl gemessen, sondern als drei getrennte Größen, deren Verwechslung der häufigste Fehler in der Bewertung solcher Systeme ist.

Die Erkennungsquote gibt an, welcher Anteil der benötigten Felder aus den Dokumenten überhaupt einen Vorschlagswert erhält. Die Übernahmequote gibt an, welcher Anteil dieser Vorschläge nach fachlicher Prüfung unverändert freigegeben wird. Die Nacharbeitsquote gibt an, welcher Anteil der Vorschläge korrigiert werden musste — im Unterschied zu den Feldern, die gar keinen Vorschlag erhielten. Ein Beispiel verdeutlicht den Unterschied: Erhalten von 200 relevanten Feldern 160 einen Vorschlag und sind davon 130 fachlich korrekt, so beträgt die Erkennungsquote 80 Prozent, die fachlich korrekte Übernahme bezogen auf alle Felder 65 Prozent und bezogen auf die Vorschläge 81 Prozent. Die drei Zahlen beantworten verschiedene Fragen: die erste, wie gut die Dokumentenlage ist; die zweite, wie viel Handarbeit bleibt; die dritte, wie sehr man den Vorschlägen trauen kann. Nur die dritte entscheidet darüber, ob eine Vier-Augen-Prüfung entfallen könnte — und die Antwort des Piloten darauf wird voraussichtlich lauten, dass sie nicht entfallen darf.

Der Weg vom Vorschlag zum offiziellen Wert ist dabei bereits vorgezeichnet und muss im Piloten nicht erfunden werden. Ein erkannter Wert wird gemeldet, liegt damit im Arbeitsbereich und verändert den offiziellen Wert nicht; erst die Freigabe schreibt ihn in den Pfad der führenden Quelle. Der Pilot misst an dieser Kante zwei Dinge: wie viele Meldungen je Gebäude entstehen und wie viele davon ohne Änderung freigegeben werden. Das Verhältnis ist zugleich die belastbarste Aussage über die Qualität der maschinellen Erkennung, weil es nicht auf einer Selbsteinschätzung beruht, sondern auf einer protokollierten Entscheidung eines Fachbearbeiters.

Eine methodische Falle ist beim Import ausdrücklich zu vermeiden. Die Bezugsfläche ist kanonisch die Nutzfläche nach DIN 277 mit eigener Quellenangabe; A_N, die Wohnfläche, die Bruttogrundfläche und die Netto-Raumfläche sind ausdrücklich nicht als Ersatz zulässig. Ein aus einem alten Energieausweis übernommener Flächenwert ist deshalb in aller Regel nicht die Bezugsfläche des heutigen Verfahrens, sondern eine andere Größe — der Übergang ist keine Umrechnung. Wird dieser Unterschied beim Import übergangen, entsteht ein Wert, der formal besetzt und inhaltlich falsch ist, und alle nachgelagerten flächenbezogenen Kennwerte sind es ebenfalls. Der Pilot muss deshalb jeden übernommenen Flächenwert mit seiner Herkunftsgröße führen, und die vorhandene Plausibilitätsbremse, die eine Nutzfläche unterhalb von 55 Prozent der Bruttogrundfläche beanstandet, ist als Prüfpunkt in das Protokoll aufzunehmen.

Für Nichtwohngebäude gilt eine zweite Vorsichtsregel. Das Nutzungsprofil wird kanonisch über die Hauptnutzungsnummer des Gebäudes und die Profilnummer je Zone geführt; dieselbe Größe trug zuvor vier verschiedene Bezeichnungen, und die zonenweise Bilanz griff in keinem einzigen Projekt. Die Nichtwohngebäude des Piloten betreten damit einen Pfad, der zwar bereinigt, aber praktisch noch nicht belegt ist. Das ist kein Argument gegen ihre Aufnahme — im Gegenteil, es ist der wichtigste Grund dafür —, wohl aber ein Argument dafür, sie früh aufzunehmen und ihren Aufwand getrennt auszuweisen.

16.7 Berechnungen und Referenzgleis

Nach der Freigabe des Datensatzes folgt die energetische Bilanz. Gerechnet wird nach DIN V 18599:2018-09; diese Ausgabe ist die öffentlich-rechtliche Grundlage. Die DIN/TS 18599:2025-10 ist eine Technische Spezifikation und keine Grundlage des GEG; Ergebnisse aus ihr sind Vergleichsrechnung. Für den Piloten hat das eine unmittelbare Konsequenz: Jedes Ergebnis, das ein Dokument verlässt, benennt die gerechnete Normfassung, und wo beide Fassungen gerechnet werden, werden sie getrennt ausgewiesen und nicht gemittelt. Die Umschaltbarkeit ist über die Normstand-Registry vorhanden, ebenso der Rechtsstandwechsel zwischen 2026 und 2027 mit dem Stempel an jedem Ergebnis.

Die Prüfung im Piloten richtet sich auf vier Fragen. Erstens, ob alle benötigten Eingangsgrößen vollständig und in der richtigen Einheit übernommen wurden. Zweitens, ob die Zonierung sachgerecht ist — bei Nichtwohngebäuden und gemischt genutzten Gebäuden der kritische Punkt. Drittens, ob die Anlagentechnik korrekt zugeordnet ist, insbesondere die Trennung von Heizung, Trinkwarmwasser und, wo vorhanden, Schwimmbad oder Lüftung. Viertens, ob das Ergebnis reproduzierbar ist, also ob ein erneuter Lauf mit unverändertem Datenstand denselben Wert liefert.

Die vierte Frage ist die einzige, die sich vollständig automatisieren lässt, und für sie existiert das Referenzgleis. Vor und nach jeder Pilotphase laufen die acht Testgebäude mit ihren eingefrorenen Sollwerten und die 34 Validierungsfälle durch; der Funktions-Wächter läuft täglich. Weicht ein Testgebäude ab, liegt eine Regression vor und der Pilot wird angehalten, bis die Ursache geklärt ist. Weicht kein Testgebäude ab und ist dennoch ein Pilotgebäude auffällig, liegt ein Daten- oder Modellierungsproblem des konkreten Gebäudes vor. Diese Trennung ist die Voraussetzung dafür, dass Pilotbefunde überhaupt auswertbar sind.

Wo eine unabhängige Referenz vorliegt — ein bestehender Energieausweis, ein vorhandener Wärmeschutznachweis, eine Berechnung mit einer zweiten Software —, wird verglichen. Ein solcher Vergleich ist allerdings nur aussagekräftig, wenn drei Bedingungen erfüllt sind: identische Eingabedaten, identische Normfassung und identische Randbedingungen. In der Praxis ist die dritte Bedingung selten erfüllt, und der Pilot sollte die dafür verantwortlichen Effekte vorab kennen und im Protokoll ausweisen, statt sie als Softwareabweichung zu deuten. Drei sind besonders folgenreich. Erstens der Bezugsflächenwechsel: Ein alter Ausweis auf A_N und eine neue Bilanz auf der Nutzfläche nach DIN 277 haben unterschiedliche Nenner, was jeden flächenbezogenen Kennwert verschiebt. Zweitens die Auslegungsstaffel 19: Die Luftwechselrate der bedarfsgeführten Abluftanlage steigt im Referenzgebäude von 0,45 auf 0,55 pro Stunde, während im auszuführenden Gebäude 0,45 zulässig bleibt; die Primärenergie des Referenzgebäudes steigt dadurch um rund 6,8 Prozent beim Einfamilienhaus und 9,3 Prozent beim Mehrfamilienhaus — eine Verschiebung, die einen unveränderten Gebäudeentwurf besser dastehen lässt, ohne dass sich am Gebäude etwas geändert hätte. Drittens der Faktorwechsel zum Rechtsstand 2027 mit dem Primärenergiefaktor Strom von 1,8 auf 1,5, dem CO₂-Faktor Strom von 560 auf 100 Gramm, Holz von 0,2 auf 0,7 und Fernwärme von 1,3 auf 0,7. Jeder dieser drei Effekte kann eine zweistellige prozentuale Abweichung erzeugen, ohne dass ein Rechenfehler vorliegt.

Eine Einschränkung ist bei den Wärmepumpenfällen zu führen. Die Validierung der Wärmepumpen liegt als Teilabnahme vor; was fehlt, ist das BIN-Verfahren, für das die 8 760 Stundenwerte des Testreferenzjahres nicht vorliegen. Für Pilotgebäude mit Wärmepumpe bedeutet das nicht, dass nicht gerechnet werden kann, wohl aber, dass der Ergebnisstatus im Protokoll als Teilabnahme geführt wird und Abweichungen gegenüber einer Fremdberechnung mit BIN-Verfahren erwartbar sind. Angesichts der Rolle der Wärmepumpe in nahezu jedem Sanierungspfad ist dies der bedeutsamste offene Punkt des Rechenkerns und im Pilotbericht als solcher zu benennen.

Neben der Bedarfsbilanz laufen die weiteren Fachrechnungen auf demselben Datensatz: der Wärmeschutznachweis mit der Referenzausführung aus einer Quelle, die raumweise Heizlast mit Trinkwarmwasser und gegebenenfalls Schwimmbad sowie der daraus abgeleiteten Erzeugerauslegung, die Kühllast und die Kostenschätzung nach Gewerken. Hier misst der Pilot die Wiederverwendung: Für jede Fachrechnung wird ausgewiesen, wie viele ihrer Eingangsgrößen aus dem bereits vorhandenen Datensatz stammen und wie viele zusätzlich erhoben werden mussten. Diese Wiederverwendungsquote ist der eigentliche Beleg der Plattformthese aus Kapitel 6 — dass Daten einmal erfasst und mehrfach genutzt werden — und sie ist eine harte, zählbare Größe. Ein Detail ist dabei zu beachten: Die Heizlast liest den U-Wert des Bauteils vorrangig und legt damit den sanierten Zustand aus; wo im Piloten der Ist-Zustand ausgelegt werden soll, ist die Reihenfolge der Werte ausdrücklich zu dokumentieren.

16.8 Energieausweis

Auf dem freigegebenen Datensatz wird der Energieausweis erzeugt. Im Gebäudepass ist die Ausweiskachel produktiv, und bei vollständigem Energiekern entsteht ein Bedarfsausweis automatisch als Dokument; eine neue Version wird erzeugt, sobald sich die Endenergie ändert, und die Kachel warnt, wenn das abgelegte Dokument und die aktuellen Daten auseinanderlaufen. Die interne Ausweisnummer ist deterministisch aus der Gebäudekennung abgeleitet und ausdrücklich keine Registriernummer des Deutschen Instituts für Bautechnik. Diese Unterscheidung ist im Piloten durchgehend zu halten: Es entsteht ein inhaltlich vollständiger Ausweis, kein registrierter Ausweis.

Der Prüfumfang ergibt sich aus Anhang V EPBD und ist als Checkliste je Gebäude abzuarbeiten, wie in Kapitel 12 dargestellt. Auf der Titelseite verlangt Anhang V Nummer 1 die Energieeffizienzklasse, die jährliche Primärenergie in Kilowattstunden je Quadratmeter und Jahr je Energieträger, die jährliche Endenergie ebenso je Energieträger, den Anteil erneuerbarer Energie vor Ort in Prozent sowie die operativen Treibhausgasemissionen in Kilogramm CO₂-Äquivalent je Quadratmeter und Jahr, ergänzt um den Lebenszyklus-GWP-Wert, sofern verfügbar. Hinzu kommen Primär- und Endenergie in absoluten Werten, der Hauptenergieträger und die Art der erneuerbaren Erzeugung, der Energiebedarf je System, die Angabe zur Demand-Response-Fähigkeit, die Angabe zur Niedertemperaturfähigkeit des Verteilsystems, die Kontaktdaten der zentralen Anlaufstelle sowie die Referenzwerte und Modernisierungsempfehlungen.

Der Pilot misst hier keine Zufriedenheit, sondern eine Quote: den Anteil der Anhang-V-Pflichtangaben, die aus dem Datensatz belegt und ohne Nacherhebung ausgegeben werden können. Vier Punkte dieser Liste verdienen besondere Aufmerksamkeit, weil sie erfahrungsgemäß nicht als geschlossene Felder vorliegen. Die Aufschlüsselung von Primär- und Endenergie je Energieträger ist eine andere Anforderung als der Gesamtwert; sie ist im Piloten ausdrücklich zu prüfen und, wo sie fehlt, als Entwicklungsbedarf zu erfassen. Der Anteil erneuerbarer Energie vor Ort ist als Kennzahl zu definieren, bevor er gemessen wird — die Anlagendaten zur Photovoltaik sind vorhanden, ihre Verdichtung zu einer ausweisfähigen Prozentangabe ist zu belegen. Die Angabe zur Niedertemperaturfähigkeit folgt nach den Kommissions-Leitlinien einem vierstufigen Verfahren von der Heizlast über die Heizkörperleistung und den Volumenstrom zur Systemtemperatur, mit dem Schwellenwert von 45 Grad Celsius in der Auslegung beziehungsweise 42 Grad Celsius im saisonalen Mittel; die raumweise Heizlast liefert dafür die Grundlage, das Ergebnisfeld selbst ist im Pilot anzulegen. Und die Treibhausgasangabe verlangt Sorgfalt, weil der Gebäudepass drei getrennte CO₂-Karten führt — die Angabe aus dem Ausweis, die automatische Betriebsbilanz und die Ökobilanz — und bewusst keinen zusammengeführten Gesamtwert bildet; ein eigener Prüfschritt sichert diese Trennung. Für den Ausweis ist ausschließlich der operative Wert zu verwenden, und der Lebenszyklus-Wert bleibt leer, solange er nicht aus Bauteilflächen und Materialmengen berechnet wird — heute liegt dafür lediglich ein geschätzter Grauenergie-Benchmark von 500 Kilogramm je Quadratmeter vor, der als Ausweisangabe nicht taugt.

Die Klassenzuordnung ist der Punkt, an dem der Pilot auf eine harte externe Grenze stößt. Für Wohngebäude ist die Klassenbildung vorhanden. Für Nichtwohngebäude gibt die Klassenfunktion zwischen A und G bewusst keinen Wert zurück, weil die Klassengrenzen B bis F der Anlage 10a nicht festgelegt sind; die Skala ist in der Rechtsstand-Registry als Lücke geführt. Die Nichtwohngebäude des Piloten erhalten deshalb einen vollständigen Kennwertsatz und ausdrücklich keine Klasse. Das ist kein Mangel der Software, sondern die korrekte Abbildung eines offenen Rechtsstands, und der Pilot sollte diesen Umgang ausdrücklich als Ergebnis dokumentieren: Ein System, das an dieser Stelle einen Wert erfindet, wäre schlechter, nicht besser.

Für Gebäude mit älteren Ausweisen wird zusätzlich die Historie aufgebaut, also der frühere Ausweis mit seinem Ausstellungsdatum, seiner Klasse und seiner Rechtsgrundlage neben dem aktuellen Stand geführt. Geprüft wird dabei nicht, ob die Werte übereinstimmen — sie werden es aus den in Abschnitt 16.7 genannten Gründen häufig nicht —, sondern ob der frühere Zustand erhalten bleibt, ob die Zuordnung zur damaligen Rechtslage korrekt ist und ob die Zehnjahresfrist der Gültigkeit nach Artikel 19 EPBD richtig geführt wird. Für Gebäude unterhalb der Klasse C ist zusätzlich der Hinweis auf die zentrale Anlaufstelle nach Artikel 19 Absatz 13 EPBD zu prüfen.

Auf der Verbrauchsseite ist der Übergang vom bisherigen Verfahren mit drei Abrechnungsperioden zur nach Energieträgern differenzierten, mindestens monatlichen Erfassung über 24 Monate nach § 80 GMoDG zu testen. Der Umschalter zwischen beiden Verfahren ist vorhanden; bis zum Anwendungsdatum müssen beide Wege parallel bedienbar sein. Für den Piloten ist das die Gelegenheit, an realen Abrechnungen zu prüfen, ob monatliche, nach Energieträgern getrennte Werte überhaupt beschaffbar sind — eine Frage, die über die Umsetzbarkeit der Vorschrift mehr aussagt als jede Softwarefunktion. Der Anwendungstermin des Artikels 2 GMoDG ist dabei mit Vorbehalt zu führen: Sekundärquellen nennen den 01.01.2027, während die Sechsmonatsfrist ab der Verkündung am 28.07.2026 rechnerisch auf den 28.01.2027 führt.

Nicht durchführbar sind im Piloten drei Dinge, die zum Energieausweis gehören und nicht an der Software hängen: die Ausgabe im amtlichen Muster nach § 85 Absatz 3 GMoDG, weil das Muster nicht vorliegt; die Registrierung und die Vergabe einer amtlichen Registriernummer, weil das Registerverfahren nicht besteht; und der Lebenszyklus-Treibhausgasbericht nach § 88b GMoDG, weil das dafür vorgesehene Datenformat offen ist. In allen drei Fällen kann der Pilot die zugrunde liegenden Daten erzeugen und maschinenlesbar bereitstellen — die Pflichtangaben nach § 85 werden im Zertifikatsexport bereits maschinenlesbar mitgeführt —, aber er kann das Ergebnis nicht in ein Zielformat überführen, das es nicht gibt.

16.9 Renovierungspass

Der Renovierungspass ist der Teil des Piloten mit dem größten Erkenntnisgewinn und der größten Unsicherheit. Nach Artikel 12 EPBD hatten die Mitgliedstaaten bis zum 29.05.2026 ein Renovierungspass-System einzuführen; für Eigentümer ist der Pass freiwillig. Der Zielzustand ist die umfassende Renovierung auf Niedrigstenergieniveau vor dem 01.01.2030 und auf Nullemissionsniveau ab diesem Datum, mit einer Rückfallschwelle von mindestens 60 Prozent Primärenergiereduktion, wo dies nicht erreichbar ist. Für den Piloten ist entscheidend, dass Anhang VIII die Inhalte des Passes vollständig auflistet — der Test ist damit nicht offen, sondern eine abarbeitbare Prüfliste.

Für ausgewählte Pilotgebäude wird ein Sanierungspfad mit mehreren Stufen erzeugt, beispielsweise vom Ist-Zustand über den Erzeugertausch zur Wärmepumpe, den Fenstertausch, die Fassadendämmung und die Photovoltaik bis zum Zielzustand. Geprüft wird für jede Stufe, ob die fünf Pflichtfelder nach Anhang VIII Nummer 1 Buchstabe e vorliegen: die Bezeichnung und Beschreibung der Maßnahme einschließlich Technologie- und Materialoptionen; die Veränderung von Primär- und Endenergie in Kilowattstunden und in Prozent gegenüber dem Zustand vor dem Schritt; die Veränderung der operativen Treibhausgasemissionen; die Kostenersparnis in Euro mit offengelegten Energiepreisannahmen; und die Zielklasse des Energieausweises nach dem Schritt. Hinzu kommen die grafische Roadmap von der Ausgangslage zum Endzustand, die Begründung der Schrittfolge zur Vermeidung von Festlegungseffekten, die Liste der nationalen Anforderungen mit Stichtagen, die Angaben zu Fernwärmeanschluss, zum Anteil erneuerbarer Energie und zum Eigenverbrauch nach der Sanierung, die Angaben zu Zirkularität und Lebenszyklus-Kohlenstoff sowie Fördermöglichkeiten mit Verweisen und die Kontaktdaten der Beratungsstellen.

Die Kennzahl dieses Abschnitts ist entsprechend definiert: der Anteil der Anhang-VIII-Pflichtfelder, die je Schritt und je Gebäude belegt ausgegeben werden können. Aus dem heutigen Entwicklungsstand lassen sich drei Felder benennen, bei denen ein Fehlbetrag erwartet wird. Die Veränderung der operativen Treibhausgase je Schritt ist rechenbar, aber die Faktortabellen liegen derzeit getrennt in der CO₂-Bilanz, im Renovierungspass-Modul und in der Anlagentechnik; solange sie nicht an der zentralen Rechtsstand-Registry hängen, können zwei Module für denselben Schritt unterschiedliche Werte ausweisen. Der Pilot sollte diesen Abgleich ausdrücklich als Prüfpunkt führen, weil ein solcher Widerspruch in einem Dokument, das der Eigentümer erhält, besonders schwer wiegt. Die Zirkularität und der Lebenszyklus-Kohlenstoff sind nicht belegbar, solange die Ökobilanz nicht aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen rechnet; der heutige Stand ist die Betriebsbilanz mit einem geschätzten Grau-Benchmark. Die Kostenersparnis mit offengelegten Preisannahmen ist erzeugbar, aber die Wirtschaftlichkeitsseite hat eine Lücke: In keinem Projekt sind bisher die Sowieso-Anteile erfasst, obwohl die Kostenwerkzeuge eine Spalte dafür führen. Ohne Sowieso-Anteile wird die Sanierungsinvestition systematisch zu hoch und die Wirtschaftlichkeit systematisch zu schlecht dargestellt. Der Pilot sollte diese Anteile für mindestens einen Teil der Gebäude vollständig erfassen und damit zugleich prüfen, ob die Erfassung im laufenden Beratungsprozess praktikabel ist.

Für die Kopplung an den Energieausweis gilt Artikel 12 Absatz 3 in Verbindung mit Artikel 19 Absatz 6 EPBD: Werden Ausweis und Renovierungspass gemeinsam ausgestellt, ersetzt der Pass die Modernisierungsempfehlungen des Ausweises. Für den Piloten ist das ein günstiger Umstand, weil beide Dokumente ohnehin auf demselben Datensatz beruhen; er ist zugleich ein Prüfpunkt, weil die Dokumente dann widerspruchsfrei sein müssen. Nach Anhang VIII Nummer 3 sind die Ausweisdaten als Ausgangszustand zu berücksichtigen, dürfen aber durch Befunde der Vor-Ort-Aufnahme überschrieben werden — der Renovierungspass verlangt ausdrücklich mindestens einen Vor-Ort-Besuch und geht in der Tiefe über die Ausweisaufnahme hinaus. Der Pilot sollte deshalb den Zeitbedarf der Vor-Ort-Aufnahme für Ausweis und Renovierungspass getrennt erfassen.

Zur Formfrage ist ein Missverständnis auszuräumen, das die Aufwandsschätzung erheblich beeinflusst: Der Renovierungspass muss digital und druckfähig sein; Maschinenlesbarkeit in XML ist eine Empfehlung der Leitlinien, keine Pflicht. Maschinenlesbar sein muss der Energieausweis, für den ein gescanntes PDF ausdrücklich nicht genügt. Ungeklärt ist der Status des deutschen individuellen Sanierungsfahrplans: Er wird in Annex 4 der Kommissions-Leitlinien zweimal als Vorbild genannt, ist damit aber kein Renovierungspass im Sinne des Artikels 12; nicht abgedeckt sind insbesondere die Veränderung der operativen Treibhausgase, Zirkularität und Lebenszyklus-Kohlenstoff sowie die Stichtagsliste. Ob Deutschland den Sanierungsfahrplan förmlich zum Renovierungspass erklärt, ist nicht entschieden. Für den Piloten folgt daraus eine klare Trennung: Das Anhang-VIII-Feldmodell wird vollständig geführt und gemessen; das Datenblatt des Sanierungsfahrplans bleibt eine Ausgabe daraus. Ein förderfähiger Sanierungsfahrplan entsteht ausschließlich in der amtlichen Druckapplikation des BAFA, und ein maschinelles Importformat dafür wird nicht veröffentlicht — die Doppelerfassung an dieser Stelle ist im Piloten zu messen, nicht zu beheben.

16.10 Partnerzugänge

Der marktseitige Teil des Piloten prüft, ob derselbe Gebäudedatensatz für unterschiedliche Adressaten unterschiedliche, jeweils brauchbare Sichten erzeugt. Hier ist zuerst eine Klarstellung nötig, weil sie den zeitlichen Ablauf bestimmt: Ein abgestuftes Zugriffsrollenmodell existiert seit dem 23. August 2026. Was existiert, sind die Anzeige-Rollen der Kennwerte-Seite, die die Reihenfolge und Hervorhebung der 43 Kennwerte je Zielgruppe steuern, und der veröffentlichte Pass-Snapshot, der über einen Prune-Vorgang ausschließlich Gebäudekennwerte ohne personenbezogene Daten enthält, mit einer vierstelligen PIN gesichert wird und dessen Zugang nach je drei Fehlversuchen gestaffelt für 1, 5, 15, 30 und 60 Minuten sperrt. Der Snapshot ist damit ein belastbarer Freigabemechanismus, aber kein Rechtesystem: Er kennt Empfänger nicht, protokolliert keine individuelle Nutzung und erlaubt keinen Widerruf für einen einzelnen Dritten.

Daraus folgt der Zuschnitt des Partnertests. In der ersten Ausbaustufe wird je Empfängertyp ein Freigabepaket definiert — eine feldweise festgelegte Teilmenge des Datensatzes, die als eigener Snapshot veröffentlicht wird. Das Bankenprofil enthält die Gebäudeidentität, die Ausweisangaben mit Klasse, End- und Primärenergie, das Heizsystem, den Sanierungsbedarf mit den Investitionskosten des Renovierungspfads, die Fördermöglichkeiten und — als eigenständiges Feld — die Datenqualität in Gestalt des Anteils freigegebener Werte und der mittleren Vertrauensstufe. Das Maklerprofil ist deutlich schmaler: Ausweisangaben, Baujahr, Heizsystem, dokumentierte Modernisierungen, Sanierungshistorie. Das Verwaltungsprofil zielt auf Betrieb und Wartung: Anlagenhistorie, Prüfungen, Wartungen, Rechnungen, Verbrauchswerte.

Der Test misst je Profil drei Größen. Erstens die Trefferquote: Welcher Anteil der vom Partner tatsächlich benötigten Felder ist im Profil enthalten? Zweitens den Überschuss: Welche Felder werden mitgeliefert, aber nicht verwendet? Drittens die Fehlliste: Welche Felder fehlen, und lassen sie sich aus dem Datensatz erzeugen oder müssten sie neu erhoben werden? Diese drei Zahlen ersetzen die Frage nach der Zufriedenheit. Ein Partner, der angibt, das Profil sei „gut", liefert keine verwertbare Information; ein Partner, der elf von vierzehn benötigten Feldern vorfindet und drei benennt, die fehlen, liefert eine Arbeitsliste. Ergänzend wird die Zahl der strukturierten Änderungsanforderungen erfasst und nach Dringlichkeit klassifiziert; sie ist die eigentliche Ausbeute des Markttests.

Für den Bankenteil gilt eine ausdrückliche Grenze. Der Gebäudepass liefert technische Informationen mit ausgewiesener Herkunft und Belastbarkeit; die Kreditentscheidung trifft das Institut nach seinem eigenen Modell. Der Pilot soll deshalb nicht versuchen, aus dem Datensatz eine Bewertung abzuleiten, und auch der Building Trust Index ist hier korrekt einzuordnen: Er bewertet ausdrücklich nicht den Eigentümer und ist kein Bonitäts- und kein Bankenscore, sondern ein erklärbares Rating der Datenqualität und des technischen Zustands auf einer Skala von 0 bis 100 mit sieben gewichteten Säulen. Der Pilot liefert dabei eine Leistung, die die Software allein nicht erbringen kann: Die Kalibrierung des Index mit Echtprojekten ist ausdrücklich offen. Vierzig reale Gebäude mit gleichzeitig vorliegendem fachlichem Urteil sind genau die Datenbasis, die dafür fehlt. Zu beachten ist dabei, dass die Säule Wartungszustand derzeit den Wert null trägt, solange Dokumente und Wartungen nicht verdrahtet sind — für die Kalibrierung ist diese Säule zunächst auszuklammern, und für den Test der Hausverwaltung ist sie umgekehrt der zentrale Entwicklungsgegenstand.

Die Rollen- und Rechteprüfung im engeren Sinne — sieht ein Makler tatsächlich nur die Verkaufsdaten, ist eine Freigabe befristbar und widerrufbar, wird jeder Zugriff protokolliert — lässt sich seit dem 23. August 2026 am laufenden System beantworten und gehört damit in den Piloten. Prüfbar sind die feldweise Filterung der ausgelieferten Sicht, das Ablaufdatum, der sofort wirksame Widerruf und das Zugriffsprotokoll mit Rolle, Zeitpunkt und Ergebnis. Zwei Punkte bleiben Inhaltsprüfung statt Rechteprüfung: der Entzug der Berechtigung beim Eigentümerwechsel, der heute über den Widerruf der Codes von Hand läuft, und das empfängerbezogene Freigabepaket. Der Pilot sollte diese beiden ausdrücklich als offene Punkte ausweisen, statt sie zu simulieren. Damit wird der praktische Test der in Kapitel 9 beschriebenen Anforderungen an Datensouveränität und Protokollierung teils erbracht und teils als Entwicklungsbedarf sichtbar gemacht — was für einen Piloten ein legitimes, ja gewünschtes Ergebnis ist.

Zwei weitere Prüfungen gehören in diesen Abschnitt, weil sie den Lebenszyklusgedanken belegen. Erstens das Änderungsereignis: In mindestens einem Pilotgebäude wird während der Laufzeit eine reale Maßnahme durchgeführt, etwa der Einbau einer Wärmepumpe. Geprüft wird die vollständige Kette vom neuen Dokument über die Erkennung, die Aktualisierung der Anlage, die Historisierung des früheren Zustands, die automatische Kennzeichnung der betroffenen Auswertungen als veraltet, die Neuberechnung bis zur Fortschreibung des Sanierungspfads und der Gebäudechronik. Die Mechanik dafür ist vorhanden: Die Neuberechnungs-Engine erkennt über einen Fingerabdruck je Eingabesektion die betroffenen Auswertungen, und die Abhängigkeits-Engine kennt die Wirkkette — die Freigabe eines Fensterwerts löst dreizehn nachgelagerte Aufgaben aus. Der Pilot misst, wie viele dieser Aufgaben ohne Eingriff abgearbeitet werden. Zweitens der Eigentümerwechsel, der prüft, ob der Pass am Gebäude und nicht am Nutzer hängt: Die Gebäudehistorie bleibt bestehen, personenbezogene Daten des Voreigentümers werden getrennt, die Gebäudekennung bleibt unverändert. Die Kennung ist idempotent und persistent angelegt, was die Grundlage dafür bildet.

16.11 Schnittstellentest

Der Schnittstellentest zerfällt in zwei Teile, die im Piloten strikt zu trennen sind: Was heute geprüft werden kann, und was mangels eines Zielschemas nicht geprüft werden kann. Die Trennung ist wichtig, weil ein Pilotbericht, der beides vermengt, entweder eine nicht vorhandene Anschlussfähigkeit behauptet oder eine vorhandene Leistung unterschlägt.

Heute prüfbar sind die eigenen Formate. Das Projektformat in JSON mit Export und Import, die Pass-Artefakte in XML und IFC, für die bereits ein Wächter-Prüfschritt existiert, der Zertifikatsexport, der die Pflichtangaben nach § 85 maschinenlesbar mitführt und in das Kostenformat überführt werden kann, sowie die Ausgabe als CSV und als PDF. Die Prüfkriterien sind formal: Ist die Ausgabe schemavalide, sind alle Pflichtfelder besetzt, ist die Zeichenkodierung durchgängig, sind Einheiten und Dezimaltrennzeichen eindeutig, ist die Datei ohne Kenntnis des erzeugenden Systems interpretierbar? Die Zielgröße ist hier eindeutig und binär: Alle definierten Exportprofile sind maschinell valide oder der Pilot hat einen Befund. Ergänzend prüft der Pilot die Rückrichtung, also ob ein exportierter Datensatz wieder eingelesen werden kann und dabei identisch rekonstruiert wird — die Rundlauf-Prüfung ist der einzige belastbare Nachweis, dass ein Format vollständig ist. Für IFC ist dieser Rundlauf nicht möglich, weil der Weg als Eingang ohne Ausgang angelegt ist; dieser Befund ist als solcher zu vermerken.

Ein Zugriff über eine Programmierschnittstelle durch einen externen Testpartner ist im heutigen Stand nur eingeschränkt darstellbar. Die vorhandenen Endpunkte betreffen Projekte, die Veröffentlichung des Passes und den Abruf des veröffentlichten Passes; eine allgemeine Service-API mit getrennten Adressräumen für Rechner, Agenten und Prüfläufe steht als offener Roadmap-Punkt, ebenso die geschlossenen Exportformate. Der Pilot kann deshalb den Abruf eines veröffentlichten Passes durch einen Partner testen — einschließlich Authentifizierung über die PIN oder einen befristeten Rollenzugangscode, der rollenabhängig gefilterten Sicht, der Sperrstaffel bei Fehlversuchen, des Zugriffsprotokolls und der Reaktionszeit —, nicht aber einen feldselektiven Abruf über eine Rollen-API: Die Filterung wirkt heute auf die ausgelieferte Ansicht und die Ausgabeformate, nicht auf eine adressierbare Datenschnittstelle. Wird ein solcher Abruf für den Partnertest benötigt, ist er als Entwicklungsaufgabe vorzuziehen (Abschnitt 16.14) und nicht als vorhandene Funktion zu testen.

Nicht prüfbar sind alle Übertragungen an staatliche Register. Deutschland verfügt zum Quellenstand über keine nationale Energieausweis-Datenbank; der Eintrag in Annex 5 der Kommissions-Leitlinien lautet „n/a". Ein Schema nach Artikel 22 EPBD, gegen das ein Konnektor entwickelt und geprüft werden könnte, existiert nicht. Damit sind auch die daran hängenden Anforderungen nicht testbar: der Upload des Renovierungspasses nach Artikel 12 Absatz 7, die Registrierung des Ausweises mit den vollständigen Berechnungs-Eingangsdaten nach Artikel 20 Absatz 8, die Übertragung an das europäische Gebäudebeobachtungssystem nach Artikel 22 und die Zugriffsstufen für Eigentümer, Finanzinstitute und Kommunen. Ebenfalls offen sind das Schema für den Smart-Readiness-Indikator — dessen Pflicht ohnehin erst durch einen delegierten Rechtsakt bis zum 30.06.2027 und dann nur für Nichtwohngebäude über 290 Kilowatt entsteht — sowie das Schema der DIBt-Kontrolldatei für Monatswerte, ohne das die 24-Monats-Erfassung nur im bisherigen Periodenformat übergeben werden kann.

Was der Pilot an dieser Stelle stattdessen tun kann und tun sollte, ist die Vorbereitung: Für jedes der genannten offenen Ziele wird der interne Datenbestand daraufhin geprüft, ob er die absehbar geforderten Inhalte trägt. Für Artikel 20 Absatz 8 lässt sich das konkret prüfen, weil die Auslegung die Mindest-Rohdaten je Ausweis benennt: Gebäudekategorie, Bezugsfläche und bei Mischnutzung deren Aufschlüsselung, der nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Gebäudetechnik disaggregierte Bedarf, Leistung und Effizienz der technischen Anlagen, die installierte Leistung der erneuerbaren Erzeugung sowie Flächen und U-Werte der Hauptbauteile. Der Pilot weist aus, welcher Anteil dieser Rohdaten je Pilotgebäude vorliegt. Damit entsteht eine belastbare Aussage — der Datenbestand ist zu X Prozent registerfähig —, ohne dass ein Register existiert.

16.12 Erwartete Fehler und Erkenntnisse

Ein Pilot ist nicht dann erfolgreich, wenn keine Fehler auftreten. Ein fehlerfreier Pilot bedeutet in aller Regel, dass zu einfache Gebäude ausgewählt wurden oder dass die Befunde nicht sauber erfasst worden sind. Der Zweck des Piloten besteht darin, Schwachstellen zu finden, bevor die Plattform in der Breite eingesetzt wird; Fehler sind daher das eigentliche Produkt. Voraussetzung dafür ist, dass sie systematisch klassifiziert werden, denn nur klassifizierte Fehler lassen sich zählen, priorisieren und in Entwicklungsaufgaben überführen.

Für die Erkennung aus Dokumenten hat sich eine Klassifikation in fünf Klassen bewährt, die den Ursachen und nicht den Symptomen folgt:

• E1 — Dokument nicht erkannt. Die Datei wurde keinem Dokumenttyp zugeordnet oder gar nicht verarbeitet. Ursache ist meist die Form: Scanqualität, gedrehte Seiten, Mischdokumente mit mehreren Typen in einer Datei.
• E2 — Wert falsch gelesen. Der richtige Wert stand an der richtigen Stelle, wurde aber falsch übernommen — Zahlendreher, verwechselte Einheit, Dezimaltrennzeichen, abgeschnittene Nachkommastelle.
• E3 — Wert korrekt, falsch zugeordnet. Der gelesene Wert stimmt, wurde aber dem falschen Bauteil, der falschen Zone oder dem falschen Geschoss zugewiesen. Diese Klasse ist die tückischste, weil das Ergebnis plausibel aussieht.
• E4 — widersprüchliche Quelle. Zwei Dokumente enthalten unterschiedliche Werte für dieselbe Größe. Hier ist ausdrücklich kein automatischer Vorrang zu setzen; nach den Regeln des Datenmodells werden Konflikte erzeugt und nicht automatisch aufgelöst, und die vier doppelt geführten Felder werden gegen die jeweils andere Quelle geprüft, ohne dass etwas überschrieben wird.
• E5 — fachlich unplausibler Wert. Der Wert ist formal korrekt gelesen, aber technisch unmöglich oder unwahrscheinlich — ein U-Wert von 0,05 W/(m²·K) an einer Bestandswand, eine Nutzfläche unterhalb der Plausibilitätsschwelle von 55 Prozent der Bruttogrundfläche.

Aus dem heutigen Entwicklungsstand und aus der Struktur des Gebäudebestands lassen sich mehrere Befunde bereits vorhersagen. Sie vorab zu benennen ist kein Widerspruch zum Piloten, sondern erhöht seinen Wert: Der Pilot muss sie dann nicht entdecken, sondern quantifizieren.

Der erste erwartete Befund betrifft die Bezugsfläche. Alte Unterlagen führen A_N, die Wohnfläche oder die Bruttogrundfläche; kanonisch ist die Nutzfläche nach DIN 277. Der Unterschied ist keine Umrechnung, und die Größenordnung ist erheblich. Erwartet wird, dass ein großer Teil der Klasse-B- und Klasse-C-Gebäude keinen direkt verwertbaren Flächenwert liefert und dass die Fläche aus dem Grundriss neu ermittelt werden muss. Da Wohnfläche und A_N bewusst nicht aus dem Grundriss abgeleitet werden, ist das ein zusätzlicher Arbeitsschritt und keine Automatisierung — mit unmittelbarer Wirkung auf den Zeitbedarf je Gebäude.

Der zweite erwartete Befund betrifft die Mehrfachschreiber. Das Rollenmodell der Schreibrechte ist beschrieben — der Steckbrief ist Quelle, CAD, Geschoss-Editor, U-Wert-Rechner und Import sind Ermittler auf Nutzeraktion, die Rechenwerkzeuge schreiben ausschließlich auf die Ergebnispfade, Berichte und Pass schreiben gar nichts —, es ist seit dem 23. August 2026 auch erzwungen. Die 55 Verstöße in 15 Werkzeugen, gezählt bei 1 258 literalen Schreibzugriffen, sind abgearbeitet; 35 Registerfelder haben weiterhin mehrere schreibende Werkzeuge, und 58 Aufrufe mit dynamischem Pfad bleiben unerfasst. Für den Piloten heißt das: Ein Wert kann sich ändern, ohne dass ein Bearbeiter ihn geändert hat. Genau das würde jede Messung der Datenqualität entwerten. Die Bereinigung mindestens für die 23 Pflichtfelder ist deshalb keine Erkenntnis des Piloten, sondern seine Voraussetzung.

Der dritte erwartete Befund betrifft die Nichtwohngebäude. Die zonenweise Bilanz griff bislang in keinem Projekt; die Klassenskala fehlt; die Marktwertermittlung liefert für Nichtwohngebäude einen Ertragswert von null; die Energiebedarfs-Staffel für Nichtwohngebäude ist bewusst nicht hinterlegt. Der Aufwand je Nichtwohngebäude wird deshalb deutlich über dem der Wohngebäude liegen, und ein Teil der Ausgaben bleibt unvollständig. Dies ist der Grund, die Nichtwohngebäude in der ersten Stufe des Piloten aufzunehmen und nicht in der letzten.

Der vierte erwartete Befund betrifft die Abweichung zwischen Bedarf und Verbrauch. Sie wird auftreten, und sie ist kein Fehler. Die Bedarfsrechnung arbeitet mit Standardrandbedingungen — Innentemperatur, Nutzungszeiten, Luftwechsel, Warmwasserbedarf —, der gemessene Verbrauch mit dem realen Nutzerverhalten und dem realen Wetter. Der Pilot muss deshalb vorab und einheitlich festlegen, wie bereinigt wird — welche Gradtagzahlen, welcher Bezugszeitraum, welche Behandlung von Leerstand und Zusatzheizungen — und diese Festlegung offenlegen. Erst dann ist die Abweichung eine Kennzahl. Sie ist besonders aufschlussreich, wenn sie in eine Richtung systematisch ausfällt: Eine durchgängige Überschätzung des Bedarfs in schlecht gedämmten Gebäuden ist ein bekanntes Muster und ein wichtiges Argument in Bankengesprächen, weil sie die Einsparerwartung nach einer Sanierung dämpft.

Der fünfte erwartete Befund betrifft die Wirtschaftlichkeit. Der Leistbarkeits-Check arbeitet bislang ohne Anbindung an den Projektspeicher; die Sowieso-Anteile sind in keinem Projekt erfasst. Wirtschaftlichkeitsaussagen im Piloten entstehen daher zunächst mit manueller Datenübergabe und mit einer bekannten systematischen Verzerrung. Beides ist zu dokumentieren, statt die Ergebnisse als integrierte Rechnung darzustellen.

Zu den erwarteten Erkenntnissen gehört schließlich eine, die über den Piloten hinausweist. Aus der feldweisen Auswertung ergibt sich, welche Datenfelder in praktisch jedem Gebäude benötigt werden und welche nur in Sonderfällen. Daraus lässt sich ein stabiler Kernsatz von Feldern ableiten, der die Grundlage für die Standardisierungsdiskussion mit Verbänden und für ein späteres europäisches Kernmodell bildet: Welche Felder sind universell, welche allein durch deutsches Recht bestimmt? Diese Unterscheidung ist die Voraussetzung jeder Skalierung über Deutschland hinaus, und der Pilot ist die einzige Gelegenheit, sie empirisch statt gutachterlich zu beantworten.

16.13 Kennzahlen des Piloten

Die Kennzahlen sind so zu wählen, dass sie ohne Interpretationsspielraum erhoben werden können und dass ihre Erhebung den Pilotbetrieb nicht dominiert. Sie zerfallen in vier Gruppen: Daten, Aufwand, Ergebnisqualität und Anschlussfähigkeit. Jede Kennzahl wird je Gebäude erhoben und anschließend nach Gebäudetyp und Datenqualitätsklasse ausgewertet — ein Gesamtmittelwert über alle Gebäude ist für die Interpretation wertlos, weil er die beiden Einflussgrößen vermischt, die den Aufwand bestimmen.

• Datenvollständigkeit je Pflichtfeld. Für jedes der 23 Pflichtfelder in acht Kategorien der Anteil der Pilotgebäude, in denen es besetzt ist. Ausgewiesen wird die Verteilung über die Felder, nicht ihr Mittelwert. Ergänzend die Vollständigkeit der Mindest-Rohdaten nach Artikel 20 Absatz 8 EPBD als eigene Liste.
• Anteil freigegebener Werte. Der Anteil der Werte im Datenzustand „freigegeben" an allen erfassten Werten. Diese Größe ist maschinell auswertbar, weil sie im Datenmodell geführt wird und in die Datenqualitätssäule des Building Trust Index eingeht. Sie ist die härteste Qualitätsaussage des Piloten, weil nur freigegebene Werte in offizielle Berichte gelangen dürfen.
• Mittlere Vertrauensstufe. Der Mittelwert über die Vertrauensstufen 0 bis 5 aller erfassten Werte, zusätzlich als Verteilung. Der Unterschied zwischen einem Gebäude mit vielen Werten der Stufe 2 — aus Dokument erkannt — und einem mit vielen Werten der Stufe 4 — geprüft — ist für die Verwendbarkeit entscheidend und geht in einem Vollständigkeitswert vollständig unter.
• Erkennungsquote, Übernahmequote, Nacharbeitsquote. Getrennt ausgewiesen wie in Abschnitt 16.6 definiert, zusätzlich je Dokumenttyp, weil sich Grundrisse, Wärmeschutznachweise und Rechnungen deutlich unterschiedlich verhalten.
• Zeitbedarf je Gebäude. In Minuten, getrennt nach Eingangsinventar, Dokumentenaufbereitung, maschineller Verarbeitung, fachlicher Prüfung und Freigabe, Ortsbegehung, Berechnung sowie Dokumenterzeugung. Die Erfassung erfolgt über ein einheitliches Protokollblatt je Phase; eine automatische Zeiterfassung existiert nicht und soll für den Piloten auch nicht geschaffen werden. Zusätzlich der Zeitbedarf je erzeugtem Dokument — Energieausweis, Renovierungspass, Bankenprofil — und der Vergleich mit dem Zeitbedarf der herkömmlichen Bearbeitung desselben Gebäudetyps.
• Anzahl der Rückfragen. Je Gebäude gezählt und klassifiziert nach fehlendem Dokument, unklarer Feldbedeutung, widersprüchlicher Quelle, Bedienfrage und Fachfrage. Diese Zahl ist der beste verfügbare Ersatz für die nicht messbare Größe „Verständlichkeit" und zugleich ein direkter Kostentreiber im späteren Regelbetrieb.
• Abweichung Bedarf zu Verbrauch. Für alle Gebäude mit belastbaren Verbrauchsdaten die prozentuale Abweichung der berechneten Endenergie vom bereinigten gemessenen Verbrauch, mit offengelegtem Bereinigungsverfahren, ausgewiesen als Verteilung mit Vorzeichen und nicht als Betrag.
• Wiederverwendungsquote. Für jede nachgelagerte Anwendung — Heizlast, Wärmeschutznachweis, Renovierungspass, Bankenprofil — der Anteil der Eingangsgrößen, der aus dem bereits vorhandenen Datensatz stammt.
• Abweichung gegenüber Referenz. Für die acht Testgebäude die Einhaltung der eingefrorenen Sollwerte innerhalb eines Prozents; für Pilotgebäude mit unabhängiger Vergleichsrechnung die dokumentierte Abweichung mit Angabe der drei Vergleichbarkeitsbedingungen.
• Exportvalidität und Historienlückenfreiheit. Der Anteil schemavalider Exporte je Profil mit dem Zielwert 100 Prozent sowie der Anteil der Wertänderungen, für die Zeitpunkt, Urheber, Quelle und Vorzustand vollständig nachvollziehbar sind — letzteres ist zugleich die Prüfung der Auditanforderung nach Anhang VI EPBD, nach der der Urheber jeder Änderung ermittelbar sein muss.

Nicht zu den Erfolgskriterien gehören Zufriedenheitswerte. Eine Angabe wie „4,5 von 5" ist weder reproduzierbar noch in eine Entwicklungsaufgabe überführbar und hängt stärker von der Erwartungshaltung des Befragten ab als von der Software. Rückmeldungen der Partner werden deshalb nicht als Bewertung, sondern als gezählte und klassifizierte Änderungsanforderungen erfasst. Ein Partner, der zehn konkrete Anforderungen formuliert, ist für den Piloten wertvoller als einer, der eine hohe Punktzahl vergibt.

Alle Kennzahlen laufen in einer gemeinsamen Auswertung zusammen, die drei Schnitte erlaubt: nach Gebäudetyp, nach Datenqualitätsklasse und nach Pilotstufe. Erst der dritte Schnitt zeigt, ob die zwischenzeitlich vorgenommenen Softwareänderungen gewirkt haben — die Verbesserung einer Quote zwischen Stufe A und Stufe C ist die belastbarste Aussage, die ein Pilot überhaupt erzeugen kann, weil sie an demselben Verfahren mit derselben Messmethode gewonnen wurde.

16.14 Notwendige Softwareänderungen

Ein Teil der beschriebenen Prüfungen setzt Änderungen voraus, die vor der jeweiligen Pilotstufe abgeschlossen sein müssen. Sie hier zu benennen ist Teil des Pilotdesigns, weil ein Pilot, der auf einem bekannt fehlerhaften Messaufbau läuft, unbrauchbare Zahlen liefert. Die folgende Ordnung folgt der Frage, welche Stufe eine Änderung blockiert.

Vor Pilotstufe A (Technik) zwingend. Erstens der automatische Dokumentenlauf beim Öffnen des Gebäudepasses: Er erzeugt und lädt heute ohne Nutzeraktion Dokumente hoch. Solange das so ist, sind Zeitmessung, Versionszählung und die Zuordnung von Auslösern nicht auswertbar; der Lauf gehört hinter eine ausdrückliche Nutzeraktion. Zweitens die Bereinigung der Mehrfachschreiber mindestens für die 23 Pflichtfelder, damit für jedes gemessene Feld genau ein schreibender Zugriffspfad existiert und die Regel der einen führenden Quelle nicht nur formuliert, sondern durchgesetzt ist; der Funktions-Wächter sollte diese Eindeutigkeit als eigenen Prüfschritt führen. Drittens eine einheitliche Protokollierung der Pilotmessgrößen — feldweise Vollständigkeit, Freigabeanteil, mittlere Vertrauensstufe, Zahl der Meldungen und Freigaben — als auswertbarer Export, damit die Kennzahlen nicht händisch aus der Oberfläche abgelesen werden müssen.

Vor Pilotstufe B (Prozesse) erforderlich. Erstens die Zusammenführung der CO₂-Faktortabellen aus CO₂-Bilanz, Renovierungspass-Modul und Anlagentechnik an der zentralen Rechtsstand-Registry, damit die Veränderung der operativen Treibhausgase je Sanierungsschritt in allen Modulen denselben Wert ergibt. Zweitens die Erfassung der Sowieso-Anteile, ohne die jede Wirtschaftlichkeitsaussage systematisch verzerrt ist. Drittens die Anbindung des Leistbarkeits-Checks an den Projektspeicher, damit die Wirtschaftlichkeitsrechnung auf demselben Datensatz arbeitet wie die technische Bewertung und nicht auf einer manuell übertragenen Kopie. Viertens die Vervollständigung des Renovierungspass-Moduls um die fehlenden Anhang-VIII-Felder, soweit sie nicht extern blockiert sind.

Vor Pilotstufe C (Markt) erforderlich. Der Kern ist die Rechteschicht. Für den Partnertest genügt zunächst keine vollständige Umsetzung des siebenstufigen Rollenmodells; erforderlich sind aber empfängerbezogene Freigabepakete mit vier Eigenschaften: eine feldweise definierte Teilmenge je Empfängertyp, eine Bindung an einen benannten Empfänger statt an eine geteilte PIN, eine Befristung mit Widerrufsmöglichkeit und eine Zugriffsprotokollierung. Erst damit sind die Prüffragen aus Kapitel 9 — Freigabe, Widerruf, Befristung, Protokollierung, Schutz personenbezogener Daten — praktisch beantwortbar. Hinzu kommt die Verdrahtung von Dokumenten und Wartungen, ohne die die Wartungssäule des Building Trust Index den Wert null trägt und der Test mit einer Hausverwaltung ohne Gegenstand bleibt.

Nachgelagert, aber vorzubereiten. Die Ökobilanz aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen ersetzt den geschätzten Grau-Benchmark und ist Voraussetzung sowohl für den Lebenszyklus-Wert im Ausweis als auch für die Zirkularitätsangaben des Renovierungspasses. Die Registerkonnektoren bleiben bis zur Veröffentlichung der Zielschemata bei der internen Kante stehen: Der Datenbestand wird auf die absehbaren Inhalte geprüft und bereitgehalten, die Übertragung selbst wird nicht spekulativ entwickelt. Dieselbe Regel gilt für das amtliche Ausweismuster, das Format des Lebenszyklusberichts und das Schema des Smart-Readiness-Indikators.

16.15 Erfolgskriterien

Die Erfolgskriterien werden vor Beginn festgelegt und nicht nach Vorliegen der Ergebnisse. Sie sind zudem nach Datenqualitätsklasse zu differenzieren, weil ein einheitlicher Zielwert entweder für Klasse A trivial oder für Klasse C unerreichbar wäre. Alle Kriterien sind so formuliert, dass die Erfüllung ohne Wertung feststellbar ist.

• Datenvollständigkeit. Für Gebäude der Klasse A sind mindestens 90 Prozent der 23 Pflichtfelder besetzt; für Klasse B mindestens 75 Prozent; für Klasse C mindestens 60 Prozent. Zusätzlich gilt für alle Klassen: Kein einzelnes Pflichtfeld ist in mehr als der Hälfte der Gebäude unbesetzt — ein Feld, das durchgängig fehlt, ist entweder falsch definiert oder nicht erhebbar, und beides ist ein Befund.
• Anteil freigegebener Werte. Mindestens 80 Prozent der Werte, die in ein offizielles Dokument eingehen, stehen im Datenzustand „freigegeben". Werte in anderen Zuständen dürfen in keinem erzeugten Dokument erscheinen; Verstöße hiergegen sind kritische Befunde, nicht Abweichungen vom Zielwert.
• Mittlere Vertrauensstufe. Über alle erfassten Werte eines Gebäudes mindestens 3,0 auf der Skala 0 bis 5 für die Klassen A und B, mindestens 2,5 für Klasse C. Für die Werte, die in den Energieausweis eingehen, gilt unabhängig von der Klasse mindestens 3,5.
• Automatisierung. Erkennungsquote mindestens 70 Prozent bei Klasse A und mindestens 40 Prozent bei Klasse C; fachlich korrekte Übernahme mindestens 80 Prozent der erkannten Werte in allen Klassen. Das zweite Kriterium ist das wichtigere: Eine hohe Erkennungsquote bei niedriger Übernahmequote erzeugt mehr Arbeit als sie spart.
• Zeitbedarf. Der Zeitbedarf vom Eingangsinventar bis zum freigegebenen Datensatz liegt für ein Einfamilienhaus der Klasse B mindestens 30 Prozent unter dem Zeitbedarf der herkömmlichen Bearbeitung desselben Gebäudes durch dieselbe Bearbeitergruppe. Für die übrigen Typen wird der Wert erhoben, aber im ersten Piloten kein Zielwert gesetzt, weil kein belastbarer Vergleichswert vorliegt.
• Rückfragen. Im Mittel höchstens fünf Rückfragen je Gebäude in Stufe C; keine einzelne Feldbedeutung führt in mehr als drei Gebäuden zu einer Rückfrage. Die zweite Bedingung zielt auf systematische Verständlichkeitsprobleme, die ein Mittelwert verdeckt.
• Abweichung Bedarf zu Verbrauch. Für mindestens zwei Drittel der Gebäude mit belastbaren Verbrauchsdaten liegt die Abweichung innerhalb von ±30 Prozent; eine systematische Verzerrung in eine Richtung wird beziffert und erklärt. Der Zielwert ist bewusst weit gefasst — enger wäre er nicht erreichbar und daher kein Kriterium, sondern eine Fiktion.
• Berechnungsqualität. Alle acht Testgebäude halten ihre eingefrorenen Sollwerte innerhalb eines Prozents ein, und der Funktions-Wächter zeigt am Ende jeder Pilotstufe keinen neuen roten Befund. Diese Bedingung gilt absolut: Eine Regression hält den Piloten an.
• Schnittstellen. 100 Prozent der definierten Exportprofile sind schemavalide, und der Rundlauf aus Export und Wiedereinlesen rekonstruiert den Datensatz vollständig — mit Ausnahme des IFC-Wegs, für den der fehlende Ausgang als Befund geführt wird.
• Versionssicherheit. Für 100 Prozent der Wertänderungen sind Vorzustand, neuer Zustand, Zeitpunkt, Urheber und Quelle nachvollziehbar. Auch dieses Kriterium gilt absolut, weil es die Auditanforderung nach Anhang VI EPBD unmittelbar abbildet.
• Anschlussfähigkeit der Profile. Für jedes Empfängerprofil sind mindestens 80 Prozent der vom Partner benannten benötigten Felder enthalten, und für jedes fehlende Feld liegt eine Entscheidung vor, ob es erzeugt, erhoben oder verworfen wird.

Diese Kriterien sind bewusst nicht alle als „bestanden oder nicht bestanden" formuliert. Drei von ihnen gelten absolut — Regressionsfreiheit, Versionssicherheit, Schemavalidität —, weil sie Voraussetzungen für die Verwendbarkeit der Ergebnisse sind. Die übrigen sind Zielwerte, deren Verfehlung einen Befund und eine Entwicklungsaufgabe erzeugt, aber nicht das Scheitern des Piloten. Der Pilot scheitert nur an einer Stelle wirklich: wenn die Zahlen am Ende nicht erhoben wurden.

16.16 Stufung, Entscheidungstore und Empfehlung für den Rollout

Der Pilot wird in vier Stufen geführt, die aufeinander aufbauen und nach denen jeweils eine formale Entscheidung getroffen wird. Stufe A — Technik mit zehn Gebäuden prüft Datenmodell, Import und Berechnung. Stufe B — Prozesse mit etwa zwanzig Gebäuden nimmt Renovierungspass, Historie, Änderungsereignis und Förderlogik hinzu. Stufe C — Markt mit rund vierzig Gebäuden öffnet den Piloten für Banken, Makler und Hausverwaltungen und setzt die Freigabepakete voraus. Stufe D — Skalierung mit einem größeren Portfolio zielt allein auf Automatisierung und Zeitverhalten und ist erst sinnvoll, wenn die Ergebnisse der Stufe C stabil sind.

Nach jeder Stufe steht eine Entscheidung mit drei möglichen Ausgängen: die Freigabe der nächsten Stufe; die Freigabe unter Auflagen, wenn benannte Punkte parallel abgearbeitet werden; oder das Anhalten, wenn ein grundlegender Umbau erforderlich ist. Damit diese Entscheidung nicht zur Formalie wird, ist sie an die Kennzahlen der jeweiligen Stufe zu binden und schriftlich zu begründen. Die Befunde werden dabei in vier Dringlichkeitsstufen einsortiert: kritisch — vor dem Rollout zu beheben; hoch — vor breiter Nutzung zu beheben; mittel — in einem späteren Release; niedrig — Optimierung. Diese Priorisierung ist zugleich die Übergabe an die Entwicklungsplanung aus Kapitel 14.

Zum Abschluss entsteht ein eigener Pilotbericht mit zwölf Abschnitten: Zielsetzung, Gebäudeauswahl, Ausgangsdaten, Datenimport, Berechnungen, Renovierungspass, Partnerzugänge, Schnittstellen, Fehler und Erkenntnisse, Kennzahlen, notwendige Softwareänderungen und Empfehlung für den Rollout. Sein Wert liegt weniger in der Bestätigung als in der Belegbarkeit. Der Unterschied zwischen der Aussage „die Plattform kann Gebäudedaten verwalten" und der Aussage „vierzig reale Gebäude wurden aufgenommen, die feldweise Vollständigkeit lag zwischen X und Y Prozent, Z Prozent der Werte waren freigegeben, der Zeitbedarf je Einfamilienhaus betrug N Minuten, drei Kreditinstitute haben das Bankenprofil geprüft und elf Felder nachgefordert" ist für jedes Gespräch mit Verbänden, Instituten oder Ministerien der entscheidende. Er ist auch die Grundlage der Standardisierungsdiskussion: Erst die feldweise Auswertung über einen realen Bestand zeigt, welche Felder tatsächlich in nahezu jedem Gebäude gebraucht werden und damit als Kernsatz taugen.

Die Empfehlung für den Rollout folgt daraus in drei Teilen. Erstens sollte der Rollout nach Gebäudetyp gestaffelt erfolgen und mit Wohngebäuden beginnen, weil dort die Klassenbildung vollständig ist, die Rechenwege am besten belegt sind und die Fallzahl am höchsten ist. Nichtwohngebäude folgen, sobald die Klassengrenzen nach Anlage 10a vorliegen; bis dahin werden sie mit vollständigem Kennwertsatz und ohne Klasse geführt. Zweitens sollte der Rollout nicht auf die Veröffentlichung des Registerschemas nach Artikel 22 EPBD warten. Die registerbezogenen Funktionen bleiben an der internen Kante stehen, während alle übrigen Funktionen produktiv genutzt werden; ein Warten wäre bei einem Schema, das zum Quellenstand nicht einmal angekündigt terminiert ist, eine unbestimmte Verzögerung. Drittens sollte kein Rollout beginnen, bevor die als kritisch eingestuften Befunde behoben und die drei absolut geltenden Erfolgskriterien erfüllt sind. Ein Rollout auf einer Datenbasis, deren Änderungshistorie Lücken aufweist, wäre nicht nur technisch riskant, sondern liefe der Grundregel des Datenmodells zuwider, nach der jede Information genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie hat.

Die folgende Übersicht fasst die Arbeitspakete des Piloten zusammen. Die Dauerangaben sind Planungsansätze für die Aufwandsschätzung und keine gemessenen Werte; sie beziehen sich, wo nicht anders angegeben, auf die jeweilige Pilotstufe und sind nach Verfügbarkeit der Bearbeiter und der Gebäude anzupassen. Die letzte Spalte enthält die für das Whitepaper wesentliche Unterscheidung: „ja" bedeutet, dass Recht und Spezifikation vorliegen und das Paket mit dem heutigen Stand durchführbar ist; „teilweise" bedeutet, dass das Paket bis zu einer benannten Kante läuft; „nein" bedeutet, dass es an einer fehlenden externen Spezifikation oder an einer zuvor zu leistenden Entwicklungsarbeit blockiert ist.

Die Übersicht zeigt die tragende Aussage dieses Kapitels in verdichteter Form: Von achtzehn Arbeitspaketen sind dreizehn mit dem heutigen Stand vollständig durchführbar, drei laufen bis zu einer benannten Kante und werden dort angehalten, eines setzt eine klar umrissene eigene Entwicklungsleistung voraus, und genau eines ist durch das Fehlen einer staatlichen Spezifikation blockiert. Das Verhältnis ist der eigentliche Befund. Der Pilot scheitert nicht an der Software und nicht an der Regulierung als ganzer, sondern an einzelnen, benennbaren Stellen — und an allen anderen Stellen kann er sofort beginnen. Damit wird er zum Bindeglied zwischen der Entwicklungsplanung aus Kapitel 14 und der Marktbetrachtung aus Kapitel 15: Er liefert die Zahlen, die beide bisher nur schätzen können.

17 Chancen, Risiken und Grenzen

Ein Whitepaper, das nur Chancen beschreibt, ist eine Werbeschrift. Der digitale Gebäudepass führt technische Gebäudedaten, Energiekennwerte, Sanierungsplanung, Finanzierungsrechnungen, Dokumente und künftig Betriebsdaten in einem einzigen, dauerhaft geführten Datensatz zusammen — und genau diese Bündelung erzeugt neben dem Nutzen auch Risiken. Dieses Kapitel benennt beide Seiten mit gleicher Genauigkeit: die Chancen, die sich aus dem gemeinsamen Datensatz ergeben, die Risiken, die in der eigenen Umsetzung nachweisbar vorhanden sind, und die Grenzen, die auch eine vollständig entwickelte Plattform nicht überschreiten kann. Die zentrale Frage lautet nicht, ob der Gebäudepass nützlich sein kann, sondern unter welchen Bedingungen er seinen Nutzen entfaltet und wo seine Aussagekraft endet.

17.1 Zweck und Systematik des Kapitels

Die Kapitel 12 bis 14 haben den Gebäudepass gegen die Anforderungen der EPBD gestellt, seinen Reifegrad bestimmt und die Entwicklungsschritte geordnet. Dieses Kapitel wechselt die Perspektive: Es fragt nicht, was noch fehlt, sondern was schiefgehen kann — im System, in der Anwendung, im rechtlichen Umfeld und im Markt. Diese Frage ist nicht akademisch. Ein Gebäudepass soll Jahrzehnte bestehen, Daten für Nachweise, Finanzierungen und Verwaltungsentscheidungen liefern und dabei einen Datenbestand führen, der personenbezogene Bezüge, wirtschaftlich relevante Informationen und technische Nachweise verbindet. Fehler in einem solchen System wirken nicht punktuell, sondern entlang der Wirkkette bis in das Dokument, das ein Eigentümer einer Bank oder einer Behörde vorlegt.

Die Darstellung folgt deshalb drei Unterscheidungen, die im weiteren Text konsequent durchgehalten werden. Erstens: Risiko oder Grenze. Ein Risiko ist ein Ereignis, dessen Eintritt sich durch Gegenmaßnahmen unwahrscheinlicher oder folgenärmer machen lässt. Eine Grenze ist eine Eigenschaft des Systems, die auch bei vollständiger Entwicklung bestehen bleibt — etwa die Tatsache, dass eine Software fehlende Bauteilinformationen nicht erzeugen kann. Zweitens: in eigener Hand oder nicht. Ein Risiko, das aus dem eigenen Code, dem eigenen Prozess oder der eigenen Kommunikation stammt, ist behebbar; ein Risiko, das aus einer fehlenden staatlichen Spezifikation folgt, ist nur abfederbar. Diese Trennung entscheidet darüber, ob eine Gegenmaßnahme ein Arbeitspaket oder eine Beobachtungsaufgabe ist. Drittens: belegt oder vermutet. Wo dieses Kapitel ein Risiko der eigenen Plattform benennt, stützt es sich auf die dokumentierten Befunde der Entwicklungsunterlagen und nicht auf abstrakte Möglichkeiten.

Für die Eintrittswahrscheinlichkeit verwendet dieses Kapitel ausschließlich die qualitativen Stufen gering, mittel und hoch. Zahlenwerte werden bewusst nicht angegeben: Für ein System, das sich noch in der Entwicklung befindet und dessen Nutzungsumfang wächst, gäbe es keine belastbare Grundlage für eine Quantifizierung, und eine erfundene Prozentzahl wäre genau der Fehler, den dieses Kapitel an anderer Stelle als Scheingenauigkeit kritisiert. Die Zuordnung der Stufen wird im Text jeweils begründet; ein Risiko, dessen Eintritt in den Entwicklungsunterlagen bereits als Befund dokumentiert ist, wird als hoch geführt, weil es nicht mehr um Eintritt, sondern um Ausmaß geht.

17.2 Chance: ein gemeinsamer, mehrfach nutzbarer Gebäudedatensatz

Die größte Chance des Gebäudepasses liegt nicht in einer einzelnen Funktion, sondern in der Aufhebung einer Zersplitterung. Heute liegen die Informationen über ein Gebäude in mindestens sechs voneinander getrennten Beständen: beim Eigentümer als Ordner, beim Energieberater als Projektdatei, beim Architekten als Planwerk, bei der Hausverwaltung als Verwaltungsakte, bei der Förderstelle als Antragsunterlage und bei der Bank als Beleihungsakte. Keiner dieser Bestände kennt den anderen, keiner wird durch die Änderung eines anderen aktualisiert, und jeder wird bei Bedarf neu aufgebaut. Der Gebäudepass macht daraus einen gemeinsamen, versionierten Datensatz, auf den alle Beteiligten in ihrer jeweiligen Rolle zugreifen.

Der wirtschaftliche Kern dieser Chance ist die Wiederverwendung. Ein erheblicher Teil des heutigen Aufwands entsteht dadurch, dass dieselben Größen mehrfach erhoben werden: Flächen, Bauteilaufbauten und U-Werte, das Heizsystem, das Baujahr, die Sanierungshistorie. Werden diese Angaben einmal erfasst, geprüft und freigegeben, lassen sie sich in der Heizlastberechnung, im Wärmeschutznachweis, im Energieausweis, in der Sanierungsplanung, in der Förderprüfung und in der Finanzierungsrechnung ohne erneute Erhebung verwenden. Das Prinzip „einmalige Datenerfassung — Mehrfachnutzung" ist in der vorhandenen Plattform bereits weitgehend umgesetzt: Der ProjektStore führt das Projektobjekt zentral, die Rechenwerkzeuge lesen aus denselben Pfaden, und die Abhängigkeitsschicht kennt die Wirkkette vom Bauteil über U-Wert und Heizlast bis zu Nachweis, Ausweis, CO₂-Bilanz und Finanzierungsbericht.

Die zweite, weniger offensichtliche Chance ist die Richtung der Datenqualität. Ein klassischer Gebäudeordner altert; ein gepflegter Gebäudedatensatz kann besser werden. Der typische Verlauf lässt sich an einer Dachdämmung zeigen: Im Erstzustand ist die Dämmstärke geschätzt und trägt eine niedrige Vertrauensstufe. Später findet sich die Handwerkerrechnung, das Dokument wird hinterlegt und über die Kante „belegt durch" mit dem Datensatz verbunden — die Vertrauensstufe steigt. Noch später wird das Dach im Zuge einer Maßnahme geöffnet, der Aufbau fotografiert und aufgenommen, der Wert geprüft und freigegeben. Derselbe Datensatz trägt am Ende eine belastbare Angabe, wo er zu Beginn eine Annahme trug. Ein Gebäudepass wird also nicht nur älter, er kann mit jeder Nutzung präziser werden — vorausgesetzt, das System hält die Qualitätsstufe eines Wertes fest und macht sie sichtbar. Damit ist bereits der Übergang zum ersten Risiko benannt.

17.3 Risiko: Datenqualität, Scheingenauigkeit und der Umgang mit Unsicherheit

Die grundlegende Schwäche jedes digitalen Gebäudemodells ist einfach zu formulieren und schwer zu beheben: Eine gute Software kann aus schlechten Eingangsdaten keine richtigen Gebäudedaten machen. Im Bestand ist das der Regelfall und nicht die Ausnahme. Pläne stimmen nicht mit der Ausführung überein, weil während der Bauzeit geändert wurde. Eigentümer erinnern Maßnahmen mit falschem Jahr oder falschem Umfang. Sanierungen sind ohne Rechnung und ohne Nachweis erfolgt. Ein vorhandener Energieausweis ist zehn Jahre alt und bildet einen zwischenzeitlich veränderten Zustand ab. Jede dieser Lücken erzeugt in der Bilanzierung eine Annahme — und Annahmen sind zulässig, solange sie als solche kenntlich bleiben.

Daraus folgt die wichtigste Konstruktionsregel des Datenmodells: Kein Wert steht für sich. Jeder fachlich relevante Wert trägt Quelle, Methode, Erfasser, Datum, Prüfstatus und Version. Die Plattform setzt das über die Governance-Schicht bereits um; sie kennt die vier Datenzustände Entwurf, gemeldet, geprüft und freigegeben, führt Vertrauensstufen von der unbekannten Angabe bis zur amtlich signierten Information und hält in der Herkunftskennzeichnung je Wert fest, ob er aus einem Dokument, aus einer Nutzerangabe, aus einer Berechnung, aus einer Fachplanung oder aus einer Schätzung stammt. Ein geschätzter U-Wert darf damit nicht denselben Status besitzen wie ein durch Berechnung und Nachweis bestätigter Wert — und er hat ihn im Datenmodell auch nicht.

Das zweite Risiko dieses Feldes ist subtiler und in der Praxis folgenreicher: die Scheingenauigkeit. Ein Ergebnis wie ein auf den Euro bezifferter Sanierungsbedarf wirkt präzise, auch wenn drei der zugrunde liegenden Bauteile nur geschätzt wurden. Die Nachkommastelle einer Bilanz sagt nichts über die Belastbarkeit ihrer Eingangsgrößen. Der richtige Umgang besteht deshalb nicht darin, ungenaue Ergebnisse zu verschweigen, sondern darin, sie mit Bandbreite und Qualitätsangabe auszugeben: eine Kostenspanne statt eines Punktwerts, ergänzt um die Angabe, auf welcher Datenqualität sie beruht. Die Plattform folgt diesem Grundsatz an mehreren Stellen bereits konsequent — die Kennwerte-Seite zeigt fehlende Werte als Strich und erzeugt ausdrücklich keine Fantasiewerte, der Berichtsgenerator setzt bei fehlendem Sommerschutznachweis den Vermerk, dass der Nachweis nicht geführt wurde, statt einen Wert einzusetzen, und die Klassenfunktion für Nichtwohngebäude gibt zwischen der besten und der schlechtesten Klasse bewusst keinen Wert zurück, solange die Klassengrenzen nicht amtlich feststehen.

An anderen Stellen ist derselbe Grundsatz noch nicht durchgezogen, und die Entwicklungsunterlagen benennen die Fälle offen. Die Ökobilanz arbeitet für die grauen Emissionen derzeit mit einem geschätzten Benchmark je Quadratmeter statt mit einer Berechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen. Im Finanzierungsteil sind eine Monatsrate von null Euro und eine negative Nettobelastung als offene Befunde dokumentiert, ebenso ein Widerspruch zwischen einem Dokumentenstand von rund der Hälfte und einem als vollständig ausgewiesenen Dokumentationszustand. Solche Konstellationen sind keine Katastrophen, aber sie sind genau die Stellen, an denen ein Leser einer Ausgabe mehr Genauigkeit entnimmt, als das System liefern kann. Die Gegenmaßnahme ist immer dieselbe: Kennzeichnung des Herkunftsniveaus, Bandbreite statt Punktwert, Lücke statt Ersatzwert.

Aus dem Problem entsteht zugleich ein eigenständiger Nutzen. Ein Gebäudepass kann nicht nur zeigen, was über ein Gebäude bekannt ist, sondern auch, wie gut es bekannt ist. Der Vollständigkeitsteil des vorhandenen Passes führt dafür dreiundzwanzig Pflichtfelder in acht Kategorien mit Priorität und Sprungziel; die Kennwerte-Seite versieht jeden der dort geführten Kennwerte mit einer Herkunftsplakette. Für einen Energieberater ist die Aussage, dass die Fensterdaten weitgehend belegt und die Dachdaten überwiegend geschätzt sind, unmittelbar handlungsleitend: Sie sagt ihm, wo eine zusätzliche Prüfung den größten Erkenntnisgewinn bringt. Für eine Bank ist dieselbe Aussage Teil der Risikoeinschätzung. Sichtbare Unsicherheit ist damit kein Eingeständnis von Schwäche, sondern ein Produktmerkmal.

17.4 Risiken der eigenen Umsetzung: Datenhoheit, Automatik und Zugang

Die folgenden drei Befunde stammen nicht aus einer allgemeinen Risikobetrachtung, sondern aus den Entwicklungsunterlagen der vorhandenen Plattform. Sie werden hier benannt, weil ein Risikokapitel, das die eigenen dokumentierten Schwachstellen auslässt, seinen Zweck verfehlt. Alle drei sind in eigener Hand und damit behebbar; alle drei berühren jedoch genau die Eigenschaft, mit der der Gebäudepass steht und fällt — die Verlässlichkeit der Zuordnung zwischen einem Wert, seiner Quelle und der Person, die ihn verantwortet.

Das Rollenmodell der Schreibrechte ist beschrieben und seit dem 23. August 2026 erzwungen

Das Datenmodell fordert für jede Information genau eine führende Quelle. Dazu gehört ein klares Rollenmodell der Schreibrechte: Der Steckbrief ist die Quelle der Gebäudestammdaten; ermittelnde Werkzeuge wie der CAD-Editor, der Geschoss-Editor, der U-Wert-Rechner und der Import schreiben nur auf ausdrückliche Nutzeraktion; die Rechenwerkzeuge für Heizlast, Kühllast, Wärmeschutznachweis, Ökobilanz, Photovoltaik und Marktwert schreiben ausschließlich in die Ergebnispfade; ausgebende Werkzeuge wie Berichte und Pass schreiben gar nichts. Kein Standardwert wird gespeichert, und beim bloßen Laden eines Werkzeugs wird nicht geschrieben.

Diese Regel ist dokumentiert, aber sie ist im Code nicht durchgesetzt. Belegt sind sechsundvierzig Profilfelder mit mehreren schreibenden Werkzeugen sowie neunundvierzig Verstöße in dreizehn Werkzeugen bei eintausendeinhundertsiebzig literalen Schreibzugriffen. Diese Zahl ist ausdrücklich eine Untergrenze, weil sechsundfünfzig Aufrufe mit dynamisch zusammengesetztem Pfad in der Auswertung nicht erfasst werden konnten. Die Wirkung ist nicht theoretisch: Wo zwei Werkzeuge dasselbe Feld schreiben, entscheidet die Reihenfolge der Benutzung über den Inhalt, und ein geprüfter Wert kann durch einen später geöffneten Rechner mit einem Standardwert überschrieben werden, ohne dass jemand den Vorgang bemerkt. Damit ist die Grundregel „genau eine führende Quelle" derzeit eine Konvention und keine technische Eigenschaft. Die Eintrittswahrscheinlichkeit ist deshalb als hoch einzustufen — die Verstöße sind gezählt, es geht nicht mehr um den Eintritt, sondern um die Häufigkeit im laufenden Betrieb. Die Gegenmaßnahme ist bekannt und in Kapitel 14 als Arbeitspaket der ersten Entwicklungsstufe verankert: ein Feldeigentümer je Feld, eine erzwungene Schreibschicht und eine automatische Prüfung dieser Eindeutigkeit durch den Funktions-Wächter, der mit inzwischen 499 Prüfungen ohnehin täglich läuft.

Das Öffnen des Passes erzeugt Dokumente ohne Nutzeraktion

Der zweite Befund betrifft dieselbe Regel von der anderen Seite. Die Dokumenten-Engine erzeugt in ihrer aktuellen Fassung sieben automatische Dokumente — Bedarfsausweis, Wärmeschutznachweis, Grundriss, hydraulischer Abgleich, Heiz- und Kühllastbericht, Maßnahmenbericht und Finanzierungsbericht —, jeweils mit einem Hash-Merker, sodass eine Neuerzeugung nur bei geänderter Datengrundlage erfolgt. Diese Mechanik ist sinnvoll. Ihre Auslösung ist es nicht: Das bloße Öffnen des Gebäudepasses startet den automatischen Lauf, erzeugt ungefragt PDF-Dokumente und lädt sie hoch, ohne dass eine Nutzeraktion vorliegt; im produktiven Browserbetrieb ist das Verhalten weiterhin aktiv.

Das ist ein doppelter Widerspruch. Fachlich widerspricht es der eigenen Regel, dass ausgebende Werkzeuge nicht schreiben und dass beim bloßen Laden nichts geschrieben wird. Rechtlich ist es das größere Problem: Ein Bedarfsausweis oder ein Wärmeschutznachweis ist kein Nebenprodukt einer Ansicht, sondern ein Dokument mit Aussagewert, das ein Ersteller verantwortet. Entsteht es ohne Anstoß, ist im Zweifel nicht mehr rekonstruierbar, ob die zugrunde liegenden Werte zum Erzeugungszeitpunkt bereits freigegeben waren und wer die Erzeugung veranlasst hat. Für die Haftungsfrage in Abschnitt 17.6 ist genau das die kritische Größe. Die Gegenmaßnahme ist klein im Aufwand und groß in der Wirkung: Die Erzeugung offizieller Dokumente wird an eine ausdrückliche Nutzeraktion und an den Datenzustand „freigegeben" gebunden; automatische Läufe erzeugen allenfalls einen Entwurf, der als solcher gekennzeichnet ist und nicht in die Dokumentenablage des Gebäudes wandert.

Der veröffentlichte Pass hängt an einer vierstelligen PIN

Der dritte Befund betrifft den Zugang. Der veröffentlichte Gebäudepass entsteht über einen Snapshot, der vor der Veröffentlichung bereinigt wird: In die öffentliche Fassung gelangen nur Gebäudekennwerte, keine personenbezogenen Daten. Diese Bereinigung ist die wichtigste Schutzmaßnahme, und sie greift. Der Zugang zur veröffentlichten Adresse wird anschließend durch eine bei der Veröffentlichung vergebene vierstellige PIN geschützt, ergänzt um eine gestaffelte Sperre von einer bis sechzig Minuten nach jeweils drei Fehlversuchen. Der zugehörige QR-Ausdruck enthält die PIN nicht.

Eine vierstellige Ziffernfolge hat einen Wertebereich von zehntausend Möglichkeiten. Die Fehlversuchssperre verhindert das schnelle Durchprobieren wirksam und ist deshalb keine Nebensache, sondern die eigentliche Schutzwirkung. Für die Weitergabe an Kaufinteressenten, Makler oder Banken war diese Konstruktion an der Untergrenze des Angemessenen: Eine PIN wird weitergegeben, sie wird nicht widerrufen, sie ist nicht empfängerbezogen, und sie ist nicht befristet — wer sie einmal erhalten hat, behält den Zugang unbegrenzt. Die EPBD zeichnet für diesen Fall ein deutlich feineres Bild: Artikel 22 sieht für Kauf- und Mietinteressenten sowie unabhängige Experten den Zugang ausdrücklich nur mit Erlaubnis des Eigentümers vor und empfiehlt befristeten Zugang, gegebenenfalls als reine Bildschirmansicht. Genau das leistet seit dem 23. August 2026 das abgestufte Zugriffs-Rollenmodell: Für jeden Empfänger wird ein eigener Code mit Rolle, Ablaufdatum und wahlweise reiner Bildschirmansicht ausgestellt, der Zugang ist jederzeit widerrufbar, und jeder Zugriff steht im Protokoll. Die PIN bleibt daneben ausschließlich der Zugang des Eigentümers und ist nicht mehr das Mittel der Weitergabe. Offen bleiben die sechsstellige PIN und die digitale Signatur je Freigabe. Die Eintrittswahrscheinlichkeit eines unbefugten Zugriffs ist bei der derzeitigen Nutzungszahl als mittel einzustufen; sie steigt mit jeder zusätzlichen Veröffentlichung und mit jedem weitergegebenen QR-Ausdruck.

17.5 Risiken der eigenen Umsetzung: Aussagekraft der Ergebnisse

Die zweite Gruppe eigener Risiken betrifft nicht den Weg der Daten, sondern die Belastbarkeit dessen, was am Ende ausgegeben wird. Auch hier gilt: Die Befunde sind dokumentiert, sie sind behebbar, und sie sind für die Außenwirkung des Gebäudepasses erheblich, weil sie Kennzahlen und Dokumente betreffen, die Dritte zur Grundlage eigener Entscheidungen machen könnten.

Der Building Trust Index ist berechenbar, aber nicht kalibriert

Der Building Trust Index ist in der Plattform als eigene Datenschicht über dem Projektbestand umgesetzt und liefert eine Bewertung auf einer Skala von null bis einhundert, getragen von sieben gewichteten Säulen: Dokumentationsqualität und technischer Zustand mit je zwanzig Prozent, Energiequalität und Datenqualität mit je fünfzehn Prozent sowie Wartungszustand, Sanierungsreife und Zukunftsfähigkeit mit je zehn Prozent. Er ist ausdrücklich kein Energie-, Banken- oder Bonitätsscore, sondern bewertet die Qualität und Vertrauenswürdigkeit der Gebäudedaten sowie den technischen Zustand; jeder positive und negative Beitrag ist im Regelwerk offengelegt und damit erklärbar. Das ist eine bewusst gewählte, gute Konstruktion.

Zwei dokumentierte Einschränkungen begrenzen die Aussagekraft jedoch derzeit erheblich. Erstens steht die Säule Wartungszustand auf null, solange Dokumente und Wartungen nicht mit ihr verdrahtet sind. Da diese Säule mit zehn Prozent in das Gesamtergebnis eingeht, verliert jedes bewertete Gebäude systematisch bis zu zehn Punkte, unabhängig von seinem tatsächlichen Wartungszustand. Für ein gut dokumentiertes Gebäude entscheidet das über den Sprung in die nächste Ampelstufe und damit über die Statusaussage der Passkarte. Zweitens ist die Kalibrierung an Echtprojekten offen; verifiziert ist das Regelwerk bislang in vier gerechneten Szenarien. Solange nicht geprüft ist, ob ein bekannt gut dokumentiertes Gebäude tatsächlich den erwarteten Bereich erreicht und ein bekannt schlecht dokumentiertes den erwarteten unteren Bereich, ist der Index eine plausible, aber nicht validierte Größe.

Daraus folgt kein Verzicht, sondern eine Kommunikationsregel und eine Entwicklungsaufgabe. Der Index darf, solange die Wartungssäule leer und die Kalibrierung offen ist, nicht als absolute Kennzahl gegenüber Dritten verwendet werden — insbesondere nicht gegenüber Banken, für die er ausdrücklich nicht gedacht ist. Sinnvoll bleibt er als interne Fortschrittsanzeige und als Wegweiser: Die zweite Stufe der Berechnung weist ohnehin nicht nur den Status aus, sondern das Potenzial, also die Maßnahmen mit dem größten geschätzten Zugewinn, darunter das Prüfen und Freigeben offener Werte. Genau diese Richtung — nicht der Punktwert, sondern der nächste sinnvolle Schritt — ist die belastbare Verwendung. Bis zur Kalibrierung sollte jede Ausgabe des Index die leere Wartungssäule ausweisen, statt sie im Gesamtwert verschwinden zu lassen.

Normstand und Rechtsstand dürfen nicht verwechselt werden

Das anschaulichste Beispiel für ein Risiko, das rein aus dem Zusammenspiel von Technik und Recht entsteht, ist die Normlage bei DIN V 18599. Verbindlich gerechnet wird die Ausgabe DIN V 18599:2018-09; sie ist die öffentlich-rechtliche Grundlage, auf die das Gebäudeenergierecht Bezug nimmt. Die 2025 herausgegebene Reihe DIN/TS 18599:2025-10 ist eine Technische Spezifikation und keine Grundlage des GEG. Ergebnisse, die auf ihr beruhen, sind Vergleichsrechnung und nicht rechtsverbindlicher Nachweis. Die Plattform folgt dieser Trennung: Die Rechenkerne arbeiten auf der Ausgabe 2018-09, und die Normstand-Registry führt beide Fassungen als umschaltbares Paar, wobei die Grundsatzentscheidung lautet, dass nur die Ausgabe 2018 gerechnet wird und die Ausgabe 2025 als Vergleich mitläuft.

Das Risiko liegt nicht in der Rechenlogik, sondern im Dokument, das das Haus verlässt. Wird eine Vergleichsrechnung ohne deutliche Fassungsangabe ausgegeben, kann sie mit einem Nachweis verwechselt werden — und der Unterschied ist inhaltlich relevant, denn die Änderungen der Ausgabe 2025-10 betreffen unter anderem den Wärmebrückenzuschlag der Kategorie B, die saisonale Fensterlüftung bei Wohngebäuden, die Nutzungsprofile des Teils 10 und die normativ neu gefassten CO₂-Äquivalente. Hinzu kommt eine zweite Verwechslungsgefahr auf der Faktorenebene: Der Anhang der Norm 2025 weist für Strom einen anderen Primärenergiefaktor aus als die geltende Anlage des GEG. Für Energieausweise und öffentlich-rechtliche Nachweise haben die Faktoren des GEG Vorrang. Beide Punkte verlangen dieselbe Maßnahme, und sie ist billig: Jede Ausgabe, die ein Dokument verlässt, benennt die gerechnete Normfassung, den zugrunde gelegten Rechtsstand und die verwendete Faktortabelle. Die Rechtsstand-Registry setzt bereits einen Stempel an jedes Ergebnis; dieser Stempel muss vollständig bis in die Beschriftung des ausgegebenen Dokuments durchgereicht werden.

Die erzeugten Ausweise tragen keine amtliche Registriernummer

Der Gebäudepass erzeugt bei vollständigem Energiekern automatisch einen Bedarfsausweis als Dokument und versieht ihn mit einer internen Ausweisnummer, die deterministisch aus der Gebäudekennung abgeleitet wird. Diese Nummer ist ausdrücklich keine Registriernummer des Deutschen Instituts für Bautechnik. Die Entwicklungsunterlagen führen den Energieausweis-Agenten folgerichtig als nur teilweise umgesetzt und benennen als offen unter anderem die Ausweisarten, die Gültigkeitsregelung und eben die Registriernummer.

Für die Außenwirkung ist das der heikelste Punkt des gesamten Ausgabeteils. Ein Dokument, das wie ein Energieausweis aussieht, eine Effizienzklasse trägt und eine Nummer führt, kann von einem Eigentümer für einen amtlichen Ausweis gehalten werden. Es ist keiner. Der amtliche Ausweis entsteht durch einen ausstellungsberechtigten Aussteller nach den Regeln des GEG und wird registriert; die EPBD verlangt darüber hinaus in Artikel 20 Absatz 8 die Hinterlegung des vollständigen Ausweises einschließlich aller Berechnungs-Eingangsdaten in der nationalen Datenbank nach Artikel 22. Solange diese Datenbank in Deutschland nicht existiert — dazu Abschnitt 17.8 —, kann der Gebäudepass die Registrierung nicht einmal technisch nachvollziehen. Die Gegenmaßnahme ist ausschließlich eine Frage der Kennzeichnung und der Prozessführung: Die intern erzeugten Ausweise sind als Arbeits- und Entwurfsdokument zu kennzeichnen, die interne Nummer ist als solche zu benennen, und der Übergang zum amtlichen Ausweis muss als eigener, ausdrücklich vollzogener Schritt sichtbar bleiben. Dieselbe Trennung gilt bereits an anderer Stelle und funktioniert dort: Das Datenblatt für den individuellen Sanierungsfahrplan ist eine reine Ausgabe, und der förderfähige Sanierungsfahrplan entsteht ausschließlich in der amtlichen Druckapplikation.

17.6 Risiko: Haftung des Erstellers und die Grenze der Fachverantwortung

Die praktisch wichtigste Rechtsfrage eines gemeinsamen Gebäudedatensatzes lautet: Wer haftet, wenn ein gespeicherter Wert falsch ist? Die Antwort hängt vollständig davon ab, ob rekonstruierbar bleibt, woher der Wert stammt und wer ihn in den offiziellen Bestand übernommen hat. Ein Wert kann vom Eigentümer stammen, aus einem eingelesenen Dokument, aus einer maschinellen Erkennung, aus einer Fachplanung, aus einer Berechnung oder aus einem Import eines fremden Systems. Diese Quellen tragen sehr unterschiedliche Verantwortung, und sie dürfen im Datenmodell nicht vermischt werden.

Der Gebäudepass beantwortet diese Frage nicht durch eine Haftungsregel, sondern durch eine Herkunftskette: Quelle, Übernahme, Prüfung, Freigabe. Für jeden Wert bleibt damit erkennbar, wer welche Informationsstufe verantwortet hat. Diese Kette reduziert die Haftung nicht — sie verteilt sie richtig. Bemerkenswert ist, dass die EPBD dieselbe Anforderung von der Aufsichtsseite her stellt: Nach Anhang VI muss der Urheber jeder Hinzufügung und jeder Änderung in der nationalen Datenbank für die Behörden ermittelbar sein. Eine belastbare Herkunftskette ist damit nicht nur Eigenschutz des Erstellers, sondern eine Voraussetzung dafür, dass Daten aus dem Gebäudepass überhaupt in ein amtliches Register übernommen werden können.

Genau an dieser Stelle wirken die Befunde aus Abschnitt 17.4 unmittelbar auf die Haftungsfrage zurück. Eine Herkunftskette ist nur so belastbar wie die Eindeutigkeit des Schreibpfads: Wo mehrere Werkzeuge dasselbe Feld schreiben, kann die Kette den letzten Schreiber ausweisen, aber nicht mehr zuverlässig die fachliche Verantwortung. Und ein Dokument, das ohne Nutzeraktion entsteht, hat im strengen Sinn keinen Ersteller. Die Durchsetzung der Schreibrechte und die Bindung der Dokumentenerzeugung an eine ausdrückliche Freigabe sind deshalb keine Aufräumarbeiten, sondern die technische Grundlage der Haftungsklarheit. Ergänzend bleibt in den Unterlagen die digitale Signatur je Freigabe als offener Punkt geführt; sie wäre die konsequente Fortsetzung, ist aber weder von der EPBD noch vom deutschen Recht als Pflicht vorgegeben.

Ein eigenes Kapitel dieser Risikogruppe bildet die maschinelle Erkennung. Die Plattform wertet Pläne, Wärmeschutznachweise und Energieausweise über eine gemeinsame Ablagezone maschinell aus; das reduziert den Erfassungsaufwand erheblich. Sie kann dabei aber Maßstäbe falsch erkennen, Dämmstärken falsch lesen, Fenster falsch zuordnen oder handschriftliche Ergänzungen übersehen. Maschinelle Erkennung ist deshalb niemals mit einer Fachprüfung gleichzusetzen. Die Arbeitsregel der Plattform ist an dieser Stelle bereits eindeutig formuliert — die Maschine schlägt vor, der Mensch entscheidet —, und das Datenmodell stützt sie, indem Drittsysteme und Erkennungsdienste ausschließlich Vorschläge in den Arbeitsbereich liefern. Die Reihenfolge lautet: erkennen, durch Prüfregeln kontrollieren, durch eine Fachperson bestätigen.

Das dazugehörige psychologische Risiko heißt Automatisierungsbias. Eine Zahl, die aus einer Software kommt, wirkt objektiv, und Nutzer neigen dazu, ihr mehr zu vertrauen als der eigenen Anschauung. Deshalb genügt es nicht, dass ein erkannter Wert intern eine niedrige Vertrauensstufe trägt — er muss auf der Oberfläche als erkannt erkennbar sein. Das Bedienkonzept sieht dafür fünf klar unterschiedene Zustände einer Angabe vor, von bestätigt über erkannt und prüfbedürftig bis unbekannt und handlungsbedürftig. Diese Zustände sind Teil der verbindlichen Bedienvorgabe und noch nicht durchgängig umgesetzt; ihre Umsetzung ist die eigentliche Gegenmaßnahme gegen den Automatisierungsbias.

Bei aller Sorgfalt bleibt eine Grenze bestehen, die keine Entwicklungsstufe aufhebt: Der Gebäudepass unterstützt fachliche Entscheidungen, er ersetzt sie nicht. Der Energieberater bleibt für seine fachliche Leistung verantwortlich, die Bank für ihre Kreditentscheidung, die Behörde für ihre Verwaltungsentscheidung. Der Gebäudepass liefert Daten, Berechnungen und deren Herkunft — und macht damit prüfbar, worauf eine Entscheidung beruht. Dass die Rechenkerne dabei sorgfältig geprüft sind, ändert daran nichts: Die Validierung gegen die Fälle der Gütegemeinschaft ist mit vierunddreißig Fällen und knapp eintausend geprüften Größen ohne Toleranzüberschreitung abgeschlossen, die Wärmepumpenfälle jedoch nur als Teilabnahme, weil das dafür erforderliche stundenbasierte Verfahren mangels vorliegender Klimastundenwerte nicht umgesetzt ist. Auch ein geprüfter Rechenkern hat einen definierten Geltungsbereich, und dieser Geltungsbereich gehört in jede Ausgabe.

17.7 Risiko: Datenschutz und Informationssicherheit

Mit der Datentiefe wächst das Datenschutzrisiko. Ein vollständig geführter Gebäudepass kann Eigentümerdaten, Verträge, Verbrauchswerte, Finanzierungsinformationen und künftig hochauflösende Betriebsdaten enthalten. Verbrauchs- und Betriebsdaten eines bewohnten Gebäudes sind personenbeziehbar; sie lassen Rückschlüsse auf Anwesenheit und Lebensgewohnheiten zu. Daraus folgt unmittelbar, dass nicht jede Information für jeden Nutzer verfügbar sein darf und dass die Zweckbindung je Empfängergruppe unterschiedlich ausfällt — die Grundlagen dazu sind in Kapitel 9 dargestellt.

Die EPBD gibt für den Zugang eine differenzierte Ordnung vor, die als Zielbild taugt. Nach Artikel 16 erhalten Eigentümer, Mieter und Verwalter direkten und kostenlosen Zugang zu den Gebäudesystemdaten und können ihn selbst benannten Dritten kostenlos weitergeben; für andere Berechtigte dürfen die Mitgliedstaaten Gebühren festlegen. Artikel 22 staffelt den Zugang zur nationalen Datenbank nach Gruppen, gewährt Finanzinstituten einen Portfoliozugang, bindet den Zugang von Kauf- und Mietinteressenten sowie unabhängigen Experten an die Erlaubnis des Eigentümers und stellt das Ganze ausdrücklich unter die Datenschutz-Grundverordnung und den Data Governance Act, mit abgestuftem Zugang und Datenschutz durch Technikgestaltung. Ein Gebäudepass, der diese Ordnung abbilden will, braucht eine durchgesetzte Rechteschicht.

Genau diese Rechteschicht war lange der größte offene Punkt der Plattform; sie ist seit dem 23. August 2026 vorhanden. Das abgestufte Zugriffs-Rollenmodell und die Rollen-Durchsetzung tragen: Rechte auf Feldebene, befristete und widerrufbare Zugänge, vollständiges Zugriffsprotokoll. Die Anzeigerollen der Kennwerte-Seite — Architekt, Makler, Hausverwaltung, Fachplaner, Bank, Energieberater — bestehen daneben fort und steuern weiterhin nur Reihenfolge und Auswahl der Darstellung. Offen bleiben als Datenschutzrisiko die Freigabepakete je Empfänger und vor allem die förmliche datenschutzrechtliche Vorprüfung der Freigabeschicht. Unverändert gilt außerdem die Regel, die der veröffentlichte Pass bereits umsetzt: Was nach außen geht, wird vorher inhaltlich bereinigt, statt sich allein auf Zugriffsschutz zu verlassen. Datensparsamkeit ersetzt keine Rechteschicht, aber sie begrenzt den Schaden auch dann, wenn ein einzelner Zugang missbraucht wird.

Ein zentraler Gebäudedatenbestand ist zugleich ein lohnendes Angriffsziel — durch Datenabfluss, Manipulation, Identitätsmissbrauch oder Verschlüsselungsangriffe. Die Bedeutung wächst mit jeder Anbindung an Banken, Verwaltung oder Gebäudeautomation. Vollständige Sicherheit kann kein digitales System zusichern; das ist eine Grenze und kein Versäumnis. Die Plattform kann das Risiko jedoch durch Verschlüsselung, Mehrfaktor-Authentifizierung, durchgesetzte Rollenrechte, Protokollierung, gesicherte Datenhaltung und regelmäßige Sicherheitsprüfungen wirksam senken. Ansätze dazu sind vorhanden — der Fachbereich ist nur mit Anmeldung zugänglich, der Server sichert vor jeder Änderung eine Vorversion, und der veröffentlichte Pass ist gegen Durchprobieren gesperrt. Der Sprung von diesen Einzelmaßnahmen zu einer beschriebenen und geprüften Sicherheitsarchitektur steht aus. Die Eintrittswahrscheinlichkeit eines relevanten Sicherheitsvorfalls ist derzeit als mittel einzuschätzen und steigt mit Nutzerzahl, Datentiefe und externer Anbindung.

Datenschutz ist zugleich die Chance dieses Abschnitts. Wenn ein Eigentümer jederzeit erkennen kann, welche Daten gespeichert sind, wer Zugriff hat, warum dieser Zugriff besteht und wann er endet, entsteht Vertrauen — und für einen Pass, der ein Gebäudeleben lang geführt werden soll, ist dieses Vertrauen keine Nebenbedingung, sondern die Geschäftsgrundlage. Datensouveränität ist deshalb als Produktmerkmal zu behandeln und nicht als Pflichtübung.

17.8 Das größte externe Risiko: fehlende staatliche Schnittstellen

Alle bisher genannten Risiken liegen ganz oder überwiegend in eigener Hand. Für das größte Risiko des Vorhabens gilt das nicht. Die EPBD verlangt von den Mitgliedstaaten seit dem 29.05.2026 eine nationale Gebäudedatenbank oder einen Verbund mit einem öffentlichen Zugangspunkt nach Artikel 22, in dem Energieausweise einschließlich aller Berechnungs-Eingangsdaten, Inspektionsberichte, Renovierungspässe, Bewertungen der Intelligenzfähigkeit sowie berechnete und gemessene Verbräuche zusammenlaufen. Deutschland betreibt eine solche Datenbank nach dem Stand der Kommissions-Leitlinien nicht; der entsprechende Eintrag lautet „n/a". Ein deutsches Schema nach Artikel 22, gegen das eine Übertragung entwickelt werden könnte, existiert damit zum Quellenstand nicht.

Dieser Befund steht nicht allein. Ausdrücklich offen sind darüber hinaus das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG, das Datenformat für den Lebenszyklus-Treibhausgasbericht nach § 88b GMoDG, die Klassenskala und die Klassengrenzen für Nichtwohngebäude, das Schema für den Intelligenzfähigkeits-Indikator, das Kontrolldatei-Schema für monatliche Verbrauchswerte sowie die Frage, ob der individuelle Sanierungsfahrplan formal zum Renovierungspass im Sinne des Artikels 12 erklärt wird. Hinzu kommt die ungelöste Frage der Leistungsschwelle für die Gebäudeautomation, für die die Quellen zwei belegte Werte und einen dritten ohne Rechtsgrundlage führen. Für die Softwareentwicklung bedeutet jeder dieser Punkte dasselbe: Das Recht steht, die Spezifikation fehlt, die Funktion ist blockiert.

Die Eintrittswahrscheinlichkeit dieses Risikos ist nicht zu bewerten, weil es bereits eingetreten ist. Zu bewerten ist allein die Dauer, und sie liegt außerhalb der Kontrolle des Plattformbetreibers. Daraus folgen drei Gegenmaßnahmen, die alle auf Schadensbegrenzung und nicht auf Vermeidung zielen. Erstens die Trennung von Datenkern und Anbindung: Der Gebäudedatenkern wird nicht direkt an ein Register gekoppelt, sondern über ein Exportprofil und einen austauschbaren Anschlussbaustein. Ändert sich das Register oder erscheint es überhaupt erst, wird primär dieser Baustein angepasst und nicht das Datenmodell. Zweitens die aktive Beobachtung: Der bereits produktive Monitor für die europäische und deutsche Rechtsentwicklung wertet täglich achtzehn amtliche Quellen aus, schlägt anhand des fachlichen Inhalts und nicht anhand einer Textänderung Alarm und führt Vorlaufwarnungen bis zu einhundertachtzig Tage vor einem Termin. Drittens die Disziplin, Lücken als Lücken zu führen: Die Klassenfunktion für Nichtwohngebäude gibt zwischen bester und schlechtester Klasse bewusst keinen Wert zurück, und die offenen Kennwerte sind in der Rechtsstand-Registry als Lücke hinterlegt. Das ist unbequem und richtig — ein erfundener Zwischenwert würde die Lücke unsichtbar machen, ohne sie zu schließen.

Aus derselben Lage folgt die wichtigste kommunikative Grenze des gesamten Whitepapers. Solange die nationalen Datenformate, Prüfverfahren und Registerstrukturen nicht feststehen, darf keine pauschale amtliche EPBD-Konformität behauptet werden. Zu unterscheiden sind technische Bereitschaft und amtliche Integration — die erste kann der Betreiber herstellen, die zweite nicht.

17.9 Risiko: unterschiedliche nationale Umsetzungen der EPBD

Die EPBD schafft einen europäischen Rahmen, aber sie bindet Private nicht unmittelbar. Adressat aller Pflichten ist der Mitgliedstaat; erst die nationale Umsetzung erzeugt Verpflichtungen für Eigentümer und Aussteller. Damit entstehen zwangsläufig Unterschiede — bei den Datenfeldern, bei der Ausgestaltung der Energieausweise, beim Renovierungspass, bei den Berechnungsmethoden, beim Aufbau der Register und bei den Schnittstellen. Die Richtlinie selbst legt diese Unterschiede teilweise an: Sie überlässt den Mitgliedstaaten die Schwellenwerte für Nullemissionsgebäude, sie stellt die Verpflichtung zum Renovierungspass in deren Ermessen, und sie erlaubt bei der Ausweisskala nationale Optionen. Ein in ganz Europa identisches System ist kurzfristig nicht realistisch, und ein Whitepaper, das etwas anderes behauptet, wäre unglaubwürdig.

Die technische Antwort darauf ist eine Zweiteilung der Architektur. Gebäude besitzen universelle Grunddaten — Geometrie, Bauteile, Anlagen, Energieströme, Materialien —, die in jedem Mitgliedstaat gleich beschrieben werden können. Nationale Besonderheiten betreffen dagegen die Bewertung: welche Norm gerechnet wird, welche Faktoren gelten, welche Klassengrenzen angesetzt werden, welche Pflichtangaben ein Ausweis trägt. Trennt man beides, ergibt sich ein gemeinsamer Gebäudedatenkern mit darüberliegenden nationalen Regelmodulen. Der Kern bleibt stabil, die Module werden ausgetauscht.

Der Nutzen dieser Trennung zeigt sich schon innerhalb Deutschlands, und zwar an einem Fall, der ohne sie teuer geworden wäre. Der Wechsel des Rechtsstands zum Gebäudemodernisierungsgesetz betraf zahlreiche Paragrafenverweise, geänderte Primärenergie- und Emissionsfaktoren, neue Ausweisbezeichnungen und eine geänderte Bezugsfläche. Er wurde nicht als Umbau der Gebäudemodelle abgewickelt, sondern über eine Rechtsstand-Registry, die zwischen dem Stand 2026 und dem Stand 2027 umschaltet und die geänderten Größen überlagert. Kein Gebäude musste dafür neu modelliert werden. Genau dieses Muster ist die Voraussetzung dafür, dass aus einem nationalen ein europäisch skalierbares System werden kann.

Das umgekehrte Risiko ist die Überanpassung. Wird eine Plattform direkt um ein bestimmtes Formular oder eine einzelne Vorschrift herum gebaut, entsteht eine harte Abhängigkeit: Ändert sich die Vorschrift, muss das System grundlegend umgebaut werden. Die Konsequenz für die Entwicklung lautet deshalb, Gesetze, Normen und Förderregeln nicht als Programmlogik, sondern als versionierte Regelwerke mit Kennung, Rechtsquelle, Gültigkeitszeitraum und betroffenen Datenfeldern zu behandeln. Ändert sich eine Regel, ändert sich das Regelwerk und nicht das Gebäudemodell. Eine Grenze bleibt allerdings auch hier: Europäische Skalierung bedeutet keine rechtliche Vereinheitlichung. Mehrsprachigkeit, unterschiedliche Rechtsmodule und abweichende Dokumentenlayouts bleiben dauerhaft erforderlich.

17.10 Risiko: Akzeptanz bei Eigentümern

Technische Qualität erzeugt keine Nutzung. Ein Gebäudepass, den Eigentümer als zusätzliche Bürokratie, als Kostenfaktor oder als Kontrollinstrument wahrnehmen, wird nicht gepflegt — und ein nicht gepflegter Gebäudepass verliert innerhalb weniger Jahre seinen Wert. Erschwerend kommt hinzu, dass die Richtlinie hier keine Hilfestellung leistet: Sie verpflichtet niemanden, ein digitales Gebäudelogbuch zu führen. Sie definiert es in Artikel 2 Nummer 41 und knüpft in Artikel 12 Absatz 8 nur konditional daran an, dass ein Renovierungspass dort zu hinterlegen ist, wo ein Logbuch existiert; Artikel 22 Absatz 7 verlangt lediglich Interoperabilität. Auch ein digitaler Zwilling ist keine Pflicht, sondern in Artikel 19 Absatz 14 Buchstabe c ein zulässiger Kanal für vereinfachte Ausweisaktualisierungen. Der Gebäudepass kann sich seine Nutzer folglich nicht über eine Pflicht erschließen. Er muss über Nutzen überzeugen.

Der Nutzen muss dabei für den Eigentümer unmittelbar erkennbar sein und nicht erst nach einer Erläuterung des europäischen Regelungsrahmens: Unterlagen gehen nicht mehr verloren; durchgeführte Sanierungen sind belegt; Fördermöglichkeiten werden sichtbar, bevor sie verfallen; ein Verkauf wird einfacher, weil die Unterlagen vollständig vorliegen; und anstehende Investitionen werden planbar, weil Zustand, Restlebensdauer und Kostenrahmen zusammen dargestellt sind. Erst aus solchen Punkten entsteht freiwillige Nutzung.

Das zweite Akzeptanzrisiko ist die Komplexität. Ein vollständiger Gebäudedatensatz enthält hunderte bis tausende Einzelangaben; die vorhandene Plattform führt allein für die Kennwertdarstellung dreiundvierzig Kennwerte und im Fachbereich mehr als siebzig Werkzeuge. Eine Oberfläche, die diesen Umfang eins zu eins abbildet, ist für einen Eigentümer unbrauchbar. Technische Vollständigkeit und vollständige Darstellung sind zu trennen: Der Eigentümer sieht Zustand, nächste sinnvolle Maßnahme und Kostenrahmen; der Energieberater sieht U-Werte, Zonen und die Eingangsgrößen der Bilanzierung; die Bank sieht Energiekennwerte, Investitionsbedarf und Datenqualität.

Hier ist der Abstand zwischen Konzept und Umsetzung ehrlich zu benennen. Das Bedienkonzept beschreibt genau diesen Weg — einen persönlichen Assistenten statt einer Fachsoftware, nie leere Masken, einen einzigen Hauptbutton zur Vervollständigung, die jederzeit zulässige Antwort „weiß ich nicht", keine Fachsprache auf der ersten Ebene und drei Modi vom einfachen bis zum fachlichen. Der Ist-Stand ist ein anderer: Das heutige Werkzeug ist die Fach- und Betreiberansicht, und der Assistent-Modus ist ausdrücklich als noch nicht vorhanden gekennzeichnet. Die Eintrittswahrscheinlichkeit einer Akzeptanzschwäche bei privaten Eigentümern ist damit derzeit hoch — nicht weil das Konzept fehlte, sondern weil die Oberfläche, die es umsetzt, noch nicht gebaut ist.

Das dritte Akzeptanzrisiko ist die Aktualisierungsbereitschaft. Ein Gebäudepass ist nur so viel wert wie seine Pflege. Wird eine neue Heizung eingebaut und nicht eingetragen, beginnt der Datensatz zu veralten, und der erste falsch gebliebene Wert entwertet die Glaubwürdigkeit der übrigen. Die belastbare Antwort besteht nicht in Erinnerungsmails, sondern darin, die Aktualisierung an reale Vorgänge zu koppeln: Der Handwerker lädt das Dokument hoch, der Energieberater aktualisiert nach der Maßnahme, die Hausverwaltung pflegt die Wartung ein, eine Schnittstelle übernimmt Zählerstände. Die technische Voraussetzung dafür ist in der Plattform vorhanden: Die Neuberechnungsschicht erkennt über einen Fingerabdruck je Eingabesektion, welche Auswertungen von einer Änderung betroffen sind, und kennzeichnet den Pass als veraltet. Was fehlt, ist die Einbindung der externen Beteiligten — und damit ein Rollenmodell, das ihnen einen begrenzten, nachvollziehbaren Schreibzugang gibt.

17.11 Risiko: Betreiberabhängigkeit, Datenportabilität und Langzeitarchivierung

Ein Gebäudedatensatz soll länger bestehen als eine Software und regelmäßig auch länger als das Unternehmen, das sie betreibt. Daraus folgt eine strategische Anforderung, die im Interesse des Eigentümers und nicht im kurzfristigen Interesse des Betreibers liegt: Der Datensatz darf nicht dauerhaft an einen einzelnen Anbieter gebunden sein. Ein proprietärer Datensilo wäre für einen lebenslang geführten Pass die falsche Konstruktion, unabhängig davon, wie gut die Anwendung ist.

Der vorhandene Stand ist hier zweigeteilt. Belastbar vorhanden ist ein vollständiger Projektexport und -import im JSON-Format, ergänzt um Ausgaben als PDF, CSV und im Kartenformat sowie um einen maschinenlesbaren Block der Pflichtangaben im Zertifikatsexport. Der Weg aus dem System heraus ist damit im Grundsatz offen. Nicht vorhanden sind dagegen die programmierbare Dienstschnittstelle, die im Pflichtenheft als Punkt der Roadmap geführt wird, ein geschlossenes Modul für weitere Ausgabeformate und ein Ausgang für das Modellformat des Bauwesens: Der Weg über IFC ist als reiner Eingang gekennzeichnet, ein Rückweg besteht im Werkzeugpfad nicht. Für die Portabilität heißt das: Der Datensatz ist heute ausleitbar, aber nicht in jedem Zielformat, das ein Nachfolgesystem erwarten würde.

Die eigentliche Absicherung gegen Betreiberabhängigkeit ist deshalb nicht das Exportmenü, sondern das dokumentierte kanonische Datenmodell. Solange die fachliche Bedeutung jedes Feldes — Definition, Einheit, Berechnungsmethode, führende Quelle — schriftlich und maschinenlesbar festliegt, lässt sich der Bestand in ein anderes technisches System überführen, auch wenn die heutige Anwendung nicht mehr existiert. Der in Kapitel 14 als erste Entwicklungsstufe beschriebene Feldkatalog ist damit zugleich die Antwort auf das Langzeitrisiko: Die Anwendung darf sich ändern, der Gebäudedatensatz bleibt.

Eng damit verbunden ist ein Problem, das in der Praxis früher auftritt als jeder Systemwechsel: die fehlende gemeinsame Terminologie. Schon einfache Begriffe sind nicht austauschbar — Nutzfläche, Nettoraumfläche, Gebäudenutzfläche und Wohnfläche bezeichnen unterschiedliche Größen. Der Gebäudepass hat diesen Konflikt bereits in eigener Sache durchlaufen: Die Bezugsfläche wurde kanonisch auf die Nutzfläche nach DIN 277 festgelegt, mit der ausdrücklichen Feststellung, dass es sich gegenüber der früheren Bezugsfläche nicht um eine Umrechnung, sondern um eine andere Größe handelt; ersatzweise Verwendungen sind unzulässig, und fehlt die kanonische Fläche, meldet die Bilanz eine Lücke, statt zu schätzen. Ein zweiter Fall betraf ein Nutzungsprofil für Nichtwohngebäude, das zuvor unter vier verschiedenen Bezeichnungen geführt wurde, mit der Folge, dass eine zonenweise Bilanz in keinem einzigen Projekt griff. Beide Fälle zeigen dasselbe: Semantische Interoperabilität entsteht nicht durch Dateiformate, sondern durch einen verbindlichen Datenkatalog.

Ein letzter Punkt dieser Gruppe betrifft den Zuschnitt der Plattform selbst. Eine Datenplattform kann sich durch fortlaufenden Funktionsausbau überladen; Bedienbarkeit, Wartbarkeit und Qualität leiden dann gleichzeitig. Der Gebäudepass muss keine Fachsoftware für Statik, Brandschutz oder komplexe Gebäudesimulation ersetzen. Sinnvoller ist die Rolle als Datenfundament, das Spezialsoftware mit geprüften Eingangsdaten versorgt und deren Ergebnisse mit Herkunftsangabe zurücknimmt. Diese Rolle setzt allerdings genau die Schnittstelle voraus, die derzeit noch aussteht — die Begrenzung des eigenen Funktionsumfangs ist deshalb kein Verzicht, sondern die Voraussetzung dafür, dass ein Partnerökosystem überhaupt entstehen kann.

17.12 Wirtschaftliche Grenzen und Erwartungsmanagement

Die technische Speicherung von Gebäudedaten ist vergleichsweise günstig. Die Kosten entstehen an anderer Stelle: bei der Ersterfassung, bei der fachlichen Prüfung, bei der Aktualisierung und im Support. Ein Geschäftsmodell, das diese Kosten nicht abbildet, skaliert nicht — die Einzelheiten dazu behandelt Kapitel 15. Für das Risikokapitel ist die Gegenrichtung wesentlich: Der Aufwand je zusätzlicher Anwendung sinkt in dem Maß, in dem vorhandene Dokumente maschinell ausgewertet und einmal geprüfte Daten mehrfach verwendet werden. Automatisierung und Wiederverwendung sind damit nicht nur technische Merkmale, sondern unmittelbar wirtschaftlich wirksame Größen. Umgekehrt gilt: Jede Funktion, die eine erneute manuelle Erfassung erzwingt, ist ein wirtschaftliches Risiko, auch wenn sie fachlich korrekt arbeitet.

Ein zweites wirtschaftliches Risiko liegt in überzogenen Erwartungen an die Marktwirkung. Ein vollständiger Gebäudepass verbessert die Transparenz einer Immobilie. Daraus folgt jedoch nicht, dass jede Immobilie mit Gebäudepass einen bestimmten Wertaufschlag erzielt; der Marktwert hängt von Lage, Nutzung, Marktlage und zahlreichen weiteren Faktoren ab. Belastbar ist die schwächere und richtige Aussage: Der Gebäudepass verbessert die Datengrundlage einer Bewertung, indem er energetischen Zustand, durchgeführte Modernisierungen, verbleibenden Sanierungsbedarf und Dokumentenqualität sichtbar macht. Welche wirtschaftliche Wirkung daraus entsteht, entscheidet der Markt.

Dieselbe Zurückhaltung ist im Bankenkontext geboten. Die Versuchung, komplexe Gebäudedaten zu einer einzigen Nachhaltigkeitskennzahl zu verdichten, ist groß, und sie ist gefährlich: Ein Gesamtwert verdeckt genau die Unterschiede, auf die es bei der Risikobetrachtung ankommt, und er verschleiert seine eigene Datenqualität. Der Gebäudepass sollte deshalb kein geschlossenes Gesamturteil erzeugen, sondern nachvollziehbare Teilinformationen bereitstellen — Energiekennwerte, Emissionen, Investitionsbedarf, Datenqualität und Transformationspfad, jeweils mit Herkunft und Stand. Die Bank bildet daraus ihr eigenes Risikomodell; die Bewertung bleibt ihre Aufgabe. Methodisch strikt zu trennen sind dabei Portfolioaussagen und Einzelobjektbewertung: Aus einem statistischen Zusammenhang, der auf Portfolioebene beobachtet wird, folgt keine Aussage über ein einzelnes Gebäude. Ein Evidenzpaket mit offengelegten Quellen ist deshalb das robustere Produkt als ein automatisches Rating — und es ist zugleich das ehrlichere, weil es die eigene Unsicherheit mitliefert.

17.13 Gesamtbewertung: Risikomatrix

Die folgende Tabelle fasst die im Kapitel behandelten Risiken zusammen. Die Eintrittswahrscheinlichkeit ist ausschließlich qualitativ angegeben. Als hoch gilt ein Risiko, dessen Eintritt in den Entwicklungsunterlagen bereits als Befund dokumentiert ist oder dessen Ursache strukturell vorliegt und im Regelbetrieb wirksam wird. Als mittel gilt ein Risiko, dessen Ursache vorhanden ist, dessen Eintritt aber von zusätzlichen Umständen abhängt — etwa von Nutzungsumfang, äußeren Angriffen oder Fehlbedienung. Als gering gilt ein Risiko, dessen Ursache durch bereits vorhandene Maßnahmen wirksam begrenzt ist. Die letzte Spalte unterscheidet, ob eine Gegenmaßnahme durch eigene Entwicklung wirksam werden kann.

Die Auswertung der Matrix führt zu drei Beobachtungen. Erstens liegt die überwiegende Mehrheit der Risiken in eigener Hand: Von einundzwanzig geführten Risiken sind zwei ausschließlich extern bedingt und drei nur teilweise beeinflussbar. Das ist eine gute Nachricht, denn behebbare Risiken sind Arbeitspakete und keine Unwägbarkeiten. Zweitens konzentrieren sich die als hoch eingestuften Risiken auf zwei Gruppen: auf die noch nicht erzwungenen Regeln des eigenen Datenmodells und auf die noch fehlende Konkretisierung des deutschen Rechts. Die erste Gruppe entspricht exakt der ersten Stufe der Entwicklungsroadmap; die zweite lässt sich nicht auflösen, sondern nur beobachten und abfedern. Drittens ist auffällig, dass fast alle schweren Risiken denselben Kern haben — die Zuordnung zwischen einem Wert, seiner Herkunft und der Person, die ihn verantwortet. Wer diesen Kern absichert, senkt gleichzeitig das Datenqualitäts-, das Haftungs-, das Datenschutz- und das Akzeptanzrisiko.

17.14 Chancenbilanz und neue Dienstleistungen

Den Risiken steht eine Chancenseite gegenüber, die sich aus demselben Datensatz speist. Der Gebäudepass eröffnet Dienstleistungen, die ohne dauerhaft geführte Gebäudedaten nicht möglich sind: die Prüfung und Aufwertung vorhandener Gebäudedaten, die Aktualisierung von Energieausweisen, das Monitoring von Sanierungsfortschritt und Fördermitteln, ein Evidenzpaket für Banken, die technische Objektprüfung im Ankaufsprozess, die Portfolioanalyse und die Betriebsoptimierung. Alle diese Leistungen greifen auf denselben Bestand zu; der Aufwand entsteht einmal, der Nutzen mehrfach.

Besonders deutlich wird der Unterschied bei der Energieberatung selbst. Sie ist heute überwiegend projektbezogen: Analyse, Bericht, Abschluss. Mit einem fortgeführten Gebäudedatensatz entsteht eine andere Abfolge — Analyse, Planung, Umsetzung, Monitoring, nächste Maßnahme —, in der jede Runde auf den Ergebnissen der vorherigen aufsetzt. Aus einer Beratungsleistung wird eine Begleitung. Werden künftig Betriebsdaten angebunden, kommt eine dritte Ebene hinzu: Das System kann unerwartet hohen Verbrauch, eine ineffizient arbeitende Wärmepumpe, eine auffällige Photovoltaikleistung oder einen ablaufenden Nachweis erkennen und darauf hinweisen. Aus der Dokumentation wird eine Überwachungsfunktion. Auf Portfolioebene schließlich lassen sich Einzelgebäudedaten zu Sanierungsprioritäten, Investitionsplanungen, Energieklassenverteilungen und Emissionspfaden aggregieren — für Wohnungsunternehmen, Kommunen und Banken die eigentlich relevante Betrachtungsebene.

Die dritte Spalte ist der eigentliche Ertrag dieser Tabelle. Keine der genannten Chancen entsteht aus einer zusätzlichen Funktion; jede entsteht aus einer Eigenschaft des Datenmodells. Das erklärt, warum die Entwicklungsreihenfolge in Kapitel 14 mit dem Feldkatalog und nicht mit einer sichtbaren Anwendung beginnt: Die Chancen dieser Tabelle sind sämtlich Folgeerscheinungen sauber geführter Daten. Umgekehrt gilt, dass eine Chance, deren Voraussetzung nicht erfüllt ist, nicht als vorhandenes Leistungsmerkmal dargestellt werden darf.

17.15 Der entscheidende Erfolgsfaktor

Aus der Gegenüberstellung von Chancen und Risiken ergibt sich ein einziger zentraler Erfolgsfaktor, und er ist keine Funktion: Es ist das Vertrauen in die Daten. Nicht die Zahl der Werkzeuge entscheidet langfristig über den Wert des Gebäudepasses, sondern ob Nutzer sich darauf verlassen können, dass Werte richtig zugeordnet sind, dass ihre Herkunft bekannt ist, dass Änderungen nachvollziehbar bleiben und dass Zugriffe kontrolliert werden. Genau diese vier Punkte sind die Themen der Abschnitte 17.3 bis 17.7 — und genau sie sind die Punkte, an denen die eigenen dokumentierten Schwachstellen liegen.

Damit verschiebt sich die strategische Perspektive über die Entwicklungsphasen hinweg. Die erste Phase eines solchen Systems konzentriert sich zwangsläufig auf Funktionen: Rechenkerne, Werkzeuge, Ausgaben. Die zweite konzentriert sich auf Interoperabilität: Formate, Schnittstellen, Datenkatalog. Die dritte muss sich auf Vertrauen konzentrieren: durchgesetzte Schreibrechte, belegte Herkunft, kontrollierter Zugang, kalibrierte Kennzahlen, ehrliche Kennzeichnung dessen, was ein Dokument ist und was es nicht ist. Ein Gebäudepass, dessen Daten von Banken, Fachplanern, Eigentümern und Behörden verwendet werden sollen, muss mehr sein als technisch leistungsfähig — er muss nachvollziehbar sein.

Die Grenzen bleiben dabei bestehen und sollten offen benannt werden. Der Gebäudepass kann fehlende Gebäudedaten nicht ersetzen, sondern nur ihr Fehlen sichtbar machen. Er kann Fachverantwortung nicht automatisieren, sondern nur deren Grundlage prüfbar machen. Er kann staatliche Schnittstellen nicht selbst definieren, sondern nur anschlussfähig auf sie warten. Und er kann Datenschutz- und Sicherheitsrisiken nicht auflösen, sondern nur beherrschbar halten. Diese vier Sätze sind keine Einschränkung des Nutzens, sondern seine Bedingung: Ein System, das sie beachtet, liefert belastbare Aussagen; ein System, das sie übergeht, liefert schnell mehr und langfristig weniger.

18 Schlussfolgerungen und Empfehlungen

Die vorangegangenen siebzehn Kapitel haben die europäische Gebäuderichtlinie in ihre Datenanforderungen zerlegt, den vorhandenen Gebäudepass daran gemessen und die verbleibenden Lücken benannt. Dieses Schlusskapitel wertet aus. Es führt zusammen, was der digitale Gebäudepass zur Umsetzung der EPBD beitragen kann, welche technische Weiterentwicklung dafür erforderlich ist und welche Entscheidungen an anderer Stelle getroffen werden müssen — beim Gesetzgeber, in der Kreditwirtschaft, in der Immobilienwirtschaft und in der Energieberatung selbst. Neue Fakten kommen nicht hinzu; die Empfehlungen folgen ausschließlich aus den in den Kapiteln 3 bis 17 festgestellten Befunden.

18.1 Beitrag des Gebäudepasses zur EPBD-Umsetzung

Die Untersuchung führt zu einem Befund, der zunächst unspektakulär klingt und dennoch die Architektur der gesamten Umsetzung bestimmt: Die Anforderungen der Richtlinie (EU) 2024/1275 sind zu einem erheblichen Teil keine Berechnungsaufgaben, sondern Datenaufgaben. Der Energieausweis muss maschinenlesbar sein und samt aller Berechnungs-Eingangsdaten in eine Datenbank gelangen (Artikel 20 Absatz 8). Der Renovierungspass muss in dieselbe Datenbank hochladbar sein (Artikel 12 Absatz 7) und dort, wo ein digitales Gebäudelogbuch existiert, in diesem gespeichert oder über eine eindeutige Adresse zugänglich sein (Artikel 12 Absatz 8). Der Datenaustausch nach Artikel 16 verlangt, dass Eigentümer, Mieter und Verwalter unentgeltlich an definierte Gebäudesystemdaten kommen und diese an selbst benannte Dritte weitergeben dürfen. Die nationale Datenbank nach Artikel 22 muss mit Kataster, Grundbuch und digitalen Logbüchern interoperabel sein und ihre Daten mindestens einmal jährlich an das EU Building Stock Observatory übergeben. In allen vier Fällen entscheidet nicht die Qualität einer einzelnen Rechenroutine über die Erfüllbarkeit, sondern die Frage, ob die zugrunde liegenden Gebäudedaten strukturiert, identifizierbar, versioniert und exportierbar vorliegen.

Genau an dieser Stelle liegt der Beitrag des digitalen Gebäudepasses. Er ersetzt kein Instrument der Richtlinie. Er ist weder Energieausweis noch Renovierungspass noch staatliches Register, und er ist es auch nicht in Teilen. Seine Funktion ist eine andere: Er hält den Gebäudedatensatz, aus dem diese Instrumente erzeugt werden. Damit dreht er das gewohnte Verhältnis zwischen Dokument und Daten um. Bisher beschreiben Dokumente das Gebäude — der Energieausweis, die Rechnung des Heizungsbauers, der Bestandsplan, die Nachweisberechnung. Jedes dieser Dokumente enthält Gebäudedaten, aber in einer Form, die maschinell nicht weiterverwendbar ist, und jedes wird bei Bedarf neu erstellt, weil die Daten dahinter nicht erhalten geblieben sind. Im Gebäudepass verläuft die Kette umgekehrt: Aus dem strukturierten Datensatz entsteht die Berechnung, aus der Berechnung das Dokument. Das Dokument wird zum Ergebnis, nicht zur Quelle. Nachvollziehbarkeit, Aktualisierbarkeit und Wiederverwendbarkeit sind dann keine nachträglich hinzugefügten Eigenschaften, sondern folgen aus der Reihenfolge.

Die Richtlinie selbst hat diesen Weg an einer Stelle ausdrücklich geöffnet. Artikel 19 Absatz 14 verpflichtet die Mitgliedstaaten, vereinfachte Aktualisierungen des Energieausweises zuzulassen — nach Einzelmaßnahmen, nach umgesetzten Schritten eines Renovierungspasses und, nach Buchstabe c, über digitale Zwillinge oder zertifizierte Werkzeuge. Das ist die rechtliche Grundlage dafür, dass ein gepflegter Gebäudedatensatz als Datenquelle des Ausweises dient, statt bei jeder Ausstellung erneut aufgenommen zu werden. Zwei Mitgliedstaaten praktizieren das bereits: Dänemark und Portugal speichern in ihren Datenbanken keine PDF-Dokumente, sondern erzeugen den Ausweis aus den Rohdaten. Der Gebäudepass folgt derselben Logik, allerdings eine Ebene tiefer — nicht auf der Ebene des staatlichen Registers, sondern auf der Ebene des einzelnen Gebäudes und seines fachlichen Betreuers.

Aus dieser Rollenverteilung ergibt sich eine klare Arbeitsteilung, die für die Wartbarkeit der Software entscheidend ist und deshalb hier noch einmal ausdrücklich festgehalten wird. Der Gebäudepass hält die Daten. Die DIN V 18599 liefert die energetische Berechnungslogik. Der Energieausweis stellt einen normierten Ausschnitt der Ergebnisse dar. Der Renovierungspass fügt die zeitliche Dimension hinzu: Der Ausweis beantwortet die Frage nach dem heutigen Zustand, der Renovierungspass die Frage nach dem möglichen Entwicklungspfad, und der Gebäudepass dokumentiert darüber hinaus, was tatsächlich umgesetzt wurde. Erst aus dieser dritten Information entsteht eine belastbare Transformationshistorie — und damit auch die Datengrundlage für den Nachweis der Bestandspfade nach Artikel 9, die Deutschland gegenüber der Kommission erbringen muss.

Der zweite wesentliche Beitrag betrifft die Datenqualität. Mit zunehmender Digitalisierung verschiebt sich die entscheidende Frage von der Menge auf die Belastbarkeit: nicht wie viele Daten vorliegen, sondern wie gut belegt sie sind. Die Richtlinie selbst enthält dazu in Anhang VI eine bemerkenswert konkrete Anforderung an die Datenbanken — der Urheber jeder Hinzufügung und jeder Änderung muss für die Behörden ermittelbar sein. Wer diese Anforderung ernst nimmt, kommt nicht umhin, jeden fachlich relevanten Wert mit Quelle, Datum, Erfassungsmethode, Prüfstatus und Version zu führen. Der vorhandene Gebäudepass hat diesen Schritt bereits vollzogen: Die Governance-Schicht kennt vier Datenzustände von Entwurf über gemeldet und geprüft bis freigegeben, sechs Vertrauensstufen von unbekannt bis amtlich signiert und ein Vier-Augen-Verfahren, bei dem ein gemeldeter Wert zunächst nur im Arbeitsbereich liegt und erst die Freigabe ihn in den führenden Datenpfad schreibt. Der Building Trust Index macht die daraus folgende Datenqualität in einem erklärbaren Regelwerk sichtbar. Diese Bausteine sind nicht als Vorgriff auf die EPBD entstanden, sie erfüllen aber deren Nachvollziehbarkeitsanforderung bereits weitgehend.

18.2 Notwendige technische Weiterentwicklung

Die Reifegradanalyse hat ein charakteristisches Bild ergeben: Der fachliche Kern — Geometrie, Bauteile, Anlagentechnik, Bilanzierung, Nachweiserstellung, Qualitätssicherung — ist ausgebaut und in der Berechnung an Validierungsfällen belegt. Was fehlt, sind überwiegend die verbindenden Teile. Der größte Entwicklungsbedarf liegt deshalb nicht bei weiteren Einzelberechnungen, sondern bei Datenstandards, Rollenmodellen, Exportprofilen, Registerschnittstellen und der externen Nutzbarkeit des Datenbestandes. Das ist eine Verschiebung des Schwerpunkts, keine Neuentwicklung. Die folgenden zwölf Maßnahmen ergeben sich aus dieser Analyse; Kapitel 14 ordnet sie zeitlich, hier stehen sie in der Sache.

Am Anfang steht der vollständige Gebäudedatenkatalog. Solange nicht für jedes fachlich relevante Datenfeld eine eindeutige Kennung, eine Definition, eine Einheit, ein Datentyp, eine zulässige Quelle, ein Qualitätsstatus, eine Gültigkeitsregel und die Beziehung zu anderen Datenobjekten festgeschrieben sind, bleibt jede Schnittstelle eine Absprache und keine Spezifikation. Der Katalog ist das gemeinsame Vokabular der Plattform und zugleich die Voraussetzung dafür, dass ein Exportprofil überhaupt versioniert werden kann. Wie dringend dieser Schritt ist, zeigt ein Befund aus der eigenen Analyse: 35 der 94 im Feld-Register geführten Felder werden derzeit von mehreren Werkzeugen beschrieben; die Zählung der Schreibzugriffe außerhalb des vorgesehenen Rollenmodells ergab 55 Verstöße in 15 Werkzeugen, die inzwischen abgearbeitet sind — die Zahl blieb eine Untergrenze, weil dynamisch gebildete Pfade nicht mitgezählt werden konnten. Das Rollenmodell der Schreibrechte, das Quelle, Ermittler, Rechner und Ausgabe unterscheidet, ist beschrieben, aber noch nicht technisch erzwungen. Ein Feldkatalog mit eindeutiger Eigentümerschaft je Feld ist die Voraussetzung dafür, das nachzuholen.

Unmittelbar daran schließt das regulatorische Mapping an. Jedes Datenfeld sollte mit den Anforderungen verknüpft sein, für die es benötigt wird — der U-Wert der Außenwand also mit der Bilanzierung nach DIN V 18599, mit dem Wärmeschutznachweis, mit der Heizlastberechnung, mit den Pflichtangaben des Energieausweises und mit den Maßnahmenschritten des Renovierungspasses. Der praktische Nutzen zeigt sich bei jeder Rechtsänderung: Wer die Zuordnung pflegt, erkennt sofort, welche Funktionen von einer geänderten Vorschrift betroffen sind, statt den gesamten Bestand durchsuchen zu müssen. Die GMoDG-Migration hat den Aufwand des umgekehrten Falls dokumentiert — über eintausenddreihundert Fundstellen mussten gesichtet werden, weil die Zuordnung vorher nicht existierte.

Die dritte Maßnahme ist die vollständige Umsetzung des Renovierungspasses. Sie hat unter den fachlichen Modulen die höchste Priorität, weil hier die Differenz zwischen Anforderung und Umsetzungsstand am größten ist. Anhang VIII der Richtlinie verlangt je Sanierungsschritt fünf Pflichtangaben — Bezeichnung und Beschreibung einschließlich der Technologie- und Materialoptionen, die Veränderung von Primär- und Endenergie in Kilowattstunden und in Prozent gegenüber dem Zustand vor dem Schritt, die Veränderung der operativen Treibhausgasemissionen, die Kostenersparnis mit offengelegten Energiepreisannahmen und die Zielklasse des Energieausweises nach dem Schritt. Hinzu kommen die grafische Roadmap vom Ausgangs- zum Endzustand, die Begründung der Schrittfolge zur Vermeidung von Lock-in-Effekten, die Liste der nationalen Anforderungen samt Stichtagen, Angaben zu Zirkularität und Whole-Life-Carbon sowie Förderhinweise mit Verweisen und die Kontaktdaten der Anlaufstellen. Die Datenstruktur dafür ist vorbereitet, die vollständige Befüllung steht aus.

Die vierte Maßnahme betrifft die strikte Trennung von Norm- und Rechtsstand. Sie ist bereits angelegt und muss konsequent auf alle Ausgaben durchgezogen werden. Verbindlich gerechnet wird nach DIN V 18599:2018-09, weil das Gebäudeenergierecht diese Ausgabe in Bezug nimmt; die DIN/TS 18599:2025-10 ist eine Technische Spezifikation und keine öffentlich-rechtliche Grundlage, Ergebnisse daraus sind Vergleichsrechnung. Da die Reihe 2025-10 nur die Teile 1, 2 und 10 geändert hat, ist der Unterschied überschaubar, aber er ist vorhanden — von der neuen normativen Behandlung der CO₂-Äquivalente über den Wärmebrückenzuschlag der Kategorie B bis zur Großrevision der Trinkwarmwasser-Tabelle für Nichtwohngebäude. Jede Berechnung muss deshalb dokumentieren, welche Normfassung, welcher Rechtsstand, welche Softwareversion und welcher Datenstand ihr zugrunde liegen. Ohne diese vier Angaben ist eine Berechnung nach wenigen Jahren nicht mehr reproduzierbar, und ein Gebäudedatensatz, der Jahrzehnte überdauern soll, verliert dann rückwirkend seinen Wert.

Die fünfte Maßnahme ist der Ausbau des Rechte- und Rollenmodells. Was heute existiert, ist eine Darstellungssteuerung: Die Kennwerteseite kennt Sichten für Architekten, Makler, Hausverwaltungen, TGA-Planer, Banken und Energieberater und ordnet die Werte für jede Sicht anders an. Das ist nützlich, aber es ist keine Zugriffsschicht. Das abgestufte Zugriffsmodell mit sieben Stufen von der öffentlichen Ansicht bis zum Eigentümer ist seit dem 23. August 2026 implementiert. Für die Erfüllung von Artikel 16 ist es unverzichtbar, denn dort ist die Weitergabe an selbst benannte Dritte eine Rechtsposition des Eigentümers, nicht eine Komfortfunktion. Ebenso unverzichtbar ist die Rückansicht: Der Eigentümer muss jederzeit erkennen können, welche Informationen an wen und für welchen Zeitraum freigegeben wurden. Die Leitlinien empfehlen für den nachgeordneten Zugriff ausdrücklich befristete Freigaben und gegebenenfalls reine Bildschirmansichten.

Die sechste Maßnahme sind Qualitätsstufen für alle wesentlichen Daten. Die vier Datenzustände und sechs Vertrauensstufen sind produktiv; die feinere Abstufung der Zielspezifikation mit neun Datenwert-Status ist Konzept. Wichtiger als die Zahl der Stufen ist, dass die Unterscheidung zwischen gemessenen, berechneten, dokumentierten und geschätzten Werten bis in die Ausgaben durchschlägt. Ein Wert ohne Qualitätskennzeichen wird im Zweifel wie ein gemessener behandelt, und genau daraus entstehen die Fehleinschätzungen, die eine datenbasierte Sanierungsplanung unterlaufen.

Die siebte Maßnahme ist die Standardisierung der Schnittstellen. Vorhanden sind JSON als Projektformat mit Export und Import, ein XML-Artefakt des Passes, IFC als Eingangsweg ohne Ausgang, PDF-Erzeugung, KI-gestützte Plan- und Dokumentenanalyse sowie einzelne Fach-Endpunkte. Was fehlt, ist die dokumentierte, versionierte Service-Schnittstelle; sie steht im Pflichtenheft ausdrücklich als offener Roadmap-Punkt. Beim Ausbau gilt ein architektonischer Grundsatz: Externe Systeme dürfen nicht auf den internen Datenkern zugeschnitten werden. Zwischen Kern und Außenwelt gehören klar definierte Exportprofile, die unabhängig von internen Umbauten stabil bleiben. Dieselbe Überlegung führt zur achten Maßnahme, der Anbindung staatlicher Register ausschließlich über Connectoren. Der Weg lautet dann: Gebäudedatenkern, standardisiertes Exportprofil, Register-Connector, externes System. Ändert der Staat sein Schema — und Registerstrukturen ändern sich —, bleibt die Anpassung auf eine schmale Integrationsschicht begrenzt. Dass diese Vorsorge nicht theoretisch ist, zeigt Kapitel 17: Zum Redaktionsstand existiert für Deutschland weder eine nationale Energieausweis-Datenbank noch deren Schema.

Die neunte Maßnahme führt Ökobilanz und Energiebilanz zusammen. Die Lebenszyklusbetrachtung sollte kein getrenntes System werden, denn Bauteile und Materialien sind bereits Bestandteil des Gebäudemodells; sie müssen um ökologische Eigenschaften ergänzt werden. Heute arbeitet das Modul für den grauen Anteil mit einem geschätzten Benchmark; die echte Berechnung aus Bauteilflächen, Materialmengen und EPD-Datensätzen ist als offener Punkt ausgewiesen. Fachlich ist der Weg vorgezeichnet: Anhang III in der Fassung der Delegierten Verordnung (EU) 2026/52 setzt die Systemgrenzen nach EN 15978, einen Bezugszeitraum von 50 Jahren, die Einheit Kilogramm CO₂-Äquivalent je Quadratmeter Nutzfläche und eine feste Liste von Pflichtmodulen; die Rohdatenbasis ist die Bauteil- und Materialliste, die aus einem BIM-Modell extrahierbar ist. Damit lassen sich Sanierungsvarianten künftig gleichzeitig nach Energie, Betriebsemissionen, Lebenszyklus-Treibhauspotenzial und Kosten beurteilen.

Die zehnte Maßnahme ist die getrennte Führung von Bedarf und Verbrauch. Der normative Bedarf und der reale Verbrauch sind unterschiedliche Größen mit unterschiedlichen Randbedingungen; die Erweiterung in Richtung eines digitalen Zwillings darf diese Grenze nicht verwischen. Die Plattform sollte den Bedarf nicht durch den Verbrauch ersetzen, sondern beide Größen vergleichbar machen und die Abweichung als eigene Information führen. Der Gesetzgeber selbst rückt diese Frage in den Vordergrund: Mit dem Übergang des Verbrauchsausweises von drei Abrechnungsperioden auf eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate entsteht erstmals eine Datenbasis, mit der ein Bedarfs-Verbrauchs-Abgleich methodisch sauber möglich ist.

Die elfte und zwölfte Maßnahme verlassen die Software. Ein Pilotprojekt an realen Gebäuden muss nicht nachweisen, dass die Plattform viele Funktionen besitzt — das ist unstrittig und in Kapitel 13 belegt. Es muss vier andere Punkte belegen: dass sich die Daten unter Praxisbedingungen zuverlässig erfassen lassen, dass die Ergebnisse reproduzierbar sind, dass Informationen tatsächlich mehrfach genutzt werden und dass verschiedene Beteiligte dieselben Daten gleich verstehen. Erst danach ist eine unabhängige fachliche Bewertung sinnvoll, die Berechnungsqualität, Datenmodell, Interoperabilität, Datenschutz und Informationssicherheit prüft und aus einer Selbstauskunft eine extern belastbare Aussage macht. Kapitel 16 beschreibt den Zuschnitt eines solchen Pilotprojekts im Einzelnen.

Über all diesen Maßnahmen steht eine Regel, die den Erfolg stärker beeinflusst als jede einzelne von ihnen: Die Reihenfolge ist nicht beliebig. Sinnvoll ist der Weg vom Datenmodell über die Qualitätsschicht zum Renovierungspass, von dort zu den Rollen, dann zu den Schnittstellen, danach zu den Banken- und Ökobilanzprofilen, anschließend zu den Betriebsdaten und zuletzt zur Registerintegration. Wer eine Stufe überspringt, gewinnt keine Zeit, sondern verlagert Aufwand in spätere Umbauten, die dann mehrere Module gleichzeitig betreffen.

18.3 Empfehlungen an den Gesetzgeber

Die technische Weiterentwicklung des Gebäudepasses ist an mehreren Stellen nicht durch eigene Entscheidungen begrenzt, sondern durch fehlende staatliche Spezifikationen. Kapitel 12 und 17 haben diese Punkte einzeln aufgeführt; sie werden hier zu Empfehlungen zusammengefasst. Die Reihenfolge folgt der Dringlichkeit aus Sicht der Umsetzung, nicht dem Gewicht der jeweiligen Rechtsnorm.

Die fehlenden deutschen Spezifikationen

Das Gebäudemodernisierungsgesetz ist am 28. Juli 2026 verkündet worden; seine eigentliche EPBD-Umsetzung tritt später in Kraft. Der Rechtsrahmen steht damit in wesentlichen Teilen. Was in mehreren Fällen fehlt, ist die technische Ausführungsebene — und ohne sie kann eine Anforderung zwar geregelt, aber nicht implementiert sein. Fünf Punkte sind dabei besonders folgenreich.

Erstens das Schema der nationalen Gebäudedatenbank nach Artikel 22. Die Frist zur Einrichtung war der 29. Mai 2026. Deutschland ist in Annex 5 der Kommissions-Leitlinien bei den nationalen Energieausweis-Datenbanken mit „n/a" geführt; ein deutsches Datenbankschema existiert zum Redaktionsstand nicht. Solange es fehlt, ist jede Registeranbindung reine Vorbereitung. Die Empfehlung lautet, das Schema mit hoher Priorität zu veröffentlichen und dabei den vollen Umfang des Artikels 20 Absatz 8 abzubilden — also nicht nur die Ausweisergebnisse, sondern die Berechnungs-Eingangsdaten: Gebäudekategorie, Bezugsfläche mit Aufschlüsselung bei Mischnutzung, den nach Heizung, Kühlung, Trinkwarmwasser, Beleuchtung und Anlagentechnik disaggregierten Bedarf, Leistung und Effizienz der technischen Anlagen, die installierte Leistung erneuerbarer Erzeuger sowie Flächen und U-Werte der Hauptbauteile. Wird das Schema enger gefasst, entsteht eine Datenbank, aus der sich der Ausweis nicht rekonstruieren lässt — und damit ist der Weg verstellt, den Dänemark und Portugal bereits gehen.

Zweitens das amtliche Ausweismuster nach § 85 Absatz 3 GMoDG. Das Muster bestimmt die Anordnung und Beschriftung der Pflichtangaben und damit die Ausgabeschicht jeder Fachsoftware. Bis zu seiner Veröffentlichung kann die Ausgabe vorbereitet, aber nicht abgeschlossen werden. Da Anhang V der Richtlinie den Inhalt bereits vorgibt — Effizienzklasse, Primär- und Endenergie je Energieträger, Anteil erneuerbarer Energie vor Ort, operative Treibhausgasemissionen und, soweit verfügbar, das Lebenszyklus-Treibhauspotenzial — geht es nicht mehr um inhaltliche Klärung, sondern um Formalisierung. Sie sollte mit ausreichendem Vorlauf vor dem Anwendungsdatum erfolgen.

Drittens das Datenformat der Übermittlung. Hierunter fallen zwei getrennte Punkte, die in der Praxis zusammenwirken: das Format des Lebenszyklus-Treibhausgasberichts im Ausweis nach § 88b GMoDG und das Schema der Kontrolldatei für die neuen Monatswerte des Verbrauchsausweises. Der Verbrauchsausweis für Wohngebäude verlangt künftig keine drei Abrechnungsperioden mehr, sondern eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate. Solange das zugehörige Übermittlungsschema fehlt, müssen die Monatswerte in der Struktur des bisherigen Periodenformats transportiert werden — technisch machbar, aber eine Behelfslösung, die spätere Migrationen erzwingt. Beide Formate sollten als maschinenlesbare Spezifikation mit Beispieldateien veröffentlicht werden, nicht als Beschreibung in Prosa.

Viertens die Klassengrenzen für Nichtwohngebäude. Die Effizienzklassenskala für Nichtwohngebäude ist an ihren Rändern definiert, in der Mitte jedoch nicht: Zwischen der besten und der schlechtesten Klasse fehlen die Grenzen der Zwischenklassen. Der Gebäudepass führt diesen Punkt bewusst als Lücke und gibt für die betroffenen Fälle keine Klasse aus, statt einen Wert zu erfinden. Das ist die fachlich richtige Reaktion, aber sie hat eine Konsequenz, die über die Software hinausreicht: Ohne Klassengrenzen kann für Nichtwohngebäude weder ein vollständiger Ausweis nach dem neuen Recht ausgestellt noch der Bestand für die Zielpfade des Artikels 9 klassifiziert werden. Die Empfehlung lautet, die Klassengrenzen zusammen mit den noch ausstehenden Referenzgebäude-Kennwerten zu veröffentlichen, weil beide Größen zusammen die Bezugsbasis bilden.

Fünftens das SRI-Schema. Hier ist die Lage anders gelagert und die Empfehlung entsprechend zurückhaltender. Eine Pflicht zum Smart Readiness Indicator besteht derzeit nicht; sie entsteht erst durch einen delegierten Rechtsakt, der bis zum 30. Juni 2027 zu erlassen ist, und dann zunächst nur für Nichtwohngebäude oberhalb einer Nennleistung von 290 Kilowatt. Im Energieausweis ist der Indikator bis dahin ein Feld mit einer Ja-Nein-Angabe und einem Wert, die Datenbank soll SRI-Bewertungen aufnehmen können. Die Empfehlung ist deshalb nicht, die Pflicht vorzuziehen, sondern das nationale Datenschema so früh zu definieren, dass die Aufnahmefähigkeit der Datenbank und die Feldstruktur des Ausweises feststehen, bevor der delegierte Rechtsakt in Kraft tritt. Eine Spezifikation, die erst mit der Pflicht erscheint, erzeugt genau die Umsetzungsspitze, die durch rechtzeitige Festlegung vermeidbar wäre.

Identifikatoren und Registriernummern

Artikel 22 verlangt eindeutige Gebäude- und Einheitenkennungen, die datenbankübergreifend gelten, geografisch referenziert sind und, wie die Leitlinien formulieren, „von Anfang an" mitgeführt werden; Absatz 7 fordert zusätzlich Interoperabilität mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern. Deutschland hat diese Kennung bisher nicht standardisiert. Der Gebäudepass vergibt deshalb eine eigene, dauerhafte und idempotente Gebäude-Kennung, die innerhalb der Plattform stabil bleibt — als Übergangslösung tragfähig, als nationale Infrastruktur ungeeignet, weil sie an einen Betreiber gebunden ist.

Die Empfehlung an den Gesetzgeber lautet, einen stabilen Gebäudeidentifikator festzulegen, der unabhängig von Eigentümer, Energieberater und Softwareanbieter besteht und einen Eigentümerwechsel überdauert. Das Gebäude bleibt bestehen; seine technische Geschichte darf bei einem Verkauf nicht bei null beginnen. Ohne eine solche Kennung lassen sich Energieausweis, Inspektionsbericht, Renovierungspass und künftige SRI-Bewertung desselben Gebäudes nicht zuverlässig zusammenführen, und die Auswertungen der nationalen Datenbank beruhen auf einer Zuordnung über Adressen, die bei Teilverkäufen, Zusammenlegungen und Umnummerierungen erfahrungsgemäß bricht.

Eng damit verbunden ist die Frage der Registriernummern. Die Registrierung des Ausweises erfolgt nach der Richtlinie über die Datenbank nach Artikel 22 — Registrierung und Datenübermittlung sind dort ein Vorgang. In Deutschland wird die Registriernummer bislang außerhalb der Fachsoftware vergeben; der Gebäudepass erzeugt eine eigene, deterministisch aus der Gebäude-Kennung abgeleitete Dokumentnummer, die ausdrücklich keine amtliche Registriernummer ist, und führt die Anbindung der amtlichen Nummernvergabe als offenen Punkt. Die Empfehlung lautet, die Vergabe der Registriernummer maschinell über die Schnittstelle der künftigen Datenbank abzuwickeln und dabei an den stabilen Gebäudeidentifikator zu koppeln. Damit entfiele der heutige Medienbruch, die Registrierung würde zum Nebenprodukt der ohnehin erforderlichen Datenübermittlung, und die Anforderung des Anhangs VI, den Urheber jeder Änderung ermitteln zu können, wäre technisch erfüllbar, statt organisatorisch nachgebildet werden zu müssen.

Rechtsklarheit zum Verhältnis von iSFP und Renovierungspass

Der individuelle Sanierungsfahrplan ist in der Renovierungspass-Leitlinie der Kommission zweimal als Beispiel guter Praxis genannt — für die Darstellung des Sanierungswegs auf einer Seite und für die schrittbezogenen Förderhinweise. Diese Anerkennung macht ihn jedoch nicht zum Renovierungspass im Sinne des Artikels 12. Drei Pflichtinhalte des Anhangs VIII sind vom iSFP nicht automatisch abgedeckt: die Veränderung der operativen Treibhausgasemissionen je Schritt, die Angaben zu Zirkularität der Bauprodukte und zum Lebenszyklus-Treibhauspotenzial sowie die Liste der nationalen Anforderungen mit ihren Stichtagen. Ob Deutschland den iSFP formal zum Renovierungspass erklärt, ist zum Redaktionsstand nicht entschieden; offen ist ausdrücklich auch die Strukturfrage, ob ein Feldmodell nach Anhang VIII mit iSFP-Darstellung oder das förmliche Layout der Förderanwendung maßgeblich sein soll.

Diese Unklarheit hat konkrete Folgen für die Praxis, und sie sind nicht theoretisch. Ein förderfähiger iSFP entsteht ausschließlich in der amtlichen Druckanwendung des Fördergebers, für die kein maschinelles Importformat veröffentlicht ist; jede Fachsoftware kann deshalb nur ein Datenblatt zur Ausgabe erzeugen, das ausdrücklich kein amtliches Austauschformat ist. Zugleich verlangt Artikel 12 Absatz 7, dass der Renovierungspass in die nationale Datenbank hochladbar ist, und Artikel 19 Absatz 6 lässt zu, dass er bei gemeinsamer Ausstellung die Modernisierungsempfehlungen des Energieausweises ersetzt. Ein Instrument, das rechtlich diese Wirkung entfalten soll, aber technisch nur als Druckerzeugnis existiert, lässt sich nicht in eine Datenkette einfügen.

Die Empfehlung lautet deshalb zweistufig. Zunächst sollte der Gesetzgeber ausdrücklich entscheiden und veröffentlichen, ob der iSFP zum Renovierungspass nach Artikel 12 erklärt wird, in welcher Fassung und mit welchen Ergänzungen für die drei nicht abgedeckten Pflichtinhalte. Unabhängig vom Ausgang dieser Entscheidung sollte anschließend ein maschinenlesbares Austauschformat für den Sanierungsfahrplan bereitgestellt werden — die Richtlinie verlangt Maschinenlesbarkeit für den Renovierungspass nicht, empfiehlt sie aber, und ohne sie bleibt die Kopplung an Ausweis und Datenbank Handarbeit. Solange beide Punkte offen sind, muss die Fachsoftware den iSFP und den Renovierungspass als getrennte Instrumente führen, deren fachliche und rechtliche Identität nicht vermischt werden darf. Das ist der gegenwärtige Stand der Plattform, und er ist die vorsichtige, nicht die komfortable Lösung.

Normstand, Bezugsgrößen und Schwellenwerte

Die Normstandfrage ist der Punkt, an dem der Gesetzgeber am unmittelbarsten Planbarkeit herstellen kann. Gegenwärtig referenziert das Gebäudeenergierecht die DIN V 18599 in der Ausgabe 2018-09, während die Reihe technisch mit der DIN/TS 18599:2025-10 weiterentwickelt wurde. Beide Fassungen sind in der Software als getrennte Stände geführt und beide werden gerechnet — die eine als verbindliches Ergebnis, die andere als Vergleich. Diese Doppelführung ist die richtige Antwort auf die derzeitige Lage, aber sie ist dauerhaft aufwendig und für den Anwender erklärungsbedürftig.

Die Empfehlung lautet, den Übergang nicht als Ereignis, sondern als Verfahren zu regeln: ein bekanntgegebener Stichtag mit ausreichendem Vorlauf, eine definierte Phase, in der beide Fassungen zulässig sind, und eine eindeutige Regel, welche Fassung für welche Nachweisart gilt. Ergänzend sollte eine Divergenz aufgelöst werden, die heute stillschweigend über eine Vorrangregel entschärft wird: Der Anhang der Normfassung 2025 nennt für Strom einen anderen nicht erneuerbaren Primärenergiefaktor als die Anlage des Gebäudeenergierechts, und auch bei den Verdrängungs-Emissionsfaktoren weichen Norm und Rechtsanwendung voneinander ab. Für Energieausweise und öffentlich-rechtliche Nachweise gelten die Werte des Gesetzes; fachlich bleibt eine Norm, deren eigener Anhang andere Zahlen führt als das Recht, das sie anwendet, jedoch eine dauerhafte Fehlerquelle in der Beratungspraxis.

Ähnlich liegt die Frage der Bezugsfläche. Die neue kanonische Bezugsgröße der Nutzfläche nach DIN 277 ist keine Umrechnung der bisherigen Gebäudenutzfläche, sondern eine andere Größe; die Differenz liegt in einer Größenordnung, die Kennwerte spürbar verschiebt. Beide Bezüge sind zulässig, und die Software führt die Bezugsfläche deshalb ausdrücklich mit Quellenangabe. Für den Vergleich von Gebäuden untereinander — und damit für jede Klassifizierung, jede Portfolioauswertung und jede Meldung an eine Datenbank — ist Eindeutigkeit jedoch die Voraussetzung. Die Empfehlung lautet, für jede gesetzlich definierte Kennzahl die Bezugsfläche verbindlich zu benennen und die Angabe der verwendeten Bezugsfläche in jeder Ausgabe vorzuschreiben.

Der dritte Punkt dieser Gruppe betrifft Leistungsschwellen. In den Regelungen zu Gebäudeautomation, Inspektionspflichten und künftiger SRI-Pflicht kursieren mehrere Werte nebeneinander: 290 Kilowatt als Schwelle der Automationspflicht für Nichtwohngebäude, der dreijährigen Inspektion und der künftigen SRI-Pflicht, 70 Kilowatt für die fünfjährige Inspektion und für die bis Ende 2029 nachzurüstende Automation mit Beleuchtungssteuerung — sowie ein dritter Wert, der in den Quellen ohne Rechtsgrundlage auftaucht und deshalb nicht als geltende Schwelle verwendet werden darf. Der Gebäudepass löst das, indem er die Schwelle nicht als Konstante über den Code verteilt, sondern als einen Parameter mit Herkunftsangabe führt und in jeder Ausgabe die verwendete Schwelle nennt. Das ist eine Notlösung. Die Empfehlung an den Gesetzgeber lautet, die Schwellen je Pflicht eindeutig zu benennen und ihre Herkunft in der Begründung nachvollziehbar zu machen, damit Softwareanbieter nicht drei Werte parallel vorhalten müssen.

Verfahrensempfehlungen

Über die einzelnen Spezifikationen hinaus ergeben sich aus der Analyse fünf Empfehlungen zum Verfahren, die alle künftigen Digitalisierungsschritte betreffen und deshalb hier zusammengefasst werden.

• Testsysteme vor Produktivpflichten. Eine neue digitale Anforderung sollte nicht erst am Tag ihres Inkrafttretens technisch erprobbar sein. Erforderlich sind eine Testumgebung, Beispieldatensätze, definierte Testfälle und ein Validierungswerkzeug — und zwar mit so viel Vorlauf, dass eine Fachsoftware die Prüfung durchlaufen und Fehler beheben kann, bevor die Pflicht greift.
• Interoperabilität statt zusätzlicher Einzelplattformen. Für jede neue Nachweispflicht eine weitere isolierte Datenplattform zu schaffen, vervielfacht die Erfassungslast, ohne die Datenqualität zu verbessern. Sinnvoll ist die einmalige strukturierte Erfassung mit Wiederverwendung für unterschiedliche gesetzliche Zwecke. Voraussetzung sind einheitliche Definitionen für Gebäude-Identität, Flächen, Energiekennwerte, Emissionen und Renovierungsstatus; technische Interoperabilität ist unmöglich, wenn Systeme dieselben Begriffe unterschiedlich belegen.
• Vorhandene qualitätsgesicherte Daten anerkennen. Wo belastbare Gebäudedaten bereits vorliegen, sollte keine erneute Erhebung verlangt werden. Das senkt Kosten und Bürokratie und vermeidet Fehler, die bei jeder Wiederholung einer Aufnahme neu entstehen. Anhang VIII sieht diese Logik bereits vor, wenn er die Daten des Energieausweises als Ausgangszustand des Renovierungspasses berücksichtigt und zugleich zulässt, dass Befunde der Vor-Ort-Aufnahme sie überschreiben.
• Datenhoheit der Eigentümer respektieren. Eine nationale Gebäudedateninfrastruktur muss nicht bedeuten, dass sämtliche privaten Gebäudeunterlagen zentral gespeichert werden. Staatliche Systeme benötigen die gesetzlich definierten Informationen; der vollständige operative Datensatz kann davon getrennt bleiben. Die Zugriffsstufen des Artikels 22 zeichnen diese Abstufung bereits vor — kostenloser Vollzugriff für Eigentümer, Mieter, Verwalter und Finanzinstitute mit Portfoliobezug, Zugriff Dritter nur mit Erlaubnis, Gebietsdaten mit Raumbezug für die kommunale Wärmeplanung, aggregierte Veröffentlichung für die Öffentlichkeit.
• Softwareprüfung stärken. Mit wachsender Digitalisierung wächst die Abhängigkeit von der Richtigkeit der Rechenkerne. Definierte Testfälle, veröffentlichte Referenzberechnungen, Regressionsprüfungen und eine dokumentierte Versionsführung sollten zum Standard werden. Die Validierungsfälle der Gütegemeinschaft und die Prüfinfrastruktur des Gebäudepasses zeigen, dass ein solches Vorgehen praktikabel ist; was fehlt, ist seine Verankerung als allgemeine Anforderung.

Diese fünf Punkte haben eine gemeinsame Eigenschaft: Sie kosten den Gesetzgeber vergleichsweise wenig und ersparen der Umsetzungsseite viel. Keiner von ihnen erfordert eine inhaltliche Neubewertung der energetischen Anforderungen; sie betreffen ausschließlich die Art und Weise, wie bereits getroffene Entscheidungen technisch zugänglich gemacht werden.

18.4 Empfehlungen an Banken und Immobilienwirtschaft

Für die Kreditwirtschaft entsteht mit der Richtlinie eine Rechtsposition, die in der bisherigen Praxis kein Vorbild hat: Artikel 22 zählt Finanzinstitute mit Portfoliobezug zu den Stellen, die den vollständigen Energieausweis kostenlos und sowohl maschinenlesbar als auch als Druckdokument erhalten. Das verändert die Ausgangslage. Bisher war die Beschaffung energetischer Gebäudedaten für Banken ein Aufwandsproblem; künftig wird sie ein Auswertungsproblem. Die Empfehlung lautet deshalb, sich weniger mit dem Zugang zu Daten zu befassen als mit der Frage, welche Datentiefe für welche Entscheidung tatsächlich erforderlich ist.

Dafür bietet sich eine Abstufung in vier Ebenen an. Die erste Ebene ist der Energieausweis; er bleibt der standardisierte, flächendeckend verfügbare Einstieg und ist als einziges Instrument maschinenlesbar verpflichtet. Die zweite Ebene sind die technischen Gebäudedaten — Bauteilaufbau, U-Werte, Anlagentechnik, Erzeugerleistung, Restlebensdauer der Wärmeerzeugung —, also die Angaben, die erklären, warum ein Ausweisergebnis so ausfällt, wie es ausfällt. Die dritte Ebene umfasst den Sanierungsbedarf, den daraus folgenden Investitionsbedarf und den zeitlichen Transformationspfad; sie beantwortet die Frage nach dem künftigen Mittelbedarf und ist damit für die Kreditentscheidung häufig relevanter als der heutige Kennwert. Die vierte Ebene enthält Emissions- und Nachhaltigkeitsangaben sowie — und das ist der Punkt, der in der Praxis am häufigsten fehlt — die Qualitätskennzeichnung der zugrunde liegenden Daten. Ohne die vierte Ebene werden Werte unterschiedlicher Belastbarkeit miteinander verglichen, als wären sie gleichwertig.

Daraus folgt die zentrale Empfehlung zur Arbeitsteilung: Der Gebäudepass sollte keine Kreditlogik abbilden. Kreditrating, Beleihungswertermittlung, Preisbildung und Risikopolitik bleiben Sache der Bank; sie sind Kern ihres Geschäfts, unterliegen aufsichtsrechtlichen Anforderungen und lassen sich nicht sinnvoll in eine Fachsoftware für Gebäudedaten auslagern. Was der Gebäudepass liefern kann und liefern sollte, ist ein strukturiertes Evidenzpaket: Ausweisdaten, technische Kennwerte, Sanierungsbedarf, Investitionsschätzung, Emissionen und die Datenqualität dazu, jeweils mit Herkunft und Stand. Diese Trennung ist nicht nur organisatorisch sauber, sie reduziert auch Haftungs- und Modellrisiken auf beiden Seiten: Die Bank übernimmt keine fremde Bewertungsmethodik, und der Datenlieferant übernimmt keine Verantwortung für Kreditentscheidungen.

Für die Immobilienwirtschaft im engeren Sinn führt die Analyse zu einer schlichteren, aber weitreichenden Empfehlung: Gebäudedaten sollten als dauerhafte Vermögensinformation behandelt werden, nicht als Anlass-Dokumentation. Heute geht bei jedem Verkauf, jeder Sanierung und jedem Verwalterwechsel ein erheblicher Teil des Wissens über ein Gebäude verloren, weil es an Personen und an Aktenbeständen hängt, die nicht mitwandern. Ein Gebäudedatensatz, der Eigentümer- und Verwalterwechsel überdauert, reduziert diesen Verlust — vorausgesetzt, die Kennung des Gebäudes ist stabil, was auf die Empfehlung an den Gesetzgeber zurückverweist.

Für die einzelnen Akteure ergeben sich daraus unterschiedliche Schwerpunkte, die sich in wenigen Sätzen fassen lassen. Maklerinnen und Makler sollten sich nicht darauf beschränken, den Energieausweis einzusammeln, weil er in der Anzeige gefordert ist. Ein hochwertiger Verkaufsdatensatz enthält zusätzlich die Sanierungshistorie, Angaben zum Heizsystem einschließlich der zu erwartenden Restlebensdauer, die Belege für durchgeführte Modernisierungen und den Qualitätsstatus dieser Angaben; er macht die Immobilie nicht schöner, aber überprüfbarer, und er verkürzt die Prüfphase auf Käufer- und Finanziererseite. Hausverwaltungen sind die Stelle, an der die Aktualität des Datensatzes tatsächlich entsteht: Sie kennen Wartungen, Störungen, Rechnungen und Modernisierungen als erste. Fließen diese Informationen laufend in den Gebäudepass, bleibt er aktuell, ohne dass eine gesonderte Erhebung nötig wird. Wohnungsunternehmen schließlich sollten den Gebäudepass nicht nur objektbezogen einsetzen. Auf Portfolioebene lassen sich Energieklassen, Heizsysteme, Sanierungsstände, künftiger Investitionsbedarf und Emissionen zusammenführen; daraus entsteht ein Steuerungsinstrument, das für die Zielpfade des Artikels 9 und für die eigene Investitionsplanung dieselbe Datengrundlage nutzt.

18.5 Empfehlungen an Energieberater und Fachplaner

Die Veränderung, die sich für die Energieberatung abzeichnet, betrifft weniger die Methodik als die Zeitachse der Leistung. Bisher ist die typische Beauftragung punktuell: Ein Nachweis wird benötigt, er wird erstellt, das Mandat endet. Ein Gebäudedatensatz, der über Jahrzehnte fortgeschrieben wird, verlangt und ermöglicht etwas anderes — die dauerhafte fachliche Begleitung eines Gebäudes, in der Daten geprüft, Sanierungsschritte begleitet, Förderfähigkeiten beurteilt und Berechnungsergebnisse aktualisiert werden. Die Richtlinie stützt diese Verschiebung an mehreren Stellen: Die vereinfachten Ausweisaktualisierungen nach Artikel 19 Absatz 14 setzen voraus, dass jemand den Datenstand pflegt; die Einladung zur Beratungsstelle nach fünf Jahren für Gebäude unterhalb der Klasse C schafft einen wiederkehrenden Anlass; und der Renovierungspass ist seiner Natur nach ein über Jahre begleitetes Instrument.

Aus dieser Rolle folgen sechs praktische Empfehlungen. Erstens sollte in jedem Dokument, das die Praxis verlässt, festgehalten sein, nach welcher Normfassung und welchem Rechtsstand gerechnet wurde. Das ist keine Formalie: Solange das Recht die Ausgabe 2018-09 in Bezug nimmt und die technische Weiterentwicklung als Spezifikation daneben steht, ist ein Ergebnis ohne diese Angabe nicht einzuordnen — und nach einem Rechtsstandwechsel nicht mehr reproduzierbar. Dasselbe gilt für die verwendete Bezugsfläche, die bei denselben Kennwerten zu spürbar unterschiedlichen Zahlen führt.

Zweitens sollte die Vor-Ort-Aufnahme nicht als Formsache behandelt werden. Die Richtlinie verlangt für den Energieausweis einen Vor-Ort-Besuch, der virtuell mit einer Sichtprüfung per Video zulässig ist; für den Renovierungspass verlangt sie mindestens einen Vor-Ort-Besuch und stellt ausdrücklich fest, dass die Aufnahme für den Pass tiefer geht als die für den Ausweis. Wer diese beiden Anlässe verbindet, erhebt einmal und verwendet zweifach — das ist der praktische Kern des Wiederverwendungsprinzips auf der Ebene der einzelnen Beratung.

Drittens sollten Modernisierungsempfehlungen den inhaltlichen Anforderungen der Richtlinie genügen. Sie sind kostenoptimal auszurichten, mit ihrer Wirkung auf Treibhausgasemissionen und Raumklima zu beschreiben und je Empfehlung mit einer quantifizierten Schätzung zu versehen. Zwei Punkte verdienen dabei besondere Aufmerksamkeit, weil sie in der Praxis regelmäßig unterbleiben: die Beurteilung der Niedertemperatur-Eignung des Verteilsystems, für die die Leitlinien ein vierstufiges Verfahren von der Heizlast über die Heizkörperleistung und den Volumenstrom bis zur erforderlichen Systemtemperatur beschreiben, und die Berücksichtigung der Restlebensdauer der Wärmeerzeugung — steht der Austausch ohnehin in Kürze an, gehört die fossilfreie Alternative in die Empfehlung, unabhängig davon, ob eine Sanierung angefragt war.

Viertens sollte die Arbeitsteilung mit KI-gestützten Werkzeugen klar geregelt bleiben. Die automatisierte Plan- und Dokumentenanalyse beschleunigt die Erfassung erheblich, und der Gebäudepass verfügt über entsprechende Funktionen. Der Grundsatz dahinter muss jedoch unangetastet bleiben: Die Maschine erzeugt Vorschläge, den endgültigen Status erhält ein fachlich relevanter Wert erst durch einen definierten Prüf- und Freigabeschritt. Der Gebäudepass bildet das im Vier-Augen-Verfahren technisch ab — ein gemeldeter Wert verändert den offiziellen Datenbestand nicht, erst die Freigabe tut es. Diese Trennung ist der Grund, warum Verantwortung nachvollziehbar bleibt, und sie sollte nicht aus Bequemlichkeit umgangen werden.

Fünftens sollte die Datenübergabe an den Eigentümer als Teil der Leistung verstanden werden. Artikel 16 gibt Eigentümern, Mietern und Verwaltern einen Anspruch auf direkten und kostenlosen Zugang zu den Gebäudesystemdaten und auf deren unentgeltliche Weitergabe an selbst benannte Dritte. Eine Beratung, die ihre Ergebnisse ausschließlich als PDF hinterlässt, erfüllt zwar ihren Auftrag, überträgt aber keine wiederverwendbaren Daten — und erzwingt damit bei der nächsten Gelegenheit eine erneute Erfassung, die der Eigentümer bezahlt.

Sechstens — und das richtet sich vor allem an Fachplanerinnen und Fachplaner der technischen Gebäudeausrüstung — sollte die Dokumentationspflicht nach Artikel 13 Absatz 6 als Datenquelle genutzt werden. Nach dem Einbau eines gebäudetechnischen Systems ist die Gesamtenergieeffizienz des veränderten Teils zu bewerten, zu dokumentieren und dem Eigentümer zu übergeben. Diese Dokumentation entsteht ohnehin; wird sie strukturiert in den Gebäudedatensatz übernommen, ersetzt sie einen erheblichen Teil der Bestandsaufnahme bei der nächsten Ausweisausstellung. Umgekehrt gilt für die Auslegung: Wenn Bauteile bereits saniert sind, muss die Heizlastberechnung den sanierten Zustand abbilden, sonst wird der Erzeuger auf einen Zustand ausgelegt, den es nicht mehr gibt. Ein gepflegter Gebäudedatensatz macht diesen Unterschied sichtbar, weil er den Ist-Zustand je Bauteil mit Herkunft und Datum führt.

18.6 Perspektive einer europäischen Gebäudedatenplattform

Die Richtlinie legt bereits eine mehrstufige Datenarchitektur an, ohne sie so zu nennen. Auf der untersten Ebene steht das einzelne Gebäude mit seinen Daten. Darüber liegt die nationale Datenbank nach Artikel 22, die Energieausweise, Inspektionsberichte, Renovierungspässe, SRI-Bewertungen sowie berechnete und gemessene Verbräuche aufnimmt und über ein öffentliches Zugangsportal erreichbar ist. Darüber wiederum liegt die europäische Aggregationsebene: Die nationalen Datenbanken übermitteln mindestens einmal jährlich Daten an das EU Building Stock Observatory, wofür die Durchführungsverordnung (EU) 2025/1328 die Vorlagen bereitstellt. Die Verbindung zwischen nationaler Ebene und europäischer Auswertung ist damit nicht mehr Zukunftsmusik, sondern geregelt.

Entscheidend ist, welche Form diese Architektur annimmt. Eine europäische Plattformstrategie muss nicht bedeuten, dass sämtliche Detaildaten jedes einzelnen Gebäudes zentral auf Unionsebene gespeichert werden. Die naheliegende und mit Datenschutzrecht und nationalen Zuständigkeiten besser vereinbare Form ist eine föderierte Struktur: Die Daten bleiben möglichst nah an ihrer Quelle, werden aber über gemeinsame Definitionen und Formate interoperabel gehalten. Aggregierte Auswertungen entstehen dann durch Übermittlung definierter Kennzahlen, nicht durch zentrale Speicherung vollständiger Gebäudeakten. Die Richtlinie geht diesen Weg bereits — sie verlangt für die Öffentlichkeit ausdrücklich aggregierte und anonymisierte Daten und stellt die Datenbanken unter die Datenschutz-Grundverordnung und den Data Governance Act.

Für eine solche Struktur wäre ein europäischer Mindestdatensatz sinnvoll, der die Größen umfasst, die für jede grenzüberschreitende Auswertung benötigt werden — Gebäudeidentität mit geografischem Bezug, Gebäudetyp, Bezugsfläche, Energieeffizienzklasse, die wesentlichen Energie- und Emissionskennwerte und der Renovierungsstatus. Nationale Systeme könnten darüber hinaus ergänzen, was ihr eigenes Recht verlangt. Ein solcher Mindestdatensatz existiert in Ansätzen bereits: Die Pflichtangaben der Ausweis-Titelseite nach Anhang V sind europaweit einheitlich definiert, und für den Lebenszyklusbereich enthalten die Leitlinien ein maschinenlesbares Standard-Gebäudedokument mit Projektkennung, Typologie, Flächen, Geokoordinaten, den Treibhauspotenzialen je Modul und einer Datenqualitätsmetrik. Was fehlt, ist die Zusammenführung dieser Ansätze zu einer gemeinsamen Feldliste.

In einer solchen Architektur hat der digitale Gebäudepass eine klar umrissene Aufgabe. Er übersetzt das reale Gebäude in einen strukturierten Datensatz und diesen wiederum in die Formen, die verschiedene Empfänger benötigen — den Energieausweis für den Rechtsverkehr, den Renovierungspass für die Sanierungsplanung, das Förderprofil für den Antrag, das Evidenzpaket für die Bank, den Meldesatz für das Register. Er ist damit die Übersetzungsschicht zwischen dem Gebäude und den digitalen Anwendungen, die es beschreiben. Diese Positionierung ist auch die tragfähigere: Ein Werkzeug, das beansprucht, Energieausweis, Sanierungsfahrplan und Gebäudemodell zu ersetzen, stellt sich gegen etablierte Instrumente, Zuständigkeiten und Rechtsformen. Ein Werkzeug, das deren Daten über den Lebenszyklus verbindet, ergänzt sie — technisch wie ordnungspolitisch die stärkere Position.

18.7 Die Empfehlungen im Überblick

Die folgende Übersicht führt die Empfehlungen der Abschnitte 18.2 bis 18.6 zusammen. Sie nennt je Empfehlung den Adressaten, die Begründung aus den vorangegangenen Kapiteln und einen Zeithorizont. Die Zeitangaben sind dort an ein Datum gebunden, wo die Richtlinie oder das deutsche Recht ein Datum vorgeben; wo das nicht der Fall ist, steht eine relative Angabe. Ein Zeithorizont „laufend" bedeutet, dass es sich um eine dauerhafte Praxis handelt, nicht um ein abzuschließendes Vorhaben.

Die Übersicht zeigt eine Asymmetrie, die für die weitere Arbeit wesentlich ist. Von den Empfehlungen an den Gesetzgeber sind mehrere mit „sofort" ausgewiesen, weil die zugehörige Frist bereits läuft oder verstrichen ist; sie blockieren jeweils eine ganze Kette nachgelagerter Umsetzungsschritte. Die Empfehlungen an Banken, Immobilienwirtschaft und Beratung tragen dagegen überwiegend den Zeithorizont „laufend" — sie hängen nicht von einer staatlichen Entscheidung ab, sondern von der eigenen Praxis, und können deshalb unabhängig davon begonnen werden. Für die Plattformentwicklung schließlich gilt eine dritte Logik: Sie kann bis an die Schnittstellenkante bauen, muss diese Kante klar benennen und darf für alles, was jenseits davon liegt, keinen Termin zusagen.

18.8 Ausblick

Die Aufgabe der kommenden Jahre besteht nicht allein darin, Millionen Gebäude energetisch zu verbessern. Sie besteht zugleich darin, zu verhindern, dass für jede Sanierung, jeden Energieausweis, jede Finanzierung und jeden Eigentümerwechsel dieselben Gebäudeinformationen erneut gesucht, geschätzt und erhoben werden. Diese doppelte Arbeit ist heute die Regel, nicht die Ausnahme, und sie ist der stillste und teuerste Teil der Gebäudewende. Der digitale Gebäudepass setzt genau an dieser strukturellen Schwäche an. Sein Wert liegt nicht in einem weiteren Dokument, sondern in der dauerhaften, überprüfbaren und wiederverwendbaren Information über das Gebäude.

Für die Beteiligten bedeutet das Unterschiedliches, aber es läuft auf dieselbe Bewegung hinaus. Eigentümer können die technische Entwicklung ihres Gebäudes erstmals über Jahrzehnte nachvollziehbar dokumentieren; die Frage ist dann nicht mehr nur, in welchem Zustand ein Gebäude heute ist, sondern woher es kommt, was an ihm gemacht wurde, was noch zu tun bleibt und welche Unterlagen das belegen. Für die Energieberatung verschiebt sich die Leistung von der punktuellen Nachweiserstellung zur dauerhaften Qualitätssicherung eines Datenbestandes — fachlich anspruchsvoller und wirtschaftlich tragfähiger als das heutige Einzelmandat. Für Banken verbessert sich nicht das Bewertungsmodell, sondern dessen Eingangsseite: Die Risikologik bleibt, die Daten werden belastbarer. Für den Immobilienmarkt sinkt die Informationsasymmetrie zwischen dem, der ein Gebäude kennt, und dem, der es kaufen oder finanzieren soll. Und für Politik und Verwaltung entsteht die Möglichkeit, den Gebäudebestand auf Basis strukturierter statt geschätzter Daten zu verstehen — vorausgesetzt, es werden nur die dafür erforderlichen und rechtlich zulässigen Informationen verwendet.

Die zeitliche Perspektive lässt sich mit der gebotenen Vorsicht in drei Etappen beschreiben. Bis zum Ende dieses Jahrzehnts geht es darum, die vorhandenen Bausteine stabil zu verbinden: Gebäudedaten, Energieausweis, Renovierungspass, Förderung, Ökobilanz, Rollen und standardisierte Schnittstellen. Das ist keine Vision, sondern die Summe der Anforderungen, die bis 2030 ohnehin rechtlich wirksam werden — von der Nullemissionspflicht für alle Neubauten über die Ausweisung des Lebenszyklus-Treibhauspotenzials bis zu den Zwischenzielen der Bestandspfade. In einer zweiten Etappe, mit zunehmender Verbreitung von Mess- und Betriebsdaten, kann der Gebäudepass stärker zum digitalen Zwilling werden und neben dem normativen Bedarf auch die reale Energieperformance, den Betrieb der Wärmeerzeugung, den Ertrag der Photovoltaik und die Gebäudeautomation abbilden. Die Perspektive verschiebt sich dann vom Nachweis zum laufenden Gebäudemanagement — ohne dass Bedarf und Verbrauch dabei zu einer Größe verschmelzen dürften. Langfristig könnte jedes Gebäude über eine dauerhaft fortgeschriebene digitale Identität verfügen, die nicht sämtliche privaten Daten zentral vorhält, aber autorisierten Beteiligten einen aktuellen, nachvollziehbaren und interoperablen Zugriff eröffnet. Die digitale Dokumentation begleitete dann die reale Lebensdauer eines Gebäudes.

Ob dieser Weg eingeschlagen wird, entscheidet sich nicht an der Software. Die Richtlinie gibt die europäische Richtung vor, das nationale Gebäudeenergierecht konkretisiert die Anforderungen, die DIN V 18599 liefert die Berechnungsverfahren, Energieausweis und Renovierungspass stellen definierte Ergebnisse und Entwicklungspfade dar. Was der digitale Gebäudepass hinzufügt, ist die Verbindung der zugrunde liegenden Informationen über den Lebenszyklus: Aus einzelnen Dokumenten wird ein Gebäudedatensatz, aus dem Datensatz eine Gebäudechronik, aus der Chronik kann ein digitaler Zwilling entstehen und aus interoperablen Zwillingen langfristig eine Dateninfrastruktur für den europäischen Gebäudebestand. Jede dieser Stufen setzt die vorhergehende voraus, und keine lässt sich überspringen.

Der entscheidende Schritt ist deshalb nicht die Digitalisierung eines weiteren Formulars. Er ist die dauerhafte Digitalisierung des Gebäudes selbst — mit dem Vorbehalt, den dieses Whitepaper von Anfang an mitgeführt hat: Wo die staatlichen Spezifikationen noch fehlen, kann vorbereitet, aber nicht abgeschlossen werden. Diese Lücken sind benannt. Sie zu schließen, ist die Voraussetzung dafür, dass aus vorhandener technischer Leistungsfähigkeit tatsächlich eine funktionierende Dateninfrastruktur wird.

19 Der Abgleich: Whitepaper-Zielbild und der Stand der eigenen Entwicklung

Die vorangegangenen achtzehn Kapitel beschreiben eine Plattform. Teile dieser Plattform arbeiten seit Jahren in realen Projekten und sind mit Prüfnachweisen belegt, andere Teile sind Konzept, wieder andere existieren nicht. Dieses Kapitel legt beide Seiten nebeneinander — das im Dokument beschriebene Zielbild und den dokumentierten Stand der eigenen Entwicklung — und benennt für acht Themenfelder nicht nur, ob es eine Differenz gibt, sondern welcher Art sie ist.

19.1 Wozu dieser Abgleich

Ein Whitepaper über einen digitalen Gebäudepass kann auf zwei Arten unbrauchbar werden. Es kann beschreiben, was die Richtlinie verlangt, und offenlassen, ob irgendjemand es umsetzen kann — dann ist es eine Zusammenfassung des Rechtstexts. Oder es kann beschreiben, was eine Software leisten soll, und offenlassen, was sie heute leistet — dann ist es eine Absichtserklärung. Die ersten achtzehn Kapitel bewegen sich zwangsläufig zwischen beidem: Sie entwickeln ein Datenmodell, eine Funktions- und Schnittstellenarchitektur, ein Rollenkonzept und eine Roadmap. Wer sie liest, ohne den Umsetzungsstand zu kennen, erhält kein falsches, aber ein unscharfes Bild — er kann nicht unterscheiden, welcher Satz einen Zustand beschreibt und welcher eine Absicht.

Kapitel 12 und Kapitel 13 haben diese Unschärfe bereits verringert, aber sie messen in eine andere Richtung. Die Anforderungsmatrix misst die Software an der Richtlinie und beantwortet die Frage, ob eine Rechtspflicht erfüllt ist. Die Reifegradanalyse misst die Software an sich selbst und beantwortet die Frage, wie belastbar eine Funktion ist. Beide Kapitel nehmen dabei die Beschreibung des Zielbilds als gegeben hin. Genau das tut dieses Kapitel nicht: Es prüft das Dokument gegen die Software und nicht die Software gegen das Dokument. Die Frage lautet hier, ob das Whitepaper und die Entwicklungsdokumentation überhaupt dieselbe Sache meinen, wenn sie dasselbe Wort verwenden — und wo sie es nicht tun, ob der Unterschied in der Benennung liegt, in der Konstruktion oder im Vorhandensein.

Diese Prüfrichtung fördert einen Befund zutage, den die beiden anderen Kapitel systematisch nicht zeigen können: Der Abstand zwischen Dokument und Software geht in beide Richtungen. An mehreren Stellen ist die vorhandene Software genauer, strenger oder weiter als das, was das Zielbild von ihr verlangt. Ein Whitepaper, das ausschließlich Rückstände auflistet, gibt ein ebenso schiefes Bild wie eines, das ausschließlich Fähigkeiten aufzählt — und Energieberater, Banken und Ministerien brauchen die Auskunft in beide Richtungen.

Für die Beweislage gilt dieselbe Regel wie in Kapitel 13: Jede Aussage über die Software stützt sich auf die datierten Entwicklungsunterlagen. Wo diese einen Punkt ausdrücklich als Konzept, als offen oder als extern blockiert führen, wird er hier ebenso geführt. Wo sie schweigen, steht in diesem Kapitel keine Aussage — insbesondere keine geschätzte Fertigstellungsquote und keine Prozentzahl, die nicht aus einer Zählung stammt.

19.2 Der Maßstab

Ein Abgleich braucht ein Vokabular, sonst endet er bei der Auskunft „teilweise", die für alles gilt und nichts erklärt. Das folgende Kapitel verwendet durchgehend vier Differenzarten. Sie unterscheiden sich nicht nach Größe, sondern nach Ursache — und damit nach der Handlung, die aus ihnen folgt.

• Deckung. Zielbild und Software beschreiben dieselbe Sache mit derselben Konstruktion. Der Text des Whitepapers lässt sich ohne Einschränkung als Beschreibung des Vorhandenen lesen. Deckung heißt nicht Vollständigkeit — ein gedeckter Bereich kann Einzellücken enthalten —, sondern Übereinstimmung der Bauform.
• Vorsprung. Die Software kann mehr oder Genaueres, als das Zielbild beschreibt — geprüfte Rechenkerne, tägliche automatisierte Prüfung, Abgleich der Daten gegen ihre eigenen Quellen, Herkunftskennzeichnung je einzelnem Wert. Ein Vorsprung ist kein Grund zur Untätigkeit, sondern ein Hinweis, dass die Beschreibung nachzuziehen ist: Was nicht beschrieben ist, kann von außen nicht geprüft und nicht anerkannt werden.
• Abweichung. Beide Seiten haben etwas zu demselben Gegenstand, aber unterschiedlich konstruiert. Der gefährlichste Fall ist die Abweichung unter gleichem Namen — etwa die sechsstufige Qualitätsskala der Modellskizze gegen die real umgesetzte Trennung in eine Vertrauensskala und vier Datenzustände, oder das Wort „Rolle", das im Zielbild eine Rechteschicht und in der Software eine Anzeigepriorisierung bezeichnet. Eine Abweichung erzeugt keinen Entwicklungsaufwand, aber sie erzeugt Missverständnisse, solange sie nicht ausgesprochen ist.
• Lücke. Das Zielbild beschreibt etwas, das nicht existiert. Jede Lücke wird zusätzlich danach unterschieden, ob ihre Schließung in eigener Hand liegt oder an einer fremden Festlegung hängt — an einer nationalen Spezifikation, einem ausstehenden Rechtsakt oder Daten, die nicht vorliegen. Diese Unterscheidung ist keine Entlastung, sondern eine Planungsauskunft: Nur die erste Sorte verschwindet durch Entwicklungsleistung.

Drei Zuordnungsregeln gehören dazu. Je Themenfeld wird eine dominierende Differenzart vergeben; sekundäre Differenzarten nennt der Text ausdrücklich, weil kein Themenfeld einheitlich ist. Im Zweifel gilt die ungünstigere Zuordnung: Wo unklar bleibt, ob eine Funktion vorhanden oder nur beschrieben ist, wird sie als Lücke geführt. Und eine Beschreibung im Pflichtenheft, im Datenmodell oder im Bedienkonzept ist ein Beleg für das Konzept, niemals ein Beleg für die Umsetzung.

19.3 Datenmodell und Gebäudeidentität

Das Zielbild beschreibt in Kapitel 4 den Übergang vom Gebäudedokument zum Gebäudedatensatz: ein Gebäude, ein Datensatz, eine über die gesamte Lebensdauer stabile Identität, darunter gegliederte Bereiche für Stammdaten, Geometrie und Bezugsflächen, Nutzung und Zonierung, Hülle, Anlagen, Bilanz, Ausweis, Verbrauch, Sanierungshistorie, Förderung, Lebenszyklus und Dokumente. Kapitel 8 ergänzt die Forderung nach einem kanonischen Datenmodell statt einer Formularlogik: Jede Größe existiert genau einmal, unter genau einem Namen, mit genau einer führenden Quelle.

Der belegte Stand deckt diesen Kern. Sämtliche Werkzeuge arbeiten über einen gemeinsamen Projektspeicher mit pfadadressierten Werten auf einem Projektobjekt je Gebäude; ein Audit vom 10.08.2026 weist 74 Werkzeuge, 64 Registerfelder und 96 reale Projekte auf demselben Bestand aus. Geschrieben wird automatisch, aber nur bei tatsächlicher Änderung, und der Server sichert den vorherigen Stand, bevor er schreibt. Die Gebäudeidentität ist als Kennung nach dem Muster DG-Jahr-Laufnummer umgesetzt, einmalig erzeugt und danach unveränderlich, geführt in einem eigenen, additiv angelegten Abschnitt des Datensatzes. Ein Objektgraph verbindet die Datenobjekte über benannte Kanten — belegt durch, beeinflusst, ersetzt —, und eine Abhängigkeitskette führt vom Bauteil über U-Wert und Heizlast zu den Bilanzgrößen, zum Nachweis, zur Emissionsbilanz, zum Bewertungsindex und bis in den Finanzierungsbericht.

An zwei Stellen ist die Software genauer als ihre Beschreibung. Die Bezugsfläche ist nicht als Begriff, sondern als benanntes Feld mit eigener Quellenangabe festgelegt; Gebäudenutzfläche, Wohnfläche, Bruttogrundfläche, Netto-Raumfläche und ein früher dreifach belegtes allgemeines Nutzflächenfeld sind als Ersatz unzulässig, und fehlt die kanonische Fläche, meldet die Bilanz eine Lücke, statt einen Näherungswert zu verwenden. Ebenso ist das Nutzungsprofil für Nichtwohngebäude auf je ein kanonisches Feld für Hauptnutzung und Zonenprofil zusammengeführt worden; zuvor trug dieselbe Größe vier verschiedene Namen, und die zonenweise Bilanz griff in keinem einzigen Projekt. Beides sind abgeschlossene Migrationen mit belegtem Ergebnis, die das Zielbild nur als Grundsatz beschreibt.

Die Differenzart dieses Feldes ist deshalb Deckung, mit einem Vorsprung bei der Feldkanonik. Zwei Einschränkungen bleiben und sind als Lücken zu führen. Geometrie und Bauteile sind im Grundrisseditor und im Gebäudesteckbrief vorhanden, aber noch nicht als Knoten des Passes verlinkt — der Datensatz ist vollständig, der Pass greift jedoch noch nicht auf jeden seiner Teile als eigenes Objekt zu. Und die Identität reicht bislang nur nach innen: Eine Passport-Kennung im vorgesehenen Format ist nicht vergeben, ein regional gegliedertes Kennungsschema, der Katasterbezug sowie maschinenlesbare Träger wie NFC oder eine Maschinenzeile sind ausdrücklich Konzept. Artikel 22 Absatz 7 EPBD verlangt Interoperabilität mit Kataster und Grundbuch sowie mit digitalen Gebäudelogbüchern und setzt datenbankübergreifend eindeutige Gebäude- und Einheitenkennungen voraus; die erste dieser Lücken liegt in eigener Hand, die zweite hängt am fehlenden deutschen Schema.

19.4 Datenqualität, Herkunft und Freigabe

Das Zielbild fordert, dass jeder wesentliche Wert einen Qualitätsstatus trägt, weil ein Gebäudedatensatz ohne diesen Status eine Sammlung gleich aussehender Zahlen unterschiedlicher Belastbarkeit ist. Die ursprüngliche Modellskizze sah dafür eine einzige sechsstufige Skala von Q0 bis Q5 vor, die von der unbekannten Größe über die Schätzung, die Eigentümerangabe und die Dokumentation bis zur fachlichen Verifikation und zur Messung reicht. Ergänzend beschreibt Kapitel 9 einen Prüf- und Freigabeweg sowie eine Historisierung ohne Überschreiben.

Das umgesetzte System löst dieselbe Aufgabe mit zwei getrennten Achsen. Die erste ist eine Vertrauensskala von 0 bis 5: unbekannt, Eigentümerangabe, aus einem Dokument erkannt, plausibilisiert, geprüft, amtlich signiert. Die zweite ist ein davon unabhängiger Datenzustand mit vier Werten — Entwurf, gemeldet, geprüft, freigegeben —, wobei ausschließlich der freigegebene Zustand in offizielle Berichte gelangen darf. Der Übergang vom gemeldeten in den freigegebenen Zustand ist als Vier-Augen-Verfahren realisiert: Das Melden erzeugt einen Vorschlag im Arbeitsbereich und lässt den offiziellen Wert unverändert, erst die Freigabe schreibt in den führenden Pfad. Fünfzehn Konsistenzregeln legen den Rahmen fest, darunter die eine führende Quelle je Information, das Verbot des Überschreibens zugunsten einer neuen Version, die Pflicht zu Metadaten je Wert, die Belegbeziehung zwischen Dokument und Datensatz sowie die Regel, dass Drittsysteme nur Vorschläge liefern und Konflikte erzeugt statt automatisch aufgelöst werden. Die Herkunft ist als eigene Angabe je Wert und je Kante hinterlegt und unterscheidet acht Kategorien — Dokument, Nutzereingabe, KI-Erkennung, Berechnung, Fachplaner, amtliche Quelle, Messung, Annahme. Eine Neuberechnungslogik markiert bei geänderten Eingaben die betroffenen Auswertungen als veraltet, stößt die Rechenkette an und protokolliert den Vorgang.

Die Differenzart ist Abweichung, und sie fällt zugunsten der Software aus. Die Modellskizze vermischt in einer Skala zwei Fragen, die das umgesetzte System trennt: woher ein Wert stammt und wie gut er abgesichert ist. Ein aus einem Dokument erkannter Wert kann geprüft oder ungeprüft sein, eine Messung plausibel oder fehlerhaft — die zweiachsige Konstruktion bildet das ab, die einachsige nicht. Hinzu kommt ein deutlicher Vorsprung: Wertversionierung, Vier-Augen-Trennung, Belegkanten und die Neuberechnungskette gehen über das hinaus, was die Modellskizze verlangt, und die Ausgabeseite hält die Regel durch — der Kennwertkatalog mit 43 Kennwerten zeigt zu jedem Wert eine Herkunftsplakette und stellt fehlende Werte als Strich dar, statt sie zu füllen.

Drei Lücken bleiben, und sie sind benannt. Die weitergehende Zielspezifikation mit neun Datenwert-Status von „verifiziert" bis „widersprüchlich" ist Konzept und nicht implementiert. Digitale Signaturen je Freigabe sind ausdrücklich offen, weshalb die oberste Vertrauensstufe „amtlich signiert" praktisch nicht erreichbar ist — die Skala ist an ihrem oberen Ende derzeit leer. Und die Konfliktauflösung sowie die Durchsetzung der Rollen sind als offene Punkte geführt; die Freigabeschicht trägt zusätzlich den Vermerk einer noch ausstehenden datenschutzrechtlichen Vorprüfung. Der erste Punkt liegt vollständig in eigener Hand, der zweite hängt zusätzlich an der Frage, welches Signaturverfahren eine spätere amtliche Stelle anerkennt.

19.5 Rechenkerne, Nachweise und Dokumente

Das Zielbild beschreibt die normative Berechnung als Funktion des Datenmodells: Aus dem Gebäudedatensatz entstehen Bilanz, Nachweis und Dokument, und die Dokumente sind Ausgaben des Datenbestands und keine eigenständig gepflegten Dateien. Kapitel 5 fügt hinzu, dass jede Ausgabe die gerechnete Normfassung und den Rechtsstand benennen muss, damit ein Ergebnis reproduzierbar ist; Kapitel 7 beschreibt Ausweis-, Bauphysik- und Anlagenmodule als Bausteine derselben Plattform.

Der belegte Stand geht darüber hinaus. Die Berechnung stützt sich auf einen Satz eigener Rechenkerne für Nutzenergiebedarf, Anlagentechnik, Referenzgebäude, Monatsbilanz, Energiebilanz und Geometrie auf Grundlage der DIN V 18599 in der Ausgabe 2018-09, ergänzt um eine Normstand-Registry, die die Ausgabe 2025-10 als Vergleich mitführt. Die Prüfung erfolgt gegen 34 Validierungsfälle der Gütegemeinschaft mit 964 Einzelgrößen; zum Stand 17.08.2026 liegt keine Größe außerhalb der Ein-Prozent-Toleranz, die Wärmepumpenfälle sind als Teilabnahme geführt. Ein Prüfbericht dokumentiert das Ergebnis mit den SHA-256-Prüfsummen der sechs Kerne, und acht Testgebäude mit eingefrorenen Sollwerten sichern die Ergebnisse gegen Regressionen. Die Rechtsstandsführung ist als Registry mit umschaltbarem Stand umgesetzt; die zwölf Umstellungsbausteine der Migration sind abgeschlossen, jeder Ergebniswert trägt einen Rechtsstandsstempel, hartcodierte Faktoren wurden entfernt, und der Wechsel der Bezugsfläche ist ausdrücklich nicht als Umrechnung, sondern als Wechsel auf eine andere Größe behandelt. Auf der Ausgabeseite erzeugt eine Dokumentenmaschine sieben Dokumenttypen — vom Bedarfsausweis über Wärmeschutznachweis und Heizlastbericht bis zum Finanzierungsbericht — je mit Hash-Merker, sodass eine Neuerzeugung nur bei geänderter Datengrundlage erfolgt; die Ausweiskachel warnt, wenn die Endenergie des abgelegten Dokuments von den aktuellen Daten abweicht.

Die Differenzart ist Vorsprung. Das Whitepaper beschreibt an dieser Stelle einen Grundsatz, die Software liefert einen geprüften und mit Prüfsummen belegten Nachweisapparat. Dieser Vorsprung ist der wichtigste Einzelbefund des Kapitels, weil er die Beweislast umkehrt: Für den Rechen- und Nachweiskern muss nicht plausibel gemacht werden, dass er funktionieren könnte, sondern es liegt ein datierter Prüfstand vor, den ein Dritter nachvollziehen kann.

Die verbleibenden Differenzen dieses Feldes sind überwiegend nicht in eigener Hand. Die Referenzgebäude-Kennwerte und die Klassengrenzen zwischen den Randklassen für Nichtwohngebäude sind in der Registry als Lücke geführt; die Klassenfunktion gibt zwischen der besten und der schlechtesten Klasse bewusst keinen Wert zurück, statt eine plausible Zahl zu erfinden. Die Vollabnahme der Wärmepumpenfälle scheitert am fehlenden Stundenverfahren, für das die erforderlichen Jahresstundenwerte nicht vorliegen. Die Ausweisnummer ist eine deterministisch aus der Gebäudekennung abgeleitete interne Kennung und ausdrücklich keine amtliche Registriernummer; Ausweisarten und Gültigkeitsdauer sind offen. Hinzu kommt eine Abweichung, die in eigener Hand liegt: Der Ausweis arbeitet mit der bisherigen deutschen Klassenlogik, während Artikel 19 Absatz 2 EPBD seit dem 29.05.2026 eine geschlossene Skala von A bis G verlangt, bei der die Bestklasse dem Nullemissionsgebäude vorbehalten ist.

19.6 Rollen, Rechte und Datenzugang

Das Zielbild ist an dieser Stelle besonders ausführlich. Kapitel 9 entwirft acht fachliche Rollen vom Eigentümer über Energieberater, Architekt, Fachplaner, Hausverwaltung, Bank und Makler bis zur Behörde, dazu sechs abgestufte Rechte von Lesen über Hochladen, Bearbeiten, Prüfen und Freigeben bis Löschen, ferner Rechte auf Datenfeldebene nach dem Prinzip der geringsten Berechtigung sowie einen siebenstufigen Zugriffspfad von der Öffentlichkeit bis zum Eigentümer. Kapitel 10 und 11 setzen darauf auf und beschreiben empfängerbezogene Freigabepakete mit Befristung, Zweckbindung und Widerruf.

Der belegte Stand ist ein anderer. Vorhanden sind die Anzeigerollen der Kennwertseite — alle Werte, Architekt, Makler, Hausverwaltung, Fachplaner, Bank, Energieberater —, die die Reihenfolge der Gruppen und die Hervorhebung einzelner Werte steuern. Die Entwicklungsdokumentation bezeichnet sie ausdrücklich als Priorisierung der Darstellung und ausdrücklich nicht als Rechteschicht. Das abgestufte Zugriffsmodell mit den sieben Stufen war in der Entwicklungsdokumentation wörtlich als noch nicht existierend geführt; es ist am 23. August 2026 gebaut worden, und die Rollen- und Rechteschicht ist damit vom offenen Punkt des Pflichtenhefts zum umgesetzten Bestandteil geworden. Vorhanden ist ferner ein Schreibrollenmodell, das die Werkzeuge in Quelle, Ermittler, Rechner und Ausgabe einteilt — der Gebäudesteckbrief als einzige Quelle der Stammdaten, Grundriss- und Geschosseditor sowie Import als Ermittler, die Fachrechner mit Schreibzugriff ausschließlich auf den Ergebnisbereich, Berichte und Pass ohne jeden Schreibzugriff. Es ist definiert und seit dem 23. August 2026 erzwungen: Von den 55 Verstößen in 15 Werkzeugen, gezählt bei 1.258 literalen Schreibzugriffen, sind keine mehr offen — eine Untergrenze, weil 58 Aufrufe mit dynamisch gebildetem Pfad nicht erfasst werden konnten.

Für den Zugang nach außen existiert dagegen ein funktionierender Teilmechanismus. Eine Veröffentlichung erzeugt aus dem Projekt eine bereinigte Momentaufnahme ohne personenbezogene Daten, legt sie unter der Gebäudekennung ab und vergibt eine vierstellige PIN; drei Fehlversuche lösen gestaffelte Sperrzeiten von einer Minute bis zu einer Stunde aus. Ergänzt wird das durch einen QR-Ausdruck ohne PIN, ein Kartenprodukt und einen schreibgeschützten Demonstrationspass.

Die Differenzart ist Lücke, überlagert von einer Abweichung im Begriff. Die Abweichung ist die gefährlichere der beiden, weil dasselbe Wort auf beiden Seiten steht: Wer im Whitepaper „Rollen" liest und in der Software „Rollen" sieht, kann zu dem Schluss kommen, die Rechteschicht sei vorhanden. Sie ist es nicht — die vorhandenen Rollen steuern, was zuerst angezeigt wird, nicht, wer was sehen oder ändern darf. Die Lücke liegt vollständig in eigener Hand; keine externe Spezifikation blockiert sie. Sie ist zugleich die Bedingung dafür, dass die in Abschnitt 19.4 beschriebene Governance-Schicht ihre Wirkung entfaltet, denn ein Vier-Augen-Prinzip ohne Rechtedurchsetzung ist eine Verabredung und keine Kontrolle. Auch das Bedienkonzept gehört hierher: Es ist als verbindliche Vorgabe formuliert und beschreibt einen Assistentenmodus mit fünf Zuständen je Angabe und empfängerbezogenen Freigabepaketen — die Dokumentation hält ausdrücklich fest, dass das heutige Werkzeug die Fach- und Betreiberansicht ist und dieser Modus noch nicht existiert.

19.7 Schnittstellen, Formate und Register

Kapitel 8 beschreibt eine Zielarchitektur mit Schichtentrennung, versionierten Programmierschnittstellen mit gestuften Zugriffsebenen und Ereignisbenachrichtigung, maschinenlesbaren Formaten, Exportprofilen für Behörden, Banken und Fachplaner, einer Anbindung an Ausweisregister und nationale Gebäudedatenbanken sowie einer Verbindung zum europäischen Beobachtungssystem. Die Richtlinie liefert dazu die harten Vorgaben: Der Energieausweis muss digital und maschinenlesbar sein, ein gescanntes PDF genügt ausdrücklich nicht; Artikel 20 Absatz 8 EPBD verlangt die Übergabe des vollständigen Ausweises einschließlich aller Berechnungseingangsdaten; Artikel 22 EPBD regelt Datenbank, Zugriffsstufen und Formate; der Transfer an das Beobachtungssystem folgt den Vorlagen der Durchführungsverordnung (EU) 2025/1328.

Real vorhanden ist ein breiter, aber nach innen gerichteter Bestand. Das Projektformat ist JSON mit Export und Import; Grundrissdaten gelangen über JSON und XML in das System; die Plan- und Dokumentenanalyse läuft über eine einzige Ablagezone, in der Grundriss, Wärmeschutznachweis und Energieausweis abgelegt werden und die Erkennung selbst bestimmt, welcher Dokumenttyp vorliegt. Kostendaten kommen über eine eigene Importschnittstelle, und ein Zertifikatsexport trägt die Pflichtangaben des künftigen Ausweisrechts maschinenlesbar. Für den Pass existieren Artefakte in XML und IFC, deren Erzeugung ein Prüflauf überwacht. Ausgabeformate sind PDF, CSV, ZIP sowie ein Kartenprodukt; Routen für digitale Brieftaschen sind angelegt, die Zertifikate stehen aus.

Die Differenzart ist Lücke, und sie zerfällt sauber in zwei Hälften. In eigener Hand liegt die Dienstschnittstelle: Die im Pflichtenheft vorgesehene Service-Programmierschnittstelle ist als offen geführt, ebenso die Trennung in eigene Endpunkte für Rechner, Agenten und Prüfsystem, ebenso das geschlossene Modul für die Ausgabeformate der Fachpraxis und der Ein-Klick-Import als Kombination aus Schnittstelle und Bedienoberfläche. Bezeichnend ist der IFC-Weg, der ausdrücklich als Eingang ohne Ausgang gekennzeichnet ist: Ein Modell kann hinein, aber nicht heraus — der Pass ist an dieser Stelle eine Senke, während das Zielbild einen Austausch beschreibt. Extern blockiert ist dagegen alles, was ein Register voraussetzt. Deutschland führt nach dem Anhang 5 der Kommissions-Leitlinien bislang keine nationale Ausweisdatenbank, das Schema nach Artikel 22 EPBD existiert zum Quellenstand nicht, das Kontrolldateischema für monatliche Verbrauchswerte ist offen, und die Durchführungsakte zur Interoperabilität des Datenzugriffs nach Artikel 16 Absatz 5 EPBD sind trotz einer am 31.12.2025 abgelaufenen Frist nicht veröffentlicht. Registrierung, Upload und Weitergabe an das Beobachtungssystem haben damit derzeit kein Ziel.

Für das Whitepaper folgt daraus eine Formulierungspflicht. Kapitel 8 liest sich an einigen Stellen wie die Beschreibung einer vorhandenen Dienstschicht; belegt ist eine anwendungsinterne Endpunktmenge für Projekte, Veröffentlichung und Datenübergabe. Der Unterschied ist erheblich, denn eine Berechnung, deren Ergebnis nur auf dem Bildschirm erscheint, erfüllt keine Registerpflicht.

19.8 Renovierungspass, Förderung und Wirtschaftlichkeit

Das Zielbild beschreibt den Renovierungspass als eigenen Baustein der Plattform: eine grafische Roadmap vom Ist- zum Zielzustand, je Schritt die fünf Pflichtangaben nach Anhang VIII Nummer 1 Buchstabe e EPBD — Bezeichnung mit Technologieoptionen, Änderung von Primär- und Endenergie gegenüber dem Zustand vor dem Schritt, Änderung der betriebsbedingten Treibhausgase, Einsparung in Euro mit offengelegten Preisannahmen und die Zielklasse nach dem Schritt —, dazu die nationale Stichtagsliste, die Begründung der Schrittfolge, Fördermittel mit Verweisen und die Kontaktdaten der Anlaufstellen. Daneben stehen ein Fördermittelmodul und eine Wirtschaftlichkeitsrechnung.

Der belegte Stand teilt sich deutlich. Für die Wirtschaftlichkeits- und Förderseite liegt ein umfangreicher, produktiver Bestand vor: ein achtschrittiger Leistbarkeitsassistent mit Ampelbewertung, vier Varianten und getrennten Tilgungsplänen für Bank- und Förderdarlehen samt Übergabe an eine Finanzierungsidee, Baukostenrechner für Neubau und Sanierung mit einer eigenen Spalte für Sowieso-Anteile, eine Marktwertermittlung, ein Zinsrechner und eine gepflegte Fördermatrix; auch die Förderregeln selbst sind präzise abgebildet, etwa die Unterscheidung zwischen Honorarzuschüssen und Höchstkostengrenzen. Für die Passseite dagegen existieren Sanierungsmaßnahmen, ein Maßnahmenbericht und ein Datenblatt zum Sanierungsfahrplan als reine Ausgabe; das Feldmodell des Anhangs VIII ist nicht umgesetzt, Sanierungsvarianten und Zielzustände stehen in der offenen Entwicklungsphase.

Die Differenzart ist Lücke mit einem ausgeprägten Vorsprung auf der Finanzierungsseite. Die Lücke liegt in eigener Hand, ist aber anspruchsvoller, als sie wirkt: Anhang VIII verlangt die Änderungen jeweils gegenüber dem Zustand vor dem betreffenden Schritt und nicht gegenüber dem Ausgangszustand. Das setzt einen versionierten Zwischenzustand des Gebäudes voraus — jeder Schritt erzeugt ein neues Gebäude, gegen das der folgende Schritt gerechnet wird. Diese Zustandsführung ist die eigentliche Aufgabe; die Darstellung ist der kleinere Teil. Der Vorsprung wiederum ist im Whitepaper unterbelichtet: Varianten, Tilgungspläne und die Sowieso-Systematik sind fachlich weiter, als das Zielbild verlangt, und die dort geforderte Offenlegung der Preisannahmen ist damit erreichbar.

Zwei Vorbehalte gehören dazu. Erstens ist der Leistbarkeitsassistent ohne Anbindung an den Projektspeicher geführt — er rechnet, aber nicht auf dem Gebäudedatensatz, was ihn vom kanonischen Modell abkoppelt und die Sowieso-Anteile in keinem Projekt erfasst lässt. Zweitens entsteht ein förderfähiger individueller Sanierungsfahrplan ausschließlich in der amtlichen Druckapplikation der Fördermittelstelle; das eigene Ausgabeformat trägt den Vermerk, kein amtliches Importformat zu sein, und ein maschinelles Importformat veröffentlicht die amtliche Anwendung nicht. Ob Deutschland den Sanierungsfahrplan förmlich zum Renovierungspass im Sinne des Artikels 12 EPBD erklärt, ist nicht entschieden; die Kommissions-Leitlinien führen ihn zweimal als Vorbild, was ihn nicht zum Renovierungspass macht. Dieser Teil der Differenz liegt nicht in eigener Hand.

19.9 Lebenszyklus, Emissionen und Betriebsdaten

Das Zielbild beschreibt eine Lebenszyklusbilanz nach Anhang III EPBD in der Fassung der Delegierten Verordnung (EU) 2026/52: Systemgrenzen nach EN 15978, Bezugszeitraum 50 Jahre, Ausweisung in Kilogramm Kohlendioxidäquivalent je Quadratmeter Nutzfläche und Ausweisung je Phasengruppe. Daneben stehen Betriebsdaten mit Zeitreihen, Zählerimport und Soll-Ist-Vergleich sowie die Zirkularität der Bauprodukte, die Anhang VIII Nummer 1 Buchstabe h EPBD für den Renovierungspass anspricht.

Der belegte Stand ist an dieser Stelle am dünnsten und zugleich am diszipliniertesten dokumentiert. Der Pass führt drei getrennte Emissionskarten — die Angabe aus dem Ausweis, eine automatisch gebildete Betriebsbilanz und die Ökobilanz —, bildet daraus ausdrücklich keinen zusammengeführten Gesamtwert und sichert diese Trennung durch einen eigenen Prüffall ab. Das Ökobilanzwerkzeug rechnet für Nichtwohngebäude den projektspezifischen Anforderungswert gegen eine amtlich verifizierte Wertetabelle, und die Kachel ist im Pass aktiv. Die graue Emission dagegen ist bislang ein geschätzter Pauschalwert je Quadratmeter; die Rechnung aus Bauteilflächen, Materialmengen und Umweltproduktdeklarationen ist ebenso offen wie die getrennte Bilanzlogik für Neubau und Sanierung. Auf der Betriebsseite existiert eine Verbrauchshistorie mit Auswertung sowie ein Umschalter zwischen dem bisherigen Dreijahresverfahren und der monatlichen Erfassung über 24 Monate, die das neue Ausweisrecht verlangt; Zeitreihenhaltung, Zählerimport und der Abgleich gegen die Bilanz fehlen, gemessener Verbrauch und tatsächliche Photovoltaikerträge gehen nicht in die Emissionsrechnung ein. Für die Zirkularität ist weder ein Datenfeld noch eine Rechenvorschrift belegt.

Die Differenzart ist Lücke, und sie liegt weit überwiegend in eigener Hand. Die Voraussetzung ist in beiden Fällen dieselbe und liegt nicht in der Rechenvorschrift, sondern im Datenmodell: eine Mengenaufstellung der Bauprodukte für die Ökobilanz und eine Zeitreihenstruktur für die Betriebsdaten. Beides fehlt, und ohne beides bleibt jede weitere Rechenlogik ohne Eingangsdaten. Ein Vorsprung ist gleichwohl zu verzeichnen, und er betrifft eine Haltung: Die Software führt drei Emissionsbilanzen bewusst getrennt, weil sie unterschiedliche Fragen beantworten, und verweigert die Summenbildung, die ein Leser erwarten würde. Das Zielbild spricht demgegenüber von einer Emissionsbilanz im Singular — an dieser Stelle ist die Beschreibung ungenauer als das Programm, und die Beschreibung sollte der Software folgen und nicht umgekehrt.

Ein Terminhinweis gehört dazu, ohne ihn zu dramatisieren. Die Nachweispflicht für das Treibhauspotenzial beginnt am 01.01.2028 für Neubauten über 1 000 Quadratmeter und gilt ab 01.01.2030 für alle Neubauten; für den Bestand besteht keine Pflicht, mit der einzigen Ausnahme einer Sanierung auf die freiwillige Spitzenklasse. Der Zeitdruck ist damit real, aber auf ein abgegrenztes Segment beschränkt. Die Betriebsdatenlage zeigt daneben eine mittelbare Folge: Die Bewertungssäule Wartungszustand liefert null Punkte, solange Wartungsdokumente nicht mit dem Datensatz verknüpft sind — kein Fehler der Bewertungslogik, sondern eine Folge des fehlenden Anlagenereignisses mit Datum, Ergebnis, Prüfer und Belegverweis.

19.10 Qualitätssicherung und Betrieb

Das Zielbild behandelt Qualitätssicherung an mehreren Stellen als Grundsatz: Prüf- und Freigabeprozesse als eigener Baustein, Protokollierung und Revisionssicherheit als Teil der Datenschutzarchitektur, eine Berechnungsmomentaufnahme mit Zeitstempel als Voraussetzung der Nachvollziehbarkeit und eine laufende Regelwerksbeobachtung als Querschnittsaufgabe.

Der belegte Stand ist hier am weitesten von der Beschreibung entfernt — nach oben. Ein Funktionswächter prüft täglich einen von 116 auf 499 Prüfungen gewachsenen Bestand statisch, über HTTP und im kopflosen Browser; zum Sollstand 17.08.2026 sind 493 von 495 Prüfungen grün, und die beiden roten sind als bekannte Datenbefunde in Live-Projekten und ausdrücklich nicht als Regression eingeordnet. Die Läufe werden archiviert, ein Schnelltest läuft nach jedem Serverstart, und die Ergebnisse gehen als eigene Kennzahl in die Bewertung ein. Daneben steht ein Datenabgleich mit sechs Regeln, der prüft, ob die Daten in sich stimmen, während der Wächter den Code prüft; die vier doppelt geführten Merkmale Bauweise, Keller, Firstrichtung und Geschosszahl prüft der Steckbrief gegen die jeweils andere Quelle — überschrieben wird dabei nichts automatisch. Für das Regelwerk existiert ein eigener Beobachtungsdienst, der täglich 18 amtliche Quellen auswertet, seit dem 12.08.2026 nicht mehr am Seitentext, sondern an einem fachlichen Fingerabdruck Alarm schlägt, Vorlaufwarnungen von 180 Tagen bis zu einem Tag ausgibt und Veröffentlichungs-, Inkrafttretens-, Anwendungs- und Produktivdatum getrennt führt; seine Arbeitsregel lautet, dass die Erkennung vorschlägt und der Mensch entscheidet. Hinzu kommen ein Agentenmodell mit 31 Agenten in zehn Kategorien und automatische Sicherungskopien der letzten zwanzig Projektstände.

Die Differenzart ist Vorsprung. Die Lücken dieses Feldes sind überschaubar und liegen sämtlich in eigener Hand: Der Datenabgleich ist auf 24 bislang ungeprüfte Werkzeuge auszuweiten, eine Auswertungsoberfläche für die Wächterläufe fehlt, der formalisierte Prüfpfad mit Berechnungsmomentaufnahme und Signatur ist offen, und fünf Felder des Prüfberichts tragen noch Platzhalter, darunter Empfänger und Unterschrift. Ein Betriebsbefund ist ausdrücklich zu nennen: Das Öffnen des Gebäudepasses stößt den automatischen Dokumentenlauf an, der ohne Nutzeraktion PDF-Dokumente erzeugt und ablegt. Das widerspricht dem Grundsatz, dass Dokumente Ausgaben eines bewussten Vorgangs sind, und es gehört in die Bestandsaufnahme, weil eine Plattform, die ungefragt Nachweisdokumente erzeugt, ihre eigene Freigabelogik unterläuft.

19.11 Die Gesamtdifferenz

Die folgende Tabelle fasst die acht Themenfelder zusammen. Sie nennt in verkürzter Form das Zielbild des Whitepapers, den dokumentierten Umsetzungsstand, die dominierende Differenzart nach dem Maßstab aus Abschnitt 19.2 und die Frage, ob die Schließung der Differenz von eigener Entwicklungsleistung abhängt.

Die Verteilung über die acht Felder ist ungleich, und gerade darin liegt die Auskunft. In einem Feld — dem Datenmodell — decken sich Beschreibung und Programm. In einem weiteren liegt eine Abweichung vor, die zugunsten der Software ausfällt: Das Qualitätsmodell des umgesetzten Systems ist tragfähiger als die Modellskizze, weil es Herkunft und Absicherung als zwei Achsen führt statt sie in einer Skala zu vermischen. In zwei Feldern — Rechenkerne und Qualitätssicherung — ist die Software erheblich weiter als ihre Beschreibung. In den verbleibenden vier Feldern besteht eine Lücke. Die Hälfte der Themenfelder trägt damit einen Rückstand, die andere Hälfte Deckung, Abweichung oder Vorsprung.

Diese Halbierung deckt sich mit dem Bild der Anforderungsmatrix in Kapitel 12 und der Reifegradanalyse in Kapitel 13, erklärt es aber genauer. Beide zeigen eine Plattform, deren Rechen- und Nachweiskern ausgereift und deren Anschlussschichten jung sind. Der Abgleich zeigt zusätzlich, warum: Die vier Felder mit Lücke sind genau jene, in denen der Gebäudepass mit etwas außerhalb seiner selbst umgehen muss — mit einem Empfänger, der Rechte braucht, mit einem Register, das ein Format vorgibt, mit einem Sanierungsschritt, dessen Zwischenzustand vorzuhalten ist, und mit Mengen und Messwerten aus fremden Quellen. Die vier Felder ohne Lücke sind jene, in denen die Plattform mit sich selbst umgeht. Das ist keine Nachlässigkeit, sondern die Entstehungsgeschichte einer Fachsoftware, die aus Nachweiswerkzeugen für die Energieberatung gewachsen ist.

Ebenso aufschlussreich ist die letzte Spalte. Von den vier Feldern mit dominierender Lücke liegen zwei vollständig in eigener Hand — Rollen und Rechte sowie, mit Ausnahme der Grenzwertsetzung, Lebenszyklus und Betriebsdaten. Zwei Felder sind geteilt: Bei den Schnittstellen ist die Dienstschicht eigene Arbeit und die Registeranbindung fremde Festlegung, beim Renovierungspass ist das Feldmodell eigene Arbeit und der Rechtsstatus des deutschen Sanierungsfahrplans fremde Entscheidung. Auch die beiden Vorsprungsfelder tragen extern abhängige Restlücken, und zwar die härtesten des ganzen Dokuments: Ohne veröffentlichte Klassengrenzen für Nichtwohngebäude und ohne Referenzgebäude-Kennwerte des neuen Rechtsstands bleibt ein geprüfter Rechenkern an einer Stelle stumm, an der er rechnen könnte. Dass er dort keinen Wert liefert statt eines plausiblen, erscheint in der Tabelle als Blockade und ist in der Sache die richtige Entscheidung.

19.12 Was daraus folgt

Aus dem Abgleich folgen vier Feststellungen. Sie richten sich zuerst an das Dokument selbst, denn ein Whitepaper, das einen Umsetzungsstand behauptet, den es nicht belegen kann, beschädigt genau die Vertrauenswürdigkeit, die sein Gegenstand herstellen soll.

Erstens: was das Whitepaper an keiner Stelle behaupten darf. Der digitale Gebäudepass ist nicht EPBD-zertifiziert, nicht amtlich EPBD-konform und nicht an ein Register angeschlossen. Er verfügt über keinen Renovierungspass im Sinne des Anhangs VIII, keine Lebenszyklusbilanz aus Materialmengen, keine amtliche Registriernummer, keine offene Dienstschnittstelle und keine digitale Signatur je Freigabe; seine Rollen- und Rechteschicht ist seit dem 23. August 2026 durchgesetzt, das Schreibrollenmodell der Werkzeuge dagegen weiterhin nicht; der von ihm erzeugte Sanierungsfahrplan ist ein Datenblatt und kein förderfähiges Dokument. Sätze, die eine dieser Eigenschaften unterstellen — auch in weicher Form wie „bereits angebunden" oder „vollständig maschinenlesbar" —, sind zu streichen oder in die Zukunftsform zu setzen. Tragfähig ist allein die Aussage, dass der Gebäudepass auf die Daten- und Prozessanforderungen der Richtlinie ausgerichtet ist, wesentliche Funktionen für ihre Umsetzung produktiv enthält und den verbleibenden Abstand zu jeder einzelnen Anforderung benennen kann.

Zweitens: welche drei Lücken zuerst zu schließen sind. Die Substanz des Zielbilds — ein Gebäudedatensatz, der geteilt, geprüft und weiterverwendet werden kann — hängt an drei Lücken, die alle drei in eigener Hand liegen. Die erste — die durchgesetzte Rollen- und Rechteschicht mit Rechten auf Feldebene, Befristung und Widerruf — ist am 23. August 2026 geschlossen worden; die Datensouveränität, die Artikel 16 EPBD den Eigentümern, Mietern und Verwaltern zuweist, ist damit im System abbildbar, und das Freigaberecht ist ein eigenes, vergebbares Recht statt einer Verabredung. Zwei Reste dieser Lücke bleiben und rücken damit selbst in die Reihe: das empfängerbezogene Freigabepaket, also die Auswahl genau jener Felder, die ein bestimmter Dritter erhalten soll, über die Rollenzuschnitte hinaus — und die vollständige Auflösung der Mehrfachschreiber im Inneren: Die 55 gezählten Verstöße sind zwar abgearbeitet und die Prüfung erzwingt die Ordnung, doch 35 Registerfelder werden weiterhin von mehreren Werkzeugen beschrieben. Die zweite ist das Feldmodell des Anhangs VIII samt versionierter Zwischenzustände; ohne sie erzeugt die Plattform Sanierungsvorschläge, aber keinen Renovierungspass, und die in Artikel 19 Absatz 6 EPBD angelegte Ersetzung der Modernisierungsempfehlungen bleibt unerreichbar. Die dritte ist das maschinenlesbare Übergabeprofil für die Rohdaten des Ausweises nach Artikel 20 Absatz 8 EPBD samt dokumentierter Dienstschnittstelle; sie ist die aufwandsärmste der drei, weil sämtliche verlangten Größen bereits im kanonischen Datensatz liegen, und zugleich die Bedingung dafür, dass die Registerbindung nach Vorliegen des deutschen Schemas eine Konfigurations- und keine Entwicklungsaufgabe ist. Die Lebenszyklusbilanz aus Mengen steht bewusst nicht in dieser Reihe: Sie hat den engsten Termin, betrifft aber nur Neubauten und dort erst ab 2028 die Gebäude über 1 000 Quadratmeter.

Drittens: welche Stärken das Whitepaper unterverkauft. Vier Bestände sind im Dokument schwächer beschrieben, als sie belegt sind. Der Rechen- und Nachweiskern ist gegen 34 fachliche Validierungsfälle mit 964 Einzelgrößen geprüft, mit Prüfbericht und Prüfsummen unterlegt und durch acht Testgebäude mit eingefrorenen Sollwerten gegen Regressionen gesichert — nachvollziehbar auch für Dritte. Die tägliche automatisierte Prüfung von 499 Bedingungen samt des davon getrennten Abgleichs der Daten gegen ihre eigenen Quellen ist im Zielbild nur als Grundsatz erwähnt. Die Herkunftskennzeichnung je Wert und je Kante zusammen mit den vier Datenzuständen ist die tragfähigere Konstruktion gegenüber der eigenen Modellskizze und sollte als solche beschrieben werden. Die vierte Stärke ist keine Funktion, sondern eine Haltung: Die Software erfindet keine Werte. Sie liefert zwischen den Randklassen für Nichtwohngebäude keine Klasse, hinterlegt keinen Preis, wo keiner feststeht, summiert die drei Emissionsbilanzen nicht, schreibt „Nachweis nicht geführt" statt einer Zahl und stellt fehlende Kennwerte als Strich dar. Diese Disziplin ist der Grund, warum die Zahlen dieses Dokuments belastbar sind, und sie verdient mehr Raum als jede Funktionsliste.

Viertens: welcher Teil der Differenz nicht in eigener Hand liegt. Ein nennenswerter Teil des Abstands zwischen Zielbild und Programm verschwindet durch keine Entwicklungsleistung. Es fehlen die Klassengrenzen für Nichtwohngebäude und die Referenzgebäude-Kennwerte des neuen Rechtsstands, das amtliche Ausweismuster und die Registriernummer, das Datenformat des Lebenszyklusberichts, das Kontrolldateischema für monatliche Verbrauchswerte und vor allem das deutsche Datenbankschema nach Artikel 22 EPBD — Deutschland führt nach dem Anhang 5 der Kommissions-Leitlinien bislang keine nationale Ausweisdatenbank. Auf europäischer Ebene fehlen die Durchführungsakte zur Interoperabilität des Datenzugriffs nach Artikel 16 Absatz 5 EPBD, deren Frist am 31.12.2025 abgelaufen ist, sowie der delegierte Rechtsakt zur Intelligenzfähigkeit bis zum 30.06.2027. Hinzu kommen die für das Stundenverfahren erforderlichen Jahresstundenwerte, die nicht vorliegen, und die ungeklärte Frage, ob der deutsche Sanierungsfahrplan förmlich zum Renovierungspass erklärt wird. Für alle diese Punkte gilt dieselbe Handlungsregel, und sie ist zugleich das praktische Ergebnis dieses Kapitels: vorbereiten, nicht ersetzen. Die betroffenen Felder werden angelegt und bleiben leer, Schwellenwerte werden als benannte Parameter mit Herkunftsangabe geführt statt als Konstanten verstreut, und jede Ausgabe nennt die verwendete Grundlage. Eine leere Stelle ist ehrlicher als eine plausible Zahl — und sie ist die einzige Form von Rückstand, die sich später in einem einzigen Arbeitsschritt auflösen lässt.

A Prüf- und Umsetzungskatalog

Dieser Anhang überführt die Aussagen des Hauptteils in einen prüfbaren Katalog. Jede Zeile beschreibt eine einzelne Anforderung an den digitalen Gebäudepass, das Kriterium, an dem sich ihre Erfüllung entscheiden lässt, die Art des Nachweises, die Rechts- oder Normgrundlage und den Umsetzungsstand mit Stand 22. August 2026. Der Katalog ist ein Arbeitsinstrument für die Entwicklung und für spätere externe Prüfungen, keine Konformitätserklärung.

A.1 Zweck des Katalogs und Anleitung zum Gebrauch

Der Hauptteil beschreibt Zielbild, Datenmodell, Funktionsarchitektur, regulatorische Einordnung und Roadmap des digitalen Gebäudepasses. Diese Beschreibung ist notwendig, aber nicht prüfbar: Ein Satz wie „der Pass führt jede Änderung historisch" lässt sich weder bestätigen noch widerlegen, solange nicht feststeht, woran man das erkennt. Der folgende Katalog schließt diese Lücke, indem er jede wesentliche Aussage in eine Zeile mit eindeutiger Kennung, einem Prüfkriterium und einem Nachweis überführt.

Damit beantwortet der Katalog für jede Funktion dieselben sechs Fragen: Ist die Anforderung fachlich definiert? Sind die dafür nötigen Daten im Modell vorhanden? Ist die Funktion technisch umgesetzt? Existiert ein Prüfverfahren, das die Umsetzung nachweist? Hängt die Umsetzung von einer externen Spezifikation ab? Und wenn etwas offen ist – warum? Die letzte Frage ist die wichtigste, denn eine intern nicht entwickelte und eine extern nicht spezifizierte Anforderung sind zwei völlig verschiedene Sachverhalte, die im selben Katalog nicht denselben Status tragen dürfen.

Für die Arbeit mit dem Katalog gelten sieben Regeln:

• Die Prüf-ID ist dauerhaft. Sie wird nie neu vergeben und nie umsortiert; entfällt eine Anforderung, bleibt die Zeile mit dem Vermerk „entfallen" stehen. Nur so bleiben ältere Prüfberichte lesbar.
• Über Erfüllung entscheidet das Prüfkriterium, nicht der Wortlaut der Anforderung. Wo das Kriterium unscharf ist, ist es zu schärfen, bevor der Status gesetzt wird.
• Die Nachweisart bestimmt, wer prüft und womit. Ein Status ohne zugehörigen Nachweis ist eine Behauptung und wird zurückgestuft.
• Steht in der Spalte Rechtsgrundlage „intern", verlangt weder die EPBD noch das deutsche Recht diese Funktion. Solche Zeilen sind bewusste Übererfüllung und dürfen bei knappen Entwicklungsressourcen nachrangig behandelt werden.
• Der Status stammt ausschließlich aus den fünf Werten der Tabelle A.2. Lässt sich ein Status nicht belegen, gilt der nächstniedrigere.
• Jeder Prüfpunkt erhält zusätzlich eine Prioritätsklasse nach Tabelle A.3. Vor jeder produktiven Freigabe müssen alle P0-Punkte bestanden sein.
• Der Katalog wird gemeinsam mit der Software versioniert. Ein Statuswert ohne Angabe der Softwareversion, mit der er festgestellt wurde, ist wertlos.

So gelesen dient der Katalog drei Adressaten zugleich: der eigenen Entwicklung als Arbeitsvorrat, einer externen Prüfstelle als Einstiegspunkt in die Nachweise und dem Leser des Whitepapers als Beleg dafür, welche der beschriebenen Eigenschaften bereits tragen und welche noch Absichtserklärung sind.

A.2 Aufbau einer Katalogzeile

Die Tabellen dieses Anhangs zeigen aus Platzgründen sechs Spalten. In der Arbeitsfassung – der Katalog wird als Datensatz geführt, nicht als Dokument – trägt jeder Prüfpunkt die in Tabelle A.1 genannten Felder. Erst die vier zusätzlichen Felder Verantwortlicher, Softwareversion, Prüfdatum und Ergebnis machen aus der Anforderungsliste einen revisionsfähigen Nachweis, weil sie jede Statusaussage an eine Person, einen Zeitpunkt und einen Softwarestand binden.

Für den Status werden bewusst nur fünf Werte zugelassen. Eine feinere Skala – etwa mit den Zwischenstufen „in Entwicklung" und „implementiert, ungetestet" – klingt genauer, führt in der Praxis aber dazu, dass Zeilen dauerhaft in einer Zwischenstufe hängen bleiben und der Katalog seine Aussagekraft verliert. Entscheidend ist die Trennung zwischen einer Lücke, die die Entwicklung selbst schließen kann, und einer Lücke, die auf eine fehlende externe Festlegung wartet.

Die Nachweisarten stammen ebenfalls aus einer geschlossenen Liste, damit der Katalog auswertbar bleibt: Schemaprüfung gegen das Datenmodell, Codeprüfung für Regeln, die sich nur im Quelltext zeigen, Wächter-Check als automatisierter Regressionstest, Validierungsfall für Rechenergebnisse nach DIN V 18599, Testgebäude für durchgerechnete Referenzfälle, Ausgabeprüfung für erzeugte Dokumente und Exporte, Protokollprüfung für Historien- und Zugriffsnachweise sowie organisatorischer Nachweis, wo kein technischer möglich ist. Die Reihenfolge ist zugleich eine Rangfolge: Ein Wächter-Check wiegt schwerer als eine Sichtprüfung, weil er bei jeder Änderung erneut läuft.

A.3 Priorisierung der Prüfpunkte

Nicht jeder Prüfpunkt wiegt gleich schwer. Ein fehlendes Feld für die Dachneigung einer Photovoltaikanlage ist ärgerlich; ein stilles Überschreiben eines freigegebenen Wertes gefährdet einen amtlichen Nachweis. Deshalb trägt jeder Prüfpunkt zusätzlich zum Status eine Prioritätsklasse, und diese Klasse steuert, was vor einer Freigabe geprüft werden muss und was warten kann.

Als P0 gelten insbesondere sechs Fehlerbilder: ein falsches Ergebnis der Bilanzierung nach DIN V 18599, der Verlust historischer Daten, eine fehlerhafte Übertragung an eine Registrierstelle, ein unberechtigter Zugriff auf Gebäude- oder Personendaten, die falsche Zuordnung eines Datensatzes zu einem Gebäude und das stille Überschreiben eines bereits freigegebenen Wertes. Die letzten beiden Punkte sind der Grund, warum das Datenmodell zwischen Melden und Freigeben trennt: Ein Vorschlag darf im Arbeitsbereich entstehen, aber nur eine Freigabe schreibt in den führenden Pfad.

A.4 Gebäudeidentität und Stammdaten

Alles andere hängt daran, dass ein Datensatz eindeutig einem Gebäude gehört. Artikel 22 EPBD verlangt für die nationalen Datenbanken eindeutige Gebäude- und Einheitenkennungen, die datenbankübergreifend tragen und mit Kataster und Grundbuch interoperabel sind. Der Gebäudepass vergibt dafür eine eigene, dauerhafte Kennung nach dem Muster DG-JJJJ-NNNNNNNN, die einmal erzeugt und danach nie wieder verändert wird; der öffentliche Pass arbeitet mit einer davon getrennten Referenz und einer PIN, damit die Gebäudekennung nicht zum Zugangsschlüssel wird.

Offen ist die Brücke nach außen: Ein Feld für amtliche Fremdkennungen und der Flurstücksbezug fehlen, und ein Passport-Identifikator im Sinne der Zielspezifikation ist beschrieben, aber nicht vergeben. Das ist kein Versäumnis, sondern eine Folge der Reihenfolge – die Zuordnung nach außen lohnt erst, wenn das nationale Schema nach Artikel 22 EPBD feststeht, das es für Deutschland zum Quellenstand nicht gibt.

Die Häufung von „teilweise" in dieser Gruppe hat einen gemeinsamen Grund: Die Gebäudeseite des Modells ist belastbar, die Einheiten- und Personenseite nicht. Solange eine Nutzungseinheit keine eigene Kennung trägt, lassen sich weder Wohnungseigentümer einzeln bedienen, wie es Artikel 12 EPBD für den Renovierungspass vorsieht, noch Eigentümerwechsel sauber protokollieren. Diese Zeilen sind deshalb als P1 zu führen, nicht als Komfortthema.

A.5 Flächen, Geometrie und Zonierung

Kein Thema erzeugt in der energetischen Bilanzierung so viele stille Fehler wie der Flächenbegriff. Wohnfläche, Nettoraumfläche, Bruttogrundfläche, Gebäudenutzfläche und die Bezugsfläche nach DIN 277 sind verschiedene Größen, und die Umstellung der Bezugsfläche im Zuge des GMoDG hat das noch verschärft: Die neue Bezugsfläche ist keine Umrechnung der alten, sondern eine andere Größe. Der Gebäudepass führt deshalb eine kanonische Bezugsfläche mit Quellenangabe und behandelt Wohnfläche, Bruttogrundfläche und ähnliche Angaben ausdrücklich als unzulässigen Ersatz; fehlt die kanonische Fläche, meldet die Bilanz eine Lücke, statt eine andere Fläche einzusetzen.

Für die Zonierung gilt dieselbe Regel in anderer Gestalt. Dieselbe Größe hieß im Datenmodell vier Mal verschieden, mit der Folge, dass die zonenweise Bilanz für Nichtwohngebäude in keinem Projekt griff. Erst die Festlegung eines kanonischen Feldes für das Nutzungsprofil hat diesen Fehler behoben – ein Beispiel dafür, warum der Katalog Benennungsregeln als prüfbare Anforderung führt und nicht als Stilfrage.

Der Befund dieser Gruppe ist zweigeteilt. Die Flächenseite ist der am besten abgesicherte Teil des gesamten Katalogs, weil hier ein realer Fehler zu einer harten Regel geführt hat. Die Zonenseite trägt fachlich, ist aber überwiegend nur schemaseitig belegt: Die Zuordnungen existieren, der automatisierte Nachweis, dass sie in allen Kombinationen rechnen, fehlt. Genau das ist der Unterschied zwischen „teilweise" und „erfüllt" in Tabelle A.2.

A.6 Gebäudehülle und Fenster

Die Hülle ist der Teil des Modells, an dem sich die Historisierungsregel bewährt. Ein Bauteil trägt nicht einen U-Wert, sondern mehrere: den ursprünglichen, den heutigen und – bei geplanter Sanierung – den künftigen. Wird gedämmt, ersetzt der neue Wert den alten nicht, sondern tritt neben ihn; die Heizlastrechnung liest seit dem 10. August 2026 zuerst den Ist-Wert und legt damit den sanierten Zustand aus, während ältere Nachweise weiterhin auf den Werten stehen, mit denen sie gerechnet wurden.

Belastbar sind Geometrie, Orientierung, U-Werte und ihre Herkunft; die Berichtserzeugung setzt ausdrücklich keine U-Werte an, für die kein Nachweis vorliegt, und weist fehlende Sommerschutznachweise als nicht geführt aus statt sie zu schätzen. Schwächer ist die Materialebene: Schichtaufbau, Dämmstoff und Sanierungsjahr sind entweder nur rudimentär vorhanden oder offen. Das ist zugleich die größte Einzelhürde für die Lebenszyklusbetrachtung nach Abschnitt A.11, denn ohne Materialmengen gibt es keine belastbare Bilanz nach EN 15978.

Die Zeile GP-FEN-010 zeigt exemplarisch, was der Katalog leisten soll: Sie ist technisch belegt, weil die Freigabe eines einzelnen Fensterwerts nachweislich dreizehn abhängige Aufgaben auslöst. Ohne diese Wirkkette wäre die gemeinsame Datenhaltung eine Behauptung; mit ihr ist sie prüfbar. Die offenen Zeilen dieser Gruppe – Rahmenkennwert, Einbaujahr, Materialebene – sind sämtlich P2, mit einer Ausnahme: GP-HUE-011 ist P1, weil daran die gesamte Lebenszyklusbetrachtung hängt.

A.7 Anlagentechnik und erneuerbare Energien

Die Anlagentechnik ist der Bereich mit der größten Spannweite zwischen tragfähigem Kern und offenen Rändern. Die Rechenkette von der Erzeugung über Speicherung, Verteilung und Übergabe bis zur Lüftung ist nach DIN V 18599 Teil 5 und Teil 8 aufgebaut und durch Validierungsfälle abgesichert; die Auslegung des Erzeugers aus Heizlast, Trinkwarmwasser und Sonderlasten wird als eigenes Ergebnis persistiert. Der Jahresarbeitszahl-Nachweis für Wärmepumpen folgt VDI 4650, und nur ein ausdrücklich als solcher gekennzeichneter Wert trägt den Nachweis – eine Herstellerangabe ohne Verfahrensbezug tut es nicht.

Schwächer ist die Produktebene. Hersteller, Gerätetyp und Baujahr sind speicherbar, aber in den erzeugten Nachweisen bislang teilweise als Platzhalter geführt; für Wärmepumpen fehlt das stundenbasierte Verfahren, weil die dafür nötigen Klimadatenreihen nicht vorliegen. Bei den erneuerbaren Energien ist die Bestandserfassung auf das reduziert, was die Bewertung braucht: dass eine Anlage vorhanden ist. Leistung, Ausrichtung, Neigung, Speichergröße und Eigenverbrauch fehlen oder sind unvollständig – und damit fehlt die Grundlage für zwei EPBD-Pflichtangaben, den Anteil erneuerbarer Energie vor Ort nach Anhang V und den Eigenverbrauchsanteil nach dem Renovierungspass-Anhang VIII.

Für die Priorisierung folgt daraus eine klare Reihenfolge: Zuerst die Felder, an denen EPBD-Pflichtangaben hängen – installierte Leistung, Eigenverbrauch, Anteil erneuerbarer Energie –, danach die Produktdaten, die vor allem der Nachvollziehbarkeit dienen. Die Zeilen GP-EE-002 und GP-EE-006 sind deshalb P1, GP-EE-003 und GP-EE-004 P2.

A.8 Berechnung nach DIN V 18599

Für die Bilanzierung gilt eine Regel, die der Katalog gleich mehrfach absichert: Norm- und Rechtsstand sind zwei verschiedene Größen und werden getrennt dokumentiert. Verbindlich gerechnet wird DIN V 18599:2018-09, weil diese Fassung die öffentlich-rechtliche Grundlage bildet. Die Technische Spezifikation DIN/TS 18599:2025-10 ist keine Grundlage nach GEG; Ergebnisse aus ihr sind Vergleichsrechnung und laufen als solche mit. Jede Ausgabe, die das System verlässt, benennt deshalb die gerechnete Normfassung – und ebenso den Rechtsstand, denn die Umstellung der Faktoren zum Anwendungsstichtag des GMoDG verändert Ergebnisse ohne jede Änderung am Gebäude.

Dieselbe Trennschärfe gilt für die Primärenergie- und Emissionsfaktoren: Weicht eine Normfassung von den Anlagen des GEG ab, hat für Energieausweise und öffentlich-rechtliche Nachweise der GEG-Wert Vorrang. Die früher an zwei Stellen fest im Code stehenden Stromfaktoren sind entfernt und durch eine Registrierung mit Rechtsstandsstempel ersetzt worden; jedes Ergebnis trägt seither, mit welchem Stand es entstanden ist.

Diese Gruppe ist der belastbarste Teil des Katalogs: 34 Validierungsfälle mit 964 geprüften Größen liegen vollständig innerhalb der Ein-Prozent-Toleranz, die Wärmepumpenfälle als Teilabnahme, und ein Prüfbericht dokumentiert die Prüfstände der Rechenkerne mit Prüfsummen. Die verbleibenden „teilweise" betreffen nicht die Richtigkeit der Ergebnisse, sondern ihre Historisierung: Eine Berechnung wird heute fortgeschrieben, nicht als unveränderlicher Stand abgelegt. Da an dieser Zeile die Nachvollziehbarkeit amtlicher Nachweise hängt, ist GP-18599-008 als P0 zu führen.

A.9 Energieausweis

Der Energieausweis ist die einzige Ausgabe des Gebäudepasses, für die die EPBD ausdrücklich Maschinenlesbarkeit verlangt: Artikel 19 fordert eine digitale, maschinenlesbare Form in CSV, JSON oder XML, ein gescanntes PDF genügt ausdrücklich nicht. Artikel 20 Absatz 8 geht weiter und verlangt den vollständigen Ausweis einschließlich aller Berechnungs-Eingangsdaten. Beides trifft den Gebäudepass an seiner Stärke, denn der Datenbestand ist ohnehin die Quelle, aus der das Dokument entsteht – und Artikel 19 Absatz 14 Buchstabe c erkennt genau diesen Weg an, indem er vereinfachte Aktualisierungen über einen digitalen Zwilling oder zertifizierte Werkzeuge zulässt.

Zwei Punkte begrenzen den heutigen Stand. Erstens erzeugt das System einen Ausweis mit einer intern deterministisch vergebenen Dokumentnummer; das ist kein Ersatz für eine amtliche Registriernummer, und der Katalog führt beide Felder deshalb getrennt. Zweitens ist die Klassenskala nicht in eigener Hand: Die EPBD schreibt ab dem 29. Mai 2026 eine geschlossene Skala A bis G vor, bei der A dem Nullemissionsgebäude vorbehalten bleibt – ein Gebäude mit Gaskessel, das rechnerisch A erreichte, wird auf B eingestuft. Für Nichtwohngebäude fehlen die deutschen Klassengrenzen; das System führt sie als Lücke und gibt zwischen der obersten und der untersten Klasse bewusst keinen Wert zurück, statt einen zu erfinden.

Die Auswertung dieser Gruppe ist unbequem und deshalb wichtig: Die Rechenseite trägt, die Dokumentseite nicht. Ausweisart, Gültigkeit, Aussteller und Registriernummer sind die vier Felder, die aus einem berechneten Ergebnis ein Dokument mit Rechtswirkung machen – drei davon sind intern nachzuholen, eines wartet auf eine externe Festlegung. Solange die Klassengrenzen für Nichtwohngebäude fehlen, ist jede Aussage über eine Klasse in diesem Segment eine Schätzung, und der Pass gibt konsequenterweise keine aus.

A.10 Renovierungspass

Der Renovierungspass nach Artikel 12 EPBD ist für Eigentümer freiwillig; verpflichtet ist der Mitgliedstaat, ein System bereitzustellen, und diese Frist ist am 29. Mai 2026 abgelaufen. Für den Gebäudepass ist er trotzdem das anspruchsvollste Modul, weil Anhang VIII je Maßnahmenschritt fünf Pflichtfelder verlangt: Beschreibung mit Technologieoptionen, Veränderung von Primär- und Endenergie in Kilowattstunden und Prozent, Veränderung der operativen Treibhausgase, Kostenersparnis mit offengelegten Energiepreisannahmen und die erreichte Ausweisklasse nach dem Schritt. Hinzu kommen die Begründung der Schrittfolge zur Vermeidung von Lock-in-Effekten und die Angabe nationaler Stichtage.

Der deutsche individuelle Sanierungsfahrplan ist in den Kommissions-Leitlinien zweimal als Best-Practice-Vorbild genannt, ist aber kein Renovierungspass im Sinne des Artikels 12: Nicht abgedeckt sind insbesondere die Veränderung der operativen Treibhausgase je Schritt, Zirkularität und Whole-Life-Carbon sowie die Stichtagsliste. Der Gebäudepass hält beide Instrumente deshalb begrifflich getrennt und kennzeichnet sein iSFP-Datenblatt ausdrücklich als Ausgabe ohne amtliche Importwirkung – ein förderfähiger Sanierungsfahrplan entsteht ausschließlich in der amtlichen Druckapplikation.

Die Statusverteilung dieser Gruppe entspricht der Realität: Der Renovierungspass ist im Gebäudepass als Modul angelegt und im Entwicklungsplan mit hoher Priorität geführt, aber er ist kein umgesetztes Produkt. Wichtig ist die Unterscheidung der Sperrgründe. Die Pflichtfelder aus Anhang VIII kann die Entwicklung selbst schließen; die Maschinenlesbarkeit ist ohnehin nur eine Empfehlung – Pflicht ist eine digitale und druckfähige Fassung –; allein der Upload in die nationale Datenbank hängt an einer Spezifikation, die es in Deutschland zum Quellenstand nicht gibt.

A.11 Lebenszyklus und Treibhauspotenzial

Artikel 7 EPBD und Anhang III in der Fassung der delegierten Verordnung (EU) 2026/52 geben den Rahmen eng vor: Systemgrenzen nach EN 15978, Bezugszeitraum 50 Jahre, Einheit Kilogramm CO₂-Äquivalent je Quadratmeter Nutzfläche, Bilanzstand as-built, Pflichtmodule A1 bis A5, B1 bis B4, B6, C1 bis C4 sowie D1 und D2, ausgewiesen je Phasengruppe. Die Pflicht greift ab dem 1. Januar 2028 für Neubauten über 1 000 Quadratmeter und ab dem 1. Januar 2030 für alle Neubauten; für den Bestand besteht keine Pflicht, mit einer Ausnahme – bei Sanierung auf die freiwillige Klasse A+ wird der Treibhauspotenzial-Ausweis verbindlich.

Der Gebäudepass rechnet heute die Betriebsseite und setzt für die grauen Emissionen einen ausgewiesenen Benchmark an; für Nichtwohngebäude ermittelt das Nachhaltigkeitsmodul projektspezifische Anforderungswerte gegen eine amtlich abgeglichene Wertetabelle. Was fehlt, ist die Materialbasis: ohne Mengengerüst aus Bauteilflächen und Schichtdicken, ohne zugeordnete Umweltproduktdeklarationen und ohne getrennte Bilanzlogik für Neubau und Sanierung entsteht keine Bilanz nach Anhang III, sondern eine Näherung. Der Katalog benennt das als Näherung, statt sie als Ergebnis zu führen.

Diese Gruppe ist die mit dem größten Abstand zwischen Anforderung und Umsetzung – und zugleich die mit dem klarsten Weg: Alle offenen Zeilen hängen an einer einzigen Vorleistung, dem schichtweisen Bauteilaufbau mit Materialangabe aus Abschnitt A.6. Wird GP-HUE-011 geschlossen, werden aus neun offenen Zeilen normale Entwicklungsaufgaben. Vor 2028 ist das keine Pflicht, aber es ist die Reihenfolge, die den Aufwand halbiert.

A.12 Verbrauchs- und Betriebsdaten

Mit dem GMoDG ändert sich die Datengrundlage des Verbrauchsausweises grundlegend: An die Stelle der drei Abrechnungsperioden tritt eine nach Energieträgern differenzierte, mindestens monatliche Erfassung über 24 Monate. Bis zum Anwendungsstichtag müssen beide Verfahren parallel bedienbar bleiben, und genau so ist der Verbrauchszweig ausgelegt – mit einem Umschalter zwischen beiden Erfassungsarten. Artikel 22 EPBD nimmt berechneten und gemessenen Verbrauch in die nationale Datenbank auf; Artikel 16 regelt den Zugang zu den statischen Gebäudedaten, während dynamische Daten vernetzter Produkte unter den Data Act fallen.

Die wichtigste Regel dieser Gruppe ist eine Trennungsregel: Messwerte dürfen Bedarfswerte nicht überschreiben und umgekehrt. Der Gebäudepass führt beide Zweige getrennt und sichert die Trennung durch einen eigenen Regressionstest ab – dieselbe Logik, mit der auch die drei Emissionsdarstellungen auseinandergehalten werden. Offen ist dagegen das Meldeformat für Monatswerte; solange die Kontrolldatei der Registrierstelle keine Monatszeilen kennt, bleibt die Übergabe im bisherigen Periodenformat, und die Zeile steht auf extern blockiert.

Der Verbrauchszweig ist damit fachlich vorbereitet, aber datenseitig dünn: Erfasst wird, was Anwender eintragen, nicht was Zähler liefern. Für den Soll-Ist-Vergleich, den Artikel 22 EPBD als Datenquelle vorsieht und den der Gebäudepass als Kernfunktion beschreibt, ist das die eigentliche Begrenzung – nicht die Rechenlogik, sondern die Datenzufuhr.

A.13 Dokumente und KI-gestützte Erfassung

Dokumente sind im Gebäudepass keine Anhänge, sondern Belege: Jeder Wert kann über eine Belegkante mit dem Dokument verbunden werden, aus dem er stammt. Diese Kante ist die technische Umsetzung der Anhang-VI-Anforderung, dass der Urheber jeder Hinzufügung und Änderung für die Behörden ermittelbar bleiben muss. Die Erfassung selbst läuft über eine gemeinsame Ablagezone: Grundriss, Wärmeschutznachweis und Energieausweis werden in dieselbe Zone gelegt, und die Erkennung entscheidet selbst, was sie vor sich hat.

Für die maschinelle Erkennung gilt der Leitsatz, dass die Software vorschlägt und der Mensch entscheidet. Er ist im Datenmodell verankert: Ein gemeldeter Wert entsteht im Arbeitsbereich und verändert den offiziellen Wert nicht; erst eine ausdrückliche Freigabe schreibt in den führenden Pfad. Damit ist die kritischste Anforderung dieser Gruppe – kein stilles Überschreiben freigegebener Daten – nicht nur beschrieben, sondern erzwungen. Eine Gegenprobe zeigt allerdings, dass die Regel für erzeugte Dokumente noch nicht durchgängig gilt: Das Öffnen des Passes stößt heute die automatische Dokumenterzeugung an, ohne dass ein Anwender dies angefordert hat. Der Katalog führt das als eigene, offene Zeile.

Der Befund ist ermutigend und unbequem zugleich. Die Regeln, die den Missbrauch maschineller Erfassung verhindern, sind umgesetzt und getestet – das Trennen von Vorschlag und Freigabe ist keine Absichtserklärung. Die Regeln, die die Protokollierung vollständig machen, sind es nicht: Ablehnung, Korrektur und Fehlerauswertung bleiben lückenhaft, und ohne sie lässt sich die Qualität der Erkennung nicht messen, sondern nur behaupten.

A.14 Datenqualität und Versionierung

Die Qualitätsseite des Datenmodells ist der Teil, der den Gebäudepass von einer Sammlung von Rechenergebnissen unterscheidet. Ihm liegt ein Satz verbindlicher Regeln zugrunde: Jede Information hat genau eine führende Quelle, einen Gültigkeitsstatus und eine nachvollziehbare Historie. Jeder Wert trägt Metadaten – Quelle, Methode, Erfasser, Datum, Prüfstatus, Version –, Konflikte zwischen Quellen werden erzeugt und nicht automatisch aufgelöst, und Drittsysteme liefern grundsätzlich nur Vorschläge. Produktiv umgesetzt sind Vertrauensstufen von unbekannt bis amtlich signiert, vier Datenzustände vom Entwurf bis zur Freigabe und eine Herkunftskennzeichnung an jedem Kennwert.

Der Datenqualitätsindex nutzt genau diese Metadaten und legt jeden Beitrag offen; er ist bewusst kein verdichteter Einzelwert ohne Herleitung. Eine Einschränkung ist zu benennen: Eine seiner Säulen liefert derzeit strukturell null, weil Dokumente und Wartungen noch nicht durchgängig verdrahtet sind, und die Kalibrierung an Echtprojekten steht aus. Der Katalog führt das als eigene Zeile, damit die Kennzahl nicht besser aussieht, als ihre Datengrundlage ist.