Von der Idee zur Architektur: Wie eine KI-Softwareplattform entsteht

Nachdem in den ersten beiden Artikeln dieser Serie zunächst die relevanten Problemfelder identifiziert und anschließend wirtschaftlich sinnvolle Lösungsansätze abgeleitet wurden, stellt sich nun die entscheidende Frage:

Wie werden diese Entscheidungen in eine tragfähige, langfristig nutzbare Systemarchitektur überführt?

Denn genau hier scheitern viele Initiativen. Nicht an Ideen. Nicht an Technologie. Sondern daran, dass Lösungen isoliert entstehen – ohne ein gemeinsames architektonisches Fundament.

KI wird dann zu einer Sammlung einzelner Features. Ein Chatbot hier, ein Modell dort, ein Prototyp in einem Fachbereich. Was fehlt, ist ein strukturiertes System, das diese Fähigkeiten integriert, steuert und langfristig weiterentwickelbar macht.

Der eigentliche Wendepunkt: Von Einzellösungen zur Systemlogik

Bis zu diesem Punkt der Serie wurde bewusst vermieden, über konkrete Technologien oder Modelle zu sprechen. Der Fokus lag auf Problemen und Entscheidungen.

Jetzt verschiebt sich die Perspektive.

• Lösungen müssen zusammenarbeiten
• Entscheidungen müssen nachvollziehbar bleiben
• Systeme müssen erweiterbar sein
• Abhängigkeiten müssen kontrollierbar bleiben

Das bedeutet: KI darf nicht als Feature gedacht werden – sondern als Bestandteil der Systemarchitektur.

Warum klassische Integrationsansätze nicht ausreichen

Viele Unternehmen versuchen, KI direkt in bestehende Systeme zu integrieren. Ein Modell wird in eine Anwendung eingebettet, ein Service ergänzt, ein Workflow erweitert.

• Fachlogik und KI-Logik vermischen sich
• Modelle werden schwer austauschbar
• Abhängigkeiten zu Anbietern wachsen
• Qualität und Verhalten werden schwer kontrollierbar

Das System verliert an Klarheit. Genau hier braucht es eine neue Schicht in der Architektur.

Der AI Capability Layer

Ein belastbarer Ansatz besteht darin, KI nicht als monolithisches Modell zu betrachten, sondern als Sammlung klar definierter Fähigkeiten.

Diese Fähigkeiten werden in einer eigenen Schicht organisiert – dem sogenannten AI Capability Layer (eine eigenständige Architekturschicht, in der einzelne, klar definierte KI‑Fähigkeiten – z. B. Klassifikation, Extraktion oder Anomalieerkennung – als wiederverwendbare Services bereitgestellt und unabhängig von konkreten Modellen orchestriert werden).

Die Idee dahinter ist einfach, aber wirkungsvoll:

Statt ein großes Modell für alles zu verwenden, werden spezialisierte Fähigkeiten für klar abgegrenzte Aufgaben eingesetzt.

• Klassifikation von Dokumenten oder Fällen
• Extraktion relevanter Informationen
• Erkennung von Anomalien
• Bewertung von Qualität
• Zusammenfassung von Inhalten

• klassische Logik (regelbasierte Software, z. B. Validierungen, Workflows oder If-Then-Regeln; verhält sich deterministisch, ist vollständig nachvollziehbar und ideal für klar definierte Prozesse)
• spezialisierte Modelle (kleine, auf eine konkrete Aufgabe trainierte KI, z. B. Klassifikation, Extraktion oder Anomalieerkennung; effizient, präzise und gut kontrollierbar für klar abgegrenzte Anwendungsfälle)
• generative Modelle (große, flexible KI-Modelle, die Inhalte erzeugen oder komplexe Zusammenhänge interpretieren, z. B. Texte zusammenfassen, Antworten formulieren oder Bewertungen erstellen; vielseitig, aber weniger deterministisch)

Der entscheidende Punkt ist nicht die Technologie – sondern die klare Trennung der Aufgaben.

Hinweis: Alle zuvor ermittelten Initiativen die nicht in eine Kategorie gefallen sind, die KI beinhaltet, wandern in den Automation Layer und werden in diesem Schritt nicht mehr betrachtet. Dies ist konzeptionell extrem wichtig und verhindert Overengineering.

Orchestrierung statt Monolith

