Wie wählt man eine Firma für KI-Anwendungen? Ein praktischer Leitfaden aus Sicht eines software house

  • Strona główna
  • Wie wählt man eine Firma für KI-Anwendungen? Ein praktischer Leitfaden aus Sicht eines software house
Wie wählt man eine Firma für KI-Anwendungen? Ein praktischer Leitfaden aus Sicht eines software house

Die Wahl eines Unternehmens, das Ihnen eine KI-basierte Anwendung baut, ähnelt der Auswahl eines Handwerksbetriebs für eine komplizierte Gebäudeinstallation. Nicht der eindrucksvolle Entwurf auf dem Papier zählt. Es zählt, ob das Ganze funktioniert, sich warten lässt und bei der ersten größeren Belastung nicht auseinanderfällt. Wir sind das Team von Web Systems, ein software house aus Łódź, das seit 2006 tätig ist, und wir haben Dutzende Projekte gesehen, in denen KI ein magischer Knopf sein sollte. Und sich als komplexes Ingenieurvorhaben herausstellte. In diesem Leitfaden zeigen wir, worauf Sie vor der Vertragsunterschrift wirklich achten sollten und wie Sie ein Team, das Versprechen verkauft, von einem unterscheiden, das schlicht eine funktionierende Lösung liefert.

Wozu Sie einen KI-Dienstleister brauchen und wonach Sie wirklich suchen

Das erste Missverständnis, auf das wir bei Kunden treffen? Die Überzeugung, die Einführung Künstlicher Intelligenz (KI) laufe darauf hinaus, ein fertiges Sprachmodell anzuschließen. Tatsächlich ist es ein Ingenieurprojekt, in dem das Modell selbst oft der am wenigsten problematische Teil ist. Die Schwierigkeit liegt woanders: in der Integration mit bestehenden Systemen, in der Aufbereitung der Daten, im Umgang mit Randfällen und im Betrieb des Ganzen nach dem Produktivstart. Ein Modell ohne den Kontext Ihres Unternehmens erzeugt schön klingende, aber nutzlose Antworten. Erst die Verbindung mit Ihren Daten, Prozessen und Geschäftsregeln schafft Wert.

Ein Kunde, der einen Dienstleister für eine KI-Anwendung sucht, sucht im Grunde einen Partner, der etwas Funktionierendes liefert. Nicht die nächste Marketingpräsentation mit einer eindrucksvollen Demo. Eine Demo lässt sich an einem Tag zusammenzimmern, denn sie läuft auf ausgewählten Daten und mit vorab geplanten Fragen. Der Produktivbetrieb ist eine andere Liga. Dort tauchen echte Nutzer auf, ungewöhnliche Anfragen, fehlerhafte Eingangsdaten und die Forderung nach wiederholbarer Qualität. Und genau diesen Unterschied zwischen zwei Welten müssen Sie im Gespräch mit einem möglichen Dienstleister spüren.

Als software house aus Łódź betrachten wir KI aus der Perspektive eines Umsetzers, der die realen Projektgrenzen kennt. Wir wissen, was der Betrieb einer Integration kostet, wenn eine externe API plötzlich das Antwortformat ändert. Wir wissen, wie sich ein System verhält, wenn die Wissensbasis von tausend auf eine Million Dokumente anschwillt. Dieses Wissen stammt nicht aus der Theorie. Es stammt aus Jahren des Bauens von Webanwendungen, B2B-Systemen, Integrationen und Automatisierungen. KI haben wir diesem Kompetenzsatz als weiteres Werkzeug hinzugefügt, nicht als modisches, von der Ingenieurarbeit losgelöstes Beiwerk.

Der wichtigste Unterschied, den Sie erkennen sollten, betrifft die Sprache. Ein Unternehmen, das Hype verkauft, spricht von Revolution, Transformation und unbegrenzten Möglichkeiten. Ein Team, das die Sache versteht, spricht über Daten, Architektur, Token-Kosten, Latenzen und Wege, Qualität zu messen. Letzteres stellt Ihnen unbequeme Fragen, bevor es irgendetwas verspricht: Woher stammen die Daten, wem gehören sie, welche Systeme müssen integriert werden, welche Antwortgenauigkeit ist für Sie akzeptabel. Keine solchen Fragen? Das ist das erste Warnsignal.

Es lohnt sich außerdem, sich ehrlich zu beantworten, was Sie tatsächlich brauchen. Manchmal ist die Lösung ein Assistent auf Basis eines Sprachmodells mit Suche über eine Wissensbasis. Ein anderes Mal genügt eine einfache Automatisierung oder ein klassischer Algorithmus, der billiger und zuverlässiger arbeitet als ein generatives Modell. Ein guter Dienstleister drängt KI nicht mit Gewalt dorthin, wo eine gewöhnliche Geschäftsregel ausreicht. Schlägt ein Team Künstliche Intelligenz als Antwort auf jedes Problem vor, werten Sie das als Zeichen, dass es ein Produkt verkauft und nicht Ihr Problem löst.

