Kommentar von René Weseler, Buildsimple KI im Kernprozess: Eine Architekturfrage, keine Toolfrage

Von René Weseler 5 min Lesedauer

Anbieter zum Thema

Warum die Hoheit über KI-Architekturen in dokumentenbasierten Prozessen beim Anwender liegen muss – und wie sich Intelligent Document Processing (IDP) parallel vom Analyse- zum handelnden System wandelt.

Der Autor: René Weseler verantwortet als Senior Executive Manager die strategische Positionierung von Buildsimple, einer Plattform für intelligente Dokumentenverarbeitung. Als Mitglied der Bundesfachkommission KI des Wirtschaftsrats Deutschland bringt er strategische und regulatorische Perspektiven in die Unternehmensentwicklung ein.(Bild:  Buildsimple)
Der Autor: René Weseler verantwortet als Senior Executive Manager die strategische Positionierung von Buildsimple, einer Plattform für intelligente Dokumentenverarbeitung. Als Mitglied der Bundesfachkommission KI des Wirtschaftsrats Deutschland bringt er strategische und regulatorische Perspektiven in die Unternehmensentwicklung ein.
(Bild: Buildsimple)

In dokumentenbasierten Kernprozessen hat sich in den vergangenen Jahren etwas verschoben, das wenig mit Modellen zu tun hat und viel mit Verantwortung. In Banken und Versicherungen, also dort, wo dokumentenintensive Prozesse produktiv mit Künstlicher Intelligenz (KI) laufen, treffen die Architekturentscheidungen zunehmend nicht mehr die Anbieter – sondern die Anwender selbst. Welches Verfahren übernimmt welche Aufgabe? Wann funktioniert ein selbst trainiertes Modell, wann ein Large Language Model? Wo liegen die Konfidenzschwellen, mit denen automatisiert verarbeitet wird? Diese Fragen wandern aus dem Pflichtenheft des Lieferanten in den Steuerungsraum des Kunden. Und das ist die einzig sinnvolle Konsequenz aus drei harten Anforderungen, die nur der Anwender selbst überblickt: Wirtschaftlichkeit, Genauigkeit und gesetzliche Vorgaben.

Wirtschaftlichkeit: Kosten entstehen pro Dokument

Bei sechsstelligen Dokumentenmengen pro Jahr werden reine LLM-Ansätze schnell unwirtschaftlich. Token-Kosten fallen pro Verarbeitung an – unabhängig davon, ob ein Dokument einfach oder komplex ist. Wer Standardfälle über ein selbst trainiertes Modell verarbeiten lässt und LLMs nur für Edge Cases hinzuzieht, hat eine andere Flexibilität für Kosten. Welche Dokumentenklasse welchen Anteil am Volumen ausmacht, welche Konfidenzschwelle wirtschaftlich tragbar ist und ab welchem Punkt manuelle Nachbearbeitung günstiger ist als ein KI-Modell – das weiß der Anbieter oft nicht. Das weiß nur der Kunde, weil er die Volumina, die Margen und die Personalkostenstruktur seiner Prozesse kennt.

Genauigkeit: Reproduzierbarkeit ist nicht Sprachverständnis

Was „genau genug“ heißt, hängt vom Use Case ab. In einem Onboarding-Workflow für Privatkunden mag eine Klassifikationsgenauigkeit von 95 Prozent ausreichen – mit Quality-Team für die Reststreuung. In der Auswertung von Jahresabschlüssen für Kreditentscheidungen sieht das anders aus: Hier muss identischer Input reproduzierbaren Output liefern, heute, in einem Monat und in einem Jahr. LLMs sind generative Systeme. Sie lesen Informationen nicht einfach aus, sie erzeugen Antworten. Stark sind sie dort, wo Sprachverständnis und Einordnung gefragt sind. Weniger geeignet sind sie für reproduzierbare Massenprozesse. Selbst trainierte Machine-Learning-Modelle haben hier Vorteile, die LLMs strukturell schwerer abbilden können: Sie sind auf konkrete Dokumententypen trainiert, liefern bei identischem Input stabile Ergebnisse und schaffen die Nachvollziehbarkeit, die regulierte Umgebungen verlangen. Welche Genauigkeitsanforderung in welchem Workflow gilt, ergibt sich aus der Risikobewertung des Anwenders – nicht aus der Produktphilosophie eines Anbieters.