Sobald mehrere spezialisierte Fähigkeiten im System vorhanden sind, stellt sich zwangsläufig die Frage, wie deren Einsatz koordiniert wird: Wer entscheidet, wann welche Fähigkeit aktiv wird und in welcher Reihenfolge sie zusammenwirken? Genau hier setzt die Orchestrierung an – als zentrale Komponente, die den Ablauf steuert und sicherstellt, dass die einzelnen Fähigkeiten im richtigen Kontext, zur richtigen Zeit und in der passenden Kombination eingesetzt werden.

• Auswahl der passenden Capability
• Übergabe von Kontext
• Kombination von Ergebnissen
• Eskalation bei Unsicherheit

Damit entsteht ein System, das eher einem Team aus Spezialisten entspricht als einem einzelnen Modell – sofern der Anwendungsfall diese Aufteilung erfordert. Wichtig ist dabei: Diese Struktur ist kein Selbstzweck. In vielen Fällen reicht eine einzelne, klar definierte Fähigkeit oder sogar ein einzelnes Modell aus, um ein Problem effizient zu lösen. Erst wenn Aufgaben unterschiedliche Arten von Verarbeitung benötigen (z. B. Verstehen, Bewerten, Abgleichen), wird ein Zusammenspiel mehrerer Capabilities sinnvoll.

Konkret bedeutet das: In einfachen Szenarien kann ein einzelnes Modell Inhalte einlesen und bewerten. In komplexeren Szenarien wird die Aufgabe bewusst aufgeteilt – etwa indem ein Modell Inhalte strukturiert, ein weiteres die Ergebnisse bewertet und ein drittes Abweichungen erkennt. Die Orchestrierung verbindet diese Schritte zu einem durchgängigen Prozess, stellt den notwendigen Kontext bereit und entscheidet, wann welcher Schritt ausgeführt wird – inklusive klar definierter Übergaben und Eskalationen.

Die eigentliche Stärke dieses Ansatzes liegt in der bewussten Wahl der Komplexität: So einfach wie möglich, so modular wie nötig. Dadurch bleibt das System beherrschbar. Entscheidungen werden nachvollziehbar, Ergebnisse überprüfbar und einzelne Komponenten bleiben austauschbar. So entsteht kein intransparenter „KI-Block“, sondern eine kontrollierbare, erweiterbare Systemlogik, die sich je nach Anwendungsfall schlank oder modular aufbauen und langfristig stabil betreiben lässt.

Modellstrategie: Klein, spezialisiert, kontrollierbar

Ein zentrales Architekturprinzip ergibt sich direkt aus dieser Struktur:

Nicht ein großes Modell löst alle Probleme – sondern die passende Granularität entscheidet. In vielen Fällen genügt ein einzelnes, klar definiertes Modell oder sogar klassische Logik. Erst wenn unterschiedliche Verarbeitungsarten erforderlich sind (z. B. Verstehen, Extrahieren, Bewerten), lohnt sich die Aufteilung in mehrere spezialisierte Modelle.

So einfach wie möglich, so spezialisiert wie nötig.

• höhere Präzision pro Anwendungsfall
• geringere Kosten durch gezielten Modelleinsatz
• bessere Testbarkeit einzelner Komponenten
• einfachere Austauschbarkeit bei Änderungen

Gleichzeitig bleibt die Architektur flexibel: Einfache Anwendungsfälle können schlank mit einer einzelnen Lösung umgesetzt werden, während komplexere Szenarien modular aufgebaut werden. Dadurch lassen sich unterschiedliche Betriebsmodelle (lokal, Cloud, hybrid) gezielt kombinieren, ohne unnötige Komplexität zu erzeugen.

Infrastruktur als strategische Entscheidung

Ein oft unterschätzter, aber strategisch entscheidender Aspekt ist der Ort der Ausführung. Die Frage, wo eine Capability tatsächlich betrieben wird, beeinflusst nicht nur die Technik, sondern auch Sicherheit, Kostenstruktur und langfristige Abhängigkeiten.

Für jede Capability sollte daher bewusst entschieden werden, ob sie über externe APIs genutzt, in eigener Infrastruktur betrieben oder als hybride Lösung umgesetzt wird. Diese Entscheidung ist weniger eine technische Detailfrage, sondern vielmehr eine Architektur- und Governance-Entscheidung.

