No AI Without IA

Ist es nicht faszinierend: man wirft ein paar Prompts in einen Chat und man bekommt die Antworten auf die Frage, ja sogar einen kompletten generierten Artikel. Es ist der Alltag, in dem wir alle schon seit ein paar Jahren die KI nutzen (Use AI) und uns nur wundern, wie genauer und ausführlicher die KI-Modelle (Large Language Models, LLM) mit der Zeit werden. Eine weitere neuere Entwicklung ist umso faszinierender – die Möglichkeit mit ein paar Prompts eine ganze App zu generieren, ohne sich um Coding zu kümmern. Insbesondere in den letzten Monaten mit Tools wie Claude Code, Google’s Antigravity bzw. Cursor ist die Generative KI (GenAI) aus den Kinderschuhen von Vibe Coding rausgekommen und demokratisiert das Erstellen von Lösungen ganz ohne Programmierkenntnisse (Make AI).

Man kann sich die zwei Fragen logischerweise stellen:

• 1. Wird die Suche bei Use AI obsolet?
• 2. Braucht man sich Gedanken bei Make AI über Architektur machen?

Die Erstere lässt sich mittlerweile sicher beantworten, dass es sich um das nächste Level von Use AI handelt, wobei die intelligente Suche ein integraler Bestandteil davon ist und es in der Verantwortung der Nutzer liegt, auf die Quellinformationen zwecks Verifikation und Vermeidung von Fehlinterpretationen / Halluzinationen zuzugreifen.

Bei der Zweiteren - Make AI - befinden wir uns auf der Hype-Kurve im steilen Aufstieg – jede neue Ankündigung einer neuen LLM-Version bringt Turbulenzen bei den Unternehmenssoftware- bzw. SaaS-Anbieteraktien. Erinnern wir uns nur an den Folgen von Ankündigungen, wie „Claude Code und Claude Cowork… SaaS-Killer“ bzw. Claude’s Fähigkeit COBOL-Code zu migrieren. Dabei hat IBM erste KI-gestützte COBOL-Modernisierungen schon vor Jahren angeboten.

Daher werde ich mich in den folgenden 8 Thesen auf der zweiten Frage konzentrieren: braucht man heutzutage eine Architektur bzw. Integrationsarchitektur (IA). Dabei werde ich einige Beispiele aus dem Umfeld Manufacturing bringen, wo ich seit 14 Jahren unterwegs bin.

Architektur verbindet KI mit Ihren Unternehmensdaten

Jede KI lebt von Daten, sei es zum Trainieren der generativen Modelle, sei es zu deren konkreten Anwendung. Der größte Nutzen entsteht, wenn man KI-Prompts und Modell-Aufrufe mit traditionellen Datenstrukturen, Unternehmensdatenbanken, Anwendungs-APIs und exzitierender Business-Logik unter menschlicher Aufsicht kombiniert. Dabei handelt es sich um eine klassische Integration der verteilten Anwendungen und Daten-Pools im Unternehmen, die durch eine unternehmensübergreifende Integrationsarchitektur ermöglicht wird. Zentrale Komponenten dieser Architektur sind in Manufacturing:

• Standard-Schnittstellen, von OPC UA bis REST-APIs als Basiselemente
• der Manufacturing Service Bus (MSB) mit Protokoll-Adaptern, Mapping, Routing und Orchestrierung
• IoT-Gateways, die Legacy OT-Protokolle in Standard-Schnittstellen umwandeln
• Event-gesteuertes Messaging und Queuing
• Inklusive nicht-funktionale Aspekte, wie Skalierbarkeit, Hochverfügbarkeit, Performance, Sicherheit, Versionierung und Validierung, insbesondere in regulatorischen Umgebungen, wie MedTech und Pharma

Ein Beispiel für die erfolgreiche Verknüpfung zwischen GenAI und klassische Integrationsarchitektur ist GEC ONCITE Digital Production System. Als zentrale Drehscheibe für die produktionsrelevanten Daten, integriert ONCITE DPS Betriebs- und Maschinendaten in einem harmonisierten Datenmodell und ermöglicht damit eine einheitliche Visualisierung, Analyse und Produktionssteuerung.

