5 Fehler, wegen denen ein Software House aus Łódź keine KI-Anwendung baut

Der Bau einer Anwendung auf Basis von Künstlicher Intelligenz (KI) sieht auf Folien heute einfach aus. In der Produktion – selten. Als Team von Web Systems, einem Software House aus Łódź, das seit 2006 ununterbrochen tätig ist, haben wir Dutzende Projekte gesehen, in denen nicht das Sprachmodell versagt hat, sondern die Art, wie der Dienstleister das gesamte System angegangen ist. Eine KI-Anwendung endet nicht mit einer eindrucksvollen Demo, die während einer Präsentation hübsche Antworten erzeugt. Sie ist ein Produkt, das über Jahre gewartet, in die Werkzeuge des Unternehmens integriert, abgesichert und für echten Traffic skaliert werden muss. Und genau deshalb entscheidet sich das Verhältnis Software House aus Łódź und Bau einer KI-Anwendung so oft auf der Ebene der ingenieurtechnischen Kompetenz des Dienstleisters und nicht an der Liste der Modelle, mit denen er wirbt.

Der Unterschied zwischen einer Demo und einer Einführung ist wie der Unterschied zwischen einem Prototyp und einem für den Straßenverkehr zugelassenen Auto. Der erste soll Eindruck machen. Das zweite muss jeden Tag fahren, bei Regen und Frost, über mehrere Jahre. In KI-Projekten ist diese Kluft oft noch tiefer, denn die Unvorhersehbarkeit der Modelle, die Inferenzkosten und die Datenqualität können ein Budget kippen, das auf dem Papier völlig vernünftig aussah. Ein Kunde, der einen Dienstleister sucht, sieht diese Risiken selten, bevor sie mitten im Projekt auftauchen. Und dann ist es für eine günstige Kurskorrektur meist schon zu spät.

In diesem Artikel zeigen wir fünf Fehler, die wir am häufigsten beobachten und die real darüber entscheiden, ob ein Software House eine funktionierende KI-Anwendung liefert oder nur einen weiteren Prototyp für die Schublade. Das sind keine abstrakten Warnungen aus Ratgebern. Das sind technische, kostenbezogene, integrations- und wartungsbezogene Probleme, die wir aus eigenen Projekten kennen. Alle haben einen gemeinsamen Nenner: fehlendes systemisches Denken. Wenn ein Team KI als eine Funktion behandelt, die man an die Anwendung klebt, und nicht als System mit Architektur, Daten und Lebenszyklus, ist das Ergebnis vorhersehbar. Es funktioniert bei der Vorführung, und nach der Einführung beginnt es zu bröckeln.

Bevor wir zu den Details kommen, eine Einschränkung. Es geht nicht darum, mit Technologie Angst zu machen oder zu behaupten, KI sei schwieriger, als sie tatsächlich ist. Es geht darum, dass der Kunde dem Dienstleister die richtigen Fragen stellt, bevor er einen Vertrag unterschreibt. Ein guter technischer Partner bringt diese Themen von sich aus zur Sprache: Architektur, Retrieval, Wartungskosten, Datensicherheit, Qualitätsmetriken. Und wenn er sie nicht anspricht? Das heißt nicht, dass es die Probleme nicht gibt. Es heißt nur, dass der Kunde sie tragen wird. Meist im denkbar ungünstigsten Moment.

Warum KI-Anwendungen häufiger am Dienstleister scheitern als an der Technologie

Sprachmodelle und Bibliotheken zum Bau von KI-Lösungen sind heute in Reichweite. Der Zugang zur Claude-API, zu OpenAI-Modellen oder zu lokal gehosteten offenen Modellen ist längst keine Eintrittsbarriere mehr. Und paradoxerweise erzeugt genau diese Verfügbarkeit die Illusion, dass sich der Bau einer KI-Anwendung darauf beschränkt, ein Modell anzuschließen und ein paar Prompts zu schreiben. Tatsächlich hat sich die Schwierigkeit woandershin verlagert – vom Modell zur Ingenieursarbeit rund um das Modell. In der Schicht der Integration, der Daten, des Monitorings und der Wartung steckt der größte Teil des Projektrisikos.