Bevor Sie weitergehen, legen Sie Ihre eigene Erwartungsliste fest. Bestimmen Sie, welchen Prozess Sie verbessern wollen, welche Zeit- oder Kostenersparnis Sie annehmen und woran Sie erkennen, dass die Einführung gelungen ist. Ohne diese Grundlage wird jedes Gespräch mit einem Dienstleister zu einer Diskussion über Technologie statt über den geschäftlichen Effekt. Je konkreter Sie das Ziel beschreiben, desto leichter sortieren Sie die Firmen aus, die schön über KI reden können, und finden jene, die sie tatsächlich umsetzen können.

Tipp: Erstellen Sie eine einseitige Problembeschreibung, bevor Sie Gespräche mit Dienstleistern beginnen. Nehmen Sie das Geschäftsziel, die verfügbaren Daten, die zu integrierenden Systeme und das Erfolgskriterium hinein. Dieses Dokument zeigt sofort, welche Gesprächspartner Ihren Bedürfnissen tatsächlich zuhören und welche unabhängig von Ihren Worten ihr eigenes Angebot herunterbeten.

Technische Kompetenzen, die Sie vor der Vertragsunterschrift prüfen müssen

Der häufigste Fehler bei der Bewertung eines Dienstleisters? Der Blick allein auf eindrucksvolle KI-Demos. Über den Projekterfolg entscheidet dagegen Erfahrung in Bereichen, die man mit einem Sprachmodell nicht unmittelbar verbindet: API-Integrationen, B2B-Systeme, E-Commerce, Datenflüsse zwischen Anwendungen. Eine KI-Anwendung existiert fast nie im luftleeren Raum. Sie muss Daten aus Ihrem ERP holen, Ergebnisse im CRM speichern, auf Ereignisse im Online-Shop reagieren oder Antworten über eine sichere API bereitstellen. Ein Team, das das nie gemacht hat, lernt es auf Kosten Ihres Budgets.

Die zweite Säule ist die Kenntnis der Anwendungsarchitektur. Ein solider Dienstleister denkt in Schichten: Er trennt die Oberfläche von der Geschäftslogik und die Logik von der Datenschicht. Er wendet das Prinzip der einzigen Quelle der Wahrheit an, bestimmt also einen Ort, der Eigentümer einer Information ist und sie als Einziger ändern darf. Er achtet auf einen unidirektionalen Datenfluss, wodurch das System vorhersehbar und leichter zu debuggen wird. Das sind keine akademischen Verzierungen. Das ist das Fundament, das darüber entscheidet, ob sich die Anwendung nach einem Jahr Entwicklung überhaupt noch warten lässt.

Die Dokumentation zur Anwendungsarchitektur fasst es knapp zusammen, und das Prinzip überträgt sich unmittelbar auf die Welt der KI:

Das Prinzip der einzigen Quelle der Wahrheit wird häufig zusammen mit dem Muster des unidirektionalen Datenflusses (UDF) eingesetzt. Bei UDF fließt der Zustand nur in eine Richtung, typischerweise von der übergeordneten zur untergeordneten Komponente. Die Ereignisse, die die Daten verändern, fließen in die entgegengesetzte Richtung. Dieses Muster wahrt die Datenkonsistenz besser, ist weniger fehleranfällig und leichter zu debuggen.

Die dritte Kompetenz, bei wissensbasierten Anwendungen schlicht unverzichtbar, ist die Fähigkeit, RAG-Systeme zu bauen, also Generierung mit vorgeschalteter Suche. Bei diesem Ansatz antwortet das Modell nicht aus seinem eigenen, allgemeinen Wissen. Es antwortet auf Basis von Informationen, die in Ihrer kuratierten Wissensbasis gefunden wurden. Über die Antwortqualität entscheidet dann nicht das Modell, sondern die Qualität der semantischen Suche. Denn liefert der Suchmechanismus dem Modell unwichtige Fragmente, ist die Antwort grammatisch stimmig, inhaltlich aber daneben. Ein Dienstleister, der RAG versteht, widmet diesem Teil mindestens so viel Aufmerksamkeit wie dem Modell selbst.