Neben verschiedenen Dashboards und einer 3D-Visualisierung des Shopfloors wird dabei mit Hilfe der KI-Komponente ONCITE-X eine dialogbasierte Abfrage zum laufenden Auftrag, zu Qualität, Ausbringung und Maschinenzuständen, indem man mit einem MCP-Server (Model Context Protocol), die in ONCITE DPS enthaltenen operativen Daten für einen Chat öffnet.

Die beidseitige Integration von Anwendungen, Daten und Anlagen mit Hilfe eines Manufacturing Service Bus als Bestandteil der ONCITE DPS, dessen harmonisiertes Datenmodell und standardisierte REST-APIs haben diese AgenticAI-Erweiterung und Verknüpfung mit einer nativen menschlichen Interaktion erleichtert, so dass die erste Version von ONCITE-X innerhalb von 6 Wochen geliefert werden konnte.

Architektur erlaubt die Nutzung unterschiedlicher Datenmodelle / Standards

Einen weiteren interessanten Anwendungsbereich von GenAI in enger Verknüpfung mit Integrationsarchitektur habe ich bei der Verknüpfung von semantisch ähnlichen aber syntaktisch unterschiedlichen Datenmodellen im Rahmen der Factory-X-Initiative als Product Owner vom Traceability-Projekt erlebt. Die vom Bundesministerium für Wirtschaft und Energie (BMWE) gesponserte Initiative fokussiert sich auf den sicheren, standardisierten und souveränen Austausch von Daten zwischen Fabrikausrüster und -betreiber in einem Datenraum standardmäßig über einen sogenannten MX-Port, ohne Abgabe des Dateneigentums bzw. der -kontrolle.

Der MX-Port regelt die Authentifizierung und Autorisierung im verteilten Datenraum, allerdings ist der für das Payload „blind“. Im Traceability-Projekt, einem der 11 abgedeckten Use Cases hatte unser Team die Herausforderung, ein Traceability-Datenmodell zu definieren, das sowohl standardisiert, aber auch flexibel ist. Wir haben das minimalistische Vorgehen gewählt, zunächst die wichtigsten Datenobjekte, die eine Rolle für Traceability spielen, zu identifizieren, wie die auftragsbezogenen Buchungen, Prozessdaten (Konfigurations-, Qualitätstests-Daten, Alarme/Meldungen) und Maschinenzustände mit deren Bezug auf die Produkte, Seriennummern, Batches, AsIs-BOM (Bill of Material), verwendete Equipments bzw. Material, etc. Als Bestandteil eines History Record können sie für den Austausch über den Datenraum bereitgestellt werden.

Für weitere über das Minimal-Set von definierten Feldern hinausgehende Daten haben wir ein Key-Value-basiertes Objekt Attributes vorgesehen. Die Verknüpfung erfolgte über Fremdschlüssel-IDs bzw. Timestamps. Da jedes MES in der Lage ist, die Daten für so einen History-Record zu liefern, kann die Transformation mit einem Integrationsservice / MSB in das definierte Format überführt werden. Mit Hilfe von zwei MCP-Servern, einer auf der MX-Port-Empfangsseite und einem zu ONCITE DPS (stellvertretend für ein beliebiges MES), und den entsprechenden Tools, haben wir demonstriert, wie eine Quality Notification von einem Kunden über den Datenraum empfangen, analysiert und ein Traceability History Record zurückgeschickt werden kann. Dabei erfolgen die Mappings auf Basis der MCP Tools mit Hilfe des verwendeten LLMs (in diesem Fall Gemini Flash).

Durch die Kombination von GenAI und einer soliden Integrationsarchitektur zeigt dieses Beispiel, wie Standardkonformität mit Flexibilität kombiniert werden kann.

Architektur schützt Ihre Daten

Mit Hilfe von MCP und den entsprechenden Tools können die Unternehmensdaten kontrolliert und standardisiert der GenAI zur Verfügung gestellt werden. Allerdings sind hier wichtige Datenschutzaspekte zu berücksichtigen.

• Bleiben meine vertraulichen Daten innerhalb des Unternehmens?
• Kann es zu einem ungewollten Zugriff auf die Daten über den MCP-Server kommen?
• Ist es möglich durch Prompt-Engineering an vertraulichen Daten zu kommen?
• Kann es zu einer ungewollten Nutzung zum Training des verwendeten LLMs?
• Wie reduziere ich Halluzinationen?
• Können KI-Agenten ein Sicherheitsrisiko für meine gesamte Intranet-Infrastruktur bringen?

