Edge gegen Cloud: warum die KI-Analyse auf dem Gerät kein Hipster-Trend ist

Eine Videoanalyse, die nur in der Cloud funktioniert, ist keine Sicherheitsanlage. Sie ist ein Beobachtungsdienst mit Verfügbarkeitsrisiko.

Diese Unterscheidung ist nicht akademisch. Sie entscheidet darüber, ob ein Perimeterschutz im Moment des Ereignisses arbeitet oder ob er auf eine Internetleitung wartet, die in genau diesem Moment häufiger ausfällt, als es Datenblätter vermuten lassen. Im Bau, in der Logistik, an Umspannwerken und auf Distributionsgeländen ist die Verbindung zur Außenwelt das schwächste Glied der Kette. Wer eine Sicherheitsarchitektur baut, die dieses Glied zur Voraussetzung ihrer Funktion macht, baut auf Sand.

Boswau + Knauer hat sich aus diesem Grund früh für eine doppelte Architektur entschieden. Modelle laufen lokal auf dem Gerät, am Rand des Netzes, dort, wo das Bild entsteht. Cloud und zentrale Infrastruktur ergänzen, sie ersetzen nicht. Diese Reihenfolge ist die einzige, die sich in der Praxis dieser Märkte verteidigen lässt. Sie hat Konsequenzen für die Hardware, für die Software, für den Service und für die Beschaffung. Wer sie versteht, kauft anders ein.

Was Edge in der Videoanalyse wirklich bedeutet

Edge ist im Sicherheitsmarkt zu einem Etikett geworden, das auf Geräten klebt, die diesem Anspruch nicht standhalten. Eine Kamera mit einem Bewegungsmelder ist keine Edge-KI. Ein Encoder, der Bilder in die Cloud schiebt, ist es ebenfalls nicht. Edge in der Videoanalyse bedeutet, dass die Klassifikation eines Ereignisses auf dem Gerät stattfindet, das das Bild aufnimmt, oder auf einer Recheneinheit, die in physischer Nähe steht und nicht über ein öffentliches Netz erreicht wird.

Diese Definition hat zwei harte Folgen. Erstens muss das Gerät über genug Rechenleistung verfügen, um ein neuronales Netz in Echtzeit auszuführen. Das ist heute technisch möglich, weil spezialisierte Beschleuniger in industrieller Qualität verfügbar sind. Es ist aber nicht trivial, weil Wärmeentwicklung, Stromaufnahme und Lebensdauer der Komponenten an einer Außenanlage andere Bedingungen erfüllen müssen als an einem Schreibtisch. Zweitens muss das Modell selbst für diese Recheneinheit dimensioniert sein. Ein Modell, das in der Cloud auf einer Serverfarm trainiert wurde, läuft nicht in derselben Form auf einem Gerät am Mast. Es wird komprimiert, quantisiert und für die jeweilige Hardware übersetzt. Diese Übersetzung ist eine eigene ingenieurtechnische Disziplin.

Wer Edge-KI verkauft, ohne diese beiden Folgen zu beherrschen, verkauft ein Versprechen, das im Feld bricht. Im Kapitel 17 unseres Buches "BOSWAU + KNAUER, Vom Bau zur Sicherheitstechnologie" haben wir die Trennung von Cloud- und Edge-Funktionen offengelegt, weil sie für die Beurteilung jeder ernsthaften Sicherheitsanlage maßgeblich ist. Die Frage in der Ausschreibung lautet nicht, ob ein Anbieter KI im Portfolio führt. Die Frage lautet, wo das Modell rechnet, wer es trainiert hat, mit welchen Daten es trainiert wurde und wie es auf das Gerät kommt. Wer diese Fragen nicht beantworten kann, gehört nicht in die zweite Runde der Ausschreibung. Wer sie beantworten kann, hat eine Architektur, die geprüft werden kann, und das ist die Vorbedingung jeder Investitionsentscheidung, die in Sicherheitsbudgets zu rechtfertigen ist.

Die harte Wirklichkeit der Verbindung

In den Märkten, die Boswau + Knauer bedient, ist die Verbindung zur Außenwelt nicht stabil. Eine Baustelle in der frühen Phase hat keine Glasfaser. Sie hat Mobilfunk, der von der Topographie, vom Wetter, von der Auslastung benachbarter Zellen und vom Bauablauf selbst abhängt. Ein Logistikzentrum hat redundante Anbindungen, deren Redundanz an einer einzigen Trasse hängt, die im Falle eines Erdarbeitens unterbrochen wird. Ein Umspannwerk hat eine Anbindung, die im Falle eines gezielten Angriffs das erste Ziel ist. Wer in dieser Wirklichkeit Sicherheit verkauft, muss die Verbindung als unzuverlässig annehmen, nicht als verfügbar.