Wenn wir gescheiterte Einführungen analysieren, ist selten das Modell selbst schuld. Weitaus häufiger versagt der Dienstleister, der die KI-Anwendung nicht wie ein vollwertiges IT-System behandelt hat. Es fehlt eine geschichtete Architektur. Es fehlt eine durchdachte Verarbeitung der Eingangsdaten. Es fehlt ein Plan für Situationen, in denen das Modell eine falsche oder unvollständige Antwort liefert. Eine Demo verlangt das nicht, denn eine Demo kontrolliert die Bedingungen. Die Produktion kontrolliert sie nicht – ohne solide Ingenieursarbeit zerfällt sie also beim ersten Kontakt mit echten Nutzern und echten Daten.

Für uns, ein Software House aus Łódź mit fast zwei Jahrzehnten Erfahrung in Web- und Mobilanwendungen, B2B-Systemen und API-Integrationen, ist KI eine weitere Schicht, die in bewährte ingenieurtechnische Disziplin eingebettet werden muss. Dieselben Prinzipien, die seit Jahren über die Qualität von Software entscheiden – Trennung der Verantwortlichkeiten, eine einzige Quelle der Wahrheit, Testbarkeit, Kostenkontrolle – gelten auch hier. Eine KI-Anwendung ist keine Ausnahme von den Regeln guter Ingenieursarbeit. Sie ist ein besonders anspruchsvoller Fall davon, bei dem zusätzlich die Unvorhersehbarkeit des Modells hinzukommt.

Das Verhältnis Software House aus Łódź und Bau einer KI-Anwendung läuft also auf eine einzige Frage hinaus: Versteht der Dienstleister, dass er ein System baut und kein eindrucksvolles Spielzeug? Ein Kunde, der das nicht überprüft, kauft ein Versprechen und kein Produkt. In den folgenden Abschnitten zerlegen wir fünf Fehler, die das eine am häufigsten vom anderen trennen. Jeden beschreiben wir aus der Perspektive eines Dienstleisters, der ihre Kosten kennt, weil er mehr als einmal hinter fremden Projekten aufgeräumt oder sie in eigenen bewusst vermieden hat.

Es lohnt sich, diese Punkte wie eine Checkliste für das Gespräch mit einem möglichen Anbieter zu lesen. Nicht, um an einem Nachmittag Architekturexperte zu werden. Sondern um zu erkennen, ob auf der anderen Seite des Tisches ein Team sitzt, das systemisch denkt. Diese eine Unterscheidung schützt das Budget wirksamer als jede Technologieliste in einem Angebot. Eine bis zum Ende gelieferte KI-Anwendung ist die Summe Dutzender guter Ingenieursentscheidungen und nicht die einzelne Wahl eines Modells.

Fehler 1: KI als Gadget statt als System mit Architektur behandeln

Der häufigste Fehler ist zugleich der grundlegendste. Das Team behandelt die KI-Funktion wie eine Verzierung, die man an die Anwendung klebt, und nicht wie ein System, das eine durchdachte Architektur erfordert. In der Praxis sieht das so aus, dass die gesamte Logik an einer Stelle landet – Prompt, Modellaufruf, Parsen der Antwort und Aktualisierung der Oberfläche in derselben Funktion oder demselben Controller. Genau dieses Antimuster heißt in der Welt der Mobilanwendungen: den ganzen Code in einer Activity zu schreiben. Am Anfang funktioniert es. Aber es verhindert jede Weiterentwicklung.

Eine gut entworfene Anwendung, auch eine mit KI, beruht auf der Trennung der Verantwortlichkeiten. Die Oberflächenschicht zeigt Daten an, die Datenschicht enthält die Geschäftslogik und stellt Informationen bereit, und eine optionale Domänenschicht kapselt komplexe Regeln, die an vielen Stellen genutzt werden. Branchenquellen formulieren dieses Prinzip ohne Umschweife:

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 Activity zu schreiben.