Ein erprobtes Mittel für die Verbesserung der Genauigkeit und des Datenschutzes ist Retrieval-Augmented Generation (RAG). Dokumente oder strukturierte Daten werden in Chunks aufgeteilt und mit Hilfe von Embeddings-Modellen tokenisiert und in Vektoren übersetzt. Letztere zusammen mit den Chunks und Annotationen (für die ursprüngliche Zuordnung der Daten) werden in Vector-Datenbanken indexiert. Im Falle einer Suchanfrage (eines Prompts), wird diese analog per Embeddings in einen Vektor umgewandelt und nach semantischer Korrelation mit den gespeicherten Vektoren in der Datenbank verglichen und gerankt. Zusätzlich kann man auch Filter anwenden, zum Beispiel für bestimmte Benutzergruppen. Durch RAG hat man einen deutlich größeren Einfluss auf die Verarbeitung der Daten und hiermit kann man die Halluzinationen erheblich reduzieren.

Ein Beispiel dazu ist der KI-gestützte Montageassistent für den Einsatz in der Spezialmontage in einem der Werke eines namhaften Maschinenbauers, wo RAG in einem Piloten zum Zweck der Präzisierung der Montageanweisungen angewendet wurde, die einzig und allein aus den Auftragsstücklisten und Kundenzeichnungen generiert wurden. Folgendes Diagramm zeigt den Fluss der Daten mit den zwei Preprocessing- und ChatBot-Phasen.

Dabei ist zu erwähnen, dass dieser erfolgreiche und von Operatoren, Planer und Werksmanagement sehr begehrte Pilot in Verzug geriet. Der Grund: die Verzögerung der Digitalisierungsinitiative, die den kontinuierlichen Fluss der Aufträge, BOMs und Zeichnungen ins Preprocessing ermöglichen sollte. Hiermit hat das Fehlen einer realisierten Integrationsarchitektur den Business Case der KI-Lösung zerstört.

Im Unterschied zu den LLMs, sind Embedding-Modelle grundsätzlich stateless. Sie haben kein Gedächtnis und erweitern das Kontext-Fenster nicht, da die Anfragen punktuell zu den einzelnen Chunks erfolgen. Ein Restrisiko verbleibt, wenn man mit Hilfe eines externen LLMs die Antworten anpasst. Dabei ist ein 100 prozentiger Datenschutz durch Nutzung selbst gehosteter Embedding-Modelle und LLMs. Eine weitere Alternative ist durch Absicherung durch Garantien im Rahmen von Enterprise-Accounts, wie bei Azure, AWS oder Google. Bei Consumer- und Free-Accounts ist die Garantie nicht gegeben, dass kein Logging, Kontextualisierung und Trainieren auf den Chatverläufen durch den Anbieter erfolgt.

Architektur erhöht Geschwindigkeit und Benutzerfreundlichkeit

Ein weiterer Aspekt des KI-gestützten KI-Assistenten waren die besonderen Anforderungen der Operatoren im Werk:

• Komplexe hierarchische BOM-Strukturen
• Hohe Präzision unabdingbar
• Keine Halluzinationen erlaubt
• Keine Suche, kein Prompting
• Keine langen Wartezeiten (für Thinking)
• > 90% Hands-Free
• Minimale Intervention: click, scroll, zoom
• Kontrolliertes Power-User-Feedback

Daher wurde die Anwendungsarchitektur so gewählt, dass das Frontend zwar wie einen Chat aussah, allerdings die Navigation minimalistisch gemäß Anforderungen gestaltet wurde. Um die für GenAI typischen Wartezeiten zu reduzieren, wurde die Online-Nutzung von der Preprocessing Batch-Phase getrennt und vorrangig auf lokale Inhalte (aus der Vector-Datenbank) ausgerichtet:

Das Beispiel zeigt eine geschickte und auf die Kundenanforderungen dedizierte Kombination aus GenAI, Integrations- und Anwendungsarchitektur.

Architektur schafft Souveränität