• Datenschutz und Compliance
  Welche Daten werden verarbeitet und dürfen diese das Unternehmen verlassen? Gerade in regulierten Branchen (z. B. Finanzwesen oder Produktion) gelten oft klare Vorgaben. Best Practice ist hier: Sensible Daten möglichst lokal verarbeiten oder zumindest vorverarbeiten.
• Verfügbarkeit und Ausfallsicherheit
  Muss die Funktion jederzeit verfügbar sein – auch ohne Internetverbindung? In produktionsnahen Systemen ist es gängige Praxis, kritische Funktionen so auszulegen, dass sie unabhängig von externen Diensten weiterlaufen können.
• Produktionssicherheit
  Welche Auswirkungen hat ein Ausfall oder eine Fehlfunktion? Je kritischer der Prozess, desto stärker sollte auf kontrollierbare, lokal betriebene Komponenten gesetzt werden.
• Kostenstruktur
  Entstehen variable Kosten pro Nutzung (z. B. API-Aufrufe) oder eher einmalige Investitionen (z. B. eigene Infrastruktur)? Best Practice ist hier, stark genutzte Funktionen eher zu internalisieren, während selten genutzte oder rechenintensive Funktionen extern bezogen werden können.
• Strategische Abhängigkeit
  Wie stark macht sich das Unternehmen von einzelnen Anbietern abhängig? Eine bewusste Architektur vermeidet Lock-in-Effekte und hält Alternativen offen.

In vielen realen Szenarien führt diese Abwägung zu einem hybriden Modell. Dabei werden kritische und häufig genutzte Funktionen lokal betrieben, während weniger kritische oder besonders komplexe Aufgaben über externe Modelle abgedeckt werden.

• Kritische Kernprozesse lokal absichern
• Externe Services gezielt für Zusatzfunktionen nutzen
• Datenflüsse bewusst kontrollieren und minimieren
• Abhängigkeiten regelmäßig überprüfen

Damit entsteht eine Architektur, die sowohl leistungsfähig als auch kontrollierbar bleibt – und gleichzeitig flexibel genug ist, um neue Technologien schrittweise zu integrieren, ohne bestehende Systeme zu destabilisieren.

Mini-Workshop III: Architektur ableiten

Der folgende Workshop baut direkt auf den Ergebnissen der ersten beiden Artikel auf und überführt diese in eine erste Zielarchitektur.

• die Problem-Landkarte (AI Opportunity Map) aus Artikel 1, in der die relevanten Reibungsverluste und Handlungsfelder identifiziert wurden
• der Lösungsfahrplan (AI Opportunity Filter) aus Artikel 2, in dem diese Themen priorisiert und bewusst in Standardisierung, Automatisierung und KI eingeordnet wurden

Im Unterschied zu den vorherigen Schritten geht es nun nicht mehr darum, was sinnvoll ist, sondern darum, wie diese Entscheidungen strukturiert in ein konsistentes System überführt werden können. Ziel ist es, aus einzelnen Maßnahmen eine klare Architektur abzuleiten, in der die identifizierten Fähigkeiten nicht isoliert umgesetzt werden, sondern als zusammenhängendes System funktionieren.

• Definition eines AI Capability Layers
• Zuordnung von Fähigkeiten zu konkreten Prozessen
• Erste Architekturstruktur für das Unternehmen

Modul 1 – Capability Mapping (Fähigkeiten ableiten)

Ziel: Probleme in klar definierte, fachlich verständliche Fähigkeiten (Capabilities) überführen.

Auswahl der priorisierten KI-Themen aus dem Lösungsfahrplan

• Welche Fähigkeit wird benötigt?
• Vorgehen: Problem als „Verb“ + „Objekt“ formulieren (z. B. prüfen, klassifizieren, extrahieren, bewerten)
• Zerlegung in 2–4 Teilfähigkeiten