Diese Annahme verändert die Architektur. Eine Cloud-Analyse, die auf eine stabile Leitung angewiesen ist, fällt in genau dem Moment aus, in dem ihre Funktion am wichtigsten wäre. Der Angreifer, der die Leitung kappt, hat die Analyse abgeschaltet. Das ist nicht ein theoretisches Szenario. Es ist das Standardvorgehen bei geplanten Diebstählen, die über das Niveau des Gelegenheitstäters hinausgehen. Wer in der Versicherungswelt eine Schadensanzeige bearbeitet, kennt die Häufigkeit, mit der die Aufzeichnung im entscheidenden Moment nicht verfügbar war. Diese Häufigkeit ist nicht zufällig. Sie ist die direkte Folge einer Architektur, die ihre Schwachstelle nach außen verlegt hat.

Die Konsequenz ist eindeutig. Erkennung und Erstreaktion müssen lokal stattfinden. Das Gerät muss in der Lage sein, ein Ereignis zu klassifizieren, einen Alarm auszulösen, eine Sirene anzusteuern, ein Licht einzuschalten, eine Lautsprecherdurchsage abzusetzen, ohne dass eine Cloud diese Aktionen genehmigt. Die Cloud kommt ins Spiel, wenn die Verbindung steht, für die Archivierung, für die Modellpflege, für die übergreifende Auswertung. Sie ist die zweite Ebene, nicht die erste. Wer diese Reihenfolge umdreht, verkauft seinem Kunden eine Anlage, deren Verfügbarkeit unter der Verfügbarkeit der schwächsten Mobilfunkzelle in seinem Einzugsgebiet liegt. Das ist keine Sicherheitsarchitektur. Das ist eine Übung in optimistischer Annahme. Der BSI-Grundschutz, die Vorgaben für KRITIS-relevante Anlagen und die Empfehlungen des VdS lassen an dieser Stelle wenig Spielraum. Verfügbarkeit ist nicht verhandelbar, und sie ist nicht abhängig von Dritten zu konstruieren, deren Service Level mit dem eigenen nicht übereinstimmt.

Reaktionszeit als Maßstab

Sicherheit ist eine Funktion der Zeit. Ein System, das ein Ereignis in zwei Sekunden erkennt, ist ein anderes System als eines, das fünfzehn Sekunden braucht. Die Differenz ist nicht graduell. Sie entscheidet darüber, ob die akustische Warnung den Angreifer erreicht, bevor er das Werkzeug ansetzt, oder erst, wenn der Schaden bereits eingetreten ist. In den Anwendungen, die wir bauen, sind Reaktionszeiten unter einer Sekunde der Maßstab, nicht die Ausnahme.

Diese Zeitspanne ist mit einer Cloud-Analyse nicht zu erreichen. Allein der Weg eines Bildes vom Sensor zur Cloud, durch die Modellinferenz, zurück zum Aktor, kostet mehrere Sekunden, wenn die Verbindung gut ist. Wenn sie schlecht ist, sind es zehn Sekunden oder mehr. Wenn sie ausfällt, ist es unendlich. Wer Reaktionszeiten in einer Größenordnung verspricht, die mit einer reinen Cloud-Architektur nicht haltbar ist, hat entweder eine Edge-Komponente, die er nicht offen ausweist, oder er verspricht etwas, das er nicht halten kann. Beides ist im Procurement ein Anlass, die Architektur im Detail zu prüfen.

Auf dem Gerät selbst sind Inferenzzeiten unter hundert Millisekunden erreichbar, in vielen Fällen unter fünfzig. Die Klassifikation einer Person, eines Fahrzeugs, eines Verhaltens läuft, während das Bild noch im Speicher des Geräts liegt. Die Entscheidung, ob ein Alarm ausgelöst wird, fällt in derselben Zeitspanne, in der das nächste Bild aufgenommen wird. Diese Geschwindigkeit ist der Grund, warum die Edge-Architektur in der Praxis funktioniert. Sie ist nicht ein technisches Detail. Sie ist die Voraussetzung dafür, dass die akustische Abschreckung wirkt, dass die Lautsprecherdurchsage rechtzeitig kommt, dass das Tor schließt, bevor das Fahrzeug durch ist. Wer diese Voraussetzung nicht erfüllt, baut keine Abschreckung, sondern eine Aufzeichnung. Aufzeichnungen werden gebraucht, sie sind aber kein Schutz. Schutz wirkt vor dem Ereignis. Aufzeichnung dokumentiert es. Die Trennung ist nicht semantisch. Sie steht in der Schadensabrechnung.