Das Zitat bezieht sich formal auf Mobilanwendungen, doch das Prinzip ist universell. Wenn die Logik des Modellaufrufs, die Kontextverarbeitung, das Retrieval und die Ergebnisdarstellung miteinander vermischt sind, lässt sich das weder testen noch weiterentwickeln. Jede Prompt-Änderung droht die Oberfläche zu zerlegen. Jede Änderung der Oberfläche erfordert Eingriffe in die KI-Logik. Und es entsteht ein Monolith, den niemand anfassen will, weil jede Modifikation das Risiko einer Regression an unerwarteter Stelle birgt.

Das zweite Symptom dieses Fehlers ist das Ignorieren der Prinzipien einer einzigen Quelle der Wahrheit und eines unidirektionalen Datenflusses. In einem KI-System ist der Zustand oft komplex: der Gesprächsverlauf, der aus der Wissensbasis geholte Kontext, die Modellparameter, der Status des Aufrufs. Wenn mehrere Komponenten diesen Zustand unabhängig voneinander verändern, entstehen Fehler, die sich später nicht mehr reproduzieren lassen. Das Muster Single Source of Truth schafft hier Ordnung – es bestimmt einen einzigen Eigentümer für einen Datentyp, der diesen in unveränderlicher Form bereitstellt und Änderungen ausschließlich über definierte Ereignisse entgegennimmt.

Die Vorteile eines solchen Vorgehens sind konkret und messbar. Das gewinnt ein Projekt, dessen Architektur von Anfang an durchdacht ist:

• Testbarkeit – die Logik des Retrievals und der Modellverarbeitung lässt sich isoliert testen, ohne die gesamte Oberfläche zu starten.
• Skalierbarkeit des Teams – klare Grenzen zwischen den Schichten erlauben vielen Personen paralleles Arbeiten ohne ständige Konflikte im Code.
• Einfacheres Debugging – wenn Datenänderungen zentralisiert sind, lassen sich Fehler leichter aufspüren, weil man weiß, wo man suchen muss.
• Austauschbarkeit des Modells – eine sauber abgetrennte KI-Schicht erlaubt den Wechsel des Modellanbieters, ohne die gesamte Anwendung neu zu schreiben.
• Onboarding – neue Teammitglieder verstehen das Projekt schneller, weil die Struktur konsistent und vorhersehbar ist.

Die Folge einer missachteten Architektur ist immer dieselbe. Der Prototyp funktioniert und macht bei der Präsentation Eindruck, aber er lässt sich weder weiterentwickeln noch sinnvoll testen. Und wenn der Kunde eine neue Funktion oder eine Integration mit einem weiteren System wünscht, stellt sich heraus, dass es günstiger ist, das Projekt neu zu schreiben, als das bestehende auszubauen. Das ist das teuerste denkbare Szenario. Und seine Ursache ist eine Entscheidung aus der ersten Woche – KI wie ein Gadget zu behandeln und nicht wie ein System mit Architektur. Bei Web Systems beginnen wir mit Schichten und Verantwortungsgrenzen genau deshalb, damit dieses Szenario keine Chance hat.

Fehler 2: Schwaches Retrieval und eine ungeordnete Wissensbasis in RAG-Lösungen

Die meisten KI-Anwendungen in Unternehmen sind in der Praxis RAG-Lösungen – das Modell erzeugt Antworten auf Basis von Wissen, das aus Firmendokumenten, einer Produktdatenbank oder einer Ticket-Historie geholt wird. Und hier tritt ein Fehler auf, der trotz Einsatz des besten Modells ein ganzes Projekt ruinieren kann: die Unterschätzung des Suchmechanismus. Teams konzentrieren sich auf die Wahl des Sprachmodells und behandeln das Retrieval als Selbstverständlichkeit, die man am Ende anflanschen kann. Das stellt die Prioritäten auf den Kopf, denn gerade die Qualität des geholten Kontexts entscheidet über den Wert der Antwort.

Die Logik ist hier unerbittlich. Das Modell erzeugt seine Antwort auf Grundlage dessen, was ihm der Suchmechanismus liefert. Wenn die semantische Suche über einer ungeordneten Wissensbasis unpassende Fragmente zurückgibt, baut das Modell darauf eine Antwort, die in der Form selbstsicher, im Inhalt aber falsch ist. Branchenquellen sagen das unmissverständlich:

