Digitale Identität im Gebäude

Der Identity Graph 

Physische Zutrittskontrollsysteme werden zunehmend zur maßgeblichen Quelle für Belegungsdaten. Besuchermanagement, Aufzugssteuerung, Parkraum und Gebäudeautomation konsolidieren sich um sie herum, während Sicherheitshersteller und Enterprise-Plattformen um die Kontrolle über das entstehende Identitätsmodell konkurrieren. Damit stellt sich eine zentrale Frage: Bleibt Zutrittskontrolle austauschbare Infrastruktur, oder wird sie zur Intelligenz, die den Mehrwert aus Identität und Präsenz abschöpft?

Für den einzelnen Bauherrn entscheidet sich diese Frage nicht im globalen Wettbewerb der Plattformanbieter, sondern in Leistungsphase 3 bis 5, in einem Leistungsverzeichnis, das jemand schreibt, der in diesem Moment meist nicht weiß, dass er gerade eine Architekturentscheidung für die nächsten zwanzig Jahre trifft.

Was hinter dem Begriff steckt

Der Begriff „Identity Graph" klingt nach Produkt. Er beschreibt keines. Gemeint ist die Summe der Antworten auf eine banale Frage: Wer darf wann wohin – und woher weiß das Gebäude davon?

In der Praxis ist das eine Kette. Am Anfang steht ein führendes System, das weiß, welche Personen zur Organisation gehören; in der Regel das Personalsystem. Es speist einen Verzeichnisdienst. Darüber liegt eine Berechtigungsverwaltung, die Rollen auf Zutrittsrechte abbildet. Diese wiederum versorgt das Zutrittskontrollsystem, und erst daran hängen die nachgelagerten Gewerke, von der Aufzugsdisposition bis zur Raumbuchung.

Diese Kette ist in Neubauprojekten planbar. In Bestandsliegenschaften ist sie fast nie durchgängig, und sie reißt mit bemerkenswerter Regelmäßigkeit an derselben Stelle: bei allen Personen ohne Personaldatensatz. Wartungspersonal, Reinigung, Bauleitung, Zeitarbeit, Lieferanten. Für sie existiert kein auslösendes Ereignis, das eine Berechtigung beendet – und damit auch kein Lebenszyklus. 

Für die Planung folgt daraus ein erster nüchterner Befund: Die Qualität einer Identitätsarchitektur bemisst sich nicht an der Leistungsfähigkeit des Zutrittssystems, sondern an der schwächsten Stelle dieser Kette.

Konvergenz auf dem Papier, Gewerkegrenzen auf der Baustelle

Die beschriebene Konsolidierung ist real. Aus Planersicht hat sie allerdings eine Eigenschaft, die in Architekturdiagrammen unsichtbar bleibt: Jedes der konvergierenden Systeme ist ein eigenes Los.

Besuchermanagement, Aufzugssteuerung, Parkraum, Raumbuchung, Gebäudeautomation, Videotechnik – dahinter stehen unterschiedliche Auftragnehmer, unterschiedliche Leistungsphasen, unterschiedliche Gewährleistungsfristen und häufig unterschiedliche Fachplaner. Was auf dem Bild als gemeinsame Identitätsebene erscheint, ist auf der Baustelle eine Reihe getrennter Vergaben mit Schnittstellen dazwischen.

Und Schnittstellen liegen zwischen den Losen. Damit liegen sie im Zweifel bei niemandem.

Das typische Beispiel ist die Aufzugsanbindung. Sie scheitert selten an der Technik – die Verfahren sind seit Jahren etabliert. Sie kann daran scheitern, dass die Anbindung in keinem Leistungsverzeichnis stand, weder im Aufzugs- noch im Sicherheitslos, und in der Inbetriebnahme als Nachtrag auftaucht, für den niemand ein Budget hat. 

Wer die Konvergenz will, muss sie beauftragen. Als eigene Leistung, mit benannter Verantwortung, Schnittstellenliste und Abnahmekriterien. Nicht als Nebenpflicht des größten Loses.

Die vier Festlegungen

Vier Fragen bestimmen die Identitätsarchitektur eines Gebäudes. Sie werden in jedem Projekt beantwortet – bewusst oder dadurch, dass das zuerst installierte Gewerk Fakten schafft.

• Welches System ist führend? Wo entsteht der Personenstamm, und in welche Richtung fließen Änderungen? Solange diese Frage offen ist, entstehen parallele Datenhaltungen, die auseinanderlaufen. Die Antwort muss nicht zwingend das Personalsystem lauten – aber sie muss lauten.
• Wem gehören die Daten? Zutrittsereignisse werden zur Grundlage von Belegungsauswertung, Flächenentscheidungen und Nachhaltigkeitsberichten. Damit wird relevant, in welchem Format sie exportierbar sind, ob die Historie mitgeht und ob der Export im Standardvertrag enthalten oder ein kostenpflichtiges Modul ist.
• Welche Schnittstellen sind zugesichert? „Verfügt über eine offene Schnittstelle" ist keine Anforderung, sondern eine Hoffnung. Relevant ist der konkrete Funktionsumfang, seine Dokumentation, die Verfügbarkeit ohne zusätzliche Lizenzstufe und die Frage, ob Dritte sie ohne Zustimmung des Herstellers nutzen dürfen.
• Wie sieht der Ausstieg aus? Was geschieht bei einem Herstellerwechsel mit Ausweisen, Berechtigungsstrukturen und Ereignishistorie? Wer die kryptografischen Schlüssel der Ausweismedien nicht besitzt, kann den Dienstleister praktisch nicht wechseln.