Modellpflege und das eigentliche Argument für Cloud

Die Edge-Architektur ist nicht das Ende der Geschichte. Sie ist der Anfang einer doppelten Logik, deren zweite Hälfte in der Cloud liegt. Modelle altern. Sie werden in einem definierten Datenbestand trainiert, und sie verlieren an Genauigkeit, sobald sich die Einsatzumgebung verändert. Eine Baustelle im Sommer sieht anders aus als dieselbe Baustelle im Winter. Eine Logistikfläche mit neuem Fuhrpark stellt andere Bilder bereit als die alte. Ein Standort, an dem eine neue Beleuchtung installiert wurde, liefert andere Helligkeitsverteilungen. Wer Modelle ohne Pflege betreibt, hat eine Anlage, die im ersten Jahr funktioniert und im dritten Jahr unzuverlässig wird.

Die Pflege findet in der Cloud statt, weil sie Rechenleistung verlangt, die auf dem Gerät nicht sinnvoll vorgehalten werden kann. Daten werden gesammelt, mit Zustimmung des Kunden, anonymisiert, sofern es um Personen geht, und in den Trainingsbestand eingebracht, der die nächste Modellgeneration formt. Diese Generation wird geprüft, getestet, freigegeben und auf die Geräte ausgespielt. Der Prozess ist standardisiert, er ist dokumentiert, und er ist auditierbar. Wer einen Anbieter prüft, sollte fragen, wie oft Modelle erneuert werden, wer den Trainingsbestand verantwortet, wie die Freigabe organisiert ist und in welchen Fenstern das Update läuft. Diese vier Fragen unterscheiden eine seriöse Modellpflege von einer einmaligen Auslieferung, deren Genauigkeit über die Zeit verfällt.

Die Cloud ist also nicht der Gegner der Edge-Architektur. Sie ist ihre Voraussetzung. Ohne Cloud keine Modellpflege. Ohne Modellpflege keine dauerhafte Genauigkeit. Ohne dauerhafte Genauigkeit kein Schutz, der über das erste Jahr hinaus hält. Die Architektur, die wir bauen, hat beide Ebenen, und sie hat sie in einer Reihenfolge, die im Ausfallfall trägt. Die Edge-Ebene arbeitet immer. Die Cloud-Ebene arbeitet, wenn sie verfügbar ist. Was die Cloud beiträgt, ist Verbesserung, nicht Grundfunktion. Diese Trennung ist die Differenz, die einen industriellen Anbieter von einem Pilotprojektbauer trennt. Die BG BAU und der GDV stützen diese Trennung in ihren Empfehlungen zur Schadensreduktion auf Baustellen, weil sie aus der Erfahrung ihrer Mitglieder kommt, nicht aus der Annahme einer perfekten Welt.

Datensouveränität und der rechtliche Rahmen

Edge hat einen zweiten Vorteil, der in deutschen und europäischen Märkten zunehmend Gewicht bekommt. Bilder, die das Gerät nicht verlassen, sind Bilder, die nicht durch fremde Infrastrukturen gehen. Die Datenschutz-Grundverordnung, die Vorgaben der Aufsichtsbehörden zur Videoüberwachung und die Anforderungen an die Verarbeitung personenbezogener Daten lassen sich mit einer Edge-Architektur sauberer erfüllen als mit einer Cloud-only-Lösung. Die Klassifikation findet lokal statt, die Speicherung kann auf das beschränkt werden, was tatsächlich gebraucht wird, und die Übertragung an externe Systeme erfolgt nur in Form von Ereignismeldungen, nicht als kontinuierlicher Bildstrom.

Diese Differenz ist nicht nur juristisch relevant. Sie ist auch operativ wichtig. Ein Betreiber, der seinem Betriebsrat, seinen Mitarbeitern und seinen Auftraggebern erklären muss, was mit den Bildern seiner Anlage passiert, hat es einfacher, wenn die Bilder die Anlage nicht verlassen. Eine Betriebsvereinbarung lässt sich um eine Edge-Architektur herum aufbauen, ohne dass jede Frage zur Verarbeitung in einem Drittland beantwortet werden muss. Der TÜV und der BDSW haben in ihren Stellungnahmen zur KI-gestützten Videoanalyse mehrfach darauf hingewiesen, dass die Verarbeitung am Ort der Aufnahme die Akzeptanz solcher Anlagen erhöht und ihre rechtliche Tragfähigkeit absichert.