Der Retrieval-Mechanismus in RAG ist von entscheidender Bedeutung. Sie brauchen die beste semantische Suche auf Basis einer kuratierten Wissensbasis. Wenn die abgerufenen Informationen irrelevant sind, kann die Generierung 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. Eine verankerte, aber falsche Antwort ist gefährlicher als gar keine Antwort, weil sie glaubwürdig klingt. Der Nutzer hat keine Möglichkeit zu erkennen, dass sich das Modell auf das falsche Dokument gestützt hat. Und in B2B-Anwendungen, in denen eine KI-Anwendung zu Verträgen, Produkten oder Verfahren berät, kann ein solcher stiller Irrtum echtes Geld oder das Vertrauen des Kunden kosten.

Gutes Retrieval ist kein einzelner Parameter. Es ist eine ganze Kette von Ingenieursentscheidungen, von denen jede die Qualität der finalen Antwort beeinflusst. In RAG-Projekten achten wir mindestens auf diese Elemente:

1. Chunking – die Art, Dokumente in Fragmente zu zerlegen. Zu große verlieren an Präzision, zu kleine verlieren den Kontext, und schlecht gewählte zerschneiden Sätze mitten im Gedanken.
2. Layout-Parsing – das korrekte Auslesen der Struktur von Dokumenten, Tabellen, Überschriften und Listen, bevor sie in den Index gelangen. Ein schlecht geparstes PDF vergiftet die Wissensbasis an der Quelle.
3. Datenkuration – das Entfernen von Duplikaten, veralteten Versionen und widersprüchlichen Informationen, die die Suche verwirren und zu inkonsistenten Antworten führen.
4. Qualitätsevaluation – die systematische Messung der Trefferqualität der geholten Fragmente statt einer Einschätzung nach Gefühl nach ein paar Testabfragen.

Der letzte Punkt führt zum Kern. Ohne Metriken gibt es keine Kontrolle über Halluzinationen. Plattformen zur Modellevaluation bewerten heute den erzeugten Text und die geholten Fragmente anhand von Kennzahlen wie Groundedness, Coherence oder Question Answering Quality. Diese Metriken liefern einen Bezugspunkt, dank dem sich RAG bewusst optimieren lässt – durch Konfiguration der Suchmaschine, Ordnung in den Quelldaten, besseres Layout-Parsing und eine bessere Chunking-Strategie oder durch Präzisierung der Nutzerfrage vor der Suche.

Ein solcher metrikgetriebener RAG-Ops-Ansatz hilft Ihnen, sich Schritt für Schritt zu hochwertigem RAG und verankerter Generierung hochzuarbeiten.

Fehlen solche Metriken, fliegt das Team blind. Es weiß nicht, ob eine Änderung der Chunking-Strategie die Qualität verbessert oder verschlechtert hat, weil es nichts zum Vergleichen gibt. Jede Modifikation wird zum Ratespiel, und Halluzinationen tauchen ohne Erklärung auf und wieder ab. Deshalb behandeln wir bei Web Systems Retrieval und Evaluation als Kern eines RAG-Projekts und nicht als Beigabe. Das beste Modell auf einer schwachen, ungemessenen Wissensbasis liefert ein schlechteres Ergebnis als ein durchschnittliches Modell auf einer gut kuratierten und regelmäßig evaluierten Basis. Das ist eine Investition, die sich in der Qualität jeder einzelnen Antwort auszahlt.

Fehler 3: Kosten für Wartung, Daten und API-Integrationen ausblenden

Der dritte Fehler betrifft das Geld, zeigt sich aber erst nach Monaten. Viele Angebote für den Bau einer KI-Anwendung kalkulieren im Grunde nur eines: die Kosten für den Zugang zum Modell und die Zeit für den Bau einer Demonstration. Dabei ist das Modell oft der kleinste und am besten vorhersehbare Posten der ganzen Rechnung. Die echten Kosten stecken in der Inferenz bei realem Traffic, im Monitoring, in der Wartung, in den Integrationen und in der Arbeit mit den Daten. Ein Angebot, das darüber schweigt, ist keineswegs günstiger. Es ist schlicht unvollständig.