Wie ein Kandidat über diese Themen spricht, sagt mehr aus als ein ganzes Portfolio. Stellen Sie konkrete Fragen und hören Sie, ob die Antworten präzise sind oder hinter Allgemeinplätzen verborgen. Nachfolgend eine Reihe von Fragen, die ein Team wirklich prüfen:

  • Welchen Technologie-Stack schlagen Sie vor und warum gerade diesen? Ein gutes Team begründet die Wahl mit konkreten Projekteigenschaften und nicht mit einer Mode.
  • Wie läuft bei Ihnen der Code-Review-Prozess ab? Fehlendes Code Review bedeutet, dass die Qualität von der Laune einer einzelnen Person abhängt.
  • Wie stellen Sie die Testbarkeit der Lösung sicher? Eine Anwendung, die sich nicht isoliert testen lässt, erzeugt bei jeder Änderung Regressionen.
  • Wie gehen Sie mit technischen Schulden um? Das Bewusstsein für Schulden und ein Plan zu ihrer Tilgung zeugen von ingenieurmäßiger Reife.
  • Wie messen Sie die Qualität der vom Modell erzeugten Antworten? Lautet die Antwort “nach Gefühl”, wird die Einführung unvorhersehbar.
  • Wie isolieren Sie die Geschäftslogik vom Modell und von der Oberfläche? Eine gute Schichtentrennung erlaubt den Modellwechsel, ohne die gesamte Anwendung neu zu schreiben.

Achten Sie darauf, wie das Team über Tests spricht. KI-Anwendungen sind von Natur aus nicht deterministisch. Derselbe Prompt kann unterschiedliche Antworten liefern. Ein reifer Dienstleister hat dafür Methoden: Er testet die Suchschicht separat, nutzt Sets von Kontrollfragen mit erwarteten Antworten und überwacht die Qualität im Produktivbetrieb. Die Architekturdokumentation betont, dass der Entwurf auf Testbarkeit von Anfang an geplant und nicht am Ende angeklebt werden muss.

Überlegen Sie, wie sich jeder Teil Ihrer Anwendung isoliert testen lässt. Eine gut definierte API zum Abrufen von Daten aus dem Netzwerk erleichtert das Testen des Moduls, das diese Daten in einer lokalen Datenbank speichert. Vermischen Sie stattdessen die Logik dieser beiden Funktionen an einer Stelle oder verteilen Sie Ihren Netzwerkcode über die gesamte Codebasis, wird das Testen deutlich schwieriger, wenn nicht unmöglich.

Prüfen Sie schließlich, ob das Team sagen kann “das wissen wir nicht” oder “das muss man prüfen”. Sicherheit bei jeder Antwort, besonders bei Kosten und Terminen, ist in KI-Projekten eher ein Zeichen fehlender Erfahrung als von Kompetenz. Ein realistischer Dienstleister kennt die Unsicherheitsbereiche und kann vorschlagen, wie sie sich eingrenzen lassen. Zum Beispiel durch eine kurze Sondierungsphase vor der Kalkulation des Gesamtprojekts.

Tipp: Bitten Sie um ein Gespräch nicht nur mit dem Vertrieb, sondern mit einer technischen Person, die tatsächlich an Ihrem Projekt arbeiten wird. Fünfzehn Minuten mit einer Entwicklerin oder einem Entwickler sagen Ihnen mehr über die Kompetenzen des Teams als zehn Seiten Angebot. Und wenn eine Firma den Zugang zu ihren Ingenieuren abschirmt, überlegen Sie, wer Ihre Anwendung wirklich bauen wird.

Daten, Sicherheit und Qualität: woran KI-Projekte am häufigsten scheitern

Müssten wir eine einzige Stelle nennen, an der KI-Projekte am häufigsten umkippen, wären es die Daten. Die Qualität einer KI-Einführung hängt nicht vom gewählten Modell ab, sondern von der Qualität und Ordnung der Quelldaten. Sie können das beste Modell am Markt anschließen und dennoch schwache Antworten bekommen, wenn die Daten widersprüchlich, unvollständig oder schlecht aufbereitet sind. In den Daten steckt sowohl das größte Risiko als auch der größte Wertehebel.

In RAG-Systemen sind drei Stufen der Datenaufbereitung entscheidend. Die erste ist das Parsing: das korrekte Extrahieren von Inhalten aus PDF-Dateien, Dokumenten, Webseiten oder Datenbanken unter Beibehaltung der Struktur. Die zweite ist das Chunking, also die Aufteilung der Inhalte in Fragmente passender Größe, damit die Suche sie treffsicher einer Frage zuordnen kann. Die dritte ist der Aufbau einer semantischen Suche, die aus Hunderten Fragmenten die wirklich wichtigen auswählt. Ein Fehler auf einer dieser Stufen verdirbt das Ganze, denn das Modell erhält entweder zu wenig Kontext oder Kontext am Thema vorbei.

