Sicherheitsroboter im Flughafen-Vorfeld: LuftSiG, EASA und reale Einsatzgrenzen

Ein Sicherheitsroboter auf dem Vorfeld eines deutschen Verkehrsflughafens ist juristisch zunächst nichts anderes als eine bewegliche Hilfseinrichtung des Flughafenbetreibers. Er hat keine eigene Befugnis, er hat keinen eigenen Status, er hat keinen eigenen Raum. Er bewegt sich in einem Regelwerk, das vor seiner Erfindung geschrieben wurde und das ihn als Beitrag zu einer Pflicht behandelt, die nach wie vor beim Menschen liegt.

Dieses Verhältnis bestimmt den gesamten Einsatzrahmen. Wer einen Roboter im Sicherheitsbereich eines Flughafens betreibt, betreibt ihn unter dem Luftsicherheitsgesetz, unter den Vorgaben der Europäischen Agentur für Flugsicherheit, unter der Aufsicht der zuständigen Luftsicherheitsbehörde und unter dem Zugriff der Bundespolizei. Er erweitert nicht den Rechtsraum des Flughafenbetreibers. Er füllt ihn nur dichter aus.

Boswau + Knauer hat in der eigenen Produktentwicklung früh akzeptiert, dass Flughäfen eine eigene Klasse von Liegenschaften sind. Sie sind keine Industriegelände mit höheren Zäunen. Sie sind Kritische Infrastruktur im Sinne der KRITIS-Verordnung, sie sind reguliert durch sektorspezifisches Recht, und sie haben eine Aufsichtsstruktur, in der Fehler des Betreibers schneller in behördliches Handeln umschlagen als in anderen Sektoren. Das Buch "BOSWAU + KNAUER. Vom Bau zur Sicherheitstechnologie" hat diese Logik in Kapitel 14 angelegt, ohne sie auf den Flughafen zu spitzen. Der vorliegende Beitrag trägt sie dort zu Ende.

Der rechtliche Rahmen, in dem ein Roboter überhaupt rollen darf

Der Ausgangspunkt jedes Einsatzes ist § 8 Luftsicherheitsgesetz. Die Vorschrift verpflichtet den Flughafenbetreiber zur Sicherung des Flughafens gegen Eingriffe Unbefugter, zur Kontrolle der Personen und Gegenstände, die in den Sicherheitsbereich gelangen, und zur Aufrechterhaltung eines Sicherheitsprogramms, das von der zuständigen Behörde genehmigt ist. Dieses Sicherheitsprogramm ist das eigentliche Dokument, in dem ein Sicherheitsroboter entweder vorkommt oder nicht vorkommt. Wer einen Roboter aufstellt, ohne ihn im genehmigten Sicherheitsprogramm anzulegen, betreibt eine Anlage ohne behördliche Grundlage. Das ist im Bereich der Kritischen Infrastruktur kein Detail, sondern ein eigener Tatbestand.

Auf europäischer Ebene wirken die Durchführungsverordnungen der EU zur Luftsicherheit, insbesondere die Verordnung (EU) 2015/1998 mit ihren regelmäßigen Anpassungen. Sie beschreiben die anerkannten Verfahren der Kontrolle, der Bewachung und der Zutrittsregelung. Sie öffnen Spielräume für ergänzende technische Lösungen, sie ersetzen aber an keiner Stelle die Verfahren, die sie selbst vorschreiben. Ein Roboter darf also patrouillieren, beobachten, dokumentieren, melden. Er darf nicht ohne ausdrückliche Genehmigung an die Stelle einer geforderten menschlichen Kontrollhandlung treten.

EASA Part 145 wird in der öffentlichen Diskussion regelmäßig falsch zitiert. Part 145 betrifft Instandhaltungsbetriebe für Luftfahrzeuge. Er ist für die Frage der Vorfeldsicherheit nicht einschlägig, soweit der Roboter ausschließlich der Sicherung dient. Relevant werden Part 145 und angrenzende Regelwerke erst dann, wenn der Roboter in Bereiche fährt, in denen Instandhaltungsarbeiten stattfinden, oder wenn er Funktionen übernimmt, die in den Verantwortungsbereich des Wartungsbetriebs eingreifen. Diese Trennung sauber zu halten ist Aufgabe der Schnittstellenvereinbarung zwischen Flughafenbetreiber, Wartungsbetrieb und Sicherheitsdienstleister.