• Dokumentation: Klassifikation + Extraktion + Bewertung → Beispiel (so würde es im Workshop formuliert werden): "Eingehende Prüfberichte automatisch analysieren: Dokumenttyp erkennen, relevante Pflichtfelder (z. B. Datum, Prüfer, Ergebnis) extrahieren und prüfen, ob alle regulatorischen Anforderungen erfüllt sind."
• Qualitätskontrolle: Anomalieerkennung + Kontextabgleich + Priorisierung → Beispiel: "Produktionsdaten kontinuierlich überwachen: Abweichungen von Sollwerten erkennen, mit historischen Referenzwerten vergleichen und kritische Abweichungen priorisiert an den Verantwortlichen melden."
• Operations: Klassifikation + Scoring + Routing → Beispiel: "Eingehende Kundenanfragen automatisch einordnen: Anfrage-Typ erkennen, Dringlichkeit basierend auf Inhalt bewerten und an die zuständige Fachabteilung weiterleiten."

• Keine technischen Begriffe verwenden
• Fähigkeiten so definieren, dass sie wiederverwendbar sind
• Komplexität reduzieren statt erhöhen

• Für jedes priorisierte Thema existiert eine klar definierte Capability-Struktur
• Capabilities sind fachlich verständlich und technologieunabhängig beschrieben

Beispiel: Auszug aus des AI Capability Layer Modul 1 aus einem Workshop bei einer Druckerei.

Modul 2 – Modellstrategie festlegen (Umsetzung wählen)

Ziel: Für jede Capability eine klare und wirtschaftlich sinnvolle Umsetzungsstrategie bestimmen.

• klassische Logik (regelbasiert, deterministisch) → Beispiel: "Eingabedaten auf Vollständigkeit prüfen: Pflichtfelder validieren, Formate kontrollieren und bei Fehlern den Vorgang automatisch zurückweisen."
• spezialisiertes Modell (fokussierte KI für Muster) → Beispiel: "Rechnungen automatisch klassifizieren: Dokumenttyp erkennen und Kostenstellen basierend auf historischen Daten zuordnen."
• generatives Modell (flexible KI für Interpretation/Erzeugung) → Beispiel: "Prüfberichte zusammenfassen: Inhalte interpretieren und eine verständliche Kurzbewertung für den Entscheider generieren."

• Genauigkeit: Muss das Ergebnis immer korrekt sein oder ist eine Wahrscheinlichkeit ausreichend?
• Kosten: Welche laufenden Kosten entstehen pro Nutzung (API, Infrastruktur, Betrieb)?
• Laufzeit: Wie schnell muss das Ergebnis vorliegen?

• Immer die einfachste Lösung bevorzugen
• Genau eine primäre Strategie pro Capability wählen
• KI nur einsetzen, wenn Interpretation notwendig ist

• Jede Capability ist eindeutig einer Umsetzungsstrategie zugeordnet
• Entscheidungen sind nachvollziehbar und wirtschaftlich begründet

Beispiel: Auszug aus des AI Capability Layer Modul 2 aus einem Workshop bei einer Druckerei.

Modul 3 – Orchestrierung definieren (Ablauf festlegen)

Ziel: Ein konsistentes Zusammenspiel aller Capabilities definieren.

• Reihenfolge der Verarbeitung → Beispiel: "Zuerst wird ein Dokument klassifiziert (z. B. Rechnung oder Bericht), danach werden relevante Informationen extrahiert und anschließend eine Bewertung durchgeführt."
• Übergabe von Kontext zwischen Capabilities → Beispiel: "Die erkannte Dokumentart wird an die nächste Fähigkeit übergeben, damit nur die passenden Felder extrahiert werden (z. B. unterschiedliche Felder für Rechnung vs. Prüfbericht)."
• Eskalationspunkte bei Unsicherheit → Beispiel: "Wenn die Klassifikation unter einer bestimmten Sicherheit liegt (z. B. < 80%), wird der Vorgang an einen Mitarbeiter zur manuellen Prüfung weitergeleitet."

• Prozesse aus Sicht des Anwenders denken
• Komplexität im Ablauf vermeiden
• Klar definieren, wo menschliche Entscheidungen notwendig bleiben

Outcome:

• Ein durchgängiger Prozessfluss ist definiert
• Klarheit über Automatisierung vs. menschliche Eingriffe

Beispiel: Auszug aus des AI Capability Layer Modul 3 aus einem Workshop bei einer Druckerei.

Modul 4 – Infrastrukturstrategie (Betrieb festlegen)

Ziel: Eine stabile, sichere und wirtschaftliche Ausführung der Capabilities festlegen.