Die Bedeutung des Suchmechanismus lässt sich kaum überschätzen. Fachmaterialien zur RAG-Architektur sagen es direkt:

Der Retrieval-Mechanismus in RAG ist von kritischer Bedeutung. Sie brauchen die bestmögliche semantische Suche auf einer kuratierten Wissensbasis, damit die abgerufenen Informationen für die Eingabeanfrage oder den Kontext relevant sind. Sind die abgerufenen Informationen irrelevant, kann Ihre Generierung zwar gegroundet, aber am Thema vorbei oder falsch sein.

Dieser Satz sollte über dem Schreibtisch jeder Person hängen, die wissensbasierte Anwendungen einführt. Eine Antwort, die “gegroundet, aber am Thema vorbei” ist, ist gefährlicher als ein offensichtlicher Fehler, weil sie glaubwürdig klingt und Nutzer ihr leicht vertrauen. Fragen Sie den Dienstleister deshalb nicht, welches Modell er einsetzen wird, sondern wie er die Suchschicht auf Ihren Daten aufbaut und testet.

Ein weiterer Bereich, der Profis von Amateuren unterscheidet, ist das Messen der Qualität generierter Inhalte. Der reife Ansatz, mitunter RAG Ops genannt, behandelt Qualität als Metrik, die man beobachtet und optimiert, und nicht als Eindruck. Gemessen werden unter anderem Groundedness, also der Grad, in dem eine Antwort auf den bereitgestellten Daten beruht, dazu Konsistenz und Treffsicherheit. Fachpublikationen beschreiben diese Arbeitsweise eindeutig:

Ein metrikgetriebener RAG-Ops-Ansatz wie dieser hilft Ihnen, sich schrittweise zu hochwertigem RAG und gegroundeter Generierung hochzuarbeiten. Die Umsetzung dieser Evaluationen liefert Ihnen eine Basismessung, und Sie können die RAG-Qualität optimieren, indem Sie Ihre Suchmaschine konfigurieren, Ihre Quelldaten kuratieren und das Parsing des Quell-Layouts oder die Chunking-Strategien verbessern.

Ohne einen solchen Ansatz wissen Sie nicht, ob eine Änderung am System die Qualität verbessert oder verschlechtert. Jede Modifikation wird zum Blindflug. Ein Dienstleister, der zeigen kann, wie er Qualität messen und sie durch besseres Parsing, Chunking oder Kuratieren der Daten steigern wird, gibt Ihnen etwas Unbezahlbares: Planbarkeit der Weiterentwicklung.

Die dritte Dimension sind Sicherheit und die für KI spezifischen Risiken. Die wichtigsten davon sind:

  1. Halluzinationen des Modells – das Erzeugen von Informationen, die in den Quellen nicht vorkommen. Man begrenzt sie durch gute Suche, klare Anweisungen an das Modell und das Erzwingen von Antworten, die ausschließlich auf dem gelieferten Kontext beruhen.
  2. Abfluss sensibler Daten – das Risiko, dass Daten an einen externen Modellanbieter gelangen oder in einer Antwort einer unbefugten Person offengelegt werden. Das erfordert Zugriffskontrolle, Anonymisierung und eine bewusste Entscheidung, wo die Daten verarbeitet werden.
  3. Fehlende Kontrolle über die Quelle der Wahrheit – eine Situation, in der niemand weiß, woher eine bestimmte Information in einer Antwort stammt und wer dafür verantwortlich ist. Ohne benannten Dateneigentümer wird das System mit der Zeit nicht mehr auditierbar.

Jedes dieser Risiken lässt sich durch den Entwurf begrenzen, aber nur, wenn Sie es zu Beginn benennen. Fragen Sie den Dienstleister direkt, wie er Ihre Daten schützen will, wo sie verarbeitet werden und wie er sicherstellt, dass sich das Modell bei fehlenden Daten keine Antwort ausdenkt. Die Antwort zeigt, ob er an den Produktivbetrieb denkt oder nur an eine Demo.

Denken Sie auch daran, dass Daten keine einmalige Aufgabe sind. Die Wissensbasis altert, Dokumente werden aktualisiert, neue Produkte und Verfahren kommen hinzu. Ein guter Dienstleister plant, wie die Daten aufgefrischt werden und wer auf Seiten Ihrer Organisation dafür verantwortlich ist. Ohne das beginnt selbst ein hervorragend gebautes System nach einem halben Jahr, veraltete Antworten zu geben, und die Nutzer verlieren das Vertrauen.

