Die Einführung einer KI-gestützten Anwendung endet selten so, wie es in Startup-Filmen aussieht. Ohne Knall, ohne Drama, ohne eine einzige fatale Entscheidung. In der Praxis versanden KI-Projekte langsam. Sie verlieren Wochen mit Nachbesserungen, das Budget löst sich in Kosten auf, die niemand vorhergesehen hat, und der Kunde hat nach einem halben Jahr eine funktionierende Demo statt eines funktionierenden Produkts. Wir, das Team von Web Systems, einem Software House aus Łódź, das seit 2006 ununterbrochen tätig ist, haben Hunderte Einführungen hinter uns: Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce und seit einigen Jahren immer häufiger Lösungen auf Basis von Künstlicher Intelligenz. Und das gibt uns einen Vorteil. Wir sehen, wo ein Projekt stockt, bevor der Kunde es überhaupt als Problem benennen kann.
Ich beginne mit einer These, die in jedem Budgetgespräch Gewicht haben sollte: Die meisten Misserfolge bei Einführungen entstehen nicht aus dem “Fehlen des passenden Modells”. Sprachmodelle sind heute erstaunlich gut und günstig. Das Problem sitzt woanders – in Entscheidungen, die getroffen werden, bevor irgendjemand die erste Zeile Code schreibt. Wem gehören die Daten? Was passiert, wenn das Modell einen Fehler zurückgibt? Wie berechnen Sie die Kosten einer Anfrage mal tausend Nutzer pro Tag? Denn wenn diese Fragen erst in der Produktionsphase gestellt werden, ist es bereits zu spät. Und Korrekturen kosten dann ein Vielfaches eines gut entworfenen Fundaments.
Das Thema Software House aus Łódź und die reale Einführung einer KI-Anwendung klingt wie ein Marketingslogan, im Kern geht es aber um etwas sehr Bodenständiges. Um Ingenieursarbeit. KI ist kein magisches Extra, das man einfach an ein bestehendes System “anschließt”. Sie ist eine weitere Schicht und hat eigene Anforderungen – Architektur, Daten, Sicherheit, Wartung. Ein Unternehmen, das Künstliche Intelligenz als Funktion behandelt, die man in der Spezifikation abhakt, läuft früher oder später gegen eine Wand. Entweder beim Skalieren, oder bei der Rechnung für die Inferenz, oder dann, wenn die Anwendung anfängt, selbstsichere, aber falsche Antworten zu geben.
In diesem Text zerlegen wir fünf Fehler, die KI-Projekte in polnischen Software Houses am häufigsten aus der Spur werfen. Wir schreiben das nicht als neutraler Marktbeobachter, sondern als Dienstleister, der diese Probleme aus dem Effeff kennt. Denn einen Teil davon haben wir in der Anfangszeit selbst begangen und konkrete Schlüsse daraus gezogen. Jeder dieser Fehler hat einen gemeinsamen Nenner: Er entsteht aus der Verwechslung eines eindrucksvollen Prototyps mit einem fertigen, wartbaren Produkt. Wenn Sie einen Dienstleister für eine KI-Anwendung suchen, gibt Ihnen dieser Text eine konkrete Liste von Fragen, die Sie stellen sollten, bevor Sie einen Vertrag unterschreiben. Und wenn Sie selbst solche Lösungen bauen – betrachten Sie ihn als Checkliste, die Ihnen ein paar schmerzhafte Lektionen erspart. Also los. Von der Demo, die ausschließlich bei der Präsentation funktioniert, bis hin zum fehlenden Plan für das, was am Tag nach der Einführung passiert.
Spis treści
Fehler 1: Demo mit Produktion verwechseln – also KI, die nur bei der Präsentation funktioniert
Die häufigste Falle sieht harmlos aus. Jemand öffnet den Playground des Modellanbieters, fügt einen gelungenen Prompt ein, bekommt eine großartige Antwort und verkündet, die “Anwendung funktioniert im Grunde schon”. Eben nicht. Ein funktionierender Prompt ist keine Anwendung – er ist ein einzelnes, isoliertes Experiment unter idealen Bedingungen. Zwischen ihm und der Produktion liegt eine ganze Schicht Ingenieursarbeit, die man bei der Präsentation nicht sieht und die darüber entscheidet, ob die Lösung den Kontakt mit echten Nutzern übersteht. Es fehlen die Datenschicht, die Fehlerbehandlung, die Anfragelimits, die Kontrolle der Token-Kosten, das Monitoring. Und dieser unsichtbare Teil macht rund 80 Prozent der eigentlichen Arbeit aus.
Überlegen Sie, was passiert, wenn das Modell langsam oder gar nicht antwortet. Im Playground klicken Sie einfach auf “erneut versuchen”. In der Produktion brauchen Sie eine definierte Strategie: Timeouts, Wiederholungsversuche mit exponentieller Verzögerung, einen Notfallmechanismus für den Fall, dass der Anbieter ausfällt, eine sinnvolle Meldung für den Nutzer und ein Logging des Ereignisses, damit man es später analysieren kann. Ohne das endet der erste ernsthafte Traffic auf der Anwendung in einer Reihe von Fehlern, die niemand vorhergesehen hat. Eine Demo testet solche Szenarien nie. Denn eine Demo zeigt grundsätzlich nur den Pfad, der funktioniert.
Das zweite Gesicht desselben Fehlers ist die Architektur. Genauer: ihr Fehlen. In der Eile landet die gesamte Logik in einem einzigen Endpoint: Daten holen, Prompt bauen, Modell aufrufen, Antwort parsen, speichern – alles in einer Funktion mit mehreren hundert Zeilen. Solcher Code sieht bei einem Hackathon großartig aus und wird in der Wartung zum Albtraum. Jede Änderung droht etwas anderes kaputtzumachen, das Testen eines einzelnen Teils ist praktisch unmöglich, und die Einarbeitung eines neuen Entwicklers in das Projekt dauert Wochen. Und eine gesunde Aufteilung in Schichten – Benutzeroberfläche, Geschäftslogik, Datenzugriff – ist kein akademischer Luxus. Sie ist die Voraussetzung dafür, dass sich die Anwendung länger als einen Sprint weiterentwickeln lässt.
Die dritte Dimension ist das Geld. Im Playground sind die Kosten einer Anfrage unsichtbar. In der Produktion, bei Tausenden Nutzern, schlägt sich jedes Token in einer konkreten Rechnung nieder. Eine Anwendung, die unkontrolliert ganze Dokumente an das Modell schickt oder dieselben Anfragen ohne Caching wiederholt, kann eine Rechnung erzeugen, die um ein Vielfaches höher ausfällt als angenommen. Die Kontrolle der Inferenzkosten – Limits, Zwischenspeichern von Antworten, Wahl eines günstigeren Modells für einfachere Aufgaben, Begrenzung der Kontextlänge – muss von Anfang an entworfen werden. Nicht nach dem ersten Schock bei der Abrechnung angeklebt.
Was tun Sie damit in der Praxis? Vor der Vertragsunterzeichnung mit einem Dienstleister lohnt es sich, von der Ebene der Versprechen auf die Ebene der Konkreta hinabzusteigen.
Tipp: Bevor Sie einen Vertrag über eine KI-Anwendung unterschreiben, bitten Sie den Dienstleister, zwei Dinge schriftlich zu beschreiben – den Plan zur Behandlung von Modellfehlern (was passiert, wenn keine Antwort kommt oder sie falsch ist) und den Mechanismus zur Kontrolle der Inferenzkosten. Wenn Sie Allgemeinplätze statt Konkreta hören, ist das ein Warnsignal.
Bei Web Systems behandeln wir die Demo-Phase als Etappe zur Validierung der Idee, nie als Produkt. Nach der Vorführung eines funktionierenden Prototyps folgt immer das Gespräch darüber, was ihn von der Produktivversion trennt: über Skalierung, Kosten, Störfälle und Daten. Ein weniger spektakulärer Moment als die Präsentation selbst, zugegeben. Aber genau dann fallen die Entscheidungen, die darüber bestimmen, ob wir das Projekt im Budget liefern oder es über Monate hinweg retten müssen. Demo mit Produktion zu verwechseln ist Fehler Nummer eins, weil er allen anderen die Tür öffnet.
Fehler 2: Schwaches Retrieval in RAG – die Anwendung antwortet sicher, aber am Thema vorbei
Die RAG-Architektur, also suchgestützte Generierung, ist zum Standardweg geworden, KI-Anwendungen auf Basis von Firmenwissen zu bauen. Die Idee ist einfach und richtig: Statt darauf zu setzen, dass das Modell alles “weiß”, suchen wir zuerst in der Wissensbasis die für die Frage relevanten Fragmente und bitten dann das Modell, ausschließlich auf deren Grundlage zu antworten. Nur hängt die Qualität der gesamten Lösung nicht vom Modell ab, sondern von diesem ersten Schritt – von der Suche. Wenn der Retrieval-Mechanismus dem Modell unwichtige Fragmente unterschiebt, bekommen Sie eine Antwort, die sicher klingt, korrekt formuliert ist und völlig am Thema vorbeigeht.
Die Fachdokumentation stellt die Sache eindeutig dar:
Der Suchmechanismus in RAG ist von entscheidender Bedeutung. Sie brauchen die beste semantische Suche auf Basis einer sorgfältig ausgewählten Wissensbasis, um sicherzugehen, dass die abgerufenen Informationen für die Anfrage relevant sind. Sind die abgerufenen Informationen irrelevant, kann die erzeugte Antwort zwar in den Daten verankert, aber am Thema vorbei oder schlicht falsch sein.
Dieser Satz sollte über dem Schreibtisch jedes Menschen hängen, der RAG baut. “In den Daten verankert, aber am Thema vorbei” – das ist die gefährlichste Art von Fehler, denn der Nutzer hat keine Möglichkeit, ihn zu bemerken. Die Antwort wirkt glaubwürdig, das Modell zitiert irgendeine Quelle, der Ton ist professionell. Erst ein Fachexperte merkt, dass der Inhalt etwas Nebensächliches betrifft. Und in B2B-Anwendungen, in denen die Anwendung zu rechtlichen, technischen oder finanziellen Fragen berät, kann ein solcher stiller Fehler deutlich mehr kosten als eine offene Störung.
Woher kommen schwache Suchergebnisse? Meist aus drei Versäumnissen auf Datenebene. Das erste ist die fehlende Kuration der Wissensbasis – man wirft alles hinein, was das Unternehmen besitzt, samt veralteten Dokumentversionen, Duplikaten und in sich widersprüchlichen Materialien. Das Modell kann nicht entscheiden, welche Fassung der Geschäftsordnung gilt, also vermischt es sie. Das zweite ist schlechtes Chunking, also das Zerlegen von Dokumenten in Fragmente. Wenn Sie den Text mechanisch alle paar hundert Zeichen zerschneiden, zerreißen Sie einen Satz mitten im Gedanken und zerstören den Kontext, den das Modell braucht. Das dritte ist schwaches Parsing – falsch gelesene Tabellen, übersprungene Überschriften, aus einem PDF zusammengeklebte Spalten. Garbage in, garbage out wirkt hier unbarmherzig.
Die wichtigste Lektion betrifft jedoch die Messung. Die RAG-Qualität “nach Gefühl” zu beurteilen, indem man ein paar Beispielfragen durchklickt, erzeugt ein trügerisches Gefühl von Kontrolle. Der professionelle Ansatz besteht darin, konkrete Metriken zu messen – vor allem die Verankerung der Antwort in den Quellen (Groundedness), die sprachliche Flüssigkeit (Fluency) sowie das Maß, in dem sich die Antwort tatsächlich auf die Frage bezieht. Ein Text über Evaluationsplattformen formuliert es so:
Die Umsetzung dieser Evaluationen liefert einen Bezugspunkt und erlaubt es, die RAG-Qualität zu optimieren – über die Konfiguration der Suchmaschine, die Kuration der Quelldaten, ein besseres Parsing des Quellenlayouts oder der Chunking-Strategie oder die Präzisierung der Nutzerfrage vor der Suche. Ein metrikbasierter Ansatz erlaubt es, sich schrittweise zu hoher Generierungsqualität hochzuarbeiten.
Mit anderen Worten: RAG-Qualität ist kein einmaliger Effekt, sondern ein Prozess iterativen Feintunings. Sie messen, ändern einen Parameter, messen erneut. Ohne Baseline und Metriken ist jede “Verbesserung” schlichtes Raten.
Tipp: Wenn Sie eine Anwendung wie einen Wissens-Chatbot oder einen Dokumentenassistenten beauftragen, legen Sie mit dem Dienstleister schon zu Beginn fest, wie die Antwortqualität gemessen wird. Bitten Sie um einen Satz Testfragen mit erwarteten Antworten sowie um einen Bericht mit den Metriken Groundedness und Trefferqualität. Das verwandelt das nebulöse Versprechen “funktioniert gut” in etwas, das sich prüfen lässt und woran man jemanden messen kann.
In unseren RAG-Projekten behandeln wir die Wissensbasis als eigenes Produkt – mit Aktualisierungsprozess, Versionskontrolle und regelmäßiger Evaluation. Weniger spektakulär als das Modell selbst, in der Tat. Aber genau hier entscheidet sich, ob die KI-Anwendung wirklich hilft oder nur den Eindruck erweckt, dass sie hilft.
Fehler 3: Fehlende Architektur und keine einzige Quelle der Wahrheit für Daten
Der dritte Fehler ist grundlegender als die übrigen, denn er betrifft nicht die KI-Schicht, sondern die gesamte Art, wie die Anwendung gebaut wird. Künstliche Intelligenz ändert hier nichts. Im Gegenteil – sie legt Architekturschwächen schneller und schmerzhafter offen. Eine KI-Anwendung operiert mit Daten, Zuständen und Flüssen, die sich leicht in Chaos verwandeln, wenn die ingenieurtechnische Disziplin fehlt. Und diese Disziplin beginnt mit einem Prinzip, das banal klingt und in der Praxis Projekte rettet: der Trennung der Verantwortlichkeiten.
Die Architekturdokumentation nennt die Dinge beim Namen:
Das wichtigste Prinzip ist die Trennung der Verantwortlichkeiten – die Aufteilung der Anwendung in Methoden, Klassen, Dateien, Pakete, Module und Schichten mit klar definierten Aufgaben und Grenzen. Ein häufiger Fehler ist es, den gesamten Code in einer einzigen Komponente zu schreiben.
“Der ganze Code in einer Komponente” ist exakt dieselbe Krankheit, die wir beim ersten Fehler beschrieben haben, nur betrachten wir sie hier aus der Vogelperspektive. Wenn Geschäftslogik, Datenbankzugriff, Aufrufe des KI-Modells und die Bedienung der Oberfläche an einer Stelle vermischt werden, wird die Anwendung zu einem Monolithen, in dem sich nichts ohne Risiko ändern lässt. Jede Schicht sollte eine einzige, klar umrissene Aufgabe haben und mit den anderen über definierte Grenzen kommunizieren. Die minimale gesunde Aufteilung besteht aus Präsentationsschicht, Geschäftslogikschicht und Datenschicht – und in komplexeren Systemen kommt eine Zwischenschicht mit wiederverwendbaren Anwendungsfällen hinzu.
Die zweite Säule ist die einzige Quelle der Wahrheit, also das Prinzip, dass es für jede Art von Daten genau einen Eigentümer gibt, der sie verändern darf. Der Rest des Systems liest diese Daten nur in unveränderlicher Form und meldet Änderungen über Ereignisse. Das klingt formal, doch die Konsequenzen sind ausgesprochen praktisch. Wie das Quellenmaterial beschreibt, zentralisiert ein solches Muster alle Änderungen eines Datentyps an einer Stelle, schützt die Daten vor Manipulation von außen und macht Änderungen leichter nachvollziehbar, sodass sich Fehler leichter aufspüren lassen. In einer KI-Anwendung, in der derselbe Zustandsausschnitt von der Oberfläche gelesen, von der Logik verändert und vom Modell angereichert werden kann, führt das Fehlen eines einzigen Dateneigentümers zu Fehlern, die anschließend niemand mehr reproduzieren kann.
Mit der einzigen Quelle der Wahrheit geht der unidirektionale Datenfluss einher. Der Zustand fließt in eine Richtung, meist von der Datenschicht zur Oberfläche, und die Nutzerereignisse fließen in die Gegenrichtung, bis sie den Dateneigentümer erreichen. Dadurch weiß man jederzeit, woher ein Wert stammt und was ihn verändert haben könnte. Das ist das Fundament einer Anwendung, die skalieren soll – sowohl hinsichtlich des Traffics als auch hinsichtlich der Zahl der parallel daran arbeitenden Entwickler.
Was genau verlieren Sie, wenn Sie im Namen eines “schnelleren Starts” auf Architektur verzichten? Die Liste der Konsequenzen ist vorhersehbar und teuer:
- Schwierige Tests – wenn Netzwerk-, Daten- und Präsentationslogik verflochten sind, lässt sich kein einzelner Teil isoliert testen, also gibt es meist gar keine Tests.
- Langes Onboarding – ein neuer Entwickler braucht Wochen, um Code zu verstehen, in dem alles von allem abhängt, statt Tage bei einer lesbaren Aufteilung in Schichten.
- Konflikte im Code – mehrere Personen, die dieselbe überladene Datei bearbeiten, bedeuten ständige Konflikte beim Zusammenführen und Änderungen, die sich gegenseitig auslöschen.
- Wachsende technische Schuld – jede Abkürzung heute ist ein um ein Vielfaches höherer Preis morgen, wenn die Codebasis wächst und die Fundamente umgebaut werden müssen.
- Fehlende Skalierbarkeit – eine Anwendung, die bei hundert Nutzern lief, beginnt bei zehntausend zu bröckeln, weil niemand an Verantwortungsgrenzen gedacht hat.
Gute Architektur ist nicht kostenlos – sie erfordert Nachdenken zu Beginn. Aber sie ist eine Investition, die sich bei der ersten größeren Änderung des Umfangs auszahlt. Und in KI-Projekten sind solche Änderungen die Regel, nicht die Ausnahme. Modelle ändern sich, Anforderungen entwickeln sich weiter, neue Datenquellen kommen hinzu. Ein System mit sauberen Grenzen nimmt diese Änderungen auf. Ein System ohne Architektur bricht. Bei Web Systems entwerfen wir die Schichten, bevor wir die KI-Logik schreiben, denn wir wissen eines: Künstliche Intelligenz ist nur so gut wie das Fundament, auf dem sie steht.
Fehler 4: Integrationen, Daten und Sicherheit ignorieren
Eine KI-Anwendung existiert nicht im luftleeren Raum. Das ist eine der am häufigsten übersehenen Tatsachen in Gesprächen über Einführungen – der Kunde stellt sich einen eleganten Chat mit einem Modell vor und vergisst, dass der wahre Wert erst entsteht, wenn sich diese Intelligenz mit den Systemen verbindet, mit denen das Unternehmen tatsächlich arbeitet. Das CRM mit der Kundenhistorie, das ERP mit Bestell- und Lagerdaten, die E-Commerce-Plattform, interne B2B-Systeme, Dokumentenbestände. Eine von diesen Quellen abgeschnittene KI ist wie ein Berater, dem man den Zugang zu den Akten entzogen hat – er mag schön reden, weiß aber nichts Konkretes über Ihr Unternehmen.
Integrationen sind meist der arbeitsintensivste und am stärksten unterschätzte Teil eines Projekts. Jedes System hat seine eigene API, seine eigenen Datenformate, seine eigenen Leistungsgrenzen und seine eigenen Eigenheiten. Die Synchronisierung von Daten zwischen Modell und ERP nahezu in Echtzeit, der Umgang mit Situationen, in denen das Quellsystem nicht verfügbar ist, das Mapping von Feldern, die in verschiedenen Systemen unterschiedlich heißen – all das ist reale Ingenieursarbeit, die geplant werden muss. Und nicht die Annahme, dass sich das “schon irgendwie anschließen lässt”. Als Software House mit dem Gepäck von API-Integrationen seit 2006 wissen wir, dass Projekte genau hier am häufigsten zeitlich aus dem Ruder laufen.
Man sollte auch verstehen, dass eine moderne KI-Anwendung weit mehr ist als eine Vektordatenbank mit Ähnlichkeitssuche. Das Quellenmaterial zeigt gut, wo der zusätzliche Wert liegt:
Über den bloßen Ersatz einer Vektordatenbank hinaus bietet die Lösung fertige NLP-Anreicherungen, darunter Entitätsextraktion, Sentimentanalyse, Emotionsanalyse, Schlüsselwortextraktion, Kategorienklassifikation und Konzept-Tagging.
Das ist wichtig, denn es zeigt, dass der wahre geschäftliche Wert aus den Datenanreicherungen entsteht und nicht aus der Suche allein. Die Entitätsextraktion erlaubt es, aus einem Dokument automatisch Firmennamen, Beträge und Daten zu ziehen. Die Kategorienklassifikation leitet ein Ticket an die richtige Abteilung. Die Sentimentanalyse erlaubt es, einen unzufriedenen Kunden zu erkennen, bevor er abwandert. Diese NLP-Schichten verwandeln rohen Text in strukturiertes Wissen, auf dem sich Automatisierungen aufbauen lassen – und oft entscheiden gerade sie darüber, ob eine KI-Einführung real Zeit spart oder nur ein hübsches Gadget ist.
Der ernsteste Bereich ist jedoch die Sicherheit. In KI-Projekten erstaunlich oft stiefmütterlich behandelt. Wenn Sie Daten an ein externes Modell schicken, müssen Sie genau wissen, was wohin abfließt. Eine unbedachte Einführung kann sensible Daten an den Modellanbieter übertragen – personenbezogene Daten von Kunden, Geschäftsgeheimnisse, Informationen, die unter Vertraulichkeitsvereinbarungen fallen. Es gibt mehrere Risiken, und jedes erfordert eine bewusste Entscheidung.
- Datenabfluss ins Modell – sensible Daten, die direkt in den Prompt eingefügt werden, können die kontrollierte Umgebung verlassen; nötig sind Anonymisierung, Maskierung oder ein privat gehostetes Modell.
- Fehlende Zugriffskontrolle – die KI-Anwendung muss die Berechtigungen des Nutzers respektieren, sonst gibt sie jemandem Daten zurück, die er nicht sehen dürfte, und umgeht damit die Schutzmechanismen der Quellsysteme.
- Sensible Daten in Prompts und Logs – was in den Prompt gelangt, landet in der Regel auch in den Logs; ohne durchdachte Logging-Richtlinie schaffen Sie eine zweite, unkontrollierte Kopie vertraulicher Informationen.
Diese Fragen müssen in der Entwurfsphase geklärt werden, denn sie berühren die DSGVO-Konformität und die reale rechtliche Verantwortung des Unternehmens. Die Wahl zwischen einem Cloud-Modell und einem lokal gehosteten, die Richtlinie zur Datenaufbewahrung beim Anbieter, Verschlüsselung, Mechanismen zur Maskierung sensibler Daten vor dem Versand – das sind Architekturentscheidungen und keine Details, die man am Ende festzurrt. In Projekten, in denen personenbezogene Daten oder Betriebsgeheimnisse im Spiel sind, behandeln wir Sicherheit als erstes Gesprächsthema, nicht als letztes. Denn der Unterschied zwischen einer KI-Anwendung, die den Vorsprung eines Unternehmens ausbaut, und einer, die ein Leckrisiko schafft, liegt genau hier – in der Art, wie Daten verarbeitet, integriert und geschützt werden.
Fehler 5: Null Plan für die Wartung – die Einführung als Ende statt als Anfang
Der fünfte Fehler ist auf lange Sicht vielleicht der teuerste, denn er entspringt einem grundlegenden Missverständnis über die Natur von KI-Software. Der Kunde nimmt eine funktionierende Anwendung ab, unterschreibt das Protokoll, feiert das Projektende – und betrachtet den Moment der Einführung als Ziellinie. Für eine auf Künstlicher Intelligenz basierende Anwendung ist die Einführung aber erst die Startlinie. Was danach passiert, entscheidet darüber, ob die Lösung nach einem Jahr noch Wert liefert oder still zu einem Werkzeug verkommt, dem niemand mehr vertraut.
Beginnen wir mit den Inferenzkosten, denn das ist der greifbarste Aspekt der Wartung. Anders als bei einer klassischen Anwendung, bei der Sie nach der Einführung vor allem für den Server zahlen, erzeugt eine KI-Anwendung bei jeder Nutzung Kosten. Je beliebter sie ist, desto höher die Rechnung. Ohne Monitoring des Tokenverbrauchs, ohne Optimierung der Prompts, ohne Caching wiederkehrender Anfragen und ohne bewusste Wahl des Modells für die jeweilige Aufgabe können die Kosten schneller wachsen als der Wert, den die Anwendung liefert. Die Wartung von KI bedeutet unter anderem, die Ökonomie dieses Prozesses ständig im Blick zu behalten.
Der zweite Bereich ist der sich verschiebende Boden unter den Füßen. Modellanbieter veröffentlichen regelmäßig neue Versionen, stellen alte ein, ändern Preise und das Verhalten der API. Das Modell, auf dem Sie Ihre Anwendung aufgebaut haben, kann in einem Jahr nicht mehr verfügbar sein oder anders antworten. Ohne Plan für Aktualisierungen und ohne Abstraktionsschicht, die Ihre Anwendung vom konkreten Anbieter trennt, ist jede solche Änderung ein plötzliches Notfallprojekt. Mit gut entworfener Architektur ist es eine kontrollierte Migration.
Am heimtückischsten ist jedoch die Qualitätsverschlechterung im Lauf der Zeit. Eine Anwendung, die am Tag der Einführung hervorragend antwortete, kann nach einigen Monaten schlechter antworten, obwohl sich der Code nicht geändert hat. Die Gründe sind unterschiedlich: Die Wissensbasis ist gealtert, es sind neue Fragetypen aufgetaucht, auf die das System nicht vorbereitet war, das Verhalten des Modells hat sich nach einer Aktualisierung beim Anbieter geändert. Ohne Metriken bemerken Sie das nicht, bis die Beschwerden eintreffen. Und hier kehrt die Lektion über die Messung zurück, die wir bei RAG gelernt haben – ohne Zahlen lässt sich die Qualität nicht verbessern, weil man nicht einmal weiß, ob und wo sie gesunken ist.
Deshalb umfassen reife KI-Einführungen das, was zunehmend RAG Ops oder LLM Ops genannt wird – die operative Disziplin der Qualitätssicherung. Regelmäßige Evaluation an einem festen Satz Testfragen, Monitoring der Metriken Groundedness und Trefferqualität, Alarme bei Qualitätsabfall, ein Prozess zur Aktualisierung der Wissensbasis, Verfolgung von Kosten und Modellversionen. Das ist kein optionales Extra für die Größten. Das ist das Minimum, wenn die Anwendung dem Unternehmen über Jahre real dienen und nicht nur eine gelungene Demo zur Premiere abliefern soll.
Tipp: Planen Sie das Budget für die Wartung einer KI-Anwendung ab dem ersten Tag ein, nicht erst nach der ersten Störung. Gehen Sie davon aus, dass Betriebskosten, Monitoring und regelmäßiges Feintuning ein fester Posten sind und keine einmalige Ausgabe. Ein Unternehmen, das weiß, dass nach der Einführung die Wartung wartet, trifft schon zu Beginn bessere Architekturentscheidungen – weil es für den gesamten Lebenszyklus entwirft und nicht für den Moment der Abnahme.
Bei Web Systems behandeln wir die Wartung als integralen Bestandteil jedes KI-Projekts und nicht als nachträglich angeklebte Leistung. Wir sprechen darüber in der Angebotsphase, wir entwerfen die Anwendung so, dass sie sich überwachen und aktualisieren lässt, und wir sagen dem Kunden klar, was das Leben des Produkts nach der Einführung erfordert. Denn eine KI-Anwendung ohne Wartungsplan ist kein abgeschlossenes Projekt. Sie ist ein aufgeschobenes Problem.
FAQ: die häufigsten Fragen von Kunden auf der Suche nach einem Dienstleister für KI-Anwendungen
Wir haben drei Fragen gesammelt, die in fast jedem Gespräch mit einem Kunden wiederkehren, der die Einführung einer KI-Anwendung erwägt. Wir beantworten sie so, wie wir es in Meetings tun – ohne Fachjargon und ohne Versprechen, die sich nicht halten lassen.
Brauche ich ein eigenes Modell oder reicht die Integration eines fertigen LLM?
In der überwiegenden Mehrheit der geschäftlichen Fälle ist die Integration eines fertigen großen Sprachmodells die richtige und günstigere Wahl. Ein eigenes Modell von Grund auf zu trainieren, ist ein Projekt in der Größenordnung von Hunderttausenden Złoty und erfordert riesige Datenmengen – das lohnt sich nur selten. Der reale Wert für ein Unternehmen entsteht nicht im Modell selbst, sondern in der Schicht darum herum: in einer gut aufbereiteten Wissensbasis, in der RAG-Architektur, in den Integrationen mit Ihren Systemen und in den Datenanreicherungen. Wenn Sie eine spezifische, wiederkehrende Aufgabe und viele Daten haben, kann das Feintuning eines bestehenden Modells sinnvoll sein, aber das ist eine Optimierung für eine spätere Phase und kein Ausgangspunkt. Wir starten meist mit der Integration eines fertigen Modells und konzentrieren uns auf das, was die Lösung wirklich unterscheidet.
Was kostet die Wartung einer KI-Anwendung nach der Einführung wirklich?
Es gibt keine einzelne Zahl, denn die Kosten hängen vom Nutzungsumfang, vom gewählten Modell und von der Komplexität der Lösung ab, aber man kann sie in drei Bestandteile zerlegen. Der erste sind die Inferenzkosten, also die Gebühren für Anfragen an das Modell – sie wachsen mit der Zahl der Nutzer und lassen sich durch Optimierung der Prompts und Caching deutlich senken. Der zweite sind Infrastruktur und Hosting, ähnlich wie bei einer klassischen Anwendung. Der dritte, am häufigsten übersehene, sind die Betriebskosten für die Qualitätssicherung: Monitoring, Aktualisierung der Wissensbasis, Reaktion auf Modelländerungen und regelmäßiges Feintuning. Eine ehrliche Kalkulation berücksichtigt alle drei. Wir empfehlen, daran wie an die Kosten für den Besitz eines Autos zu denken und nicht wie an einen einmaligen Kauf – die Wartung ist ein fester Posten, den man von Anfang an einplanen sollte.
Womit fange ich an, wenn ich Daten habe, aber nicht weiß, ob sie sich für KI eignen?
Mit einem Datenaudit und einem kleinen Pilotprojekt. Bevor Sie in eine vollständige Einführung investieren, lohnt es sich zu prüfen, in welchem Zustand Ihre Daten sind – ob sie vollständig, aktuell und konsistent sind und ob sie sich sinnvoll in Fragmente für die Suche zerlegen lassen. Oft stellt sich heraus, dass der größte Wert der Anfangsphase gerade im Ordnen und Kuratieren der Daten liegt, denn sie entscheiden über die Qualität der gesamten Lösung. Wir schlagen vor, mit einem begrenzten Umfang zu beginnen – einem konkreten Anwendungsfall auf einem ausgewählten Datenausschnitt -, die Antwortqualität mit Metriken zu messen und erst danach zu skalieren. Ein solcher Pilot kostet einen Bruchteil des vollen Projekts und erlaubt eine Entscheidung auf Basis von Zahlen statt von Annahmen.
Fazit und Kontakt: Wie Sie diese Fehler nicht wiederholen
Die fünf Fehler, die wir besprochen haben, verbindet ein gemeinsamer Nenner – sie alle entstehen daraus, dass ein eindrucksvoller Start über solide Fundamente gestellt wird. Fassen wir sie kurz zusammen, denn das ist eine Liste, die man bei jedem Gespräch über eine KI-Einführung griffbereit haben sollte. Erstens: Demo mit Produktion verwechseln – ein funktionierender Prompt ist keine Anwendung, solange darunter keine Datenschicht, keine Fehlerbehandlung und keine Kostenkontrolle liegen. Zweitens: schwaches Retrieval in RAG – eine Anwendung, die sicher, aber am Thema vorbei antwortet, ist gefährlicher als eine, die sich offen irrt. Drittens: fehlende Architektur und keine einzige Quelle der Wahrheit – ohne saubere Grenzen zwischen den Schichten wird das Projekt zu einem Monolithen, der sich weder testen noch weiterentwickeln lässt. Viertens: Integrationen, Daten und Sicherheit ignorieren – KI ohne Verbindung zu den Systemen des Unternehmens und ohne Kontrolle über sensible Daten schafft Risiko statt Wert. Fünftens: kein Plan für die Wartung – die Einführung ist der Start und nicht das Ziel, und ohne Metriken und RAG Ops verschlechtert sich die Qualität still mit der Zeit.
Beachten Sie, dass keiner dieser Fehler das Modell selbst betrifft. Alle betreffen die Entscheidungen darum herum – architektonische, datenbezogene, wartungsbezogene. Und das ist kein Zufall. Künstliche Intelligenz ist heute das einfachste Teil des Puzzles. Schwer ist es, um sie herum eine Lösung zu bauen, die in der Produktion funktioniert, sich mit bestehenden Systemen integriert, die Datensicherheit respektiert und sich über Jahre warten lässt. Genau deshalb läuft das Thema Software House aus Łódź und die reale Einführung einer KI-Anwendung letztlich auf Ingenieursarbeit und Erfahrung hinaus und nicht auf den Zugang zu einem gerade angesagten Modell.
Web Systems ist seit 2006 ein solcher Partner. In diesen Jahren haben wir Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen und E-Commerce-Plattformen gebaut, und heute verbinden wir diese Erfahrung mit KI-Lösungen. Wir versprechen keine Magie – wir versprechen einen vernünftigen, technischen Ansatz, bei dem wir zuerst Ihr Problem, Ihre Daten und Ihre Systeme verstehen und erst danach die Werkzeuge auswählen. Wir arbeiten sowohl an Projekten von null an, ab dem ersten MVP, als auch an der Modernisierung bestehender Systeme, die neuen Atem oder eine Intelligenzschicht brauchen.
Wenn Sie eine KI-Anwendung, eine Integration, eine Automatisierung, ein MVP eines neuen Produkts oder die Modernisierung eines Systems planen, das dem Unternehmen nicht mehr folgen kann – sprechen wir darüber. Wir schauen uns Ihre Idee gerne an, zeigen die realen Risiken auf, bevor sie zu Problemen werden, und schlagen ein Vorgehen vor, das zu Ihren Daten, Ihrem Budget und Ihren Zielen passt. Nehmen Sie Kontakt zum Team von Web Systems auf und sehen Sie, wie die Zusammenarbeit mit einem Dienstleister aussieht, der nicht nur an die Premiere denkt, sondern an das gesamte Leben Ihrer Lösung.