Hinzu kommt die Frage der Souveränität im weiteren Sinne. Eine Anlage, deren Modell auf einem Server in einem Drittland gepflegt wird, ist von der Verfügbarkeit dieses Servers abhängig. Wenn der Anbieter wechselt, wenn die geopolitische Lage sich verändert, wenn eine Sanktion eingreift, ist die Anlage betroffen. Wer in KRITIS-relevanten Bereichen arbeitet, muss diese Abhängigkeit benennen können, und er muss sie auf ein Maß reduzieren, das in einer Krise tragbar bleibt. Die Edge-Architektur reduziert diese Abhängigkeit, weil die Grundfunktion lokal bleibt. Die Cloud-Anbindung kann ausfallen, sie kann gewechselt werden, sie kann sogar zeitweise abgeschaltet werden, ohne dass die Anlage ihre Aufgabe verliert. Diese Eigenschaft ist im Datenblatt schwer zu zeigen. Sie ist im Krisenfall der Unterschied zwischen einer Anlage, die hält, und einer Anlage, die genau dann ausfällt, wenn sie gebraucht wird.

Was Procurement prüfen sollte

Eine Ausschreibung, die KI-gestützte Videoanalyse zum Gegenstand hat, sollte fünf Fragen stellen, die den Spreu vom Weizen trennen. Erstens, wo läuft das Modell, das die Klassifikation vornimmt, in der Sekunde des Ereignisses. Zweitens, welche Reaktionszeit ist zwischen Bildaufnahme und Aktion garantiert, und mit welcher Streuung. Drittens, was passiert, wenn die Verbindung zur Cloud ausfällt, welche Funktionen bleiben erhalten und welche entfallen. Viertens, wie werden Modelle aktualisiert, mit welcher Frequenz, durch wen, und mit welchen Daten. Fünftens, wo werden die Daten gespeichert, wer hat Zugriff, und welche rechtlichen Rahmen gelten für diese Speicherung.

Diese fünf Fragen lassen sich nicht mit einer Marketingbroschüre beantworten. Sie verlangen technische Auskunft, vertragliche Zusicherung und in vielen Fällen einen Pilotbetrieb, der die Antworten unter realen Bedingungen prüft. Wer als Procurement diese Fragen stellt, qualifiziert seinen Lieferantenkreis in einer Tiefe, die im späteren Betrieb Geld spart. Wer sie nicht stellt, kauft auf Versprechen und prüft die Antworten erst im Schadensfall. Die zweite Variante ist häufiger, weil sie schneller geht. Sie ist auch teurer, weil der Schadensfall in der Regel eintritt, bevor die erste Vertragsverlängerung ansteht.

Die Antwort auf die Frage, ob Edge oder Cloud, ist keine Wahl zwischen zwei Möglichkeiten. Sie ist eine Frage nach der Architektur, und die einzige seriöse Architektur in den Märkten, die Boswau + Knauer bedient, ist die doppelte. Edge für die Grundfunktion. Cloud für die Pflege. Beides standardisiert, beides dokumentiert, beides auditierbar. Wer eine Anlage einkauft, die diese Architektur nicht ausweist, kauft eine Wette auf die Verfügbarkeit von Drittinfrastrukturen, deren Service Level mit den Anforderungen einer Sicherheitsanwendung nicht übereinstimmt. Die Wette geht oft gut. Sie geht nicht immer gut. Und im Sicherheitsmarkt ist die seltene schlechte Wette die teure.

Was bleibt

Edge-KI ist kein Trend, der im nächsten Quartal durch das nächste Schlagwort ersetzt wird. Sie ist die technische Antwort auf eine harte Anforderung, die in unseren Märkten nicht verhandelbar ist. Wenn die Verbindung ausfällt, muss die Sicherheit weiter funktionieren. Diese Anforderung lässt sich nur erfüllen, wenn die Erkennung und die Erstreaktion auf dem Gerät stattfinden. Die Cloud ergänzt diese Architektur durch Modellpflege, übergreifende Auswertung und Archivierung. Sie ersetzt sie nicht.

Die doppelte Architektur ist anspruchsvoller in der Entwicklung. Sie ist anspruchsvoller in der Pflege. Sie ist anspruchsvoller in der Beschaffung, weil sie Fragen aufwirft, die in einer rein cloudbasierten Lösung gar nicht erst gestellt werden. Sie ist die einzige Architektur, die in einer Wirklichkeit trägt, in der Verbindungen ausfallen, in der Angreifer Leitungen kappen, in der Versicherer eine Aufzeichnung verlangen, die im entscheidenden Moment tatsächlich vorhanden ist. Wer in dieser Wirklichkeit Verantwortung trägt, hat keine Wahl. Er hat eine Architekturanforderung, und er hat die Aufgabe, sie in Ausschreibung und Vertrag durchzusetzen.