Besonders häufig werden Integrationen unterschätzt. Eine KI-Anwendung lebt selten im luftleeren Raum. Sie muss mit dem B2B-System des Kunden sprechen, mit der E-Commerce-Plattform, mit dem CRM, mit bestehenden Automatisierungen und Datenbanken. Jede solche API-Integration ist konkrete Ingenieursarbeit: Authentifizierung, Datenmapping, Fehlerbehandlung, Anfragelimits, Versionierung. In Projekten, in denen dieses Element stiefmütterlich behandelt wurde, verschlangen die Integrationen später mehr Zeit als die KI-Schicht selbst – weil sich die Systeme des Kunden als älter und weniger konsistent erwiesen, als jemand angenommen hatte.

Damit ein Gespräch über das Budget Sinn ergibt, muss man die Posten auf den Tisch legen, die es in naiven Angeboten schlicht nicht gibt. Das sind die realen Kosten, die wir bei der Planung einer KI-Anwendung berücksichtigen:

1. Inferenz bei realem Volumen – die Kosten der Modellaufrufe steigen linear mit dem Traffic, und bei RAG kommen noch die Kosten für Embeddings und die Suche in der Vektordatenbank hinzu.
2. Monitoring und Observability – Logging der Anfragen, Verfolgung der Antwortqualität, Alarme bei Anomalien und bei Kosten, die außer Kontrolle geraten.
3. Pflege der Wissensbasis – Daten altern, Dokumente müssen aktualisiert, neu indexiert und kuratiert werden, sonst sinkt die RAG-Qualität von Monat zu Monat.
4. Integrationen und ihre Pflege – die APIs externer Systeme wechseln Versionen, der Kunde ergänzt neue Quellen, und jede Änderung erfordert Arbeit und Tests.
5. Modellaktualisierungen – Anbieter stellen ältere Modelle ein und führen neue ein, was Migrationen, erneute Prompt-Tests und eine neue Qualitätsevaluation erzwingt.
6. Sicherheit und Compliance – Überprüfung der Zugriffsrichtlinien, Datenaudits, Reaktion auf regulatorische Änderungen zur Verarbeitung von Informationen durch KI.

Jeder dieser Posten ist eine wiederkehrende Betriebsausgabe und keine einmalige Einführungskosten. Eine KI-Anwendung gleicht eher einem lebenden Organismus als einem fertigen Produkt im Regal. Sie braucht Beobachtung, Korrekturen und Fütterung mit frischen Daten. Wenn der Dienstleister das nicht kommuniziert, entdeckt der Kunde diese Kosten selbst – meist in dem Moment, in dem die Rechnung für die Inferenz um ein Vielfaches höher ausfällt als prognostiziert oder in dem die Antwortqualität ohne erkennbaren Grund zu sinken beginnt.

Tipp: Fragen Sie den Dienstleister nie nach den Einführungskosten, sondern nach den erwarteten Gesamtkosten für den Betrieb der KI-Anwendung über zwölf Monate. Bitten Sie um eine Aufschlüsselung nach Inferenz, Monitoring, Pflege der Wissensbasis und Integrationen. Wenn Sie nur einen Preis für den Bau des Systems hören und das Thema Wartung mit einer Allgemeinplatitüde abgetan wird, ist das das ernsteste Warnsignal des ganzen Gesprächs. Ein Dienstleister, der systemisch denkt, bringt die Betriebskosten von sich aus zur Sprache, bevor Sie überhaupt fragen können.

Bei Web Systems zeigen wir diese Posten von Anfang an, auch wenn das die optische Attraktivität des ersten Angebots verdirbt. Wir sprechen lieber über das vollständige Kostenbild, denn ein KI-Projekt rechnet sich nicht am Tag der Einführung ab, sondern über seine gesamte Lebensdauer. Ein Kunde, der die realen Wartungskosten kennt, trifft eine bewusste unternehmerische Entscheidung. Und ein Kunde, den ein niedriger Preis für eine Demonstration eingeschläfert hat, zahlt die Differenz früher oder später mit Zinsen – und verliert oft das Vertrauen in die Technologie selbst, obwohl die Kalkulation schuld war und nicht die KI.