Tipp: Machen Sie vor dem Start der Einführung ein kurzes Audit Ihrer Daten. Prüfen Sie, in welchem Format sie vorliegen, wie sie beschrieben sind und ob überhaupt eine aktuelle, verlässliche Wissensquelle existiert. Oft zeigt sich, dass die erste Etappe eines KI-Projekts nicht das Modell ist, sondern das Ordnen der Dokumentation. Und das ist ein gutes Zeichen dafür, dass der Dienstleister die Sache versteht.

Architektur, Skalierbarkeit und Betrieb: was nach der Einführung passiert

Die Einführung einer KI-Anwendung ist nicht das Ziel. Sie ist der Start. Ab diesem Moment beginnt das Leben des Systems: Nutzer stellen Fragen, die Daten wachsen, die Modelle der Anbieter ändern sich und die geschäftlichen Anforderungen entwickeln sich weiter. Wie reibungslos diese Phase verläuft? Das hängt in enormem Maß von den ganz zu Beginn getroffenen Architekturentscheidungen ab. Eine gute Architektur ist das Fundament einer skalierbaren und wartbaren Anwendung. Einer, die sich leichter testen lässt und in die sich neue Leute leichter einarbeiten.

Die technische Dokumentation lässt keinen Zweifel an der Rolle der Architektur:

Die Anwendungsarchitektur ist das Fundament einer hochwertigen Anwendung. Eine gut definierte Architektur erlaubt es Ihnen, eine skalierbare, wartbare und anpassungsfähige Anwendung zu schaffen. Eine gute Architektur in Ihrer Anwendung verbessert Wartbarkeit, Qualität und Robustheit des Gesamtsystems und lässt die Anwendung skalieren.

Eine der wertvollsten Regeln besagt, den Zustand nicht in flüchtigen Komponenten zu speichern. Also in solchen, die das System jederzeit zerstören und neu erzeugen kann. In der Welt der Anwendungen bedeutet das, dass Daten nicht in Elementen der Oberfläche gehalten werden. Auf KI übertragen klingt das so: Geschäftslogik, Daten und die Modellwahl müssen von der Präsentationsschicht und vom Modell selbst getrennt sein. So tauschen Sie das Modell gegen ein neueres, günstigeres oder besseres aus, ohne die gesamte Anwendung neu zu schreiben. Und Sie ändern die Oberfläche, ohne die Logik anzufassen.

Diese Trennung hat messbare finanzielle Folgen. Der Markt der Sprachmodelle ändert sich alle paar Monate: Neue Versionen erscheinen, Preise fallen, Fähigkeiten wachsen. Ist Ihre Anwendung starr mit einem bestimmten Modell verflochten, bedeutet jede solche Änderung ein teures Refactoring. Ist die Logik dagegen abgetrennt, ist der Modelltausch eine kleine Operation. Die Frage, wie der Dienstleister das Modell vom Rest des Systems isolieren will, ist eine der wichtigsten im gesamten Gespräch.

Der Betrieb einer KI-Anwendung bringt außerdem Kosten mit sich, die man in der Aufbruchstimmung der Einführung leicht vergisst. Dazu gehören unter anderem:

  • Kosten der Modellaufrufe – jede Anfrage an das Modell kostet, und bei hohem Verkehr kann die Rechnung überraschen. Eine gute Architektur begrenzt überflüssige Aufrufe und nutzt Caching, wo es möglich ist.
  • Monitoring von Qualität und Betrieb – Sie brauchen Einblick, wie das System antwortet, wo es sich irrt und wie schnell es reagiert. Ohne Monitoring treten Probleme erst durch Nutzerbeschwerden zutage.
  • Aktualisierungen von Modellen und Bibliotheken – Anbieter ziehen ältere Modellversionen zurück, Bibliotheken brauchen Sicherheitspatches. Das ist ein stetiger, planbarer Kostenblock.
  • Ausbau der Wissensbasis – neue Dokumente hinzufügen, falsche Antworten korrigieren, die Suche nachjustieren. Das ist laufende Arbeit, keine einmalige.

Skalierbarkeit wiederum bedeutet, dass das System sowohl mit zehn als auch mit zehntausend Anfragen pro Tag zurechtkommt. Eine Schichtenarchitektur, klare Verantwortungsgrenzen zwischen den Modulen und begrenzte Abhängigkeiten zwischen ihnen sorgen dafür, dass sich die Last verteilen und punktuell optimieren lässt. Eine Anwendung, in der alles mit allem verflochten ist, beginnt bei wachsendem Verkehr auf unvorhersehbare Weise zu bröckeln. Und die Diagnose des Problems verschlingt ganze Tage.