Im internationalen Vergleich lohnt der Blick auf die FAA. Die US-Aufsicht arbeitet mit einem ähnlichen Grundgedanken, allerdings über andere Instrumente. Die Airport Security Programs der FAA und die TSA-Vorgaben kennen technische Hilfsmittel im Vorfeldschutz, sie binden ihren Einsatz aber an dokumentierte Verfahren, an Schulungsnachweise und an wiederkehrende Wirksamkeitsprüfungen. Wer eine Lösung aus dem US-Markt nach Deutschland überträgt, übernimmt nicht die Genehmigung, sondern nur die Technik. Die Zulassung muss am Standort neu erarbeitet werden.

Was ein Roboter auf dem Vorfeld tatsächlich darf

Der Sicherheitsroboter auf dem Vorfeld bewegt sich in einem engen Korridor erlaubter Handlungen. Er darf festgelegte Routen abfahren, er darf zufällige Routen abfahren, er darf Bereiche beobachten, in denen menschliche Präsenz aus operativen Gründen reduziert ist, er darf Lagebilder erfassen und an die Sicherheitsleitstelle übertragen, er darf Auffälligkeiten klassifizieren und gewichten, und er darf akustische und optische Hinweise abgeben, die zur Abschreckung wirken. All das ist unter dem Sicherheitsprogramm möglich, sofern es dort beschrieben ist und sofern die Aufsichtsbehörde dem Programm zugestimmt hat.

Er darf nicht eigenständig Personen identifizieren und an dieser Identifikation rechtliche Folgen knüpfen. Er darf nicht den Zugang zu Sicherheitsbereichen freigeben, soweit dies eine geprüfte Kontrollhandlung ist. Er darf nicht die Befugnisse der Bundespolizei oder der Luftsicherheitsbehörde wahrnehmen, weder durch Anhalten von Personen noch durch Eingriffe in deren Bewegungsfreiheit. Er darf nicht in den fliegerischen Verkehr eingreifen, weder durch Bewegung in Sicherheitsabständen zu Luftfahrzeugen, die ihm nicht zugewiesen sind, noch durch Funkkommunikation in Frequenzen, die der Tower bedient.

Aus dieser Trennung ergibt sich die operative Architektur. Der Roboter ist Sensor und Wirkkörper für Routinevorgänge. Die Entscheidung über Eingriffe bleibt bei der Sicherheitsleitstelle. Die Befugnis zum hoheitlichen Handeln bleibt bei der Bundespolizei. Diese Drei-Ebenen-Architektur ist nicht eine Einschränkung des Roboters, sondern die Voraussetzung seines Einsatzes. Wer sie verwischt, riskiert nicht nur die Genehmigung, sondern die gesamte Akzeptanz der Technologie in einem Sektor, der nach jeder Auffälligkeit in der Lupe der Öffentlichkeit steht.

Die Konfiguration eines Vorfeldroboters folgt deshalb einer eigenen Logik. Sie minimiert Funktionen, die in den hoheitlichen Bereich hineinreichen könnten, sie maximiert Funktionen, die in den Bereich der Beobachtung und Dokumentation fallen, und sie protokolliert jede Aktion in einer Form, die im Zweifel von der Aufsichtsbehörde geprüft werden kann. Wer Vorfeldlogik mit Logistiklogik verwechselt, baut Systeme, die unter Aufsicht durchfallen.

Die reale Umgebung Vorfeld und ihre Belastungen

Das Vorfeld ist keine Industriefläche. Es ist ein Bereich mit eigener Witterungsexposition, eigenen Strahlbelastungen durch Triebwerke, eigenen elektromagnetischen Bedingungen durch Funktechnik der Luftfahrt, eigenen Lichtverhältnissen durch Befeuerung und eigenen akustischen Bedingungen durch Triebwerks- und Hilfsaggregatlärm. Ein Roboter, der in dieser Umgebung über mehrere Jahre verlässlich arbeiten soll, muss in jeder dieser Dimensionen ausgelegt sein.