Vier Schichten, zehnfach unterschiedliche Lebensdauer

Der eigentliche Grund, warum diese Festlegungen so weit tragen, ist eine Asymmetrie, die in Marktbetrachtungen keinen Platz hat: Die Bestandteile einer Identitätsarchitektur altern völlig unterschiedlich schnell.

Türbeschläge, Verkabelung und bauliche Vorbereitung überdauern zwei bis drei Jahrzehnte. Leser und Controller liegen im mittleren Bereich. Die Software wird alle paar Jahre abgelöst. Vertragsverhältnisse bei abonnementbasierten Modellen sind kündbar, teils jährlich. 

Daraus folgt eine Beschaffungsregel, die sich lohnt, laut auszusprechen: Je kurzlebiger die Schicht, desto wichtiger ihre Austauschbarkeit. Bei der Verkabelung darf man sich festlegen. Bei der Software sollte man es nicht.

Genau hier verdient auch die Beobachtung eine planerische Einordnung, dass abonnementbasierte Betriebsmodelle sich ausbreiten. Sie verschieben Kosten von der Investition in den Betrieb, bündeln Updates und Fernwartung in eine kalkulierbare Rate und nehmen dem Betreiber Arbeit ab, für die er häufig kein Personal hat. Sie binden aber eine zwanzigjährige Hardwareinvestition an ein Vertragsverhältnis mit deutlich kürzerem Horizont. Das ist kein Argument dagegen. Es ist ein Argument dafür, den Fall einer Vertragsbeendigung im Beschaffungsvorgang durchzurechnen, statt ihn in die Zukunft zu verschieben.

Die Kehrseite, über die selten gesprochen wird

Je mehr Gewerke am Präsenzsignal der Zutrittskontrolle hängen, desto weniger ist deren Ausfall ein Sicherheitsvorfall. Er wird zum Betriebsausfall.

Solange das Zutrittssystem Türen öffnet, ist ein Ausfall unangenehm und organisatorisch beherrschbar. Sobald Beleuchtung, Raumkonditionierung, Aufzugsdisposition und Arbeitsplatzbuchung von ihm abhängen, verlässt es die Sicherheitsdomäne. Es wird zu einem betriebskritischen System – mit entsprechenden Anforderungen an Verfügbarkeit, Redundanz, Wartungsfenster und Rückfallbetrieb.

In der Konvergenzerzählung kommt diese Konsequenz praktisch nicht vor, und das ist bemerkenswert, weil sie für Betreiber die folgenreichste ist. Wer Systeme koppelt, erhöht nicht nur den Nutzen, sondern auch die Abhängigkeit von einer einzigen Komponente.

Die praktische Konsequenz ist unspektakulär und wird trotzdem selten gezogen: Den Rückfallbetrieb definieren, bevor man die Integration ausschreibt. Wie lange laufen die Türsteuerungen autonom weiter? Was passiert mit den gekoppelten Gewerken? Und wer merkt den Ausfall zuerst – die Sicherheitsorganisation oder der Nutzer im dunklen Großraumbüro? 

Am Zeichentisch, nicht im Markt

Ob Zutrittskontrolle Infrastruktur bleibt oder zur Intelligenz wird, ist für die Branche insgesamt eine offene Frage. Für das einzelne Gebäude ist sie es nicht. Dort wird sie beantwortet, wenn festgelegt wird, welches System den Personenstamm hält, wem die Daten gehören, welche Schnittstellen vertraglich zugesichert sind und wie ein Ausstieg aussieht.

Diese Entscheidungen fallen früh, sie fallen leise, und sie fallen auch dann, wenn niemand sie trifft. Der Unterschied zwischen einem Gebäude mit Identitätsarchitektur und einem mit gewachsenem Zutrittssystem liegt nicht in der Produktauswahl. Er liegt darin, ob jemand die vier Fragen gestellt hat, solange sie noch offen waren.

Für Deutschland gilt: Mitbestimmung ist ein Termin, kein Nachgang

Sobald Zutrittsdaten für Belegungsauswertungen, Flächenentscheidungen oder Anwesenheitsmuster genutzt werden, handelt es sich um technische Einrichtungen, die zur Überwachung von Verhalten oder Leistung geeignet sind. Die Einführung ist damit nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig – unabhängig davon, ob eine Überwachung beabsichtigt ist. Die Eignung genügt.

Für die Projektplanung heißt das: Die Verhandlung einer Betriebsvereinbarung gehört in den Terminplan, mit realistischer Dauer und vor der Inbetriebnahme. Projekte, die diesen Schritt in die Abnahmephase verschieben, verlieren dort regelmäßig Monate – und in ungünstigen Fällen Funktionen, die technisch längst bezahlt sind.