Wer den nächsten Schritt gehen will, hat drei Möglichkeiten. Ein Gespräch von sechzig Minuten mit der Geschäftsleitung, vertraulich und ohne Folgeverpflichtung, klärt die eigene Lage im Spiegel unserer Erfahrung. Ein Audit über drei bis fünf Tage liefert eine schriftliche Standortbestimmung, die intern oder extern verwertbar ist. Ein Pilotbetrieb über neunzig Tage an einem definierten Standort liefert die Daten, die die Entscheidung über die Skalierung erlauben. Welche der drei Wege der richtige ist, ergibt sich aus der Tiefe, in der die Architekturfrage heute schon beantwortet werden kann. Wer sie nicht beantworten kann, beginnt mit dem Gespräch. Wer sie teilweise beantworten kann, beginnt mit dem Audit. Wer sie vollständig beantworten kann, beginnt mit dem Pilotbetrieb.

Häufige Fragen

Was bedeutet Edge-KI in der Videoanalyse?

Edge-KI bedeutet, dass die Klassifikation eines Bildes durch ein neuronales Netz auf dem Gerät stattfindet, das das Bild aufnimmt, oder auf einer Recheneinheit in physischer Nähe. Die Entscheidung, ob ein Ereignis vorliegt, fällt lokal, ohne dass das Bild eine Cloud erreichen muss. Das verlangt spezialisierte Hardware mit Beschleunigern in industrieller Qualität und Modelle, die für diese Hardware übersetzt und optimiert sind. Edge-KI ist nicht dasselbe wie eine Kamera mit Bewegungsmelder oder ein Encoder mit Cloud-Upload. Die Differenz liegt in der Rechentiefe und der Klassifikationsleistung am Ort der Aufnahme.

Funktioniert die Analyse weiter, wenn das Internet ausfällt?

In einer Edge-Architektur ja, in einer reinen Cloud-Architektur nein. Die Geräte, die wir bauen, halten ihre Grundfunktion bei Ausfall der Verbindung aufrecht. Erkennung, Klassifikation, Alarmauslösung, akustische Warnung, lokale Aktorik laufen weiter. Was entfällt, ist die Übertragung der Ereignisse an eine zentrale Leitstelle, die Archivierung in der Cloud und das Update der Modelle. Sobald die Verbindung wiederhergestellt ist, werden Ereignisse nachgeführt und Aufzeichnungen synchronisiert. Diese Eigenschaft ist in unseren Märkten nicht verhandelbar, weil ausgefallene Verbindungen statistisch häufiger sind als Anbieter zugeben.

Welche Reaktionszeiten sind lokal möglich?

Auf einem industriell ausgelegten Edge-Gerät sind Inferenzzeiten unter hundert Millisekunden Standard, in vielen Anwendungen unter fünfzig. Die gesamte Kette von der Bildaufnahme über die Klassifikation bis zur Aktorik bleibt unter einer Sekunde, häufig deutlich darunter. Eine vergleichbare Cloud-basierte Verarbeitung liegt selbst unter günstigen Bedingungen bei mehreren Sekunden, in schlechten Verbindungslagen erheblich höher. Diese Differenz ist der Grund, warum akustische Abschreckung und schnelle lokale Reaktion nur in einer Edge-Architektur seriös zugesichert werden können. Konkrete Werte hängen vom Modell, der Hardware und der Anwendung ab und werden im Pilotbetrieb gemessen.

Wie werden Modelle auf das Gerät ausgespielt?

Modelle werden zentral trainiert, mit Daten, die mit Zustimmung der Kunden erhoben und anonymisiert worden sind. Nach Training und Validierung durchläuft jedes Modell eine Freigabeprüfung, bevor es in eine Update-Welle eingeplant wird. Die Auslieferung auf die Geräte erfolgt in definierten Fenstern, signiert und verschlüsselt, mit Rückfallmöglichkeit auf die vorherige Version, falls Probleme auftreten. Updates erfolgen nicht ungeplant und nicht permanent, weil das im Feldeinsatz ein Risiko wäre. Der Prozess ist dokumentiert, auditierbar und entspricht den Anforderungen, die BSI-Grundschutz und VdS-Richtlinien an die Pflege sicherheitsrelevanter Systeme stellen.