Wann ein individuelles KI-Tool sinnvoll ist
Nicht jeder Workflow erfordert KI. Ein n8n-Flow oder ein einfaches Skript loest die meisten wiederkehrenden Aufgaben ohne den Overhead eines Sprachmodells. Aber es gibt Situationen, in denen das nicht funktioniert. Drei Signale, dass ein individuelles KI-Tool der richtige Ansatz ist:
- ▸Die Aufgabe erfordert Kontext: die korrekte Ausgabe haengt von Informationen ab, die ueber das Dokument oder den Datensatz verteilt sind, nicht von einer festen Regel, die in ein if-Statement passt.
- ▸Die Eingabe variiert zu stark fuer eine Regex oder ein Template: Freitext, PDF-Formulare, E-Mails in wechselnden Formaten, Bilder von Belegen. Manuelle Strukturierung ist im Massstab nicht moeglich.
- ▸Die Entscheidungen sind zu kleinteilig fuer manuelle Regeln: Support-Tickets gleichzeitig nach Inhalt, Ton und Dringlichkeit an die richtige Abteilung weiterleiten, ohne dass eine Entscheidungsmatrix realisierbar ist.
- ▸Das Volumen ist gross, aber die Arbeit ist zu repetitiv fuer einen Spezialisten: 200 Angebote pro Woche auf fehlende Klauseln pruefen ist Arbeit fuer eine KI, nicht fuer einen Juristen.
Wenn eines dieser Kriterien zutrifft, lohnt es sich, ein individuelles Tool zu erkunden. Nicht um KI einzubeziehen, sondern weil es der einzige Ansatz ist, der das Problem tatsaechlich loest.
Wann ein individuelles KI-Tool keinen Sinn ergibt
KI ist keine Antwort auf jedes Problem. Ich baue keine Tools, wenn:
- ▸Das Problem mit einer normalen Abfrage, einer Tabellenkalkulationsformel oder einer API-Integration ohne Reasoning-Ebene geloest werden kann.
- ▸Kein Business Case vorhanden ist: 'Wir wollen KI nutzen' ohne ein konkretes, messbares Problem dahinter.
- ▸Das Ziel die Generierung von Marketinginhalten ohne spezifisches Domainwissen oder interne Daten als Eingabe ist. Das kann jeder selbst mit ChatGPT.
- ▸Die Datenqualitaet nicht ausreicht, um ein Modell darauf zu betreiben: Garbage in, garbage out gilt auch fuer die fortgeschrittensten Modelle.
Mein Discovery-Ansatz: Audit vor Code
Bevor ich eine einzige Zeile Code schreibe, erfasse ich die manuelle Aufgabe. Das kostet nicht viel Zeit, verhindert aber, dass ich das falsche Tool baue. Die Schritte:
- ▸Intake: Beschreibe den Prozess Schritt fuer Schritt. Was ist die Eingabe, was ist die gewuenschte Ausgabe, welche Entscheidungen werden dazwischen getroffen?
- ▸Fehleranalyse: Wo laeuft es manuell schief? Wo treten Fehler auf, werden Schritte uebersprungen oder dauert es laenger als es sollte?
- ▸POC in 1 bis 3 Iterationen: Ich baue einen funktionierenden Prototyp mit echten Daten deiner Organisation. Keine Demo-Daten, keine Idealsituationen.
- ▸Validierung: Du oder ein Mitarbeiter bewertet die Ausgabe des Prototyps. Erst dann entscheide ich, ob das Modell geeignet ist oder angepasst werden muss.
- ▸Iteration: Nach der Validierung passe ich die Prompts, die Pipeline oder die Architektur basierend auf dem an, was nicht stimmte. Keine grosse Veroeffentlichung nach Monaten, sondern kleine Schritte, die nachweislich funktionieren.
Dieser Prozess ist bewusst kurz und konkret. Wenn der Prototyp in der ersten Iteration nutzlos ist, hoere ich dort auf. Das ist ehrlicher als monatelang auf einem fehlerhaften Fundament weiterzuentwickeln.
Welche Modelle ich nutze und warum
Die Modellwahl haengt vom Problem ab, nicht davon, was gerade am meisten diskutiert wird. Meine Standardabwaegung:
- ▸Claudes neueste Modelle (Anthropic): fuer Aufgaben, bei denen das Reasoning ueber laengeren Kontext wichtig ist, wie das Durchsuchen eines Dokuments auf Inkonsistenzen oder das Generieren strukturierter Ausgaben mit mehreren abhaengigen Feldern.
- ▸OpenAIs neuestes Modell (OpenAI): fuer Anwendungen, bei denen die Kosten pro Token staerker ins Gewicht fallen und die Aufgabe keine komplexen Reasoning-Ketten erfordert. Weit verbreitet fuer Klassifikationsaufgaben mit hohem Volumen.
- ▸Lokale Llama-Varianten (Ollama oder vLLM): fuer Situationen, in denen Daten das System nicht verlassen duerfen. On-Premise, keine API-Calls an externe Server, vollstaendig innerhalb des Netzwerks oder Servers.
- ▸Embeddings und Vector Store: fuer RAG-Anwendungen, bei denen das Modell Kontext aus einer eigenen Dokumentenbasis bezieht statt aus seinen Trainingsdaten.
Ich binde mich nicht an einen einzigen Anbieter. Das Modell, das das Problem am besten zu den niedrigsten laufenden Kosten loest, gewinnt.
Architektur, die ich typischerweise verwende
Je nach Tool kann der Stack variieren, aber die meisten individuellen KI-Tools, die ich baue, basieren auf einer aehnlichen Grundlage:
- ▸Frontend: Next.js fuer Webinterfaces oder kein UI, wenn das Tool headless per API oder Cron laeuft.
- ▸Backend: FastAPI (Python) fuer Pipelines mit vielen KI-Aufrufen, Node.js fuer Integrationen mit bestehenden Systemen.
- ▸Zustand und Speicher: PostgreSQL fuer strukturierte Daten und Entscheidungshistorie, S3-kompatibler Speicher fuer Dateien.
- ▸Vector Store: pgvector in Postgres fuer einfache RAG-Setups oder Qdrant fuer groessere Sammlungen mit mehr Suchoptionen.
- ▸Orchestrierung: LangChain oder direkte API-Aufrufe, je nachdem, ob die Komplexitaet ein Framework rechtfertigt.
- ▸Logging: Jede KI-Entscheidung wird mit Eingabe, Ausgabe und Begruendung protokolliert. Das ist keine Option, das ist Standard.
-- Anonymer Fall A
Kontextbewusstes Bearbeiten von Dateien bei einem KMU im Logistikbereich
Ein KMU im Logistikbereich verarbeitete taeglich Batches von Dateien, bei denen jedes Mal dieselben Arten von Aenderungen notwendig waren: zwei oder drei spezifische Felder lesen, einen kontextabhaengigen Wert berechnen oder anpassen, die Datei in einem anderen Format speichern und in ein externes System hochladen. Die Komplikation lag im Wort 'kontextabhaengig': der korrekte Wert hing von Informationen anderswo in der Datei ab, nicht von einer festen Regel.
Ein normales Skript konnte das nicht leisten. Ich baute einen KI-Bot, der jede Datei liest, den relevanten Kontext extrahiert, auf dieser Basis Entscheidungen ueber die Aenderungen trifft, die Anpassungen vornimmt, die Datei ins Zielformat konvertiert und hochlaedt. Der Bot protokolliert jede Entscheidung mit Begruendung, damit ein Mitarbeiter nachtraeglich pruefen kann, was getan wurde und wo der Bot unsicher war.
Der Bot laeuft vollstaendig on-premise. Bei unerwarteter Eingabe sendet er eine Benachrichtigung, anstatt still zu versagen. Der Mitarbeiter, der dies zuvor manuell erledigte, nutzt diese Zeit jetzt fuer Arbeit, die menschliches Urteilsvermoegen erfordert.
-- Anonymer Fall B
Lokales RAG ueber interne Wiki bei einer Wissensorganisation
Eine interne Wissensorganisation hatte ein umfangreiches Wiki mit Verfahren, Richtliniendokumenten und technischen Handbuecher. Das Problem: Mitarbeiter stellten Kollegen dieselben Fragen, die bereits in der Wiki beantwortet waren, weil die Suche darin zu langsam und zu ungenau war. Die Informationen waren vorhanden, aber nicht auffindbar.
Ich baute eine lokale RAG-Pipeline auf einem Server innerhalb des Netzwerks der Organisation. Alle Wiki-Dokumente werden als Embeddings in einem Vector Store indexiert. Ueber eine einfache Chat-Oberflaeche stellt ein Mitarbeiter eine Frage und erhaelt eine Antwort mit direkten Verweisen auf die relevanten Seiten. Keine Daten verlassen das Netzwerk: Das Modell laeuft lokal auf einer Llama-Variante ueber Ollama.
Das System ist kein Ersatz fuer das Wiki, sondern eine Schicht darueber. Das Wiki bleibt die Quelle der Wahrheit. Das RAG-Tool macht diese Quelle zugaenglich, ohne dass jemand genau wissen muss, wo etwas gespeichert ist.
Was ich nicht tue
Es gibt Dinge, die ich bewusst ausserhalb des Umfangs halte:
- ▸Out-of-the-box ChatGPT-API-Integrationen, bei denen das einzige Ziel darin besteht, dass auf der Website 'KI' steht. Das loest kein einziges Problem.
- ▸KI-Features als Demo oder Pilot ohne Plan fuer den Produktionseinsatz. Ein Prototyp, der in der Schublade landet, ist verschwendetes Geld.
- ▸Training eigener Modelle auf kleinen Datensaetzen. Fine-Tuning macht erst bei tausenden von Beispielen und einem spezifischen Grund Sinn, warum ein Foundational Model nicht ausreicht.
- ▸Systeme, bei denen die Ausgabe nicht ueberprueft werden kann. Jede KI-Entscheidung in der Produktion benoetigt einen Audit-Trail. Ohne das gehe ich nicht live.
Kosten und Umfang
Individuelle KI-Tools variieren stark im Umfang. Ein POC zur Validierung des Ansatzes unterscheidet sich von einem Produktionssystem mit Monitoring und Logging. Ich erstelle nach dem Intake ein Angebot basierend auf dem tatsaechlichen Umfang.
Auf Anfrage
Keine festen Pakete. Der Preis haengt von der Komplexitaet der Aufgabe, der Anzahl der fuer die Validierung notwendigen Iterationen und davon ab, ob ein Retainer fuer Wartung und Monitoring nach der Lieferung gewuenscht wird.