Triebwerksstrahl trifft auf bodengebundene Geräte mit Geschwindigkeiten und Temperaturen, die weder Bauindustriegeräte noch Logistikgeräte aushalten. Die Schutzklassen für Gehäuse, Verkabelung und Kühlung sind höher anzusetzen. Sensorik muss gegen Vereisung, Sandeintrag und Feuchtigkeit geschützt sein, ohne in der Erkennungsleistung zu verlieren. Optische Sensoren brauchen eine Kalibrierung, die sowohl die starken Befeuerungskontraste in der Nacht als auch das Reflexionsverhalten nasser Betonflächen abbildet. Akustische Sensoren sind im Vorfeld nur eingeschränkt nutzbar, weil der Lärmpegel die Klassifikation in vielen Anwendungsfällen unmöglich macht. Wer auf akustische Erkennung setzt, baut ein System, das in der Nacht funktioniert und am Tag stumm ist.

Die elektromagnetische Verträglichkeit ist eine eigene Disziplin. Vorfeldroboter dürfen weder die Funkkommunikation des Towers stören noch die Navigations- und Anflughilfen beeinträchtigen. Die Frequenznutzung muss mit der Bundesnetzagentur und den Frequenzbeauftragten des Flughafens abgestimmt sein. Wer hier Standardkomponenten aus dem Industrieumfeld einsetzt, läuft Gefahr, in eine Frequenzkollision zu geraten, die nicht der Roboter spürt, sondern der Pilot im Anflug. Diese Verkettung ist der Grund, warum eine Vorfeldlösung nicht aus Bauteilen zusammengesetzt, sondern als integriertes System entwickelt werden muss.

Bewegungsmuster auf dem Vorfeld folgen einer eigenen Choreografie. Pushback, Rollwege, Standzeiten, Be- und Entladung, Betankung. Jede dieser Bewegungen hat Vorränge und Sicherheitsabstände, die in den Betriebshandbüchern festgelegt sind. Ein Roboter, der diese Choreografie nicht kennt, ist auf dem Vorfeld kein Schutz, sondern ein Risiko. Aus diesem Grund müssen Vorfeldroboter mit den Bewegungsdaten des Flughafens verbunden sein, sie müssen Sperrzonen dynamisch verstehen, und sie müssen im Zweifel anhalten, statt eine Route fortzusetzen, deren Sicherheitsbedingungen nicht mehr gegeben sind.

Die Schnittstelle zwischen Sicherheit und Flugbetrieb

Die Sicherheit auf dem Vorfeld ist nicht von der Sicherheit im Flugbetrieb zu trennen. Beide Bereiche haben eigene Leitstellen, eigene Verantwortliche und eigene Protokolle. Der Tower verantwortet die Bewegungen der Luftfahrzeuge und die unmittelbar zugehörigen Bodenbewegungen. Die Sicherheitsleitstelle verantwortet den Schutz der Anlagen und Personen gegen Eingriffe Unbefugter. Zwischen beiden Welten muss ein Sicherheitsroboter eindeutig zugeordnet sein, sonst entsteht eine Verantwortungslücke, die im Ernstfall niemand schließt.

Die Einbindung in den Tower erfolgt nicht über direkte Funkkommunikation. Der Roboter spricht nicht mit dem Lotsen. Er spricht mit der Sicherheitsleitstelle, die ihrerseits mit dem Tower auf den dafür vorgesehenen Wegen kommuniziert. Diese Trennung ist die einzige Möglichkeit, die ohnehin hohe Funklast der Lotsen nicht weiter zu erhöhen und gleichzeitig die Lageinformation des Roboters in das integrierte Lagebild des Flughafens einzuspeisen. Moderne Flughäfen arbeiten dafür mit A-CDM-Systemen und mit Lagebildplattformen, die genau diese Aufgabe erfüllen.

Die Datenformate folgen den im Sektor etablierten Standards. Anbindungen über AODB-Schnittstellen, über sicherheitsspezifische Lagebildsysteme und über die Schnittstellen der Videomanagementsysteme sind die übliche Form. Wer hier eigene Formate verwendet, schafft eine Insellösung, die im Krisenfall nicht in die Stabsarbeit eingebunden werden kann. Stabsarbeit ist die eigentliche Prüfung jeder Sicherheitsarchitektur. Sie findet nicht in der Schönwetterlage statt, sondern in der Lage, in der mehrere Ereignisse gleichzeitig laufen.

