In weiten Teilen der Cloud-Ära wurde Skalierbarkeit vor allem als Kapazitätsproblem diskutiert. Hält die Datenbank mehr Transaktionen aus? Lässt sich automatisch eine weitere Anwendungsinstanz hinzufügen? Kann Verkehr zwischen Regionen umschalten? Trägt die Architektur die zehnfache Nutzerzahl, ohne dass die Kosten entsprechend steigen?
Diese Fragen bleiben wichtig. KI fügt eine andere Dimension hinzu.
Moderne Systeme enthalten zunehmend probabilistische Komponenten, externe Modellabhängigkeiten und Software, die Handlungen auswählen oder anstoßen kann, statt nur vorgegebene Anweisungen abzuarbeiten. Zugleich zieht KI in Banken, Verwaltung, Gesundheitswesen, Telekommunikation, Fertigung, Versorgung und nationale Infrastruktur ein — Umfelder, in denen Verfügbarkeit nur ein Teil der Systemqualität ist.
Ein System, das skaliert und dabei die Kontrolle verliert, ist nicht gut entworfen.
Für das KI-Zeitalter heißt Skalierbarkeit zunehmend, die Leistungsfähigkeit zu erhöhen, ohne dass Betriebsrisiko, Abhängigkeit und Schadensradius im gleichen Tempo mitwachsen.
Die erste architektonische Unterscheidung ist die zwischen Schlussfolgern und Befugnis.
Ein Sprachmodell kann hervorragend darin sein, einen Störungsbericht zu deuten, Belege zu verknüpfen oder die nächste Handlung zu empfehlen. Es bleibt dennoch eine probabilistische Komponente, deren Ausgabe sich mit Kontext, Modellversion und Orchestrierung ändern kann. Dass die Empfehlung meist richtig ist, heißt nicht, dass das Modell zur führenden Instanz dafür werden sollte, ob eine Handlung erlaubt ist.
Ein Agent kann feststellen, dass ein Produktivdienst offenbar neu gestartet werden muss. Eine deterministische Kontrolle kann dennoch prüfen, ob die anfragende Identität befugt ist, ob das Ziel im erlaubten Bereich liegt, ob das Änderungsfenster offen ist und ob eine zweite Freigabe nötig ist. Ein KI-System kann eine verdächtige Banktransaktion erkennen, während eine unabhängige Policy-Engine dafür zuständig bleibt, ob ein Konto tatsächlich gesperrt werden darf.
Diese Trennung wird umso wichtiger, je mehr KI von der Empfehlung zur Ausführung übergeht.
Ein Prompt ist kein Zugriffskontrollmechanismus, so wie natürlichsprachliches Schlussfolgern kein Ersatz für Transaktionsintegrität ist. Die Architektur sollte annehmen, dass das Modell falsch schließen kann, und sicherstellen, dass die Befugnisgrenzen dann weiterhin gelten.
Hochverfügbare Architekturen werden oft um den Totalausfall herum entworfen: Ein Server antwortet nicht mehr, eine Region fällt weg, der Verkehr geht woandershin.
Echte Störungen sind häufig nur teilweise.
Ein Modell-Endpunkt bleibt erreichbar, aber die Latenz steigt über den Betriebsschwellenwert. Der Identitätsdienst kann bestehende Sitzungen prüfen, aber keine neuen Berechtigungen erteilen. Eine externe Datenquelle veraltet. Die Verbindung zu einer Cloud-Region ist instabil statt vollständig weg. Eine neue Modellversion liefert gültige Antworten, verhält sich in Randfällen aber anders.
Resilienz verlangt deshalb ausdrückliche Betriebsmodi.
Ein KI-abhängiger Prozess sollte wissen, was möglich bleibt, wenn die Inferenz ausfällt. Ein kritischer Workflow kann auf deterministische Regeln, reduzierte Automatisierung oder manuellen Betrieb zurückfallen. Ein Dienst kann im Nur-Lese-Modus weiterlaufen. Handlungen können eingereiht werden, wenn sie später sicher ausführbar sind, während andere sofort abgelehnt werden sollten, wenn ihre aktuelle Befugnis nicht feststellbar ist.
Es geht nicht darum, für jeden denkbaren Fehler einen Rückfallweg zu bauen. Es geht darum, die wesentlichen Funktionen zu bestimmen und den minimalen sicheren Betriebsmodus vorab zu entwerfen.
ISO 22301 liefert einen strukturierten Managementrahmen für Geschäftskontinuität und Wiederherstellung nach Störungen. In EU-Umfeldern mit NIS2 gehören Geschäftskontinuität, Backup, Notfallwiederherstellung und Krisenmanagement ebenfalls zu den Erwartungen der Richtlinie an das Cybersicherheits-Risikomanagement.
Für Einrichtungen im Rahmen der Resilienz kritischer Einrichtungen reicht diese Logik über die Cyber-Verfügbarkeit hinaus in die breitere organisatorische Widerstandsfähigkeit. Aktuelle EU-Leitlinien verknüpfen Kontinuitätsplanung ausdrücklich mit Business-Impact-Analyse, Wiederherstellungsprioritäten, RTO/RPO und getesteten Wiederherstellungsvorkehrungen.
Recovery Time Objective und Recovery Point Objective bleiben wertvolle Kennzahlen, doch KI-Systeme bringen Fehlerzustände mit, die sie schlecht erfassen.
Eine Vektordatenbank kann innerhalb ihres RTO wiederhergestellt sein und trotzdem die neuesten Berechtigungsänderungen nicht enthalten. Ein Modelldienst kann wieder als gesund gelten, während eine neue Version das Werkzeugauswahlverhalten spürbar ändert. Ein agentenbasierter Workflow kann aus persistiertem Zustand neu starten, obwohl eine externe Transaktion vor dem Ausfall bereits festgeschrieben war.
Die Infrastruktur ist wiederhergestellt. Der Geschäftszustand womöglich nicht.
Daraus entsteht eine Anforderung an semantische und Workflow-Wiederherstellung. Das System muss feststellen, ob Wissen noch maßgeblich ist, ob unterbrochene Handlungen idempotent fortgesetzt werden können, ob Seiteneffekte abgeglichen werden müssen und ob eine veränderte KI-Komponente erst wieder eine Bewertung bestehen muss, bevor sie Produktionsbefugnis zurückerhält.
Bei Systemen mit hohen Folgen kann Verfügbarkeit ohne Zustandsintegrität gefährlicher sein als ein Ausfall, weil der Dienst gesund wirkt, während er Entscheidungen gegen einen ungültigen Zustand trifft.
Zwei Cloud-Regionen können mehr Abhängigkeiten teilen, als ein Architekturdiagramm vermuten lässt.
Sie können denselben Identitätsanbieter, dieselbe DNS-Infrastruktur, Control Plane, Software-Lieferkette, CI/CD-Zugangsdaten, denselben Telekommunikationsanbieter, Modelldienst oder dieselbe Schlüsselhierarchie nutzen. Eine Kompromittierung oder Störung in einem dieser gemeinsamen Dienste kann die geografische Redundanz deshalb aushebeln.
Eine Resilienzanalyse sollte korrelierte Abhängigkeiten kartieren, statt Regionen zu zählen.
Bei staatlichen und souveränen Workloads muss dieselbe Analyse Rechtsordnung und administrative Kontrolle einschließen. Wo der Dienst läuft, zählt — aber ebenso, wer ihn administrieren darf, wer die Schlüssel kontrolliert, wo Telemetrie und Backups verarbeitet werden, welche Control Plane Infrastruktur ändern kann und was mit diesen Grenzen bei einer Notfallwiederherstellung geschieht.
Eine Last ist nicht souverän, nur weil ihre primäre Datenbank innerhalb einer Landesgrenze liegt.
Souveränität ist eine durchgängige Eigenschaft operativer Kontrolle.
In industriellen und betriebstechnischen Umgebungen werden diese architektonischen Unterscheidungen besonders wichtig.
In der Unternehmens-IT kann eine falsche Softwareaktion einen Geschäftsprozess unterbrechen. In einem Industriesystem kann sie physische Produktion, Anlagen, Verfügbarkeit oder Sicherheit beeinflussen. Das verändert das zulässige Verhältnis zwischen probabilistischer KI und Steuerungshoheit.
IEC 62443 bildet den zentralen internationalen Cybersicherheitsrahmen für industrielle Automatisierungs- und Steuerungssysteme. Auf Systemebene definiert IEC 62443-3-3 technische Anforderungen und Sicherheitsstufen rund um Grundbereiche wie Identifikation und Authentifizierung, Nutzungskontrolle, Systemintegrität, eingeschränkten Datenfluss, rechtzeitige Reaktion und Ressourcenverfügbarkeit. Sein Systemmodell strukturiert Vertrauens- und Kommunikationsgrenzen über Zonen und Conduits.
Für eine KI-gestützte Industriearchitektur spricht das grundsätzlich dagegen, analytische und operative Befugnis in derselben Vertrauensgrenze zusammenfallen zu lassen. KI kann Telemetrie deuten, Anomalien erkennen, Bediener unterstützen oder Handlungen vorbereiten, während deterministische Kontrollen, Segmentierung und Sicherheitsmechanismen weiterhin bestimmen, was im Prozessumfeld tatsächlich geschehen darf.
Höhere Modellgenauigkeit macht diese Grenzen nicht überflüssig.
Banken und Finanzdienstleistungen fügen über DORA eine weitere Architekturebene hinzu.
DORA verlangt von erfassten Finanzunternehmen einen dokumentierten Rahmen für das IKT-Risikomanagement, den Schutz von Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit, das Verständnis wesentlicher Drittabhängigkeiten und die Aufrechterhaltung kritischer oder wichtiger Funktionen durch geeignete Reaktions- und Wiederherstellungsmaßnahmen.
Das verändert die Bewertung von KI-Infrastruktur.
Ein Modellanbieter, der eine kritische Finanzfunktion stützt, sollte nicht allein nach Qualität, Latenz und Preis bewertet werden. Die Architektur muss auch Konzentrationsrisiko, Anbieterausfall, Ersetzbarkeit, Datenverarbeitung, Sichtbarkeit von Vorfällen, vertragliche Abhängigkeiten und die Fähigkeit der Organisation berücksichtigen, die Geschäftsfunktion fortzuführen, wenn diese externe Fähigkeit wegfällt.
Das kann zu einer technisch weniger eleganten Architektur führen, die operativ stärker ist, weil sie dem regulierten Unternehmen mehr Kontrolle über Wiederherstellung und Ausstieg gibt.
Das ist keine Compliance, die die Architektur beschädigt. Es ist Architektur, die das tatsächliche Betriebsumfeld richtig einbezieht.
Eine eigene Überlegung gilt, wenn das System ein Produkt mit digitalen Elementen ist, das auf dem EU-Markt in Verkehr gebracht wird, und nicht nur eine interne Plattform.
Der Cyber Resilience Act legt Cybersicherheitsanforderungen für erfasste Produkte über Entwurf, Entwicklung und Schwachstellenbehandlung hinweg fest. Für moderne Software wichtig: Sein Anwendungsbereich kann auch Fernverarbeitung von Daten umfassen, wenn diese Verarbeitung notwendig ist, damit das Produkt eine seiner Funktionen erfüllt.
Das zählt bei cloud-verbundenen und KI-gestützten Produkten, weil sich das funktionale Produkt über lokale Software, APIs und Fernverarbeitung erstrecken kann.
Sicherheits-Supportzeiträume, Schwachstellenbehandlung, Sicherheitsupdates, Komponentenabhängigkeiten und sichere Außerbetriebnahme werden damit zu Architekturthemen über den Lebenszyklus. Der Lieferant kann Cybersicherheit nicht mit dem Release von Version 1.0 als erledigt betrachten.
Für Industrieprodukte ergänzt IEC 62443-4-1 einen branchenspezifischen sicheren Entwicklungslebenszyklus, der Bereiche wie Sicherheitsanforderungen, sicheren Entwurf und Implementierung, Verifikation, Fehlerverwaltung, Patch-Management und Produktende abdeckt.
Auch hier sollte die Norm dort eingesetzt werden, wo Sektor und Produkt es rechtfertigen, und nicht unterschiedslos auf jede Unternehmensanwendung angewandt werden.
NIS2, CER, DORA, der Cyber Resilience Act, IEC 62443 und ISO 22301 lösen unterschiedliche Probleme und gelten für unterschiedliche Bereiche. Sie als ein allgemeines Compliance-Paket zu behandeln, ist ein Zeichen dafür, dass die Architektur nicht sauber klassifiziert wurde.
Die richtige Reihenfolge ist umgekehrt.
Zuerst Dienst, Verwendungszweck, Sektor, Rechtsordnung und Folgen eines Ausfalls bestimmen. Dann klären, welche rechtlichen, regulatorischen und normativen Rahmen tatsächlich greifen. Erst danach sollten diese Anforderungen in technische Eigenschaften übersetzt werden — Segmentierung, Identitätsarchitektur, Lieferantenkontrollen, Wiederherstellung, Prüfbarkeit, Schwachstellenbehandlung und souveräner Betrieb.
Geschieht diese Arbeit vor der Auswahl von Plattform und Anbieter, verbessert Regulierung den Entwurf.
Geschieht sie am Ende, wird sie zur teuren Nachbesserung.
Eine reife Architektur des KI-Zeitalters kann in Nutzern, Daten, Regionen, Modellen und Automatisierung wachsen und ihre Befugnisgrenzen dabei sichtbar halten.
Sie kann ein Modell austauschen, ohne den Geschäftsprozess darum herum neu zu bauen. Sie weiß, welche Abhängigkeiten gemeinsam ausfallen können. Sie weiß, welche Funktionen verfügbar bleiben, wenn die KI es nicht ist. Sie erhält die operative Kontrolle über Regionen und Lieferanten hinweg. Sie kann nach einem Vorfall belegen, was geschehen ist, statt es aus Teilprotokollen zu rekonstruieren.
Das ist eine stärkere Definition von Skalierbarkeit als Transaktionen pro Sekunde.
Die Architektur hat skaliert, wenn die Leistungsfähigkeit steigt, ohne dass Abhängigkeit, Schadensradius und Betriebsrisiko unkontrolliert mitwachsen.
Wir begleiten Organisationen bei der Expansion in die Golfstaaten, nach Zentralasien und Afrika.
30-minütiges Erstgespräch buchenWir klären Ihr Ziel, den Zielmarkt und die Rahmenbedingungen. Innerhalb eines Arbeitstages erhalten Sie zwei bis drei Terminvorschläge.