Komplexe IT braucht Erfahrung über Technologiegrenzen hinweg.
EMOS unterstützt anspruchsvolle Enterprise-Landschaften – von Mainframe und Legacy über moderne Softwareentwicklung bis Cloud, Quality Engineering, Security und Operations.
In bestehende Landschaften integrierbar.
Enterprise-IT besteht selten aus einer einzigen Plattform. Wir verbinden Erfahrung mit gewachsenen Systemen, modernen Architekturen und spezialisierten Entwicklungs-, Test-, Security- und Betriebsprozessen.
Neue KI-Anwendungen, regulatorische Anforderungen und Plattformentscheidungen wirken auf bestehende Konzernlandschaften. Die Herausforderung liegt selten in einem einzelnen Werkzeug: Daten, Verantwortlichkeiten, Lieferanten und Geschäftsprozesse müssen gemeinsam betrachtet werden.
Einordnung:
01
KI vom Pilotprojekt in einen verantwortbaren Betrieb überführen
Ein erfolgreicher Demonstrator beantwortet noch nicht, wer Datenzugriffe freigibt, Modelländerungen prüft und fehlerhafte Ergebnisse erkennt. Mit mehreren Fachbereichen entstehen unterschiedliche Datenräume, Anbieter und Risikoprofile. Der AI Act wird gestaffelt angewendet; Anforderungen sind nach Anwendung und Unternehmensrolle einzuordnen. Ein allgemeines KI-Regelwerk ersetzt diese Bewertung nicht.
Sinnvoller nächster Schritt: Anwendungen inventarisieren und Verantwortliche benennen. Vor einer breiten Einführung Berechtigungen, Datenwege, Qualitätsmaßstäbe und menschliche Freigaben festlegen. Modell-, Prompt- und Indexänderungen an stabilen Vergleichsfällen prüfen und auch Kosten sowie fachliche Fehler im Betrieb beobachten.
Resilienz und Lieferantenrisiken praktisch nachweisbar machen
NIS-2 macht für erfasste Unternehmen die Organisation von Sicherheitsrisiken und Vorfallmeldungen besonders relevant. Im Finanzsektor adressiert DORA zusätzlich unter anderem Risiken aus IKT-Drittdienstleistungen. Die Regelwerke haben unterschiedliche Anwendungsbereiche: Weder die Konzernzugehörigkeit allein noch ein Lieferantenfragebogen begründet automatisch dieselben gesetzlichen Pflichten für alle Beteiligten.
Sinnvoller nächster Schritt: Kritische Geschäftsservices mit ihren technischen und externen Abhängigkeiten abbilden. Verantwortlichkeiten und Eskalationswege abstimmen und Wiederherstellung sowie Ausweichverfahren erproben. Für regulierte Finanzunternehmen gehören auch die Bewertung und vertragliche Steuerung von IKT-Drittparteien in diese Betrachtung.
Mainframe und Kernsysteme öffnen, ohne Transaktionen zu gefährden
Neue digitale Kanäle und KI-Assistenten benötigen Zugriff auf bestehende Fachfunktionen. Eine API allein beseitigt aber weder Batchfenster noch historische Datenmodelle oder transaktionale Grenzen. Entscheidend ist, wie Auskunft, Änderung und Fehlerbehandlung zwischen neuen Anwendungen und dem fachlich führenden Kernsystem zusammenspielen.
Sinnvoller nächster Schritt: Mit einer klar abgegrenzten Funktion beginnen. Datenverantwortung, Lastgrenzen und Wiederholungsverhalten definieren; fachliche Ergebnisse mit dem bestehenden Zugang vergleichen. Schreibende Vorgänge erst erweitern, wenn Doppelverarbeitung, Rückwege und Beobachtbarkeit geklärt sind.
Entwicklungsplattformen als gepflegte interne Produkte aufbauen
Wenn jedes Team Pipelines, Sicherheitsprüfungen und Telemetrie neu kombiniert, vervielfacht sich der Pflegeaufwand. Eine interne Plattform kann wiederkehrende Aufgaben bündeln. Ihr Nutzen hängt jedoch davon ab, ob Standards den tatsächlichen Bedarf treffen und bestehende Anwendungen bei Updates mitgenommen werden. Ein zentrales Portal allein schafft diese Wirkung nicht.
Sinnvoller nächster Schritt: Einen häufigen Bereitstellungsweg standardisieren: mit unterstützten Laufzeiten, Geheimnisverwaltung, Tests und Betriebsinformationen. Zuständigkeit, Versionswechsel und begründete Ausnahmen regeln. Den Erfolg anhand kürzerer Durchlaufzeiten und geringerer manueller Nacharbeit bewerten.
Cloud-Abhängigkeiten, Kosten und Wechselmöglichkeiten zusammen bewerten
Eine Multi-Cloud-Landschaft ist nicht automatisch ausfallsicher oder leicht wechselbar. Identitätsdienste, Datenformate und gemeinsame Netzwerkkomponenten können weiterhin zentrale Abhängigkeiten bilden. Auch KI-Dienste bringen Verbrauchskosten und zusätzliche Datenwege mit. Eine tragfähige Architekturentscheidung berücksichtigt deshalb Betrieb, Wirtschaftlichkeit und den Aufwand eines späteren Wechsels.
Sinnvoller nächster Schritt: Für einen kritischen Service Datenexport, Wiederanlauf und alternative Betriebswege praktisch untersuchen. Kosten einer fachlichen Leistung zuordnen und nicht nur einzelne Infrastrukturpreise vergleichen. Zusätzliche Plattformen erst dann einführen, wenn ihr Nutzen den dauerhaften Betriebsaufwand rechtfertigt.
Produktsicherheit über Releases und Lieferketten organisieren
Für Produkte im Anwendungsbereich des Cyber Resilience Act müssen Hersteller Sicherheitsverantwortung über den Lebenszyklus einplanen. Bestimmte Meldepflichten gelten seit dem 11. September 2026; die wesentlichen weiteren Anforderungen folgen am 11. Dezember 2027. In Konzernen sind dabei Produktverantwortung, zugekaufte Komponenten und dezentrale Entwicklungsteams miteinander zu verbinden.
Sinnvoller nächster Schritt: Ausgelieferte Versionen und Komponenten nachvollziehbar zuordnen. Einen verbindlichen Ablauf für Schwachstellenbewertung, Meldungen und Sicherheitsupdates etablieren. Prüfungen in die Auslieferung integrieren und dafür sorgen, dass Erkenntnisse zu einer Bibliothek alle tatsächlich betroffenen Produkte erreichen.
