Die Demo hat überzeugt. Jemand hat ein paar PDFs hochgeladen, eine Frage gestellt, und die Antwort kam nach drei Sekunden und klang richtig. Jetzt liegt ein Angebot auf dem Tisch, und die Frage lautet: beauftragen oder nicht?
Das ist der Moment, in dem die meisten KI-Projekte ihren teuersten Fehler machen. Nicht, weil die Demo gelogen hätte. Sondern weil eine Demo und ein System, das im Betrieb läuft, zwei verschiedene Dinge sind — und der Weg vom einen zum anderen in keinem Angebot steht.
Woran KI-Projekte wirklich scheitern
Gartner hat im Juli 2024 prognostiziert, dass mindestens 30 % der generativen KI-Projekte nach dem Proof of Concept abgebrochen werden, bis Ende 2025. Als Gründe nennt die Analyse schlechte Datenqualität, unzureichende Risikokontrollen, steigende Kosten und unklaren Geschäftsnutzen (Gartner, Pressemitteilung vom 29.07.2024).
Auffällig an dieser Liste: Das Modell steht nicht darauf. Kein Projekt scheitert daran, dass GPT, Gemini oder Claude zu schwach wären. Für die meisten Aufgaben im Mittelstand sind die Modelle längst gut genug. Die Projekte scheitern an dem, was um das Modell herum fehlt.
Architektur. Eine Demo besteht aus einem Prompt, einem Modell und einem Textfeld. Ein Produktivsystem braucht eine Datenbank, Nutzerverwaltung, Rollen, Protokollierung, einen Weg für Korrekturen und einen Plan für den Fall, dass die API des Anbieters gerade nicht antwortet. Wer das erst nach der Beauftragung entwirft, entwirft es unter Zeitdruck — und meist so, dass es beim ersten Umbau bricht.
Datenzugang. In der Demo lagen die Dokumente auf dem Laptop des Entwicklers. Im Betrieb liegen sie in einem DMS, in SharePoint, in einer Fachanwendung von 2011 ohne Schnittstelle, in Postfächern. Die Frage „Wie kommen die Daten sauber und aktuell in das System?" entscheidet über mehr Projekttage als jede andere, und sie wird in Angeboten fast nie beantwortet.
Kosten. Ein Modellaufruf kostet Bruchteile eines Cents. Das klingt nach nichts, bis 40 Mitarbeiter täglich Fragen stellen, jede Frage zehn Dokumentabschnitte in den Kontext lädt und das System nebenbei noch Mails klassifiziert. Dann steht am Monatsende eine Rechnung, die niemand kalkuliert hat. Und sie steigt weiter, wenn das System gut ankommt.
Sicherheit. Ein Assistent, der Dokumente lesen und Mails schreiben kann, ist ein Angriffsziel. Wer Zugriffsrechte im Prompt regelt („Antworte nur mit Informationen, die der Nutzer sehen darf") statt in der Datenbank, hat keine Zugriffsrechte. Und wer dem Modell erlaubt, nach dem Lesen einer fremden Mail selbstständig zu senden, hat einen Weg gebaut, über den eine präparierte Mail den Assistenten zum Absender macht.
Keiner dieser vier Punkte ist in einer Demo sichtbar. Alle vier entscheiden im Betrieb.
Fünf Fragen, die vor jedem Auftrag beantwortet sein müssen
Wenn du ein KI-Projekt beauftragen willst — bei mir oder bei jemand anderem —, solltest du diese fünf Fragen beantworten können. Nicht ungefähr, sondern so, dass es jemand aufschreiben kann.
1. Welche Daten braucht das System, wo liegen sie, und wer darf sie sehen? Nicht „unsere Dokumente", sondern: welche Ordner, welche Systeme, welche Formate, wie oft ändern sie sich. Und je Nutzergruppe: Was darf sie sehen, was nicht? Wenn die Antwort „alle dürfen alles" lautet, prüfe das noch einmal. Gehaltslisten, Kundenverträge und Personalunterlagen liegen in den meisten Ablagen näher an den Betriebsanleitungen, als man denkt.
2. Was passiert, wenn das Modell falsch liegt? Es wird falsch liegen. Die Frage ist nicht ob, sondern: Merkt es jemand? Gibt es einen Weg, die Antwort zu korrigieren, damit sie beim nächsten Mal stimmt? Und gibt es für jede Funktion einen manuellen Weg, der ohne KI funktioniert? Ein System, das die Antwort „Das weiß ich nicht" nicht geben kann, ist im Betrieb gefährlicher als gar keins.
3. Was kostet ein Monat Betrieb bei realer Nutzung? Mit Zahlen: Nutzer, Anfragen pro Tag, Kontextgröße je Anfrage, Modellwahl. Dazu Hosting, Backup, Updates. Wer diese Rechnung vor dem Projekt nicht aufstellt, stellt sie nach dem Projekt — dann mit den echten Rechnungen.
4. Wo läuft es, und wem gehört es? Auf welchem Server, in welchem Land, unter wessen Zugang. Was passiert mit Code und Datenbank, wenn du den Dienstleister wechselst? Ein System, das nur der Anbieter bedienen kann, ist keine Investition, sondern ein Abonnement mit hohen Ausstiegskosten.
5. Woran misst du in drei Monaten, ob es sich gelohnt hat? Bearbeitungszeit je Anfrage, Zahl der Rückfragen an die Fachabteilung, Antwortquote des Assistenten — irgendetwas, das du heute schon messen kannst, damit es später einen Vergleichswert gibt. Ohne Ausgangswert gibt es nach drei Monaten nur Meinungen.
Wer alle fünf beantworten kann, braucht kein Audit. Erfahrungsgemäß können es die wenigsten — und das ist kein Vorwurf, sondern der Grund, warum es dieses Angebot gibt.
Was das Audit in drei Tagen liefert
Das KI-Machbarkeits-Audit ist genau dafür gebaut: die fünf Fragen beantworten, bevor Geld in die Umsetzung fließt. Drei Tage, ein Dokument, ein fester Preis.
Tag 1 — Kick-off und Bestandsaufnahme. Wir gehen gemeinsam durch, was du erreichen willst und was vorhanden ist: bestehende Systeme und Schnittstellen, Datenquellen, vorhandene Oberflächen oder Entwürfe. Ich stelle die unbequemen Fragen jetzt, nicht in Woche drei eines Projekts. Am Ende des Tages ist klar, welches Problem gelöst werden soll — und welches nicht.
Tag 2 — Architektur und Datenmodell. Ich entwerfe die Systemarchitektur: welche Komponenten, welche Technologie, wie die Daten hineinkommen und wie sie geschützt werden. Dazu das relationale Datenmodell und, wo ein Wissensassistent geplant ist, die Struktur der Vektortabellen. Das ist kein Schaubild für eine Präsentation, sondern der Entwurf, nach dem gebaut werden kann.
Tag 3 — Kosten und Fahrplan. Kostenprojektion für die Modell-APIs bei deiner erwarteten Nutzung, Empfehlung zum Modell-Routing (schnelles Modell für Routine, Reasoning-Modell nur dort, wo es nötig ist), Aufwandsrahmen für die Umsetzung und ein Fahrplan in Phasen. Übergabe des Architekturberichts als Markdown und PDF, mit Besprechung.
Was du am Ende in der Hand hast: Anforderungsanalyse, Technologieauswahl mit Begründung, Datenmodell, API-Kostenschätzung und einen Fahrplan. Und eine ehrliche Antwort auf die Frage, ob das Projekt sinnvoll ist. Manchmal lautet sie: nicht in dieser Form. Das ist dann der wertvollste Satz im Dokument.
Was es kostet und was du behältst
1.500 €, Festpreis. Keine Stundenabrechnung, keine Nachträge. Anzahlung bei Beauftragung.
Das Dokument gehört dir. Du kannst damit zu jedem Dienstleister gehen, es intern umsetzen oder in der Schublade lassen. Es ist bewusst so geschrieben, dass ein anderer Entwickler damit arbeiten kann — Architektur, Datenmodell und Kostenrechnung sind nachvollziehbar und nicht an mich gebunden. Wenn du anschließend mit mir bauen willst, ist das Audit die Grundlage des Angebots. Wenn nicht, war es ein günstiger Weg, ein teures Projekt zu prüfen.
Für wen es nichts ist
Ich sage offen, für wen sich das nicht lohnt:
- Du willst erst einmal ausprobieren, ob KI für dich überhaupt taugt. Dann brauchst du kein Audit, sondern einen Account bei einem der Anbieter und zwei Wochen Zeit. Das Audit lohnt sich, wenn ein konkretes Vorhaben im Raum steht.
- Die Architekturentscheidung ist schon gefallen, und du suchst jemanden, der sie bestätigt. Ich schreibe auf, was ich für richtig halte. Wenn du das nicht hören willst, ist das Geld anderswo besser angelegt.
- In den drei Tagen ist niemand erreichbar, der die Daten und Prozesse kennt. Ohne Zugang zu Systemen und Ansprechpartnern entsteht ein Dokument über Annahmen — genau das, was ein Audit vermeiden soll.
- Du hast eine eigene Plattform- oder Architekturabteilung. Dann ist diese Arbeit dort besser aufgehoben. Ich bin die Lösung für Unternehmen, die diese Rolle nicht im Haus haben.
Der nächste Schritt
Wenn ein KI-Vorhaben bei dir ansteht und mindestens eine der fünf Fragen offen ist: Buche ein 40-minütiges Gespräch. Wir klären, ob das Audit passt — und wenn es nicht passt, sage ich dir das im Gespräch, nicht nach der Rechnung.
Termin buchen: ki-studio.koeln/termin
—
Nick Kirschbacher, KI Studio Köln — AI Systems Architect & Full-Stack Builder. Ich bringe KI-Systeme in Produktion, die über einen Chat-Wrapper hinausgehen: RAG auf eigenen Dokumenten, Multi-Agenten-Workflows, komplette Web-Anwendungen mit Datenbank, Auth und Betrieb.