Das Onboarding im Team ist ein oft unterschätzter Aspekt des Betriebs. Ist das System gut entworfen und konsistent, versteht es eine neue Person schnell und arbeitet zügig produktiv. Ist die Architektur chaotisch, erfordert jede Änderung Archäologie im Code, und das Wissen bleibt in den Köpfen weniger Personen eingeschlossen. Aus Kundensicht ist das ein Geschäftsrisiko: Sie machen sich von konkreten Menschen abhängig und nicht vom Dienstleister als Organisation. Fragen Sie deshalb, ob das Projekt dokumentiert wird und ob jemand anderes als der Autor es weiterentwickeln kann.

Planbarkeit der Weiterentwicklung ist genau das, was eine reife Zusammenarbeit vom ständigen Löschen von Bränden unterscheidet. Ist die Architektur solide, ist das Hinzufügen einer neuen Funktion eine geplante Aufgabe mit vernünftiger Kalkulation. Ist das Fundament schwach, birgt jede Änderung das Risiko, etwas anderes zu zerstören, und die Kalkulationen steigen immer weiter, weil der Dienstleister Unsicherheit einpreisen muss. Eine billige, ohne Architektur gebaute Anwendung erweist sich mit der Zeit als die teuerste Investition.

Tipp: Fragen Sie den Dienstleister im Gespräch nicht nur nach dem Preis für den Bau des MVP, sondern nach dem Plan für Betrieb und Weiterentwicklung in den kommenden zwölf Monaten. Bitten Sie um eine Schätzung der Kosten für Modellaufrufe, Monitoring und Aktualisierungen. Eine Firma, die darauf eine fertige Antwort hat, denkt langfristig über Ihr System nach. Eine Firma, die nur auf die Einführung schaut, lässt Sie direkt nach dem Start mit dem Problem allein.

Typische Fehler bei der Firmenauswahl und wie Sie sie vermeiden

Der teuerste Fehler bei der Auswahl eines Dienstleisters für eine KI-Anwendung ist eine Entscheidung allein nach dem Preis. Wir verstehen die Versuchung: Angebote können sich um ein Vielfaches unterscheiden, und der niedrigere Betrag sieht wie eine Ersparnis aus. In der Praxis bedeutet die Wahl des billigsten Anbieters meist, technische Schulden mehrfach abzuzahlen. Ein billiges Team kürzt Etappen ab, überspringt Tests, ignoriert die Architektur und liefert etwas, das in der Demo funktioniert. Und wenn es an Produktivbetrieb, Weiterentwicklung und Wartung geht, zeigt sich, dass es günstiger gewesen wäre, es gleich ordentlich zu machen.

Technische Schulden sind keine Metapher. Sie sind reales Geld und reale Zeit. Die technische Dokumentation warnt davor unmissverständlich:

Schaffen Sie keine Abkürzungen, die interne Implementierungsdetails offenlegen. Kurzfristig gewinnen Sie vielleicht etwas Zeit, doch anschließend ziehen Sie sich technische Schulden zu, die sich vervielfachen, während Ihre Codebasis wächst.

Dieser Satz beschreibt hervorragend den Mechanismus, den wir bei Kunden beobachten, die mit geerbten, gescheiterten Einführungen zu uns kommen. Die scheinbare Ersparnis am Anfang verwandelt sich in eine Kette immer teurerer Korrekturen. Irgendwann ist es günstiger, das System von Grund auf neu zu schreiben, als es weiter zu flicken. Und das heißt, dass die erste Investition vollständig verloren ist.

Der zweite häufige Fehler sind fehlende klare Verantwortungs- und Umfangsgrenzen. Ein Projekt ohne eindeutigen Dateneigentümer und ohne präzise bestimmten Umfang verschwimmt schlicht: Niemand weiß, was zum Dienstleister gehört, was zum Kunden und was übersehen wurde. Eine KI-Anwendung leidet unter solchem Chaos besonders, weil sie enge Zusammenarbeit bei den Daten verlangt. Legen Sie nicht fest, wer das Wissen liefert und aktualisiert, wer die akzeptable Qualität definiert und wer für die Sicherheit verantwortlich ist, bleibt das Projekt in wechselseitigen Erwartungen stecken.

Es gibt eine Reihe von Warnsignalen, die im Gespräch mit einem Dienstleister sofort Ihre Aufmerksamkeit wecken sollten. Hier die wichtigsten:

  • Erfundene oder nicht überprüfbare Case Studies – Beschreibungen spektakulärer Projekte, die sich nicht verifizieren lassen, ohne Kundennamen, messbaren Effekt und Ansprechperson.
  • Keine Fragen zu Integrationen – fragt der Dienstleister nicht, mit welchen Systemen die Anwendung verbunden werden muss, denkt er nicht an den Produktivbetrieb.
  • Versprechen ohne Architektur – Zusagen einer fertigen Lösung in einer Woche, ohne Gespräch über Daten, Schichten und Betrieb.
  • KI als Antwort auf alles – der Vorschlag eines generativen Modells selbst dort, wo eine einfache Regel oder Automatisierung genügen würde.
  • Kein Wort über Betriebskosten – die Konzentration allein auf den Einführungspreis, ohne das, was nach dem Start passiert.
  • Unwillen, das technische Team zu zeigen – Kontakt ausschließlich mit dem Vertrieb und Vermeidung von Gesprächen mit den Ingenieuren.