Gesetzliche Anforderungen: Die Beweislast trägt der Betreiber

Mit dem AI Act und vergleichbaren Regulierungen verschiebt sich die regulatorische Last klar auf die Seite der Anwender. Wer ein Hochrisiko-KI-System betreibt, muss nachweisen können, wie ein Ergebnis zustande gekommen ist. Eine Black Box, in der ein Anbieter „irgendeine KI“ einsetzt, ist in diesem Kontext keine Option. Erklärbarkeit, Auditierbarkeit, Datenherkunft, Modellversionierung – all das landet im Audit-Bericht des Betreibers, nicht des Plattformanbieters. Daraus ergibt sich zwangsläufig der Anspruch, die Architekturentscheidungen selbst zu kontrollieren: Welches Modell verarbeitet welche Daten? Welche Trainingsdaten flossen ein? Wer Schwellenwerte, Routing-Regeln und Modellauswahl nicht selbst steuern kann, kann auch keinen belastbaren Compliance-Nachweis führen.

In allen drei Achsen hängen die Entscheidungen, die heute über den Erfolg von KI in Kernprozessen bestimmen, an Informationen, die nur der Anwender vollständig besitzt. Die eingesetzte Lösung muss eine Wahl ermöglichen – nicht vorwegnehmen.

Gerade beim Einsatz von generativer KI lohnt sich ein tieferer Blick. So stellt beispielsweise Microsoft in seinen Nutzungsbedingungen für Copilot klar, dass der KI-Assistent nicht als verlässliche Informationsquelle zu betrachten ist und warnt explizit davor, sich bei wichtigen Ratschlägen auf das Tool zu verlassen; die Nutzung erfolgt auf eigene Gefahr.

Vom Analysesystem zum handelnden System

Parallel zu dieser Hoheitsverschiebung verändert sich das, was Intelligent Document Processing leistet. Klassische IDP-Systeme hatten eine klar umrissene Aufgabe: Ein Dokument wurde erkannt, klassifiziert, extrahiert und an Mitarbeiter oder ein Folgesystem übergeben. Die eigentliche Entscheidung fiel außerhalb des Systems.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Big Data, Analytics & AI

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Diese Trennlinie verschiebt sich. Moderne Plattformen verbinden Dokumentenanalyse zunehmend mit Workflow-Funktionen, Regelwerken, Stammdaten und Kontextwissen. Aus einem reinen Analysesystem wird ein prozessnahes, teilweise handelndes System. Es soll nicht nur sagen, was in einem Dokument steht, sondern auch, was als Nächstes passieren sollte. Ein Antrag geht bei vollständiger Dokumentenlage automatisch ins Prescoring. Eine Schadenmeldung wird anhand der extrahierten Daten direkt einer Sachbearbeitungskategorie zugeordnet. Ein Vertrag wandert nach Klassifikation eigenständig in das richtige Aktensystem.

Wie weit Unternehmen diesen Schritt gehen, hängt vom Anwendungsfall ab. In sensiblen Kernprozessen bleibt der Mensch die Instanz, die Entscheidungen trifft und die Verantwortung trägt. Aber die Richtung ist klar: IDP wandert von einer vorgelagerten Erkennungstechnologie hin zu einer Prozesskomponente, die Vorgänge versteht, einordnet und vorbereitet. Aus Dokumentenanalyse wird Prozessintelligenz. Wichtig ist: Solange ein System nur erkennt und extrahiert, sind die Folgen einer Fehlentscheidung überschaubar – im Zweifel korrigiert ein Mitarbeiter. Sobald ein System aber selbst handelt, also Routing entscheidet, Eskalationen auslöst oder Folgeprozesse anstößt, werden die Architekturentscheidungen zu Geschäftsentscheidungen. Wer hier die Hoheit aus der Hand gibt, verlagert nicht nur Technik, sondern Verantwortung.