„An Open-Source Chinese Model Just Topped the Coding Leaderboard… Z AI released GLM-5.1, an open-source model that scored…”

Ähnliche Meldungen begegnen uns fast jede Woche. Zum einen überholen sich die Modelle dauernd in ihrer Performance und Präzision, zum anderen sind verschiedene Modelle besser oder schlechter geeignet für unterschiedliche Use Cases. Nicht zuletzt ist auch eine Balance mit den Kosten erforderlich. Oft lassen sich aus Datenschutzgründen manche Use Cases ausschließlich auf selbst gehosteten Plattformen realisieren. Durch Nutzung eines Orchestrators, einer Workflow-Automation/KI-Entwicklungsplattform können komplexe Agentensysteme und Software-Lösungen gebildet werden. Insbesondere erlauben sie den Wechsel von LLMs bzw. deren Nutzung für bestimmte Zwecke.

Der 3-Säulen-Stack

Auch hier spielt die Architektur der Anwendung eine Rolle. Ein Beispiel ist der 3-Säulen-Stack, eine moderne Software-Architektur für KI-Anwendungen, die auf der strikten Trennung von Intelligenz, Funktionalität und Steuerung basiert.

Die erste Säule bildet das LLM-Gateway (liteLLM, Bifrost), das als Abstraktionsschicht verschiedene Sprachmodelle über eine einheitliche Schnittstelle verfügbar macht und so Anbieterunabhängigkeit gewährleistet.

Die zweite Säule umfasst das Model Context Protocol (MCP), das als standardisierte Verbindungsebene dient, um dem Modell externen Kontext und Werkzeuge – wie Datenbankzugriffe oder API-Anbindungen – modular bereitzustellen.

Die dritte Säule ist das Agenten-Framework (Pydantic AI oder LangGraph), welches die logische Orchestrierung übernimmt und entscheidet, wann welche Intelligenz auf welche Werkzeuge zugreift. Durch diese modulare Struktur lassen sich einzelne Komponenten austauschen oder skalieren, ohne die gesamte Anwendungslogik neu implementieren zu müssen.

Auch hier ist es notwendig aus Datenschutzgründen zu beachten, wo die Agentenlogik implementiert ist – lokal (liteLLM, Bifrost, Portkey AI Gateway oder Ollama) oder mit Cloud-Gateways, wie OpenRouter oder Portkey hosted – bzw. wo das LLM deployed ist.

Architektur spart Geld

Gute selbst designte und programmierte Anwendungen weisen meist eine sparsame kontrollierte Nutzung einzelner API-Calls gegen LLMs auf. Die Kosten bei den oben genannten Beispielen lagen zwischen 10-20€ monatlich. Entwicklungsplattformen, wie GitHub Copilot, Cursor, Antigravity oder Claude Code nutzen hingegen intensiv und oft eine vorgegebene Anzahl von LLMs.

Die ökonomische Verwendung von LLMs innerhalb agentenbasierter Systeme basiert auf der konsequenten Entkopplung von rechenintensiven Denkprozessen und rein administrativen oder explorativen Aufgaben.

Durch die Implementierung einer Tiered Skill Architecture wird sichergestellt, dass kosten- und quotenintensive Hochleistungsmodelle wie Claude 4.6 Opus oder Gemini 3.1 Pro ausschließlich für komplexe logische Probleme, Sicherheitsanalysen oder Architekturfragen reserviert bleiben.

Das methodische Vorgehen gliedert sich dabei in drei Kernbereiche:

• 1. Kontextuelle Vorverarbeitung (Context Pruning): Ein performantes, kosteneffizientes Modell (Gemini 3 Flash) fungiert als Primärinstanz. Es durchsucht umfangreiche Datenmengen und erstellt komprimierte Briefings. Dadurch wird die Token-Last für das nachgeschaltete High-End-Modell signifikant reduziert, da dieses lediglich den relevanten „Signalanteil“ statt des gesamten Datenrauschens verarbeiten muss.
• 2. Bedingungsbasiertes Routing: Über eine Skill-Manifest-Datei werden logische Trigger definiert. Aufgaben, die Standard-Boilerplate, Dokumentationen oder einfache Syntaxkorrekturen betreffen, werden automatisiert an effizientere Modelle delegiert. Ein „Modell-Upgrade“ erfolgt nur dann, wenn vordefinierte Komplexitätsschwellen überschritten werden.
• 3. Modularisierung durch prozedurale Skills: Routineabläufe werden als fest codierte Funktionen (Skills) hinterlegt. Anstatt die Planung dieser Abläufe bei jedem Aufruf durch teure Inferenzschritte neu zu generieren, beschränkt sich das LLM auf den gezielten Aufruf vordefinierter Werkzeuge. Dies minimiert die Menge der zu generierenden Output-Tokens und steigert gleichzeitig die Verlässlichkeit der Ausführung.