Jedes dieser Signale allein disqualifiziert einen Dienstleister noch nicht, doch ihre Häufung ist ein deutliches Zeichen, weiterzusuchen. Achten Sie besonders auf Case Studies. Ein echtes Projekt lässt sich konkret beschreiben: welches Problem gelöst wurde, mit welchen Methoden, welches Ergebnis erreicht wurde und welche Schwierigkeiten es gab. Eine Erzählung, die nur aus Superlativen besteht, ohne einen einzigen schwierigen Moment, ist verdächtig. Denn kein reales KI-Projekt verläuft ohne Probleme.

Der dritte Fehler ist ein Vorhaben, dessen Umfang in keinem Verhältnis zum Risiko steht. Kunden wollen oft sofort ein großes, vollständiges System bauen, das alle Prozesse auf einmal abdeckt. Das ist teuer, langwierig und mit enormem Risiko behaftet, denn viele Annahmen erweisen sich erst im Zusammenprall mit der Realität als falsch. Deutlich vernünftiger ist es, mit einem kleinen, messbaren MVP zu beginnen, das ein konkretes Problem löst. Ein solches Projekt zeigt schnell, ob KI tatsächlich hilft, was sie real kostet und wie die Nutzer reagieren.

Ein MVP liefert außerdem etwas kaum zu Überschätzendes: Wissen. Nach der ersten Etappe wissen Sie deutlich mehr über Ihre Daten, über das Verhalten des Modells und über Ihre eigenen Bedürfnisse als zu Beginn. Entscheidungen über die Weiterentwicklung treffen Sie dann auf Basis von Fakten und nicht von Annahmen. Das Risiko verteilt sich auf Etappen, und Sie geben das Budget bewusst aus. Ein Dienstleister, der einen solchen Ansatz von sich aus vorschlägt, statt Sie sofort zu einem großen Vertrag zu drängen, denkt an Ihr Interesse. Nicht nur an die Höhe der Rechnung.

Tipp: Bitten Sie jeden in Betracht gezogenen Dienstleister um Referenzen, bei denen Sie anrufen können. Ein kurzes Gespräch mit einem früheren Kunden darüber, wie das Team mit Problemen umging, Termine hielt und Schwierigkeiten kommunizierte, sagt Ihnen mehr als ein ganzes Portfolio. Und das völlige Fehlen überprüfbarer Referenzen ist für sich genommen ein ernstes Warnsignal.

FAQ: die häufigsten Fragen zur Wahl eines Dienstleisters für KI-Anwendungen

Nachfolgend beantworten wir die Fragen, die wir am häufigsten von Kunden hören, die eine Einführung Künstlicher Intelligenz erwägen. Die Antworten formulieren wir aus der Perspektive des Umsetzers, konkret und ohne Marketingzucker. Denn genau nach solchen Informationen würden wir an Ihrer Stelle selbst suchen.

Was kostet die Einführung einer KI-Anwendung und wovon hängt das Budget ab?

Die ehrliche Antwort lautet: Es kommt darauf an. Aber man kann sagen, worauf. Das Budget einer KI-Anwendung wird vor allem von drei Faktoren geprägt: dem Zustand und der Menge der Daten, der Anzahl und Komplexität der Integrationen mit bestehenden Systemen sowie dem geforderten Niveau an Qualität und Sicherheit. Ein einfaches Werkzeug auf Basis eines fertigen Modells, ohne tiefe Integrationen, ist eine völlig andere Größenordnung als ein RAG-System auf einer großen Wissensbasis, integriert mit ERP und CRM, mit Zugriffskontrolle und Qualitätsmonitoring.

Der zweite, oft übergangene Kostenbestandteil ist der Betrieb. Zum Einführungspreis müssen die Kosten für Modellaufrufe, Monitoring, Aktualisierungen und den Ausbau der Wissensbasis hinzugerechnet werden. Deshalb warnen wir vor Angeboten, die einen einzigen Betrag für den bloßen Aufbau des Systems nennen. Ein seriöser Dienstleister teilt das Budget in Einführung und Betrieb auf und weist aus, welche Kosten einmalig und welche dauerhaft sind. Das günstigste Angebot zum Start ist auf Sicht eines Jahres oft das teuerste, denn fehlende Architektur und fehlende Tests rächen sich vielfach.