Ein Beispiel aus der Praxis

Wie das in einem regulierten Umfeld aussieht, zeigt das Beispiel des Deutschen Firmenkreditpartners (DFKP). Der Spezialist für digitale Finanzierungsprozesse hat in drei Monaten eine zweistufige IDP-Pipeline produktiv eingeführt. Zwischen 2.000 und 3.000 Dokumente pro Woche, über 100.000 im Jahr, über 200 verschiedene Dokumentenklassen – allein bei Kontoauszügen 300 bis 400 unterschiedliche Bankensysteme ohne einheitliches Format.

Die Architektur trägt die drei oben beschriebenen Anforderungen in sich. Ein auf den Dokumentenbestand trainiertes Modell übernimmt Klassifikation und Extraktion. Für jede Dokumentenklasse sind eigene Konfidenzschwellen definiert. Dokumente, die den Schwellenwert überschreiten, laufen vollautomatisch durch den Prozess. Unterschreitet ein Dokument den Schwellenwert, übernimmt ein Large Language Model. Dokumente unter dem Mindest-Schwellenwert gehen an ein Quality-Team, dessen Korrekturen automatisiert als Trainingsdaten in das System zurückfließen.

Entscheidend ist, wer hier was entscheidet. Welche Dokumente wie verarbeitet werden, welche Fehlerquoten akzeptabel sind, wann welches Modell zum Einsatz kommt – das definiert nicht der Plattformanbieter, sondern DFKP selbst. Schwellenwerte werden in regelmäßigen Reviews anhand realer Produktionsdaten kalibriert. Die fachliche Steuerungslogik liegt vollständig beim Kunden.

Die Ergebnisse aus dem Produktivbetrieb: 80 bis 85 Prozent Dunkelverarbeitungsquote, sprich, der Anteil an Dokumenten, der in einem Unternehmen vollautomatisiert verarbeitet wird. Zudem eine Reduktion des manuellen Aufwands um 70 Prozent und eine Verdreifachung des Dokumentendurchsatzes. Es werden heute mehr Datenpunkte extrahiert als je zuvor. Felder, auf die früher aus Zeitgründen verzichtet wurde, fließen automatisch in nachgelagerte Systeme. Das Ziel ist nicht die maximale Quote, sondern wirtschaftlich sinnvolle Automation.

Die Plattform der Zukunft entscheidet nicht – sie ermöglicht Entscheidungen

Wer KI in dokumentenbasierte Kernprozesse integriert, trifft heute drei Entscheidungen gleichzeitig: eine wirtschaftliche, eine fachliche und eine regulatorische. Diese Entscheidungen sind nicht delegierbar. Sie hängen an Informationen über Volumina, Risikobewertungen und Audit-Anforderungen, die kein Plattformanbieter pauschal überblicken kann.

Daraus folgt: Die Plattform der Zukunft ist keine, die fertige Antworten liefert, sondern eine, die Architekturentscheidungen ermöglicht. Konfidenzwerte, Routing-Regeln, Modellauswahl, Trainingsdaten – all das gehört in den Verantwortungsbereich des Kunden. Das gilt umso mehr, je weiter sich IDP vom Analysesystem zum handelnden System entwickelt. Denn ein System, das eigenständig agiert, braucht Hoheit über genau die Parameter, die seine Entscheidungen prägen. Der Anwender entscheidet, welches Verfahren in seinen Prozess gehört.

Artikelfiles und Artikellinks

(ID:50839536)