Fehler 4: Keine Strategie für Sicherheit, Datenschutz und Skalierbarkeit

Der vierte Fehler ist der gefährlichste, denn seine Folgen sind mitunter irreversibel. Viele KI-Anwendungen entstehen ohne durchdachte Strategie für Sicherheit und Datenschutz. In der Eile schickt das Team sensible Unternehmensdaten an externe Modelle – Verträge, Kundendaten, interne Dokumentation – ohne Zugriffsrichtlinie, ohne Kontrolle darüber, was genau die Infrastruktur des Unternehmens verlässt und wo es landet. Beim Bau einer Demo bequem. In der Produktion bedeutet es reales rechtliches, reputationsbezogenes und wirtschaftliches Risiko.

Sicherheit in einer KI-Anwendung beginnt mit der Frage, welche Daten die Umgebung des Kunden überhaupt verlassen dürfen und welche lokal verarbeitet oder vor dem Versand an das Modell anonymisiert werden müssen. Nötig ist eine Zugriffsrichtlinie, die festlegt, wer in welchem Umfang das System abfragen darf und wie diese Abfragen protokolliert werden. Ohne sie verliert das Unternehmen die Kontrolle über die eigenen Informationen und kann die Grundfrage eines Auditors nicht beantworten: Wo und wie werden seine sensiblen Daten verarbeitet?

Die zweite vernachlässigte Frage ist die Skalierbarkeit. Eine Anwendung, die mit zehn Anfragen pro Tag hervorragend zurechtkommt, kann bei tausend zusammenbrechen. Eine Produktionsumgebung hat eigene Ressourcengrenzen und veränderliche Betriebsbedingungen, die eine Demonstration nie offenlegt. Branchenmaterial zur Architektur erinnert an diese Natur der Laufzeitumgebung und daran, wie Komponenten mit Ressourcen und Nebenläufigkeit umgehen sollten:

Mobile Geräte – selbst Geräte mit großem Bildschirm – sind in ihren Ressourcen begrenzt, daher kann das Betriebssystem den Prozess Ihrer App jederzeit stoppen, um dessen Ressourcen anderen Prozessen zu geben. Typen sollten main-safe sein, das heißt, sie können vom Haupt-Thread aus aufgerufen werden, ohne ihn zu blockieren.

Das Zitat beschreibt mobile Geräte, doch das Prinzip reicht tiefer und betrifft jedes System unter Last. Ressourcen sind begrenzt, und die Umgebung kann sie einem Prozess jederzeit entziehen. Typen verantworten ihre eigene Nebenläufigkeitspolitik und dürfen den Haupt-Thread nicht mit langlaufenden Operationen blockieren. Und in einer KI-Anwendung ist die langlaufende Operation genau der Modellaufruf oder die Suche in der Vektordatenbank. Wenn diese Operationen die Bearbeitung von Anfragen blockieren, antwortet das System unter Last nicht mehr, und die Nutzer sehen ein Einfrieren statt eines Ergebnisses.

Deshalb braucht eine skalierbare KI-Anwendung eine durchdachte Behandlung von Nebenläufigkeit, eine Warteschlange für Modellanfragen, Limits und Mechanismen gegen Überlastung. Man muss planen, was passiert, wenn der Modellanbieter einen Fehler zurückgibt oder ein Limit überschreitet, wie das System sich mit Anstand degradiert, statt auszufallen, und wie es mit dem Traffic mitwächst. Das sind keine Verzierungen, die man am Ende ergänzt. Das ist das Fundament, das darüber entscheidet, ob die Anwendung den ersten Tag realer Last übersteht.

Sicherheit und Skalierung sind Bereiche, in denen wir Web Systems als risikobewussten Partner positionieren. Fast zwei Jahrzehnte im Bau von B2B-Systemen, Integrationen und Webanwendungen haben uns gelehrt, dass Daten und Lastfestigkeit keine optionalen Funktionen sind, sondern Voraussetzung dafür, ein System überhaupt in die Produktion zu lassen. An KI-Projekte gehen wir mit derselben Disziplin heran – mit einer Zugriffsrichtlinie, Kontrolle über den Datenfluss, einem Skalierungsplan und einer Behandlung von Störfällen, entworfen, bevor wir die erste Zeile Geschäftslogik schreiben. Ein Kunde, der eine Anwendung ohne diese Schicht bekommt, bekommt Risiko in einer hübschen Oberfläche verpackt.

