Wie Sie KI effizient nutzen ohne sich langfristig zu binden
In 30 Minuten haben wir gezeigt, wie Organisationen KI pragmatisch in Prozesse integrieren können ohne sich frühzeitig auf einzelne Modelle, Anbieter oder Betriebsformen festzulegen. Im Fokus stand ein Architekturansatz, der schnelle Use Case-Umsetzung mit langfristiger Flexibilität verbindet. So erreichen wir eine bessere Steuerbarkeit, geringere Abhängigkeiten; außerdem können regulatorische, technische und wirtschaftliche Anforderungen kontrolliert erfüllt werden.
Sie nehmen aus dem Webinar mit
- KI-Potenziale in Ihren Prozessen identifizieren
- Typische Abhängigkeiten erkennen und vermeiden
- KI Services flexibel in bestehende Architekturen einbinden
- Effizienz- und Kostenvorteile gezielt nutzen
- Pragmatisch starten, ohne sich frühzeitig festzulegen
Agenda
Die Herausforderung:
KI effizient nutzen – ohne sich festzulegen
KI soll Prozesse effizienter machen – schnell und mit sichtbarem Nutzen. Gleichzeitig stehen viele Organisationen vor realen Unsicherheiten:
- Neue KI‑Modelle und Anbieter entstehen im Monatsrhythmus – mit teils erheblichen Unterschieden bei Leistungsfähigkeit, Kosten und Eignung für konkrete Use Cases.
- Regulatorische Anforderungen (KI Act, DSGVO, branchenspezifische Vorgaben) entwickeln sich weiter.
- Europäische und On‑Prem‑Alternativen gewinnen strategisch an Bedeutung.
Das Risiko:
Abhängigkeiten und verpasste Chancen
Wer architektonisch nicht vorbereitet ist, kann weder auf bessere Modelle noch auf günstigere Services wechseln – und verliert somit doppelt: bei Innovation und bei Kosten.
Die Folge: Organisationen starten gar nicht – oder sie starten und schaffen Abhängigkeiten, die sich später nur schwer auflösen lassen.
Die Lösung:
KI als Prozesskomponente
Allein durch Austausch des KI-Modells vermeiden wir Prozessbrüche und die Prozesslogik bleibt stabil.
Anhand eines konkreten Szenarios wird gezeigt:
- Eine Anfrage etwa im Rahmen einer Kreditprüfung, eines Versicherungs- oder Bürgerantrags – wird durch KI interpretiert, bewertet und für die Bearbeitung vorbereitet.
- Die KI bleibt dabei eine eingebettete Prozesskomponente, keine autonome Entscheidungsinstanz.
- Die Verarbeitung erfolgt in bestehenden Systemen entlang der definierten Prozesslogik.
- Gleichzeitig machen wir transparent, wo ein Modell wie OpenAI eingesetzt wird und wie es bei Bedarf durch Mistral KI oder eine On-Prem-Lösung ersetzt werden kann.
Unsere dreiteilige Webinarreihe zu KI in der Prozessautomatisierung
Flexibel bleiben statt Lock-in
KI-Workflows in der Praxis
Architektur statt Tool-Chaos
Unsere Referenten
Brian Kurbjuhn
Director Enterprise Information Management
Brian Kurbjuhn leitet den Geschäftsbereich „Enterprise Information Management“ bei it-novum. Mit 15 Jahren Erfahrung im Umfeld Dokumentenmanagement, Prozessdigitalisierung und Prozessautomatisierung ist er ein ausgewiesener Experte für die Einführung maßgeschneiderter Enterprise-Lösungen. Gemeinsam mit seinem Team hat er zahlreiche erfolgreiche Implementierungen im Bereich Dokumentenmanagement, Prozessdigitalisierung und Prozessautomatisierung in Unternehmen und der öffentlichen Verwaltung durchgeführt.
Stefan Müller
Head of Sales Enterprise Information Management
Stefan Müller ist Head of Sales für den Bereich Enterprise Information Management bei it-novum. Er begleitet Kunden, die Lösungen im Bereich Dokumentenmanagement, Prozessdigitalisierung und Prozessautomatisierung einführen wollen. Seit mehr als 15 Jahren beschäftigt sich Stefan intensiv mit Data und Analytics. Er teilt sein Wissen regelmäßig in Fachartikeln und Vorträgen und zeigt auf, wie Unternehmen Daten gezielt als strategischen Erfolgsfaktor einsetzen können.
Alles, was Sie zum Webinar wissen sollten (FAQ)
Wir sehen den AI Service Layer weniger als ein einzelnes Produkt, sondern als Architekturprinzip. Entscheidend ist, dass zwischen Fachanwendung/Geschäftsprozess und Modell eine Abstraktionsschicht liegt. Der Prozess ruft also nicht direkt OpenAI, Azure AI, Anthropic, Mistral oder ein lokales Modell auf, sondern eine definierte Fähigkeit wie Klassifikation, Extraktion, Zusammenfassung oder Entscheidungsunterstützung. Genau diese Trennung ist der Kern der in Slides gezeigten Referenzarchitektur.
In der Praxis setzen wir dafür je nach Kundensituation unterschiedliche Bausteine ein. Für die Orchestrierung kommen klassische Workflow Engines oder bestehende Integrations- und Prozessplattformen beim Kunden infrage. Die Erstellung der KI-Workflows kann bspw. iIn n8n erfolgen und für den Modellzugriff empfehlen wir eine weitere Abstraktionsschicht, die Routing, API-Key-Management, Caching und Modellwechsel unterstützt (konkretes Beispiel: OpenRouter). Wichtig ist nicht, dass jedes Unternehmen dieselbe Lösung einsetzt, sondern dass die Architektur verhindert, dass Fachanwendungen und Workflows direkt mit einzelnen Modell-APIs verdrahtet werden.
Unsere Leitfrage ist daher immer: Welche Capabilities brauchen die Prozesse, und wie stellen wir diese wiederverwendbar bereit? Erst danach entscheiden wir, welche technische Lösung am besten passt.
Das ist genau der richtige Denkansatz. Anbieterunabhängige Skills als Workflows entsprechen im Grunde dem, was wir als Capability Layer beschreiben. In Slides wird dieser Wechsel ausdrücklich gezeigt: weg von der Frage „Welches Modell nutzen wir?“ und hin zur Frage „Welche Fähigkeit benötigen wir?“. Beispiele sind Klassifikation, Extraktion, Zusammenfassung, Priorisierung oder Entscheidungsunterstützung.
Der Vorteil ist, dass eine Fähigkeit fachlich stabil bleibt, während die technische Umsetzung darunter wechseln kann. Ein Skill „Dokument klassifizieren“ kann heute ein Cloud-LLM nutzen, morgen ein kleineres spezialisiertes Modell und später vielleicht ein On-Premise-SLM. Für den aufrufenden Prozess bleibt die Schnittstelle gleich. Dadurch lassen sich Qualität, Kosten, Datenschutzanforderungen und Betriebsmodelle laufend optimieren, ohne den Geschäftsprozess neu zu bauen.
Wichtig ist allerdings: Ein Skill sollte nicht nur ein technischer Prompt sein. Für produktive Nutzung braucht er klare Eingaben, definierte Ausgaben, Fehlerbehandlung, Monitoring, Logging, Kostenbetrachtung und gegebenenfalls Human-in-the-Loop. Erst dann wird aus einem Prompt eine belastbare, wiederverwendbare Prozessfähigkeit.
Ja, auch ein Service Layer kann zu einer neuen Abhängigkeit führen. Deshalb sollte er nicht als einzelnes Produkt verstanden werden, sondern als Architekturprinzip. Ziel ist nicht, Abhängigkeiten vollständig zu vermeiden – das ist in komplexen IT-Landschaften kaum realistisch. Ziel ist vielmehr, Abhängigkeiten bewusst zu gestalten und auf eine Ebene zu verlagern, auf der sie kontrolliert und bei Bedarf geändert werden können.
Der entscheidende Unterschied besteht darin, dass Geschäftsprozesse nicht direkt an einen konkreten LLM-Anbieter gekoppelt werden. Stattdessen erfolgt der Zugriff über klar definierte Schnittstellen und Capabilities innerhalb des Service Layers. Dadurch können Modelle, Anbieter oder auch Betriebsformen – beispielsweise Cloud- und On-Premise-Modelle – ausgetauscht werden, ohne die fachliche Prozesslogik grundlegend zu verändern.
Natürlich bedeutet das nicht, dass ein Modellwechsel völlig ohne Auswirkungen bleibt. Unterschiede bei Qualität, Verhalten, Kosten oder Schnittstellen müssen weiterhin berücksichtigt werden. Diese Anpassungen sollten jedoch auf die Integrations- und Capability-Ebene begrenzt bleiben und nicht die übergeordneten Geschäftsprozesse betreffen.
Um den Lock-in des Service Layers selbst möglichst gering zu halten, setzen wir auf eine Architektur mit klar getrennten Verantwortlichkeiten, standardisierten Schnittstellen und austauschbaren Komponenten. Offene Standards wie BPMN für die Prozessorchestrierung sowie REST- und OpenAPI-basierte Schnittstellen helfen dabei, Prozesslogik, Integrationslogik und konkrete KI-Dienste voneinander zu entkoppeln.
Dadurch entsteht zwar weiterhin eine Architekturabhängigkeit, diese ist jedoch deutlich transparenter und beherrschbarer als eine direkte Kopplung der Geschäftsprozesse an einzelne KI-Anbieter. Statt viele verteilte und schwer kontrollierbare Abhängigkeiten zu schaffen, werden sie an einer zentralen Stelle gebündelt, dokumentiert und gezielt steuerbar gemacht.
Kurz gesagt: Der Service Layer beseitigt Lock-in nicht. Er verschiebt ihn auf eine Ebene, auf der er aktiv gestaltet und begrenzt werden kann.
Event Impressionen
Über it-novum
it-novum, eine Tochtergesellschaft der Allgeier SE, ist eine führende Beratung für Business Open Source. Wir verwandeln Dokumente in Insights und Abläufe in effiziente Prozesse – mit Workflow-Automation und modernem Dokumentenmanagement für den digitalen Arbeitsplatz der Zukunft in der öffentlichen Verwaltung, im Finanzwesen und in der Industrie.