Aktuelle Themen
Ob Fachartikel, Whitepaper oder Live-Event – wir teilen unser Know-how aus über 400 Projekten.
In 3 Schritten von Abhängigkeit zu Handlungsspielraum – herstellerneutral, mit Souveränitätsscore,
Risikoradar & umsetzbarer Roadmap. Umfasst Cloud, Daten, KI und den digitalen Arbeitsplatz
Sie möchten IT-Trends nicht nur verfolgen, sondern von Experten erklärt bekommen? In über 20 aktuellen Events und Webinaren teilen unsere Spezialisten praxisnahes Wissen.
Sie suchen Antworten auf konkrete IT-Herausforderungen in Ihrem Unternehmen? In über 800 Fachbeiträgen beleuchten unsere Berater aktuelle Themen. Praxisnah, verständlich und mit dem Know-how aus hunderten Kundenprojekten.
Sie wollen fundierte Entscheidungsgrundlagen für Ihre IT-Strategie? Unsere über 120 Whitepaper liefern Ihnen tiefgehende Analysen, Vergleiche und Best Practices. Kostenlos und sofort verfügbar für Ihr nächstes Projekt.
Viele Unternehmen beginnen ihre Cloud-Reise mit einzelnen Projekten, ersten virtuellen Maschinen oder einem Kubernetes-Cluster. Was anfangs funktioniert, wird jedoch schnell zur Herausforderung, sobald mehrere Teams, Anwendungen und Compliance-Anforderungen hinzukommen. An dieser Stelle wird das Konzept der Landing Zone relevant. Eine Landing Zone bildet das organisatorische, technische und sicherheitsrelevante Fundament einer Cloud-Plattform. Sie schafft Standards, Governance-Strukturen und zentrale Dienste, auf denen spätere Anwendungen aufbauen können. Ziel ist es, von Anfang an eine Umgebung zu schaffen, die skalierbar, sicher und langfristig wartbar ist.
In diesem Artikel betrachten wir, wie eine moderne STACKIT Landing Zone aussehen kann und welche Aspekte aus unserer Sicht besonders wichtig sind.
Bevor Netzwerke, Firewalls oder Plattformdienste eingerichtet werden, sollte zunächst eine sinnvolle Projektstruktur definiert werden. STACKIT bietet hierfür verschiedene Möglichkeiten. Kleinere Umgebungen können bereits durch konsequente Naming-Konventionen strukturiert werden. Für größere Organisationen empfiehlt sich die Nutzung von Foldern, um Projekte logisch zu gruppieren.
Weniger bekannt ist, dass über den STACKIT Support aktuell sogar eine zweite Folder-Ebene freigeschaltet werden kann. Diese Funktion befindet sich noch in einer erweiterten Testphase und erfordert eine engere Abstimmung mit STACKIT. Für größere Organisationen eröffnet sie jedoch zusätzliche Möglichkeiten zur Abbildung von Geschäftsbereichen, Mandanten oder Plattformdomänen. Eine durchdachte Hierarchie bildet die Grundlage für Berechtigungen, Kostenzuordnung, Logging und Governance.
Bei der Netzwerkarchitektur empfehlen wir heute grundsätzlich den Einsatz von STACKIT Network Areas. Das klassische STACKIT Public Projekt sollte aus unserer Sicht nur noch für Sonderfälle wie Sandbox- bzw. Testumgebungen verwendet werden. Der Grund dafür ist, dass bereits viele neuere Plattformdienste eine Network Area voraussetzen. Gleichzeitig ist ein späterer Wechsel zwischen Projekttypen mit entsprechendem Migrationsaufwand verbunden.
Network Areas ermöglichen es, mehrere Projekte innerhalb einer gemeinsamen Netzwerkarchitektur miteinander zu verbinden. Dadurch lassen sich klassische Hub-and-Spoke-Architekturen aufbauen, wie sie aus Enterprise-Umgebungen bekannt sind.
Eine bewährte Landing-Zone-Architektur basiert auf einem zentralen Netzwerk-Hub. In diesem Hub können zentrale Dienste betrieben werden:
Die eigentlichen Anwendungen werden in separaten Spoke-Projekten betrieben und greifen auf die zentralen Dienste des Hubs zurück. Aktuell erfolgt die zentrale Anbindung typischerweise über:
Direkte private Netzwerkverbindungen stehen heute noch nicht zur Verfügung. Mit STACKIT Connect befindet sich jedoch bereits ein entsprechender Dienst in Vorbereitung, der künftig dedizierte private Verbindungen mit entsprechenden SLAs ermöglichen soll. Ende 2026 bzw. Anfang 2027 werden wir mehr dazu wissen.
STACKIT Network Areas ermöglichen eine klare Netzwerksegmentierung. So können beispielsweise Produktions- und Non-Produktionsumgebungen bereits auf Ebene der Network Area logisch und organisatorisch voneinander getrennt werden.
Dabei gibt es jedoch einen wichtigen Aspekt zu beachten:
Sobald ein STACKIT Virtual Network für das Routing in das Transfernetz konfiguriert wird, können Kommunikationspfade zwischen den angeschlossenen Projekten entstehen. Ohne zusätzliche Schutzmechanismen kann dies zu einer deutlich größeren Netzwerksichtbarkeit führen als ursprünglich beabsichtigt.
Aus diesem Grund sollten Network Security Groups (NSGs) von Beginn an ein zentraler Bestandteil jeder STACKIT Landing Zone sein. Wir empfehlen, sämtliche Subnetze durch NSGs abzusichern, besonders schützenswerte Workloads zusätzlich auf NIC-Ebene zu schützen und Netzwerkkommunikation ausschließlich explizit freizugeben. Ein konsequent umgesetztes Default-Deny-Prinzip stellt dabei sicher, dass nur die tatsächlich benötigten Kommunikationsbeziehungen erlaubt werden. Auf diese Weise bleibt jederzeit nachvollziehbar und kontrollierbar, welche Systeme über welche Ports und Protokolle miteinander kommunizieren dürfen.
Ein Thema, das viele Nutzer von Hyperscalern kennen, sind Private Endpoints für Plattformdienste. Diese Funktion steht bei STACKIT aktuell noch nicht flächendeckend zur Verfügung. Viele PaaS-Dienste werden deshalb bewusst als sogenannte Online Services bereitgestellt und sind über öffentliche Endpunkte erreichbar.
Wichtig zu verstehen ist dabei:
Greift eine virtuelle Maschine innerhalb der STACKIT Cloud auf einen solchen Dienst zu, verbleibt der Datenverkehr zwar im STACKIT Backbone. Die Architektur unterscheidet sich jedoch von den vollständig privaten Service-Endpunkten anderer Cloud-Anbieter.
Private Endpoints befinden sich bereits in der Entwicklung. Erste Dienste, beispielsweise für den STACKIT Objektspeicher, werden voraussichtlich zeitnah folgen. Bis dahin können ACLs und Netzwerkkonzepte dabei helfen, die Angriffsfläche zu reduzieren.
Ein weiterer wichtiger Unterschied zu vielen anderen Cloud-Plattformen betrifft das Identitätsmodell. STACKIT versteht sich bewusst nicht als eigener Identity Provider. Stattdessen integriert sich die Plattform in bestehende Identitätslandschaften und unterstützt etablierte Föderationsmechanismen.
Unternehmen mit vorhandenem Identity Provider können diesen direkt anbinden. Wer noch keinen zentralen Identity Provider besitzt, kann beispielsweise auf Open-Source-Lösungen wie Keycloak setzen und diese über SSO-Föderation integrieren. Zusätzlich lässt sich durch die Einrichtung einer SCIM-Anbindung zwischen STACKIT und dem Identity Provider die Benutzerverwaltung deutlich vereinfachen, da User-Accounts und Berechtigungen automatisiert bereitgestellt und synchronisiert werden können.
Besondere Aufmerksamkeit verdienen Service Accounts. Diese sind immer organisationsgebunden und leben innerhalb von Projekten. Wer seine Landing Zone vollständig über Terraform oder die STACKIT CLI automatisieren möchte, sollte daher frühzeitig einen ausreichend berechtigten Service Account bereitstellen. Ohne diesen können spätere Automatisierungsprozesse nicht starten. Unsere Empfehlung ist es außerdem, die Authentifizierung solcher Service Accounts mit OIDC zu konfigurieren, um die Aufwände für Verwaltung und Security bezogen auf Secrets zu minimieren.
Ein Backup wird häufig erst dann betrachtet, wenn produktive Workloads bereits laufen. Unsere Empfehlung ist genau umgekehrt: Die Backup-Strategie sollte Teil der Landing-Zone-Planung sein.
Viele Unternehmen bringen bestehende Lösungen wie Veeam mit. Dieser Ansatz funktioniert auf STACKIT sehr gut. Der S3-kompatible Objektspeicher lässt sich problemlos als Backup-Repository nutzen und integriert sich bereits heute in die meisten etablierten Backup-Produkte. Bei PaaS-Diensten empfehlen wir aktuell weiterhin die nativen Backup-Funktionen der jeweiligen Services. Externe Backup-Lösungen bieten hier häufig noch keine ausreichende Integration.
Interessant ist außerdem die Möglichkeit, Object Lock zu verwenden. Dadurch können Backup-Daten nach dem WORM-Prinzip (Write Once Read Many) gespeichert werden. Das erhöht den Schutz vor Manipulationen und kann insbesondere im Kontext von Ransomware-Angriffen eine wichtige Rolle spielen.
Auch Logging sollte Bestandteil jeder Landing Zone sein. Mit dem Telemetry Router stellt STACKIT inzwischen einen zentralen Mechanismus bereit, um Telemetriedaten und Audit Logs aus Projekten, Foldern, Organisationen und Services zu sammeln. Über Telemetry Router Links können diese Daten zentral exportiert und in externe Log-Plattformen oder eigene Auswertungssysteme übertragen werden. Dadurch entsteht eine zentrale Sicht auf sicherheitsrelevante Ereignisse und Plattformaktivitäten. In STACKIT könnte man diese Logs beispielsweise in Services wie STACKIT Logs oder STACKIT Observability einspeisen, verarbeiten und im letzterem Beispiel auch Alerts generieren.
Cloud Governance endet nicht bei Sicherheit und Netzwerkdesign. Auch Kostenkontrolle sollte Bestandteil jeder Landing Zone sein. STACKIT unterstützt heute Kostenexporte im FOCUS-Format. Dadurch können Verbrauchsdaten langfristig archiviert und automatisiert ausgewertet werden.
Zusätzlich lassen sich Projekte mit Abrechnungsinformationen versehen, wodurch interne Kostenstellen oder Business Units sauber zugeordnet werden können. Projektbudgets stehen aktuell noch nicht nativ zur Verfügung. Mit den vorhandenen APIs und Kostenexporten lassen sich entsprechende Mechanismen jedoch vergleichsweise einfach selbst implementieren.
Spätestens bei mehreren Projekten, Netzwerksegmenten, Service Accounts und Sicherheitsrichtlinien wird deutlich, dass sich eine STACKIT Landing Zone nicht mehr sinnvoll manuell betreiben lässt. Infrastructure as Code ist deshalb ein zentraler Bestandteil der Plattformstrategie.
Terraform bietet hierfür bereits eine sehr solide Grundlage. Auch wenn die neuesten STACKIT-Dienste nicht immer unmittelbar als native Terraform-Ressourcen verfügbar sind, stehen die zugrunde liegenden APIs in der Regel bereits bereit und können automatisiert angebunden werden. Dadurch lassen sich selbst komplexe Landing-Zone-Architekturen reproduzierbar, konsistent und revisionssicher verwalten.
Die programmatische Beschreibung der Infrastruktur bringt darüber hinaus eine Reihe weiterer Vorteile mit sich:
Eine Landing Zone auf STACKIT besteht aus deutlich mehr als einer Netzwerkverbindung und einigen Projekten. Sie definiert die organisatorische Struktur, die Netzwerkarchitektur, Sicherheitsrichtlinien, Identitäten, Backup-Konzepte, Logging und FinOps-Prozesse, die später von allen Anwendungen genutzt werden.
Wer diese Grundlagen frühzeitig etabliert, schafft die Voraussetzung für eine Cloud-Plattform, die langfristig skalierbar, sicher und betrieblich beherrschbar bleibt. Und das ist letztlich das eigentliche Ziel einer Landing Zone.
Die Automatisierung von Geschäftsprozessen gehört inzwischen zu den wichtigsten Grundbausteinen zur Erreichung von Effizienz, Skalierbarkeit und Wettbewerbsfähigkeit. Unternehmen stehen dabei häufig vor der Frage: Soll eine klassische RPA-Plattform eingeführt werden oder reicht eine flexible Workflow-Automatisierung über APIs und Integration aus? Genau an dieser Stelle werden Automation Anywhere und n8n miteinander verglichen.
Automation Anywhere und n8n werden folgendermaßen in ihren Stärken, Gemeinsamkeiten sowie Unterschieden gegenüberstellt. Zu berücksichtigen ist, dass beide Plattformen unterschiedliche Schwerpunkte verfolgen und dabei verschiedene Automatisierungsansätze abdecken, auch wenn sie beide das gleiche Ziel der Prozessoptimierung und effizienteren Workflow-Gestaltung verfolgen.
Automation Anywhere ist eine in den USA entwickelte klassische Enterprise-RPA-Plattform (Robotic Process Automation), die heute weit über klassische Bot-Automatisierung hinausgeht und deshalb auch als AI- und Agentic-Process-Automation-Plattform zu bezeichnen ist. Neben der Automatisierung wiederkehrender Aufgaben über Benutzeroberflächen umfasst die Plattform klassische Bots, KI-gestützte Agenten, Dokumentenverarbeitung, Orchestrierung und Governance.
Automation Anywhere ist kein „Do-it-yourself“-Projekt, sondern bietet dem Kunden eine bereits fertige Automatisierungsmaschine, die nach eigenen Bedürfnissen konkretisiert werden kann. Ein wesentlicher Vorteil liegt in der strukturierten Steuerung und Skalierbarkeit, Rollen, Berechtigungen, Monitoring und Prozesskontrolle werden zentral verwaltet. Dadurch eignet sich Automation Anywhere insbesondere für größere Unternehmen, Banken, Versicherungen, Behörden oder Konzerne mit hohen Anforderungen an Compliance, Nachvollziehbarkeit und Governance. Der Schwerpunkt der Plattform liegt auf Prozessstandardisierung, organischer Kontrolle, Skalierbarkeit sowie der Reduzierung manueller und wiederkehrender Arbeitsschritte.
n8n verfolgt einen anderen Automatisierungsansatz: Die Open-Source-Plattform basiert primär auf API-gestützter Workflow-Automatisierung und dient dazu Anwendungen, Datenquellen, APIs und KI-Dienste flexibel miteinander zu verbinden. Im Gegensatz zu klassischen RPA-Plattformen liegt der Fokus nicht auf der Automatisierung von Benutzeroberflächen, sondern auf der technischen Orchestrierung von Systemen und Datenflüssen. Mithilfe sogenannter „Nodes“ können Unternehmen individuelle Workflows erstellen und unterschiedlichste Anwendungen miteinander verknüpfen, ganz nach eigenem Bauprinzip. Die aus Deutschland stammende Plattform bietet hohe Flexibilität und umfangreiche Anpassungsmöglichkeiten. Gleichzeitig setzt sie ein gewisses technisches Grundverständnis voraus. Für die Anwendung ist allerdings keine klassische Softwareentwicklung notwendig.
Außerdem überzeugt die Plattform durch die wesentliche Möglichkeit des Self-Hostings. Insgesamt liefert n8n damit eine hohe Anpassungsmöglichkeit, Flexibilität sowie eine starke Datenkontrolle. Die Plattform ist auch im Lizenz-Angebot nutzbar. Im Gegensatz zu Automation Anywhere kann n8n insbesondere auch von Start-Ups und kleineren technischen Unternehmen genutzt werden. Der Schwerpunkt dieser Plattform liegt grundlegend auf Anpassbarkeit, technischer Freiheit, experimenteller Weiterentwicklung und Integration moderner KI-Services und API-basierter Prozesse.
Automation Anywhere spielt seine Stärken insbesondere dann aus, wenn Automatisierung zentral gesteuert und unternehmensweit skaliert werden soll. Das betrifft klassische RPA-Szenarien, aber auch agentische Prozessautomatisierung mit KI-gestützten Entscheidungen, Dokumentenverarbeitung und orchestrierten Arbeitsschritten. Häufig betrifft dies größere Organisationen mit vielen standardisierten Prozessen, klaren Rollen und hohe Anforderungen an Kontrolle, Berechtigungen und Nachvollziehbarkeit. Typische Einsatzbereiche sind:
n8n eignet sich besonders für Unternehmen, die Systeme flexibel miteinander verbinden und technisch individuelle Workflows erstellen möchten. Wichtig ist die Abgrenzung: n8n ist keine RPA-Plattform, mit der Benutzeroberflächen durch Bots automatisiert werden. Typische Einsatzbereiche sind hier:
Beide Plattformen bieten unterschiedliche Lizenz- und Abonnementmodelle an. Automation Anywhere richtet sich in erster Linie an größere Unternehmen und Enterprise-Umgebungen, weshalb die Einstiegskosten aufgrund individueller Bot-Lizenzen und Unternehmensverträge höher angesetzt sind. Die wirtschaftliche Bewertung hängt stark davon ab, wie viele Bots und Agenten betrieben werden, welche Prozesse automatisiert werden und wie gut die Plattform organisatorisch verankert wird. Bei der wirtschaftlichen Betrachtung sollten jedoch nicht nur Lizenzkosten berücksichtigt werden. Entscheidend sind auch Betrieb, Wartung, Governance, interne Skills und die Frage, wie viele Prozesse langfristig automatisiert werden sollen. Unternehmen erhalten mit Automation Anywhere eine Plattform, die für Governance, Skalierung, zentrale Steuerung und moderne AI- sowie Agentic-Automation-Szenarien konzipiert wurde.
Die Plattform n8n bietet transparente Cloud-Modelle sowie eine kostenlose Open-Source-Variante. Dadurch erscheinen die Einstiegskosten häufig niedriger, allerdings sollten neben den Lizenzkosten auch Infrastruktur, Hosting, Wartung, Sicherheit, Workflow-Design, Fehlerbehandlung und interne Verantwortung berücksichtigt werden. Besonders beim Self-Hosting entstehen zusätzliche Aufgaben hinsichtlich Betrieb, Monitoring und Updates. Die tatsächlichen Kosten hängen stark von den vorhandenen technischen Kompetenzen und dem gewünschten Betriebsmodell ab. n8n kann deshalb für technisch starke Teams besonders attraktiv sein statt für Organisationen ohne klare technische Zuständigkeit.
Die Anwendung sowie der technische Aufwand der Plattform sind gering, da eine grafische Oberfläche, mit der Automatisierung erstellt und verwaltet werden kann, zur Verfügung gestellt wird. Ohne tieferes Verständnis von Programmierungswissen können automatisierte Prozessabläufe innerhalb der Enterprise-Organisation installiert werden.
Besonders lukrativ bei Automation Anywhere: Automatische Updates, damit auf dem höchsten Stand gearbeitet werden kann. Es herrscht insgesamt weniger Eigenverantwortung und es liegen klare Enterprise-Strukturen vor. Damit kann auch mit geringeren technischem Wissen die Plattform eigenständig angewendet werden. Nachteile stellt das nötige Anpassen bei veränderter Bildschirmoberfläche dar. Die Stabilität und Performance hängt stark vom jeweiligen Anwendungsfall ab.
Die Plattform n8n steht für Flexibilität in seiner Anwendung und Bedienbarkeit. Einhergehend ist damit allerdings ein erhöhtes technisches Grundverständnis notwendig. Eine erhöhte Unabhängigkeit und Freiheit bedeutet auch zunehmende Eigenverantwortung und unternehmerische Selbstorganisation hinsichtlich Updates, Hosting, Sicherheit und Wartungen. Damit erfordert n8n erweiterte Skills, liefert allerdings mit den wesentlichen Vorteilen der Unabhängigkeit, dem guten Verständnis von APIs, Datenmodellen, Authentifizierung, Fehlerbehandlung und Infrastruktur einen Ausgleich. Insgesamt verläuft n8n sehr stabil, da API-basierte Automatisierungen in der Regel weniger anfällig sind als bei RPA UI-Änderungen. Des Weiteren verlaufen die Schnittstellen n8ns performant und technisch fortschrittlich.
Bei Automation Anywhere werden starke Sicherheitsmechanismen und eine Enterprise-Governance geboten. Beinhaltet sind unter anderem Zugriffskontrollen, Verschlüsselungen sowie eine zentrale Verwaltung. Das ist besonders relevant, wenn viele Bots und KI-Agenten in verschiedenen Bereichen laufen oder Compliance-Anforderungen berücksichtigt werden müssen. Außerdem erhalten Kunden dieser Plattform einen Ansprechpartner und werden entsprechend beraten.
n8n unterscheidet sich im Vergleich zu Automation Anywhere darin, dass eine erhöhte Kontrolle hinsichtlich Infrastruktur und Datenflüsse aufgrund der Self-Hosting-Option besteht. Diese Kontrolle ist aber kein Selbstläufer: Unternehmen legen selbst den Ablauf der Verwaltung, Speicherungen und Zugriffsberechtigungen fest. Allerdings besteht auch hier die Möglichkeit, auf ein Lizenz-Angebot zurückzugreifen und die Datenkontrolle auszulagern. Wer Self-Hosting betreibt, kann das Betriebssystem offline betreiben sowie eigene Cloud-Infrastrukturen integrieren. Insgesamt lautet die Frage weniger, welche Plattform grundsätzlich sicherer ist, sondern welche besser zum eigenen Betriebsmodell und den internen Anforderungen passt.
Für die Auswahl zwischen Automation Anywhere und n8n sollten Unternehmen vor allem den eigenen Prozesskontext betrachten. Hilfreich sind fünf Fragen:
Grundsätzlich zeigt sich, dass keine Plattform pauschal besser ist als die andere. Sowohl Automation Anywhere als auch n8n verfolgen das Ziel der Automatisierung, setzen jedoch unterschiedliche Schwerpunkte. Automation Anywhere überzeugt besonders hinsichtlich zentraler Governance, der RPA, AI Automation, KI-Agenten sowie geringeren technischen Anforderungen. Die Plattform ist besonders attraktiv und geeignet für große Unternehmen, die durch standardisierte wiederholende Prozesse wertvolle Arbeitszeit durch RPA-Prozesse einsparen möchten. n8n überzeugt hingegen durch Flexibilität, technische Freiheit und umfangreiche Intergrationsmöglichkeiten in ihrer modernen API-Automatisierung. Der Einstieg in die Plattform ist technisch mit höheren Anforderungen verbunden, dennoch werden gezielte Verknüpfungen bestimmter Schnittstellen hergestellt, die ebenfalls der Prozessoptimierung dienen. Dabei ersetzt n8n keine klassische RPA-Plattform, sondern adressiert vor allem Integrations- und Workflow-Szenarien.
Es sollte sich also nicht die Frage gestellt werden „Welche Plattform ist besser?“, sondern vielmehr „Welche Anforderungen und strategischen Ziele verfolgt mein Unternehmen und welche Automatisierungs-Plattform kann diesen Anforderungen gerecht werden?“ In vielen Unternehmen kann deshalb sogar eine Kombination beider Ansätze sinnvoll sein: Während Automation Anywhere die Enterprise-Automatisierung mit Bots, KI und Governance übernimmt, kann n8n als flexible Integrations- und Workflow-Schicht dienen. Die beste Automatisierungsplattform ist letztlich diejenige, die optimal zum Prozess, zur Organisation und zur technischen Reife des Unternehmens passt.
Wenn Unternehmen über Automatisierung sprechen, landen sie oft sehr schnell bei Tools. Soll es n8n sein? Brauchen wir RPA? Oder ist ein KI-Agent der bessere Weg? Diese Fragen sind verständlich, aber häufig zu früh gestellt. Denn eine Technologie allein ist selten die Antwort.
Entscheidend ist zuerst, welchen Wert ein Unternehmen mit Automatisierung schaffen will. Erst danach ergibt sich, welcher technologische Ansatz passt. Manchmal ist das n8n, manchmal klassische RPA, manchmal ein KI-Agent. Und in vielen Fällen ist eine Kombination aus mehreren Ansätzen sinnvoller als die Suche nach dem einen richtigen Werkzeug.
Ein klassischer Toolvergleich wirkt auf den ersten Blick pragmatisch. Man vergleicht Funktionen, Lizenzmodelle, Integrationen, Bedienbarkeit und Herstellerstrategie. Das ist wichtig, aber nicht der erste Schritt.
Der Grund ist einfach: Viele moderne Automatisierungsplattformen können ähnliche Dinge, zumindest auf einer abstrakten Ebene. Daten übertragen, Workflows auslösen, Systeme verbinden, Oberflächen bedienen, Dokumente verarbeiten oder KI-Modelle einbinden. Der Unterschied liegt selten nur darin, ob ein Tool etwas grundsätzlich kann. Wichtiger ist, wie gut es zum konkreten Prozessmuster, zur Architektur und zur Organisation passt.
Deshalb sollte der Einstieg nicht lauten: „Welches Tool ist besser?“ Die bessere Frage lautet: Welche Use Cases erzeugen für uns Wert und welche Fähigkeiten brauchen wir dafür?
Robotic Process Automation (RPA) ist besonders stark, wenn Prozesse über bestehende Benutzeroberflächen laufen und Systeme nicht sauber über APIs angebunden werden können. Das betrifft häufig ältere Anwendungen, Fachverfahren oder gewachsene Prozesslandschaften.
RPA ist damit nicht automatisch „alt“ oder überholt. Der Ansatz löst weiterhin ein sehr reales Problem: Viele Unternehmensprozesse laufen nicht in perfekten API-Landschaften. Sie laufen in gewachsenen Systemen, mit Medienbrüchen, manuellen Schritten und Oberflächen, die Menschen bisher bedienen mussten.
n8n ist kein klassisches RPA-Tool. Genau das macht es für viele Use Cases interessant. Die Plattform eignet sich besonders dann, wenn Systeme über Schnittstellen verbunden werden können und technische Teams Workflows flexibel gestalten wollen.
n8n positioniert sich selbst als AI Workflow Automation Platform für technische Teams. Die Plattform verbindet visuelles Workflow-Building mit Code-Optionen, etwa JavaScript oder Python, und unterstützt Self-Hosting, Testing, Debugging und Governance-Funktionen. Damit passt n8n gut in Szenarien, in denen APIs, Events, Datenflüsse und KI-Bausteine orchestriert werden sollen.
KI-Agenten werden oft als nächster großer Automatisierungsschritt diskutiert. Dabei ist wichtig, den Begriff sauber einzuordnen. Ein KI-Agent ist nicht einfach ein besserer Bot. Er kann Aufgaben interpretieren, Kontext nutzen, Werkzeuge aufrufen und Schritte planen. Das eröffnet neue Möglichkeiten, bringt aber auch neue Anforderungen mit sich.
Gleichzeitig brauchen KI-Agenten klare Grenzen. Ohne Governance, Logging, Tests, Berechtigungen und Human-in-the-Loop entstehen Risiken. Gerade im Enterprise-Kontext reicht es nicht, einen Agenten zu bauen, der in einer Demo funktioniert. Er muss nachvollziehbar, kontrollierbar und betreibbar sein.
Viele Unternehmen wünschen sich eine klare Antwort: ein Tool, eine Plattform, eine Strategie. Das ist verständlich, aber nicht immer realistisch. In der Praxis kann eine Multi-Vendor-Strategie sinnvoll sein. Zum Beispiel, wenn RPA bestehende Oberflächen stabil automatisiert, n8n API- und KI-Workflows orchestriert und spezialisierte KI-Komponenten bestimmte Aufgaben übernehmen. Entscheidend ist dann nicht die Anzahl der Tools, sondern die Architektur dahinter.
n8n, RPA und KI-Agenten beantworten unterschiedliche Fragen. RPA hilft bei regelbasierten Prozessen über bestehende Oberflächen. n8n eignet sich für API-, Workflow- und KI-Orchestrierung. KI-Agenten können Kontext, Sprache und variablere Aufgaben einbeziehen.
Die eigentliche Entscheidung beginnt aber früher. Unternehmen sollten zuerst klären, welche Use Cases Wert schaffen, welche Strategie sie mit Automatisierung verfolgen und wie Governance, Datenschutz, Architektur und Betrieb aussehen sollen. Danach wird der Toolvergleich deutlich sachlicher.
Ein guter Automatisierungsansatz ist selten die Wahl eines einzelnen Werkzeugs. Er ist die Verbindung aus Use Case, Zielbild, Technologie, Verantwortlichkeit und Betrieb. Genau dort entsteht der eigentliche Mehrwert.
Der STACKIT Telemetry Router ist eine zentrale Komponente der STACKIT Cloud zur Verarbeitung und Weiterleitung von Telemetriedaten. Aktuell liegt der Fokus vor allem auf Audit Logs, die über standardisierte OpenTelemetry-Schnittstellen verarbeitet werden. Dieser Dienst ersetzt die STACKIT Lagacy Audit Logs zum Juni 2026.
Der Telemetry Router fungiert als zentrale Routing-Schicht für Telemetriedaten innerhalb der STACKIT Cloud. Über sogenannte Telemetry Links wird er mit Projekten, Ordnern oder Organisationen verbunden. Diese Links sorgen dafür, dass Telemetriedaten strukturiert erfasst und an den Router übergeben werden.
Wichtig ist dabei die regionale Bindung: Ein Telemetry Link kann nur mit einem Router innerhalb derselben Region verwendet werden. Dadurch entsteht eine klare und nachvollziehbare Datenstruktur.
Weitere Informationen zur Architektur des Dienst finden Sie hier: STACKIT Docs
Nach der Aufnahme durch den Router können die Daten über sogenannte Destinations an verschiedene Zielsysteme weitergeleitet werden. Dazu gehören unter anderem Observability-Stacks, Object Storage oder externe OpenTelemetry-Endpunkte. So ist beispielsweise auch die Anbindung an STACKIT Dienste wie STACKIT Observability und STACKIT Logs möglich.
Die Konfiguration der Destinations ist flexibel und erlaubt es, mehrere Zielsysteme parallel zu bedienen, ein Vorteil für hybride oder bereits bestehende Monitoring-Setups.
In ersten praktischen Tests zeigt sich, dass der Telemetry Router grundsätzlich zuverlässig arbeitet und Telemetriedaten stabil verarbeitet und weiterleitet. Die Integration in bestehende STACKIT-Umgebungen funktioniert in vielen Fällen ohne Probleme.
Allerdings merkt man auch deutlich, dass der Dienst noch in einer frühen Phase ist. Besonders bei komplexeren Setups treten gelegentlich Konfigurationsprobleme auf, etwa bei der sauberen Abstimmung von Links, Destinations und Filtern. Auch die Dokumentation deckt noch nicht alle Edge Cases ab, die in realen Umgebungen auftreten.
Ein weiterer Punkt ist der fehlende native Terraform-Support. Infrastruktur-as-Code ist in vielen Umgebungen jedoch Standard, weshalb das aktuell eine spürbare Lücke darstellt.
Der Support im STACKIT Portal ist mittlerweile schon vollständig vorhanden.
Mit dem Update des STACKIT Terraform Providers auf Version 0.98 können Telemetry-Router-Ressourcen nun direkt über die offiziell bereitgestellten Terraform-Blöcke verwaltet werden.
Damit entfällt die Notwendigkeit, auf Workarounds wie null_resource-Blöcke, individuelle REST-API-Aufrufe, die STACKIT CLI oder Curl-Skripte zurückzugreifen. Links, Destinations und weitere Konfigurationen lassen sich vollständig deklarativ über Terraform definieren und im regulären Infrastruktur-Lebenszyklus verwalten.
Die Nutzung der offiziellen Provider-Ressourcen vereinfacht nicht nur die Implementierung, sondern verbessert auch Wartbarkeit, Nachvollziehbarkeit und Konsistenz von Deployments. Anwender profitieren dabei von den üblichen Terraform-Funktionen wie State Management, Plan-Validierung und Drift Detection.
Für neue Implementierungen sowie bestehende Automatisierungen empfehlen wir daher, die mit Version 0.98 eingeführten Terraform-Ressourcen zu verwenden und auf bisherige API-basierte Workarounds zu verzichten.
Ein besonders interessanter Anwendungsfall des Telemetry Routers ist die Integration direkt in Anwendungen. Applikationslogs können dabei aus den Services ausgelagert und zentral über den Telemetry Router verarbeitet werden. Statt Logs lokal zu speichern oder direkt an einzelne Backend-Systeme zu senden, werden sie als Telemetriedaten erfasst und über einen Telemetry Link an den Router übergeben.
Von dort aus lassen sich die Daten flexibel weiterleiten, beispielsweise in einen Object Storage Bucket zur langfristigen Archivierung oder in einen zentralen Log-Dienst zur Analyse und Visualisierung. Das erleichtert nicht nur die Entkopplung der Anwendungen von der Logging-Infrastruktur, sondern sorgt auch für eine einheitliche und skalierbare Logging-Pipeline über mehrere Services hinweg.
Gerade in verteilten Systemen oder Microservice-Architekturen entsteht dadurch ein klarer Vorteil: Logs müssen nicht mehr pro Anwendung individuell verarbeitet werden, sondern folgen einem zentral gesteuerten Observability-Ansatz innerhalb der STACKIT Cloud.
Der STACKIT Telemetry Router ist eine vielversprechende Komponente für modernes Observability-Management in der Cloud. Die grundlegende Architektur mit Links, Destinations und Filterlogik ist durchdacht und funktioniert bereits gut im Alltag, obwohl es sich noch in der Beta befindet.
Die Unternehmensserver On Premises am eigenen Standort zu betreiben, verleiht ein Gefühl von Kontrolle und Sicherheit. Keine fremden Administratoren kommen an die Daten heran, es gibt keine externen Anbieter von Rechenzentren und Daten werden nicht an Unbekannte übertragen. Dieses Sicherheitsgefühl ist zwar verständlich, aber auch trügerisch. Cyberangriffe lassen sich von Wänden eines Gebäudes nicht abhalten. Kriminelle nutzen Softwarelücken, gestohlene Zugangsdaten und machen sich veraltete Systeme zunutze, die sie in On Premises Infrastruktur ebenso wie in der Cloud finden. Wir erklären heute alles rund um Cloud und On Premises Sicherheit und zeigen, warum die Vorurteile gegenüber Cloud-Sicherheit oft veraltet sind.
Angriffswege sind in den letzten Jahren immer kreativer und damit gefährlicher geworden. Kriminelle suchen nach Schwachstellen in Software, die nicht rechtzeitig aktualisiert wurde, nach Fernzugängen mit schwachen Passwörtern oder nach einem einzigen unachtsamen Klick auf eine Phishing-Mail. Ist der erste Schritt geschafft, bewegen sie sich im Netzwerk weiter, bis sie ihr Ziel erreichen. Die Angriffswege können dabei unterschiedlich aussehen:
Lokale IT-Infrastrukturen haben in diesen Szenarien oft den großen Nachteil, dass es an automatisierten Mechanismen fehlt, die den Einbruch sofort erkennen und isolieren, sobald ein Angreifer sich im System befindet. Cloud-Umgebungen hingegen sind von Grund auf für genau diese Bedrohungsszenarien gebaut worden. Darin gibt es automatische Echtzeitüberwachung rund um die Uhr und klare Prozesse für den Ernstfall.
Laut dem aktuellen Data Breach Investigations Report von Verizon erfolgen inzwischen 31 Prozent der Breaches durch Schwachstellen in Software. Damit nimmt dieser Weg den ersten Platz ein, den über Jahre gestohlene Passwörter innehatten. Oft handelt es sich bei solchen Schwachstellen um bekannte Probleme, für die es bereits einen Fix gibt. Hier scheitert es aber gerade in Unternehmen mit On Premises Infrastruktur oft an der Umsetzung, da die Updates manuell eingespielt werden müssen. Geschieht das verspätet, stehen die Türen für Angreifer offen.
In einigen Unternehmen laufen business-kritische Anwendungen auf Systemen, die seit Jahren nicht grundlegend aktualisiert wurden. Der Grund liegt meist in fehlender Zeit, fehlenden Kapazitäten für Tests und möglicher fehlender Kompatibilität nach dem Update. Grundsätzlich findet sich im laufenden Betrieb selten das richtige Wartungsfenster. Daraus entstehen Systeme, die zwar funktionieren, aber von außen angreifbar bleiben.
In der Cloud besteht grundsätzlich das gleiche Risiko. Allerdings übernimmt dieses Problem weitgehend der Anbieter. Sicherheitsupdates werden zentral und automatisiert eingespielt, ohne dass einzelne IT-Teams aktiv werden müssen. Neue Schwachstellen werden in der Regel innerhalb von Stunden oder wenigen Tagen geschlossen statt erst nach dem nächsten geplanten Wartungstermin. Für Unternehmen bedeutet das weniger manuelle Arbeit und weniger offene Angriffspunkte.
Das heißt nicht, dass Cloud-Umgebungen keine eigene Verantwortung mit sich bringen. Auch hier gibt es Konfigurationen, die Unternehmen selbst pflegen müssen. Aber der Anteil an Aufgaben, der automatisch erledigt wird, ist erheblich größer. Das macht sich am Ende in der Sicherheitsbilanz bemerkbar.
Klassische IT-Sicherheit folgt einem einfachen Prinzip: Wer im Netzwerk ist, darf auch auf alles darin zugreifen. Sicherheit entsteht durch die klare Abgrenzung nach außen. Gelingt es allerdings Angreifern, diese Grenze zu überwinden, können sie sich danach fast ungehindert im Netzwerk bewegen und großen Schaden anrichten.
Das Zero Trust Modell arbeitet nach einem anderen Prinzip: Never Trust, Always Verify. Kein Nutzer und kein System erhält automatisch Vertrauen, egal ob von innen oder von außen. Stattdessen wird jeder Zugriff kontinuierlich einzeln geprüft. Ein einmaliger Login reicht nicht mehr aus, um sich im gesamten System zu bewegen.
Diese drei Kernmerkmale machen Zero Trust aus:
Cloud-Plattformen sind strukturell gut auf dieses Modell ausgerichtet: Identitätsverwaltung, Zugriffssteuerung und Überwachung sind dort zentral organisiert und lassen sich einheitlich über alle Systeme hinweg umsetzen. Auch in On-Prem-Umgebungen ist das technisch möglich, aber oft aufwändiger in der Umsetzung.
Ob ein Server im Unternehmen steht oder in einem externen Rechenzentrum betrieben wird, entscheidet nicht darüber, wie sicher ein Unternehmen aufgestellt ist. Viel wichtiger sind aktuelle Systeme, durchdachte Zugriffskonzepte und die Möglichkeit, Bedrohungen rechtzeitig zu erkennen. Cloud-Umgebungen bieten dafür heute oft bessere Voraussetzungen als lokale Infrastrukturen – vorausgesetzt, sie werden entsprechend konfiguriert. Viele Unternehmen arbeiten inzwischen auch mit hybriden Modellen, die Sicherheit passend zur Sensibilität der Workloads ermöglichen. Welcher Ansatz für Ihr Unternehmen der richtige ist, hängt immer von Ihren konkreten Anforderungen ab. Rewion unterstützt Sie dabei, die passende Strategie zu entwickeln.
Manche Krankenhäuser starten mit KI, andere haben schon die ersten Use Cases etabliert. Nicht selten kommt es dabei aber dazu, dass einzelne Use Cases oder Pilotprojekte technisch funktionieren, aber dann nicht dauerhaft in den Regelbetrieb übergehen.
Der entscheidende Faktor liegt dabei in der Art und Weise, wie die Umsetzung organisiert ist. Denn die Einführung von KI bringt unterschiedliche Anforderungen zusammen: strategische Entscheidungen, fachliche Perspektiven, technische Umsetzung, regulatorische Rahmenbedingungen und Veränderungen im Arbeitsalltag.
Damit diese Aspekte übersichtlich und adressierbar bleiben, braucht es neben einem strukturierten Vorgehen definierte Rollen mit jeweils zugewiesener Verantwortung. Hier geht es nicht darum, zwingend neue Mitarbeiter einstellen zu müssen, sondern darum, Verantwortungsbereiche abzudecken.
Auf oberster Ebene übernimmt ein Steuerungsgremium die Einordnung von KI in den Gesamtkontext des Krankenhauses. Hier wird festgelegt, welche Rolle KI künftig spielen soll und welche Ziele damit verbunden sind.
Das Gremium trifft Entscheidungen zur Priorisierung von Initiativen, bewertet Zielkonflikte und dient als Instanz für Eskalationen. Gleichzeitig stellt es sicher, dass einzelne Projekte in eine übergeordnete strategische Logik eingebettet bleiben. Typischerweise sind Krankenhausleitung bzw. eine strategische Vertretung, IT/Digitalisierung, Vertreter betroffener Fachbereiche sowie Datenschutz, Informationssicherheit und Qualitätsmanagement eingebunden. Je nach Vorhaben können weitere Funktionen wie Medizintechnik, Beschaffung, Recht/Compliance, Mitarbeitendenvertretung oder bei patientennahen Anwendungen auch Patientenvertretungen hinzukommen.
Die zentrale Rolle der KI‑Verantwortlichen beziehungsweise System Owner verbindet die verschiedenen Ebenen miteinander. Diese Rolle begleitet einen Use Case über den gesamten Lebenszyklus hinweg und sorgt dafür, dass strategische Ziele, fachliche Anforderungen und technische Umsetzung aufeinander abgestimmt sind.
Im Mittelpunkt steht die Koordination zwischen den beteiligten Stakeholdern. Anforderungen werden zusammengeführt, Prioritäten abgestimmt und die Umsetzung entlang klarer Zielbilder gesteuert. Auch die Weiterentwicklung und Integration in den Regelbetrieb fallen in diesen Verantwortungsbereich.
Die fachliche Verantwortung liegt im jeweiligen Fachbereich. Hier wird beurteilt, ob eine KI‑Anwendung tatsächlich zur Verbesserung von Versorgung oder Prozessen beiträgt.
Der Fachbereich bringt die notwendigen Anforderungen ein, ordnet die Anwendung in bestehende Abläufe ein und begleitet ihre Nutzung im Alltag. Rückmeldungen aus der Praxis fließen in die Weiterentwicklung ein und sichern die Anschlussfähigkeit der Lösung.
Die IT sorgt für die technische Einbindung und den verlässlichen Betrieb von KI‑Anwendungen. Dazu gehört die Integration in bestehende Systeme, die Sicherstellung von Datenverfügbarkeit und -qualität sowie die kontinuierliche Betreuung im Betrieb.
Auch Aspekte wie Monitoring, Wartung und Weiterentwicklung liegen in diesem Verantwortungsbereich. Die IT schafft damit die Voraussetzung dafür, dass Anwendungen stabil funktionieren und langfristig eingesetzt werden können.
In der Praxis wird die IT häufig sehr früh in Projekte eingebunden, gleichzeitig aber stark auf die technische Umsetzung fokussiert. Eine enge Verzahnung mit fachlichen und strategischen Fragestellungen findet nicht immer in ausreichender Tiefe statt.
Governance‑Funktionen wie Datenschutz, Informationssicherheit oder Qualitätsmanagement übernehmen die Aufgabe, regulatorische Anforderungen in die Umsetzung zu integrieren. Dazu zählen unter anderem Vorgaben aus der DSGVO, Anforderungen aus dem Medizinprodukterecht oder dem EU AI Act.
Neben der inhaltlichen Prüfung gehört auch die Dokumentation zu diesem Verantwortungsbereich. Entscheidungen müssen nachvollziehbar gemacht und Anforderungen systematisch berücksichtigt werden.
Neben internen Governance‑Strukturen kann es sehr hilfreich sein, (externe) regulatorische Expertise hinzuzuziehen. Dies betrifft vor allem Fragestellungen, die spezielles regulatorisches oder normatives Wissen erfordern.
Beispiele dafür sind die Einordnung von Anwendungen im Kontext des Medizinprodukterechts, die Bewertung von Anforderungen aus dem EU AI Act oder die Ausgestaltung von Nachweispflichten. Externe Unterstützung ergänzt die internen Rollen und wird gezielt für spezifische Fragestellungen eingesetzt.
Je nach Organisationsstruktur kann dies intern über die Rechtsabteilung erfolgen oder extern durch spezialisierte Rechtsberatung unterstützt werden.
Die Einführung von KI wirkt sich auf Arbeitsabläufe, Entscheidungsprozesse und etablierte Rollenbilder aus. Change Management begleitet diese Veränderungen und sorgt für eine stabile Nutzung im Alltag.
Zu Beginn geht es darum, ein gemeinsames Verständnis für den Einsatz der Anwendung zu schaffen und die betroffenen Nutzergruppen einzubinden. Darauf aufbauend werden Schulungs- und Unterstützungsangebote entwickelt.
Im operativen Betrieb spielen Change Agents und Superuser eine wichtige Rolle. Sie fungieren als erste Ansprechpersonen im Fachbereich, unterstützen Kolleginnen und Kollegen bei der Anwendung und geben Rückmeldungen an Projekt- oder Systemverantwortliche weiter. Dadurch entsteht eine Verbindung zwischen zentraler Steuerung und tatsächlicher Nutzung im Alltag.
Die Einführung von KI im Krankenhaus umfasst mehrere Verantwortungsbereiche, die zusammenspielen. Jede Rolle bringt eine eigene Perspektive ein und trägt dazu bei, dass die Umsetzung nicht auf einzelne Aspekte reduziert wird.
Fehlende Klarheit in der Rollenverteilung führt in der Praxis zu Abstimmungsproblemen, isolierten Initiativen und fehlender Verankerung im Alltag. Sobald Verantwortung bewusst zugeordnet und übergreifend koordiniert wird, entsteht eine tragfähige Grundlage für die Einführung und Weiterentwicklung von KI-Anwendungen.
Ist auf strategischer Ebene klar geregelt, wer Prioritäten setzt und wie KI in die Gesamtstrategie eines Krankenhauses eingebettet ist? Ist eine übergreifende Verantwortung für KI‑Initiativen vorhanden, die verschiedene Aktivitäten zusammenführt?
Ist die IT über alle Phasen hinweg eingebunden? Werden regulatorische Anforderungen frühzeitig berücksichtigt oder eher nachträglich adressiert?
Sind Personen benannt, die als zentrale Ansprechstellen fungieren und die Anwendung im Fachbereich begleiten?
Diese Fragen sind ein Auszug vieler Aspekte, die Krankenhäuser im Vorfeld einer KI‑Einführung klären sollten.
In der Praxis zeigt sich jedoch, dass genau hier Unsicherheiten bestehen. Verantwortlichkeiten sind nicht eindeutig definiert, Rollen entwickeln sich erst im Projektverlauf oder hängen stark von einzelnen Personen ab. Hier kann es hilfreich sein, die eigene Ausgangssituation realistisch einzuordnen und gezielt zu prüfen, an welchen Stellen Orientierung und Klarheit fehlt.
Wechseln Unternehmen in die Cloud, stehen sie schnell vor einer wichtigen Frage: Wie stellen wir sicher, dass aus einem vielversprechenden Start kein unkontrolliertes Wachstum wird? Der Aufbau von Landing Zones kann die Antwort darauf sein. Sie schaffen die Grundlage, auf der Teams sicher, effizient und eigenständig arbeiten können, ohne dass Sicherheit oder Ordnung auf der Strecke bleiben. In diesem Artikel zeigen wir, wie Landing Zones als Teil des Cloud Platform Engineerings funktionieren und warum sie weit mehr sind als ein technisches Setup.
Cloud Landing Zones klingen erst einmal sehr abstrakt, stellen aber letztendlich nichts anderes dar als eine vorbereitete und geplante Umgebung. Zum Vergleich: Stellen Sie sich vor, ein Unternehmen bezieht ein neues Bürogebäude. Bevor die ersten Mitarbeitenden ihre Arbeitsplätze beziehen, werden Zugangssysteme installiert, Netzwerke eingerichtet und Brandschutzregeln festgelegt. Niemand würde einfach loslegen und hoffen, dass sich alles irgendwie ergibt. Eben dieses Prinzip steckt auch hinter dem Aufbau von Landing Zones in der Cloud.
Eine Landing Zone ist eine vorkonfigurierte, sichere Umgebung innerhalb der Cloud-Infrastruktur. Sie definiert von Anfang an, wie Ressourcen organisiert werden, welche Sicherheitsanforderungen gelten und wie Teams miteinander und mit der Infrastruktur interagieren. Sie ist damit der geordnete Rahmen, in dem Cloud-Nutzung erst richtig funktioniert.
Im Cloud Platform Engineering nimmt der Aufbau von Landing Zones eine wichtige Rolle ein. Cloud Platform Engineering insgesamt sorgt dafür, dass Entwicklungsteams produktiv und sicher in der Cloud arbeiten können. Landing Zones wiederum sind das strukturelle Fundament dafür. Ohne sie fehlt die gemeinsame Ausgangsbasis, sodass Teams im schlimmsten Fall parallel zueinander, mit unterschiedlichen Standards und großem Aufwand für alle Beteiligten arbeiten.
Governance klingt zuerst nach Kontrolle, Bürokratie und langen Freigabeprozessen. Im Kontext des Aufbaus von Landing Zones bedeutet es jedoch etwas anderes: Governance schafft automatisierte Leitplanken, die sicherstellen, dass Entwicklungsteams gar nicht erst in problematische Bereiche geraten können, ohne dass jemand jeden Schritt manuell prüfen muss.
Das Prinzip dahinter ist einfach: Regeln werden nicht als Checkliste verteilt, an die sich alle halten müssen, sondern stattdessen direkt in die Infrastruktur eingebaut. Setzt jemand eine neue Umgebung in der Cloud auf, bekommt er oder sie automatisch den richtigen Rahmen mitgeliefert.
Konkret können solche Governance-Regeln zum Beispiel so aussehen:
Was zunächst nach Einschränkung klingt, ist in der Praxis nützlich. Entwicklungsteams gewinnen durch klar definierte Regeln mehr Autonomie. Sie müssen sich nicht mit Sicherheitsfragen beschäftigen, die eigentlich Aufgabe der Plattform sind und können sich voll auf ihre eigentliche Arbeit konzentrieren.
Der Aufbau von Landing Zones wird oft fälschlicherweise als einmaliges Infrastrukturprojekt verstanden, das nach einem Projektzeitraum abgeschlossen ist. In der Realität zeigen Landing Zones ihren größten Nutzen erst dann, wenn sie tief in die alltäglichen Arbeitsprozesse der Entwicklungsteams integriert sind.
Der wichtigste Schritt ist die Verbindung mit bestehenden DevOps-Prozessen. Konkret bedeutet das: Wenn ein Team eine neue Anwendung in der Cloud entwickeln will, muss es nicht mehr händisch Umgebungen beantragen, Zugriffsrechte klären oder Pipelines von Grund auf aufsetzen. Stattdessen stellt die Landing Zone automatisch bereit, was gebraucht wird, zum Beispiel:
Diese Automatisierungen haben einen direkten Effekt auf die Arbeitsgeschwindigkeit. Teams starten nicht bei null, sondern können auf einer fertigen, geprüften Grundlage mit der Arbeit beginnen. Gleichzeitig wird sichergestellt, dass alle Umgebungen nach denselben Standards aufgebaut sind. Das passiert unabhängig davon, welches Team sie anlegt oder wann. Besonders in größeren Unternehmen, in denen viele Teams parallel in der Cloud arbeiten, macht dieser Unterschied sich deutlich bemerkbar. Ohne Landing Zones entsteht schnell ein Flickenteppich aus unterschiedlichen Konfigurationen, durch den irgendwann niemand mehr vollständig durchblickt. Mit Landing Zones bleibt die Infrastruktur konsistent und damit auch wartbar.
Der Aufbau von Landing Zones ist für Unternehmen eine wichtige und grundlegende Entscheidung. Sie schaffen durch die solide Grundstruktur die Voraussetzung dafür, dass Cloud-Nutzung langfristig funktioniert und sicher, effizient und skalierbar bleibt. Governance-Regeln schützen die Infrastruktur dabei, ohne Teams auszubremsen, die Verzahnung mit DevOps-Prozessen wiederum sorgt dafür, dass Teams schnell und eigenständig arbeiten können. Indem sie Landing Zones von Anfang an richtig aufbauen, legen Unternehmen den wichtigen Grundstein für eine Cloud-Infrastruktur, die mit den Anforderungen des Unternehmens wachsen kann.
Mit EnterpriseClaw bringt Automation Anywhere KI-Agenten unter Unternehmenskontrolle. KI-Agenten sind kein Zukunftsthema mehr — viele Unternehmen erproben sie bereits in ersten Prozessen. Die eigentliche Herausforderung ist nicht die Technologie, sondern die Kontrolle: Wer hat Zugriff? Was dürfen Agenten tun? Wie lässt sich nachvollziehen, was ein Agent in einem Produktivsystem verändert hat? An dieser Stelle setzt EnterpriseClaw an, das Automation Anywhere am 19. Mai 2026 gemeinsam mit Cisco, NVIDIA, Okta und OpenAI vorgestellt hat.
Viele aktuelle KI-Agenten-Lösungen basieren auf einem einzelnen Sprachmodell, das Anfragen beantwortet oder einfache Aufgaben ausführt. Im Unternehmenseinsatz reicht das nicht. Agenten müssen in Live-Anwendungen arbeiten, mit Terminals und Browsern interagieren und Ergebnisse über mehrere Systeme hinweg zusammenführen, ohne den Kontext zu verlieren.
Automation Anywhere bezeichnet diesen Ansatz als „Claw-style“-Agenten: Agenten, die direkt in laufende Anwendungen eingreifen, statt nur über APIs zu kommunizieren. Das ermöglicht Prozesse, die klassische Automatisierung nicht abbilden kann, aber es erhöht gleichzeitig die Anforderungen an Sicherheit und Governance erheblich.
Die technische Grundlage von EnterpriseClaw besteht aus zwei Komponenten:
EnterpriseClaw ermöglicht den Betrieb autonomer KI-Agenten über verschiedene Infrastrukturen hinweg: in der Cloud, auf Desktop-Systemen, in gesicherten Unternehmensnetzwerken und on-premises. Unternehmen können dabei eigene Agenten — ob intern entwickelt oder aus externen Frameworks bezogen — parallel zu bestehenden Automatisierungen einbinden.
Die Plattform bietet zentrale Sicht auf alle Agenten-Aktivitäten:
Das ist eine Grundvoraussetzung für den produktiven Einsatz. Ein Agent, der ohne Protokoll in einem ERP-System oder einer Kundendatenbank arbeitet, ist aus Compliance-Sicht ein Risiko — unabhängig davon, wie gut er die eigentliche Aufgabe erfüllt.
Was EnterpriseClaw von anderen Agenten-Lösungen unterscheidet, ist das Partnerschaftsmodell. Automation Anywhere hat vier spezialisierte Anbieter eingebunden, die jeweils eine konkrete Lücke schließen:
Jeder dieser Beiträge adressiert eine reale Schwachstelle im Enterprise-Agenten-Einsatz. Zusammen bilden sie eine Plattform, die sowohl leistungsfähig als auch betrieblich verantwortbar ist.
EnterpriseClaw ist noch in der Preview-Phase. Die allgemeine Verfügbarkeit ist vor Ende 2026 geplant. Dennoch lohnt es sich, die strategische Richtung jetzt zu bewerten.
Für Unternehmen, die bereits Automation Anywhere einsetzen, wird der Einstieg in agentenbasierte Automatisierung deutlich niedrigschwelliger. Bestehende Automatisierungen bleiben erhalten, Agenten werden ergänzt, nicht ersetzt.
Für Unternehmen mit strengen Datenschutz- oder Compliance-Anforderungen ist die On-Premises-Option durch NVIDIA OpenShell ein zentrales Argument. Wer Sprachmodelle aus regulatorischen Gründen nicht in der Cloud betreiben kann, bekommt hier einen konkreten Lösungsweg.
Drei Fragen, die sich IT-Verantwortliche jetzt stellen sollten:
EnterpriseClaw zeigt, dass der Markt für KI-Agenten nicht mehr primär über Leistungsfähigkeit differenziert, sondern über Kontrollierbarkeit. Automation Anywhere setzt damit einen Standard, den andere Anbieter in den nächsten Monaten ebenfalls adressieren müssen. Für Unternehmen bedeutet das: Wer KI-Agenten ernsthaft einsetzen will, braucht keine Experimentierumgebung, sondern eine Governance-Strategie. Die Fragen nach Zugriffsrechten, Nachvollziehbarkeit und Datensouveränität sollten vor dem ersten produktiven Agenten-Einsatz beantwortet sein, nicht danach.
Die offizielle Ankündigung von Automation Anywhere findet sich im Automation Anywhere Press Room (Mitteilung vom 19. Mai 2026).
Hinter jeder schnellen Lösung steht ein echter Mensch, der genau weiß, was er tut. Unsere zertifizierten IT-Experten sind da, um Ihre Probleme schnell, freundlich und stressfrei zu lösen.
KI-Telefonassistent Webinar: In diesem Webinar zeigen wir, wie Unternehmen Telefonanrufe mit KI strukturierter bearbeiten und daraus automatisierte Folgeprozesse machen können.
Viele Unternehmen testen KI-Telefonie aktuell als Demo. Spannend wird das Thema aber erst, wenn aus dem Gespräch ein sauberer Prozess entsteht: Anliegen verstehen, Informationen erfassen, Daten strukturiert übergeben und anschließend automatisch weiterverarbeiten.
Im Webinar zeigen wir diesen Ablauf mit Fonio.ai als KI-Telefonassistent und n8n als Workflow-Orchestrierung. Fonio.ai übernimmt das Gespräch und die Erfassung der Informationen. n8n verarbeitet die Daten weiter und stößt Folgeprozesse an, zum Beispiel eine Bestätigung, eine interne Benachrichtigung, eine Aufgabe oder einen CRM-Eintrag.
Der Praxis-Use-Case: eine telefonische Webinar-Anmeldung. Eine Person ruft an, der KI-Assistent fragt die notwendigen Informationen ab und übergibt die Daten an n8n. Dort wird der nächste Prozessschritt automatisch ausgelöst.
Stehen Sie vor der Frage, wie Ihre Lagerstrategie unter SAP S/4HANA aussehen soll? In diesem Webinar vergleichen wir SAP Stock Room Management, SAP EWM und SAP Logistics Management (LGM) inklusive klarer Entscheidungskriterien, Vor-/Nachteilen und typischen Einsatzszenarien aus der Praxis.
Im Webinar erhalten Sie Antworten auf die Fragen:
Viele Unternehmen nutzen historisch SAP WM und müssen im Zuge von S/4HANA ihre zukünftige Lagerlösung festlegen.
Stock Room Management basiert technisch auf WM (Tabellen/Customizing/Transaktionen), bietet aber eingeschränkten Funktionsumfang und ist eher für einfachere, manuell geprägte Lager gedacht.
SAP EWM ist die strategische, langfristig ausgerichtete Lösung für Lagerprozesse, geeignet von „einfach“ bis „hochkomplex“ (inkl. Varianten Embedded/Dezentral und Basic/Advanced).
SAP Logistics Management (LGM) ist die neue, cloud-basierte SAP-Lösung, die Warehouse Execution und Transportation Dispatching plus Network Collaboration in einer Plattform kombiniert und explizit auf kleine bis mittelkomplexe Versand-/Lagerstandorte zielt (inkl. AI-Assistenz).
Im Webinar ordnen wir ein, für wen welche Lösung passt, wo die Grenzen liegen und wie man daraus eine Roadmap ableitet.
Let’s talk IT – seien Sie dabei
Die Teilnahme ist kostenlos – melden Sie sich an und bringen Sie gerne konkrete Fragen aus Ihrer Lager-/S/4HANA-Roadmap mit.
Die Bedeutung von Nachhaltigkeit in der Informationstechnologie nimmt stetig zu, sowohl aus ökologischer als auch aus ökonomischer Perspektive. In diesem Webinar vermitteln wir Ihnen grundlegendes Wissen zu IT Sustainability und zeigen auf, wie Sie Nachhaltigkeitsprinzipien effektiv in Ihrer IT-Strategie verankern können.
Sie erfahren, wie sich nachhaltige IT auf den Energieverbrauch, die Reduzierung von CO2-Emissionen und die Verlängerung der Lebensdauer von IT-Komponenten auswirkt. Wir besprechen, wie Unternehmen durch die Implementierung grüner IT-Praktiken nicht nur die Umwelt schützen, sondern auch langfristig Kosten einsparen können.
Zusätzlich erhalten Sie Einblick in erfolgreiche Fallstudien und lernen Best Practices kennen, mit denen Sie Ihre IT-Prozesse und -Systeme nachhaltiger gestalten können.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