Fehler 5: Null Qualitätsevaluation und keine Erfolgsmessung nach der Einführung

Der fünfte Fehler schließt den Kreis. Das Team führt die KI-Anwendung ein und betrachtet den Starttag als Projektende. Es gibt keine Qualitäts-Baseline, keine Metriken für die Antworten des Modells, keine Möglichkeit festzustellen, ob das System besser oder schlechter arbeitet als vor einer Woche. Die Anwendung geht in die Welt und lebt ihr eigenes Leben, und das einzige Signal, dass etwas nicht stimmt, sind Beschwerden der Nutzer. Das ist Qualitätsmanagement im Blindflug. Und bei unvorhersehbaren Sprachmodellen ist es besonders riskant.

Denn die Qualität einer KI-Lösung ist nicht konstant. Sie ändert sich mit der Aktualisierung des Modells durch den Anbieter, mit dem Altern der Daten in der Wissensbasis, mit der Art, wie Nutzer ihre Fragen formulieren. Ohne Messung fangen Sie keine dieser Änderungen rechtzeitig ab. Erst das Festlegen eines Bezugspunkts, also einer Baseline, und das regelmäßige Messen von Kennzahlen wie Groundedness, Coherence oder der Qualität der Antworten auf Fragen erlaubt es, das System bewusst zu steuern, statt Brände zu löschen.

Der richtige Ansatz heißt RAG Ops – Qualität als iterativen Prozess behandeln und nicht als einmalige Einführung. Sie messen, finden die Schwachstellen, verbessern die Suchkonfiguration, kuratieren die Daten, justieren das Chunking oder präzisieren die Fragen, messen erneut und prüfen, ob die Änderung tatsächlich geholfen hat. Das ist ein methodisches Hocharbeiten zu höherer Qualität, bei dem jede Entscheidung auf Daten beruht und nicht auf einem Eindruck. Ein einmaliges Deployment ohne diesen Zyklus friert die Qualität auf dem Stand des Einführungstages ein. Und der kann mit der Zeit nur noch sinken.

Ohne Metriken lässt sich mit dem Kunden auch kein ehrliches Gespräch über die Ergebnisse führen. Entlastet die Anwendung das Serviceteam tatsächlich? Sind die Antworten treffend? Hat die Korrektur vom letzten Monat etwas gebracht? Diese Fragen beantwortet man nur mit Zahlen. Ein Team, das sie nicht erhebt, stützt sich auf Anekdoten und Hoffnung – und das reicht nicht, um ein Produkt weiterzuentwickeln, in das der Kunde reales Geld und reale Erwartungen gesteckt hat.

Woran erkennen Sie, dass ein Software House tatsächlich eine funktionierende KI-Anwendung baut?

Achten Sie darauf, worüber der Dienstleister von sich aus spricht. Wenn er selbst das Thema geschichteter Architektur, die Qualität des Retrievals, Metriken wie Groundedness, die Wartungskosten über ein Jahr und die Datensicherheitsrichtlinie anspricht, ist das ein Zeichen, dass er an ein System denkt und nicht an eine Demonstration. Dreht sich das ganze Gespräch dagegen darum, wie beeindruckende Antworten das Modell bei der Vorführung erzeugt, während Fragen nach Wartung, Skalierung und Qualitätsmessung mit Allgemeinplätzen abgetan werden, haben Sie ein Team vor sich, das einen Prototyp baut und kein Produkt. Bitten Sie außerdem um eine Beschreibung des Prozesses nach der Einführung – ein guter Partner spricht von Evaluation, Iteration und Monitoring als Teil der Leistung und nicht von einer einmaligen Codeübergabe und dem Ende der Zusammenarbeit.

