19. Dezember 2025
Ein Beitrag von Dr. Nikola Milanovic
Oft höre ich Fragen oder Beschwerden: Wie kann es sein, dass es in Star Trek keine KI gibt? Wie kann es sein, dass sich das Raumschiff nicht selbst fortbewegt, wenn der Kapitän die entsprechenden Befehle gibt? Oder: Warum braucht es überhaupt einen Kapitän auf der Brücke? Ich sehe das anders. Überall in Star Trek ist Künstliche Intelligenz. Und damit meine ich nicht nur Lt. Data (den Androiden). Geordi La Forge zum Beispiel ist seit den 1990er-TV-Jahren im Bereich Vibe Coding tätig. Er "spricht" kontinuierlich mit dem Computer und programmiert ihn, ohne eine einzige Zeile Code zu verfassen. Nicht, dass ich verstehe, was er da sagt. Aber schauen Sie sich dieses klassische Beispiel aus Folge 6 ("Booby Trap") der dritten Staffel von "Star Trek – The Next Generation" an:
Dr. Nikola Milanovic
Chief Technology Officer
Und natürlich muss ich das noch klassischere Beispiel von Scotty anführen, der im Film "Star Trek IV: The Voyage Home" versucht, mit dem Computer zu sprechen.
Doch das bringt mich zum Grübeln. Warum gibt es keine Softwareingenieure in Star Trek? Vor allem, da es doch viele Maschinenbauingenieure gibt. Sie laufen durch das Raumschiff und reparieren Dinge, machen sie kaputt und reparieren sie erneut. Aber es gibt keinen einzigen Softwareingenieur. Wurden sie vielleicht von einem Vibe-Coding-Monster getötet?
Nein, gefressen wurden sie sicherlich nicht. Ich glaube auch nicht, dass Vibe Coding oder irgendein anderes KI-Monster Softwareingenieure in absehbarer Zeit oder überhaupt je töten wird. Dabei bin ich das, was man heute als "alt" bezeichnen würde (beruflich, wohlgemerkt!): Ich gehe auf die 50 zu. Ich habe Assembler gelernt. Ich kann damit auch arbeiten. Früher habe ich einmal ein Malprogramm damit geschrieben. Es hat Monate gedauert, aber die Kreise, Rechtecke und Würfel waren dann schnell da!
Als schließlich die Programmiersprache C aufkam, wurde prophezeit, dass alle programmieren würden, weil die Sprache im Vergleich zu Assembler so einfach zu verwenden sei (man stelle sich vor, heute würde jemand behaupten, Zeigerarithmetik sei einfach). Zudem wurde vorhergesagt, dass Softwareingenieure verschwinden würden, bevor die Aufgabe überhaupt zu einem richtigen Beruf wird. Nichts davon ist eingetreten. Wenn überhaupt hat die Zahl der Softwareingenieure zugenommen.
Dann kam objektorientierte Programmierung mit C++ und Java und C# ... und wie durch ein Wunder überlebten Softwareingenieure.
Und schließlich kam Vibe Coding. Ich habe es ausführlich genutzt (Replit), und ja: Es wirkt toll und effektiv. Und ja: Ich bin mir der bekannten Formulierung "640 KB RAM werden für immer reichen" bewusst.
Dennoch behaupte ich nach wie vor, dass Vibe Coding in seiner heutigen Form einen Softwareingenieur nicht ersetzen kann. Warum? Vibe Coding wird eine gewisse Reife und Anwenderfreundlichkeit erreichen und sich dann in eine andere Abstraktionsebene weiterentwickeln. Es handelt sich nämlich dabei um nicht mehr – oder weniger – als einen Codegenerator (im schlimmsten Fall) oder eine neue Programmiersprache, die einer natürlichen Sprache sehr ähnlich ist (im besten Fall). Wie bereits gesagt, habe ich Replit genutzt. Als Nächstes habe ich mir Gedanken gemacht, wie ich den generierten Code pflegen kann. Viel Glück dabei!
Ich gehe also davon aus, dass die Zahl der Softwareexperten wieder einmal ansteigen und nicht sinken wird. Warum ist das so? Nun, abgesehen von der Frage der Pflege – Marc Andreessen erklärte es sehr treffend in seinem berühmten Artikel: "Software is eating the world“.
Das ist genau das Muster, das wir jedes Mal beobachten, wenn es einen (r)evolutionären Sprung in der Art und Weise gibt, wie wir Maschinenbefehle für den Computerprozessor darstellen. Es wird also noch mehr Software geben, die noch komplexer sein und in noch mehr Dinge integriert sein wird. Das heißt, dass wir am Ende sogar mehr Softwareingenieure brauchen werden, die das ganze Durcheinander auflösen können.
Zurück zu Star Trek. Eine wunderbare Sache an Star Trek ist, dass es sich um eine (fast) perfekte Utopie handelt. Es gibt kein Geld. Aber viele Kriege. Und alle (zumindest die Guten) haben ein einziges Ziel: sich zu verbessern. Das ist toll. Zurück zur Realität. Leider wird alles in Geld und Profit gemessen. Um beides zu generieren, so heißt es, muss man einen Wert bieten, für den Kunden bereit sind, Geld auszugeben. Bis die Utopie von Star Trek wahr wird, bleibt also die Frage, wie man das immense KI-Potenzial in Geld verwandeln kann.
Meine Antwort auf diese Frage: Ich habe keine. Was ich aber weiß, ist, dass abgesehen von der offensichtlichen Nutzung generativer KI zur Generierung von Inhalten (Text, Code, Bilder, Videos ...) niemandem so recht klar ist, wie man mit einem generischen Rezept in einem vertikalen Markt Werte schaffen kann. Ich kann Ihnen jedoch Beispiele aus der Praxis geben, die gut zu funktionieren scheinen. Hier sind also zwei Anwendungsszenarien, die ich erarbeitet habe, und die Kunden so attraktiv finden, dass sie bereit sind, dafür zu zahlen.
Ich bin im Bereich Dokumentenmanagement tätig. Das bedeutet, dass mein Team Produkte für die Archivierung und Verwaltung digitaler Dokumente entwickelt. Im Prinzip speichern wir sehr große Mengen digitaler Informationen (Dokumente wie Office-Dateien, Bilder, Videos, E-Mails und vieles mehr sowie die zugehörigen Metadaten) in einem zentralen System. Wie ich bereits vor einiger Zeit geschrieben habe, kann diese Fülle an Daten als "Benzin" verwendet werden, um verschiedene KI-"Motoren" (Engines) zu betreiben. Diese Aussage ist jedoch inzwischen überholt. Niemand will mehr Autos mit Benzinantrieb fahren. Lassen Sie uns stattdessen Business Cases ansehen.
Wer viele Dokumente archiviert, muss dem Speichersystem sagen, um welche Dokumente es sich handelt (z. B. zu welcher Klasse sie gehören). Handelt es sich um Rechnungen, Verträge, Protokolle, Angebote oder vielleicht etwas ganz anderes? Wie sehen die entsprechenden Metadaten aus und wo in das System gehören sie hin (Archivsysteme sind oft in komplexen Ablagemustern strukturiert)? Noch bevor Sie das untersuchen, müssen Sie zwischen einzelnen Dokumenten unterscheiden, wenn sie z. B. in einem großen Strom gescannt oder importiert werden (Datei, Audio oder Video). Auf jeden Fall müssen Sie ermitteln, wo ein Dokument endet und das nächste anfängt.
Wie macht man das heute? Meistens manuell, manchmal aber auch halbautomatisch mit komplexen Regeln. Hier kommt KI ins Spiel.
Das Problem,
a) zu erkennen, was ein bestimmtes Dokument ist;
b) es mit Metadaten zu beschreiben;
c) den passenden Ablageort in einer Archivierungsstruktur (z. B. Zielordner) zu finden und
d) Dokumente in einem Eingabestrom zu unterscheiden oder aufzuteilen,
ist eine bekannte Herausforderung beim maschinellen Lernen (ML) und wird als "Entity Recognition/Extraction" bezeichnet.
Kein Wunder, dass Kunden begeistert sind, wenn man solche ML-Tools in Archivsysteme integrieren und das Eingabemanagement automatisieren kann. Doch warum sind Kunden so begeistert? Erstens können sie den Import von Dokumenten beschleunigen, zweitens die Fehlerzahl reduzieren und drittens den manuellen Aufwand verringern, sodass Mitarbeiter sich sinnvolleren Dingen widmen können (z. B. Vibe Coding).
Wenn Sie erfahren möchten, wie wir das mit einem von uns entwickelten Produkt namens enaio® kairos tun, dann schauen Sie doch mal hier rein.
Ein wichtiger Aspekt: Menschen sind empfindlich, wenn es darum geht, Daten mit KI-Lösungen zu teilen. Was immer Sie tun, vergessen Sie also nicht, a) das zu berücksichtigen und b) wenn möglich, praktikable Alternativen anzubieten, mit denen die KI on-premises betrieben werden kann. Mehr dazu im zweiten Anwendungsszenario.
Das zweite Anwendungsszenario umfasst Lt. Geordi La Forge (noch einmal). Was ich Ihnen noch nicht gesagt habe, ist, dass Sie für den ersten Business Case nicht einmal LLMs benötigen. Sie können Ihre KI-Lösung also wirtschaftlich betreiben, ohne Kunden im Kleingedruckten einen portablen Atomreaktor anbieten zu müssen. Heutzutage gilt jedoch: kein LLM, keine KI.
Wie also kann man LLMs sinnvoll einsetzen? LLMs sind eine tolle Sache. Ich liebe sie. LLMs lernen auf Grundlage öffentlich zugänglicher Daten, sodass man ihnen viele verschiedene Fragen stellen kann. Man kann LLMs zum Beispiel fragen, wie man einen Käsekuchen mit Erdbeeren backt, oder sie bitten, einen Liebesbrief an den heimlichen Schwarm im Stil von Puschkin oder Taylor Swift zu schreiben bzw. Differentialgleichungen zu "lösen" (aber das konnte Mathematica vor 20 Jahren auch schon).
Was ein Allzweck-LLM jedoch nicht leisten kann, ist die Beantwortung folgender Fragen: "Wie viele Verträge muss ich diese Woche verlängern? Wo finde ich die neueste Version von SOP AA-23 für Geschäftsreisen, und wie viel kann ich bei einer Reise für Taxis ausgeben? Mit welchen Kunden habe ich im vergangenen Quartal am meisten Umsatz gemacht? Kannst du die folgenden 30 Vertragsversionen miteinander vergleichen und mir die wichtigsten Unterschiede nennen?"
LLMs wie ChatGPT oder Gemini können solche Fragen nicht beantworten, da sie nicht über die entsprechenden Informationen verfügen. Sie wurden nicht mit dem erforderlichen Datensatz trainiert, da dieser nicht öffentlich zugänglich ist. Das ginge nur, wenn Sie diese Daten im öffentlichen Internet zur Verfügung stellen. Was Sie aber nicht tun werden. Okay. Und nun? Sie müssen die genannten Daten also irgendwie an das LLM weitergeben.
Hier kommt RAG ins Spiel. RAG steht für "Retrieval Augmented Generation", was so viel heißt wie: Ich gebe einem LLM einen kleinen Einblick in unsere Geschäftsdaten. Das geschieht auf technisch spektakuläre, aber einfache Weise, indem
a) alle Ihre Geschäftsdaten als Chunks in einer Vektordatenbank neu verpackt werden;
b) bei jeder LLM-Abfrage zunächst eine Vektordatenbank konsultiert wird, um Ihnen die Top-N-Treffer zu liefern, die Ihrer Abfrage entsprechen;
c) die Abfrage angereichert wird, indem relevante Chunks aus der Vektordatenbank eingebettet werden und diese dem LLM zur Verfügung gestellt werden, und schließlich
d) das LLM seine Magie entfaltet.
Super. Nun geben Sie all diese Daten – zum Beispiel aus Ihrer Dokumentenmanagementsoftware (in der unter anderem alle Mitarbeiterverträge gespeichert sind) – in eine Vektordatenbank ein und stellen die folgende Frage: "Kannst du mir bitte das Gehalt meines Chefs nennen?“ Und voilà: Sie erhalten die Information! Es funktioniert wie vorgesehen. Hmmm. Was aber nur wenige wissen, ist, dass dies ein riesiges Loch in die Zugriffskontrolle Ihres Unternehmens reißt. Das geht natürlich nicht. Sie müssen also versuchen, die Zugriffskontrollen der verschiedenen Systeme, die Sie zum Aufbau von RAG verwenden, irgendwie in das System einzubinden. Und das ist nicht leicht.
Noch ein Punkt: Daten in einem Dokumentenmanagementsystem sind lebendig. Sie werden hinzugefügt, gelöscht und geändert. Das muss sich in der Vektordatenbank widerspiegeln. Um die Lösung vollständig zu machen, müssen Sie (leider) eine Art Indexierungsdienst hinzufügen, der die Vektordatenbank bei jeder Änderung des zugrunde liegenden Systems neu indexiert. Schließlich wollen Sie, dass KI Ihnen die aktuellste Antwort gibt, oder etwa nicht?
Wenn Sie wissen möchten, wie wir das alles gemacht haben, als wir unseren KI-Assistenten enaio® lumee entwickelt und in unsere Dokumentenmanagementsoftware integriert haben, fragen Sie mich einfach oder schauen Sie hier.
Vergessen Sie nicht Datenschutz und Sicherheit. Die Bereitstellung Ihrer Geschäftsdaten in einer Vektordatenbank kann als Risiko eingestuft werden. Sorgen Sie dafür, dass die Vektordatenbank vom Generator (LLM) getrennt ist und lokal oder zumindest in einer privaten Cloud ausgeführt werden kann. So lassen sich Risiken und Gefahren minimieren.
Ist das das Ende der Zukunft? Stehen wir kurz vor Maschinen, die in Lichtgeschwindigkeit denken? Wahrscheinlich nicht. Was als Nächstes passieren wird, sind meiner Meinung nach zwei Dinge.
Teams müssen nicht mehr nach einem Status fragen, Koordinierungssitzungen werden reduziert und Missverständnisse minimiert. Gleichzeitig haben Manager einen Echtzeit-Überblick über Arbeitsauslastung, Engpässe und Prozessqualität. Entscheidungen basieren nicht mehr auf reinem Bauchgefühl, sondern auf Fakten. Diese Transparenz hat auch im Bereich Compliance enorme Auswirkungen. Jeder Prozessschritt wird automatisch dokumentiert und revisionssicher gespeichert. Ein ECM-System berücksichtigt regulatorische Anforderungen – sei es in der Öffentlichen Verwaltung, im Gesundheitswesen, im Finanzsektor oder in anderen stark regulierten Branchen. Nur vollständig dokumentierte und nachvollziehbare Prozesse können den steigenden Anforderungen gerecht werden.
Erstens werden Menschen einsehen, dass KI, so wie wir sie heute nutzen, unverschämt teuer ist. Wir können nicht ernsthaft damit anfangen, Atomreaktoren zu bauen, nur um Rechenzentren zu betreiben, die es uns erlauben, tolle Memes zu erstellen. Darum erwarte ich, dass kleinere, sogenannte domänenspezifische LLMs, die auch in lokaler Infrastruktur betrieben werden können (dem Mooreschen Gesetz sei Dank), im Geschäftskontext (nicht B2C!) vorherrschend sein und die sehr teure Nutzung von Allzweck-LLMs wie ChatGPT und Gemini ersetzen werden.
Wenn ich Gemini beispielsweise in meine Vertragsverwaltungsanwendung integriere, die zusammen mit einer Dokumentenmanagementsoftware zum Einsatz kommt, würde ich nur einen Bruchteil der Neuronen von Gemini benötigen, um zwei Verträge miteinander zu vergleichen oder die Gültigkeit eines Vertrags zu überprüfen. Wenn ich ein kleineres LLM in einer bestimmten Domäne trainiere, brauche ich kein großes Modell mit Billionen von Parametern und Petawatt an Energie, um die Aufgabe zu erledigen.
Zweitens wird sich das Prompting von Abfragen ("Bitte finde Informationen für mich") hin zu Aktionen entwickeln. Ich gehe davon aus, dass Prompts in Zukunft folgendermaßen aussehen werden: "Bitte erhöhe das Gehalt von Nikola mit sofortiger Wirkung auf eine Million Euro pro Jahr." Als Antwort darauf wird das LLM in einem Dokumentenmanagementsystem eine Abfolge von Aktionen erstellen:
1. Suche nach meiner Personalakte;
2. Suche nach meinem Vertrag;
3. Erstellen einer neuen Version des Vertrags durch Auswahl der passenden Vorlage;
4. Ausfüllen der neuen Gehalts- und Datumsfelder;
5. Speichern der neuen Version und schließlich
6. Starten eines Workflows, damit eine zuständige Person die Version genehmigen kann.
Diese Person wird den Prompt wahrscheinlich mit folgenden Worten beantworten: "Bitte entlasse Nikola." Dieses Verfahren wird von manchen als agentenbasierte KI bezeichnet.
So, wir sind bereits am Ende angelangt. Ich hoffe, Sie hatten viel Spaß beim Lesen. Wenn Sie mir Feedback geben möchten (egal welcher Art), können Sie sich gerne an mich wenden. Ich freue mich darauf, die Themen mit Ihnen zu diskutieren, meine Erfahrungen der letzten Jahre mit der Integration von KI in das Dokumentenmanagement mit Ihnen zu teilen oder Ihnen zu zeigen, wie das Ganze wirklich funktioniert (oder nicht funktioniert). Alles Gute und "Live long and prosper!".
Allgemeines
Produkte & Services
Standorte