Durch diese granulare Steuerung der Modellressourcen lassen sich die Betriebskosten sowie die Inanspruchnahme von Nutzungskontingenten bei gleichbleibender Ergebnisqualität um bis zu 90 % optimieren.

Architektur kombiniert mit Methodik ermöglicht Kontrolle über KI

Eines der größten Bedenken beim Einsatz der AgenticAI ist die Gefahr eines Kontrollverlusts. Ein aktuelles Beispiel war neulich der Bericht einer Sicherheitsforscherin bei Meta, wie ein OpenClaw-KI-Agent versehentlich ihr gesamtes E-Mail-Postfach gelöscht hat. Welche Konsequenzen ein außer Kontrolle geratener Agent im Unternehmens-Intranet bringt, kann man sich gut vorstellen. Es geht darum, diese fortgeschrittenen Technologien mit vollem Verständnis und Bewusstsein einzusetzen. Die Lösung dazu ist, eine saubere Architektur mit einer Methodik zu kombinieren, die auf Erfahrung und Best Practices basiert.

Mit adSCAILE (adesso Smart Cycle for AI-enhanced Lightweight Software Engineering) führt adesso einen technologie-agnostischen Prozess für die skalierbare, agentische Softwareentwicklung ein.

Im Gegensatz zu reaktiven KI-Tools agieren die eingesetzten KI-Agenten proaktiv und zielorientiert, indem sie komplexe Aufgaben eigenständig planen, in Teilschritte zerlegen und mithilfe externer Werkzeuge umsetzen. Dies umfasst den gesamten Zyklus von der Planung über die Codegenerierung bis hin zum Testing.

Der Prozess basiert auf zwei zentralen Säulen:

• Strukturiertes Framework: adSCAILE integriert langjährige Projektexpertise und Best Practices als regulatorisches Gerüst, um die Effizienz der KI-Agenten sicherzustellen und Fehlentwicklungen vorzubeugen.
• Hybride Rollenverteilung: Der Mensch fungiert als Orchestrator, der strategische Ziele definiert und Architekturentscheidungen trifft. Die KI übernimmt die operative Implementierung in verkürzten Entwicklungszyklen von zwei bis vier Tagen.

Ziel des Einsatzes von adSCAILE ist eine signifikante Beschleunigung der Iterationen, eine Steigerung der Softwarequalität sowie eine verkürzte Time-to-Market sowohl bei Neuentwicklungen als auch bei der Modernisierung von Altsystemen.

Da adSCAILE tool-agnostisch ist, habe ich die Methodik in einem kleinen Test mit Antigravity ausprobiert. Dabei handelte es sich um eine dritte Iteration eines ähnlichen Use Case – Erstellung einer OPC UA Browse Anwendung auf Basis einer NodeSet-Datei, die auf Basis der VDMA Companion Specifications das Datenmodell des Servers vorgibt. Anlass war, dass ich in einem Projekt die Möglichkeit zur Erstellung eines OPC UA Servers für Simulationstests brauchte. Bei meinem ersten Versuch kurz nach Bekanntgabe von chatGPT war das Ergebnis ein Codefragment, der mir lediglich als Idee für das Backend gedient hat. Mein zweiter Versuch vor nicht mal einem Jahr mit Vibe Coding auf Basis GitHub Copilot ergab ein Programm, das trotz definierter Guardrails mit jeder Iteration ziemlich unübersichtbare Code-Strukturen ergab.