Die Schnittstelle zur Bundespolizei ist gesondert zu regeln. Die Bundespolizei ist nach § 4 Bundespolizeigesetz für die Sicherheit im Luftverkehr zuständig, soweit sie ihr durch das Luftsicherheitsgesetz übertragen ist. Sie hat eigene Lagebilder, eigene Einsatzkräfte und eigene Befugnisse. Ein Sicherheitsroboter liefert Lageinformation, er ersetzt aber keine Streife der Bundespolizei. Die Verständigung zwischen Flughafenbetreiber, Sicherheitsdienstleister und Bundespolizei muss in dokumentierten Verfahren festgelegt sein. Diese Verfahren werden im Sicherheitsprogramm und in den Einsatzunterlagen der Bundespolizei abgebildet.

Genehmigung, Aufsicht und Haftung

Die Genehmigung eines Sicherheitsroboters auf dem Vorfeld ist kein einzelner Verwaltungsakt, sondern eine Kette aus Zustimmungen. Sie beginnt mit der Aufnahme in das Sicherheitsprogramm und der Zustimmung der Luftsicherheitsbehörde des jeweiligen Landes. Sie führt über die Abstimmung mit der Flughafenaufsicht, mit der Bundesnetzagentur in Frequenzfragen und mit der zuständigen Bundespolizeiinspektion. Sie endet im operativen Alltag mit der dokumentierten Wirksamkeitsprüfung, die in regelmäßigen Abständen zu wiederholen ist.

Datenschutzrechtlich ist der Roboter eine Verarbeitungsanlage im Sinne der Datenschutz-Grundverordnung und des Bundesdatenschutzgesetzes. Die Datenschutz-Folgenabschätzung ist verpflichtend, weil regelmäßig personenbezogene Daten in einem öffentlich nicht zugänglichen, aber von vielen Personen frequentierten Bereich verarbeitet werden. Die Abstimmung mit dem behördlichen Datenschutzbeauftragten und mit der zuständigen Aufsichtsbehörde gehört zu den Voraussetzungen jeder Inbetriebnahme. Wer diesen Schritt nachholt, statt ihn vorzubereiten, baut ein System, das nach der ersten Beschwerde abgeschaltet wird.

Versicherbar ist der Einsatz nur dann, wenn alle Vorstufen dokumentiert sind. Die Versicherer im Bereich Kritischer Infrastruktur arbeiten mit harten Anforderungen an Nachweise. Der Gesamtverband der Deutschen Versicherungswirtschaft hat in den vergangenen Jahren mehrfach klargemacht, dass technische Sicherungen nur dann prämienwirksam berücksichtigt werden, wenn sie nach anerkannten Regeln betrieben werden. Hier wirken neben den luftsicherheitsrechtlichen Vorgaben auch die VdS-Richtlinien und die einschlägigen Prüfungen, etwa durch TÜV oder andere akkreditierte Stellen. Der BDSW als Branchenverband hat in diesem Zusammenhang die Forderung nach klaren Verantwortlichkeitsgrenzen zwischen Mensch und Technik immer wieder bekräftigt.

Haftungsrechtlich bleibt der Betreiber in der Verantwortung. Der Hersteller haftet für Produktfehler, der Dienstleister haftet für Bedienfehler, der Betreiber haftet für die Auswahl und die Einbettung der Lösung. Diese Kette ist im Vertragswerk abzubilden, und sie ist im Schadensfall die Grundlage jeder Auseinandersetzung. Wer hier mit Standardverträgen aus dem Industriesicherheitsbereich arbeitet, übersieht die Besonderheiten des Sektors. Das BSI hat für den Bereich Kritischer Infrastruktur Mindeststandards definiert, die in der Vertragsgestaltung berücksichtigt sein wollen.

Was bleibt

Der Sicherheitsroboter auf dem Vorfeld ist kein Ersatz für etablierte Sicherheitsverfahren. Er ist eine Verstärkung der Reichweite menschlicher Aufmerksamkeit in einem Bereich, in dem diese Aufmerksamkeit ohnehin knapp und teuer ist. Er funktioniert dort, wo seine Rolle scharf gezogen ist, wo seine Schnittstellen dokumentiert sind und wo seine Grenzen vor der Inbetriebnahme bekannt sind. Er scheitert überall dort, wo eine seiner drei Ebenen vermischt wird, sei es zwischen Sensor und Entscheider, zwischen Dienstleister und Behörde oder zwischen Beobachtung und hoheitlichem Eingriff.