Lohnt es sich, mit einem MVP zu beginnen, oder gleich ein vollständiges System zu bauen?

In der überwiegenden Mehrzahl der Fälle raten wir, mit einem MVP zu beginnen, also einer kleinen, messbaren Umsetzung, die ein konkretes Problem löst. Der Grund ist praktisch: KI-Projekte bringen viele Unbekannte mit sich, und Daten sowie Modellverhalten lassen sich vor dem Zusammenprall mit der Realität schwer vorhersagen. Ein MVP erlaubt zu prüfen, ob Künstliche Intelligenz tatsächlich hilft, die realen Kosten kennenzulernen und Nutzerreaktionen zu sammeln, bevor Sie in ein großes System investieren.

Der sofortige Bau eines vollständigen, umfangreichen Systems ergibt nur dann Sinn, wenn die Domäne gut erschlossen, die Daten geordnet und die Anforderungen stabil sind. Was in der Praxis selten vorkommt. Selbst dann lohnt es sich, das Projekt in Etappen mit messbaren Meilensteinen zu zerlegen. Ein etappenweiser Ansatz verteilt das Risiko, gibt Kontrolle über das Budget und erlaubt es, die Richtung anhand von Fakten zu korrigieren. Ein gut entworfenes MVP ist keine Sackgasse: Bei richtiger Architektur bildet es das Fundament, auf dem Sie in Ruhe das vollständige System ausbauen.

Fazit: wie Sie eine Firma für KI-Anwendungen vernünftig auswählen

Die Wahl eines Unternehmens, das KI-Anwendungen entwickelt, lässt sich auf einige Kriterien zurückführen, die man zu einem Bild zusammenfügen sollte. Erstens technische Kompetenzen jenseits eindrucksvoller Demos: Erfahrung in Integrationen, Kenntnis der Schichtenarchitektur, die Fähigkeit, semantische Suche zu bauen und nicht deterministische Systeme zu testen. Zweitens ein reifer Umgang mit Daten, denn sie entscheiden über die Qualität, und Parsing, Chunking sowie Kuratieren des Wissens wiegen schwerer als die Wahl des Modells selbst.

Drittens eine auf Skalierbarkeit und Betrieb ausgelegte Architektur mit Trennung der Geschäftslogik von Modell und Oberfläche, wodurch sich das System weiterentwickeln und Modelle ohne teure Neuschreibungen austauschen lassen. Viertens ein klarer Betriebsplan, der Aufrufkosten, Monitoring und Aktualisierungen umfasst und nicht nur den Preis für den Bau eines MVP. Und fünftens Transparenz in der Zusammenarbeit: konkrete Antworten statt Versprechen, überprüfbare Referenzen, klare Verantwortungsgrenzen und ein Dateneigentümer auf Ihrer Seite.

Wenn Sie Angebote nach diesen Kriterien vergleichen und nicht allein nach dem Preis, sehen Sie schnell, wer Ingenieurarbeit versteht und wer Hype verkauft. Der billigste Anbieter ist selten der billigste über ein Jahr, und der lauteste im Marketing ist selten der beste im Betrieb. Suchen Sie ein Team, das schwierige Fragen zu Ihren Daten und Systemen stellt, bevor es irgendetwas verspricht, und das vorschlägt, mit einem kleinen, messbaren Schritt zu beginnen statt mit einem großen, riskanten System.

Bei Web Systems entwerfen und realisieren wir seit 2006 Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce sowie Lösungen auf Basis Künstlicher Intelligenz. An KI gehen wir heran wie an jedes ernsthafte Ingenieurprojekt: Wir beginnen bei den Daten und dem Geschäftsziel, achten auf die Architektur, messen die Qualität und planen den Betrieb. Wir verkaufen keine Revolution. Wir liefern funktionierende Systeme, die sich weiterentwickeln und warten lassen.

Wenn Sie eine KI-Einführung, den Bau einer Anwendung, die Integration von Systemen, die Automatisierung von Prozessen oder die Modernisierung einer bestehenden Lösung erwägen, sprechen wir über Ihr MVP. Erzählen Sie uns von Ihrem Problem und Ihren Daten, und wir schlagen einen vernünftigen, technischen und messbaren ersten Schritt vor. Nehmen Sie Kontakt mit dem Team von Web Systems auf, wir helfen Ihnen einzuschätzen, was sich realistisch bauen lässt und womit Sie am besten beginnen.

Kostenlose Beratung buchen

Geben Sie Ihre Telefonnummer an oder vereinbaren Sie einen Termin