Bei Web Systems ist die Qualitätsmessung für uns eine natürliche Verlängerung der ingenieurtechnischen Disziplin, die wir seit 2006 in jeder Projektart anwenden. Eine KI-Anwendung ohne Evaluation ist wie ein System ohne Tests – sie mag funktionieren, aber niemand kann das garantieren oder bewusst verbessern. Deshalb behandeln wir Baseline, Metriken und iteratives Anheben der Qualität als Teil der Einführung und nicht als teures Extra. Sie sind es, die einen einmaligen Effekt in ein Produkt verwandeln, das von Monat zu Monat besser wird und nicht schlechter.

Fazit: Wie Sie einen Dienstleister wählen, der die KI-Anwendung liefert

Die fünf beschriebenen Fehler sehen nach unterschiedlichen Problemen aus, doch sie haben einen gemeinsamen Nenner: fehlendes systemisches Denken. KI als Gadget statt als System mit Architektur zu behandeln, Retrieval und Wissensbasis in RAG zu unterschätzen, Wartungs- und Integrationskosten auszublenden, keine Strategie für Sicherheit und Skalierbarkeit zu haben und null Qualitätsevaluation nach der Einführung – all das wächst aus derselben Haltung. Der Dienstleister sieht eine KI-Anwendung als eindrucksvolle Demonstration und nicht als vollwertiges IT-System, das entworfen, abgesichert, integriert, ehrlich kalkuliert und über den gesamten Lebenszyklus gemessen werden muss.

Das Gegenmittel ist leicht zu benennen und schwerer umzusetzen: gute Architektur. Sie verbessert die Qualität, macht das System testbar und erlaubt es, sowohl das Produkt als auch das daran arbeitende Team zu skalieren. Branchenquellen lassen keinen Zweifel am Nutzen einer durchdachten Struktur:

Eine gute Architektur verbessert die Wartbarkeit, die Qualität und die Robustheit der gesamten Anwendung. Sie erlaubt es der Anwendung zu skalieren – mehr Menschen und mehr Teams können mit minimalen Codekonflikten zur selben Codebasis beitragen – und sie ist leichter zu testen.

Dieselben Prinzipien – Trennung der Verantwortlichkeiten, eine einzige Quelle der Wahrheit, Testbarkeit, Kontrolle über Ressourcen und Kosten – entscheiden über den Erfolg einer KI-Anwendung genau so, wie sie in den letzten anderthalb Jahrzehnten über die Qualität von Web- und Mobilanwendungen und B2B-Systemen entschieden haben. KI setzt nichts in dieser Gleichung außer Kraft. Sie fügt nur eine Schicht Unvorhersehbarkeit hinzu, die ingenieurtechnische Disziplin hier noch wichtiger macht und nicht weniger. Beurteilen Sie einen Dienstleister also nicht nach der Modellliste im Angebot, sondern danach, ob das Team in Kategorien von System, Daten, Kosten und Lebenszyklus denkt.

Web Systems ist ein Software House aus Łódź, das seit 2006 Webanwendungen, Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce und KI-Lösungen entwirft und umsetzt. An Projekte mit Künstlicher Intelligenz gehen wir heran wie an jedes ernsthafte System – mit Architektur, messbarer Qualität und einem Plan für Sicherheit, Skalierung und Wartung. Wir versprechen keine Magie. Wir versprechen solide Ingenieursarbeit und ein Gespräch über das vollständige Bild der Kosten und Risiken, bevor wir irgendetwas bauen. So verstehen wir die Rolle eines vernünftigen, technischen Partners für Unternehmen, die wollen, dass ihre KI-Anwendung tatsächlich in der Produktion funktioniert und nicht nur bei der Vorführung.

Planen Sie ein MVP, eine KI-Anwendung, eine Integration mit bestehenden Systemen, eine Prozessautomatisierung oder die Modernisierung einer älteren Lösung? Sprechen wir darüber. Erzählen Sie uns von Ihrer Idee und Ihren Herausforderungen, und wir zeigen Ihnen, wie man das systemisch, sicher und so baut, dass es sich über Jahre warten und weiterentwickeln lässt. Nehmen Sie Kontakt zum Team von Web Systems auf und sehen Sie, wie die Zusammenarbeit mit einem Dienstleister aussieht, der an den gesamten Lebenszyklus Ihrer Anwendung denkt.