Für Betreiber von Flughäfen, für Sicherheitsdienstleister im Luftverkehr und für industrielle Akteure in angrenzenden Sektoren ist die Frage nicht, ob Roboter eingesetzt werden, sondern wie. Wer diese Frage seriös beantworten will, prüft zuerst das eigene Sicherheitsprogramm, dann die eigenen Schnittstellen, dann die eigene Datenschutzlage und erst danach die Technik. Diese Reihenfolge spart Zeit, Geld und Klärungsschleifen, die in der Aufsicht selten freundlich ausgehen.

Der nächste Schritt für Betreiber, die diese Reihenfolge anlegen wollen, ist ein vertrauliches Gespräch von rund sechzig Minuten, in dem die eigene Lage gezeichnet und mit der einer typischen Vorfeldkonfiguration verglichen wird. Boswau + Knauer führt dieses Gespräch persönlich, ohne Folgeverpflichtung, und ohne dass ein Produkt verkauft wird. Was danach folgt, entscheidet sich aus der Lage, nicht aus dem Termin.

Häufige Fragen

Welche Genehmigungen sind nach LuftSiG nötig?

Die zentrale Grundlage ist die Aufnahme des Sicherheitsroboters in das nach § 8 Luftsicherheitsgesetz genehmigte Sicherheitsprogramm des Flughafenbetreibers. Ergänzend sind die Zustimmungen der zuständigen Luftsicherheitsbehörde des Landes, die Abstimmung mit der Bundespolizei, die frequenzrechtliche Klärung mit der Bundesnetzagentur und die Datenschutz-Folgenabschätzung erforderlich. Hinzu kommen die regelmäßigen Wirksamkeitsprüfungen, die im Programm festgelegt sind. Wer Komponenten in Bereichen mit Wartungsbezug betreibt, prüft zusätzlich die Berührung mit EASA-Vorgaben für Instandhaltungsbetriebe.

Wer ist Aufsichtsbehörde am Flughafen?

Die Aufsicht ist mehrstufig organisiert. Für die Luftsicherheit nach LuftSiG ist die jeweilige Landesluftsicherheitsbehörde zuständig, vielfach ergänzt durch Vollzugsaufgaben der Bundespolizei. Für den Flugbetrieb wirken die Deutsche Flugsicherung und die Luftfahrtbehörden der Länder. Für KRITIS-relevante Fragen ist das BSI auf Bundesebene zuständig. Datenschutzrechtlich greift die jeweilige Landesdatenschutzaufsicht. Der Flughafenbetreiber selbst trägt die operative Verantwortung. Welche Behörde im Einzelfall zuerst zu beteiligen ist, hängt vom konkreten Vorhaben und vom Standort ab.

Welche Einsatzgrenzen gelten auf dem Vorfeld?

Der Roboter darf beobachten, dokumentieren, melden, abschrecken und Routinevorgänge unterstützen. Er darf nicht in den fliegerischen Verkehr eingreifen, keine hoheitlichen Befugnisse wahrnehmen, keine geprüften Kontrollhandlungen ersetzen und keine Funkkommunikation mit dem Tower aufnehmen. Operativ ist er an Sperrzonen, Sicherheitsabstände zu Luftfahrzeugen, Bewegungsvorränge des Bodenverkehrs und die Vorgaben des Sicherheitsprogramms gebunden. Bei Unklarheit über die Sicherheitslage hat er anzuhalten, nicht fortzufahren. Diese Grenzen sind im Sicherheitsprogramm und in den Einsatzunterlagen verbindlich abzubilden.

Wie wird der Tower in die Lagebilder eingebunden?

Der Roboter kommuniziert nicht unmittelbar mit dem Tower. Seine Informationen laufen in die Sicherheitsleitstelle des Flughafens, die ihrerseits über dafür eingerichtete Wege mit dem Tower und der Bundespolizei abstimmt. Die Einbindung erfolgt über etablierte Plattformen wie A-CDM-Systeme, integrierte Lagebildlösungen und Videomanagementsysteme mit definierten Schnittstellen. Diese Trennung schützt die Funklast der Lotsen, hält die Verantwortlichkeiten klar und stellt sicher, dass der Roboter im Krisenfall in der Stabsarbeit eingebunden ist, ohne den fliegerischen Verkehr zu stören.