• lokal → Bedeutung: Ausführung innerhalb der eigenen Infrastruktur (z. B. eigene Server oder Rechenzentrum) → Beispiel: "Anomalieerkennung für Produktionsdaten läuft direkt im Werk, damit die Analyse auch bei Netzausfall weiter funktioniert."
• Cloud → Bedeutung: Nutzung externer Anbieter über APIs (z. B. große KI-Modelle) → Beispiel: "Texte aus Berichten werden über einen externen KI-Service zusammengefasst, da hier hohe Modellqualität wichtiger ist als lokale Verfügbarkeit."
• Hybrid → Bedeutung: Kombination aus lokaler und externer Verarbeitung → Beispiel: "Kritische Vorverarbeitung erfolgt lokal, komplexe Auswertung wird bei Bedarf an einen Cloud-Service übergeben."

• Datenschutzanforderungen → Welche Daten dürfen das Unternehmen verlassen? Gibt es regulatorische Einschränkungen?
• Ausfallsicherheit → Muss die Funktion auch ohne Internet oder externe Dienste weiterlaufen?
• Kosten → Entstehen laufende Kosten pro Nutzung (Cloud) oder Investitionskosten für eigene Infrastruktur?

• Sensible oder kritische Prozesse → eher lokal
• Rechenintensive oder selten genutzte Funktionen → eher Cloud
• Gemischte Anforderungen → hybrid

• Kritische Funktionen bevorzugt lokal betreiben
• Abhängigkeiten zu externen Anbietern bewusst steuern
• Produktionssicherheit priorisieren

• Klare Zuordnung der Ausführungsumgebung je Capability
• Grundlage für eine stabile und skalierbare Architektur

Das Ergebnis: Eine erweiterbare Systemarchitektur

• Problemfelder sind identifiziert
• Lösungen sind bewertet
• Fähigkeiten sind definiert
• Integration ist geplant

Damit entsteht ein System, das nicht nur funktioniert – sondern sich weiterentwickeln lässt.

Zusammenfassung der Serie

Die drei Artikel dieser Serie bilden gemeinsam einen klaren roten Faden:

1. Probleme verstehen → Reibungsverluste identifizieren
2. Lösungen bewerten → Standardisierung, Automatisierung, KI
3. Architektur aufbauen → AI Capability Layer

Das Ergebnis ist kein KI-Projekt. Es ist ein strukturiertes Vorgehen, um Unternehmenssoftware gezielt weiterzuentwickeln.

Der nächste Schritt

Viele Unternehmen erreichen genau an diesem Punkt eine kritische Schwelle. Die Potenziale sind erkannt. Die Entscheidungen vorbereitet. Die Architekturidee vorhanden. Was fehlt, ist oft Fachwissen welches zu einer strukturierten Umsetzung führt. Ein fokussierter Workshop vor Ort ermöglicht es, diese Schritte gemeinsam zu vertiefen, unternehmensspezifisch anzupassen und in konkrete Maßnahmen zu überführen.

• eine priorisierte Umsetzungsstrategie
• eine abgestimmte Zielarchitektur
• klar definierte Initiativen (Projekte) pro Capability

• Zielbild der KI-Integration im Unternehmen
• priorisierte Initiativen entlang eines klaren Zeithorizonts
• Zuordnung von Verantwortlichkeiten
• grobe Budgetierung und Aufwandseinschätzung

Aus einer Vielzahl von Ideen entstehen so konkrete, budgetierbare Vorhaben, die geplant, gesteuert und umgesetzt werden können.

Der entscheidende Unterschied liegt darin, dass nicht mehr planlos mit einzelnen KI-Use-Cases gestartet wird, sondern eine strategische Umsetzung mit klaren Zielen, Prioritäten und Investitionsentscheidungen erfolgt.

Genau an dieser Stelle entfaltet ein gemeinsamer Workshop seinen größten Wert: Die erarbeiteten Inhalte werden nicht nur diskutiert, sondern in eine tragfähige Grundlage für Entscheidungen überführt – fachlich, technisch und wirtschaftlich.

Wenn Sie diesen Schritt strukturiert gehen und aus Ideen eine umsetzbare Strategie entwickeln möchten, lässt sich dieser Ansatz gemeinsam vor Ort weiter vertiefen und auf Ihre konkrete Situation anwenden. Sprechen sie mich dazu direkt an.

Kategorie: AI Engineering | Tags: KI Softwareplatform KI Architektur KI Integration Modellstrategie Infrastruktur