Das Ergebnis meines letzten Versuchs ergab eine fertige Anwendung, die nicht nur über mehreren Iterationen und Ausbauten ihre saubere Code-Basis beibehalten konnte, sondern auch team-basierte Entwicklung mit meinem Kollegen unter Nutzung von Claude Code als Teil vom streb-Framework erlauben konnte. Dabei durchlief der Entwicklungsprozess alle Stufen – von der Generierung der Issues, über die Erstellung der Use Cases, der Architektur und des Workflows, bis hin zur Programmierung und Durchlaufen der erstellten Test Cases.

Hier das Ergebnis nach einer guten Handvoll Iterationen:

Durch das Prinzip “confirm before acting”, gab es die Möglichkeit jede Stufe des Prozesses zu prüfen, validieren und anzupassen. Hiermit kann die absolute Kontrolle ausgeübt werden.

Architektur schafft Ordnung

Die Demokratisierung von der Softwareentwicklung erlaubt es allen im Unternehmen ihre Ideen in Code zu gießen. Jensen Huang, CEO von Nvidia, hat ein neues Vergütungsmodell vorgeschlagen, bei dem Ingenieure KI-Rechen-Tokens im Wert von etwa 50 % ihres Grundgehalts erhalten, um die Produktivität zu steigern.

Allerdings schafft diese niedrige Schwelle von Make AI auch alle Voraussetzungen, ein Chaos von zwar interessanten Anwendungen zu schaffen, die teilweise dieselben Probleme lösen und immer wieder eine Menge von Token im Unternehmen verbrennen. Aus Unternehmenssicht ist es unabdingbar hier eine Ordnung zu schaffen. Die Lösung dazu liefert eine weiter Architekturdisziplin: die Enterprise Architecture (EA).

In der agentischen Softwareentwicklung übernimmt die EA eine kritische Kontroll- und Steuerungsfunktion, um die Agilität der KI-Agenten mit den Anforderungen der IT-Governance in Einklang zu bringen. Da Agenten autonom Code generieren und externe Ressourcen allozieren können, definiert die EA die verbindlichen Leitplanken in Form von standardisierten Schnittstellen, Sicherheitsvorgaben und Compliance-Richtlinien. Diese Governance stellt sicher, dass agentisch erstellte Applikationen keine technischen Schulden produzieren oder Schatten-IT-Strukturen fördern, sondern nahtlos in die bestehende Bebauungsplanung des Unternehmens integriert werden. Die EA fungiert hierbei als „Systemarchitekt“, der die Interoperabilität zwischen verschiedenen Agenten-Ökosystemen gewährleistet und die Qualitätssicherung durch automatisierte Architektur-Checks (Architecture-as-Code) institutionalisiert.

Um das Innovationspotenzial dieser beschleunigten Entwicklung voll auszuschöpfen, bietet sich die Etablierung eines Enterprise App Stores an. Diese zentrale Plattform dient als kuratierter Marktplatz für die im Unternehmen agentisch erstellten Anwendungen und Micro-Services.

Das Konzept des Enterprise App Stores gibt der IT-Organisation für die zentral angebotenen Apps Sicherheit durch Prüfung der Einhaltung der EA-Vorgaben, Wiederverwendbarkeit, Nutzungs- und Kostentransparenz sowie Lizenzmanagement und Einhaltung der regulatorischen Anforderungen (EU AI Act) zu gewährleisten.

Durch die Verbindung von strenger EA-Governance und einem niederschwelligen App-Store-Modell transformiert sich die IT-Organisation von einem reinen Dienstleister hin zu einem Plattform-Provider, der die Geschwindigkeit der KI-Entwicklung sicher und skalierbar steuerbar macht.

Fazit

Mit Hilfe einer stabilen Architektur, die die Datenintegration, Anwendungs-Design unternehmensweite Nutzung umfasst, und einer auf Best Practices basierten Methodik wird KI zum Produktivitäts- und Beschleunigungsfaktor und erlaubt den Übergang vom reinem Prototyping mit einem 95%-Anteil gescheiterter Pilote zu einem produktiven und nachhaltigen Betrieb. Dabei werden die Kernprinzipien für Vertrauen und Transparenz, die IBM schon vor GenAI und AgenticAI aufgestellt hat, eingehalten:

• 1. Der Zweck von KI besteht darin, die menschliche Intelligenz zu erweitern
• 2. Daten und Erkenntnisse gehören ihren Erstellern
• 3. Neue Technologien müssen transparent und erklärbar sein