2006 haben wir Web Systems in Łódź gegründet. Mobile Apps? Steckten in den Kinderschuhen. KI? Eingeschlossen in Laboren. Heute kommen unsere Kunden mit konkreten Anliegen – sie wollen Apps, die den Kontext verstehen, die Bedürfnisse der Nutzer vorhersehen und Arbeit automatisieren, für die bisher ein Mensch nötig war. Das ist keine KI-Mode. Das ist die Antwort auf einen Markt, der sich verändert hat. Unternehmen aus E-Commerce und B2B brauchen intelligente mobile Werkzeuge auf Basis von KI, weil ihre Kunden schlicht personalisierte Erlebnisse erwarten. So einfach ist das. Wir teilen hier die Perspektive eines Dienstleisters, der den Weg von den ersten Experimenten mit Sprachmodellen bis zu produktiven Einführungen gegangen ist. Wir zeigen Ihnen die Architekturentscheidungen, die Fehler (davon gab es einige), die Kosten und die Lehren aus realen Projekten.
Spis treści
Woher die Idee kam, eine mobile App mit KI zu verbinden
Der Impuls kam nicht von einer Konferenz und nicht aus einem Gartner-Report. Er kam aus Gesprächen mit Kunden. Einer von ihnen verwaltete Hunderte von Produkten in einem B2B-System und brauchte einen Weg, damit seine Vertriebsmitarbeiter Antworten auf Fragen von Geschäftspartnern schneller finden. Er sagte es ganz direkt: “Meine Leute verlieren jeden Tag eine Stunde damit, Spezifikationen in PDFs zu suchen, macht was dagegen.” Also haben wir es gemacht. Ein solches Problem löst ein gut entworfenes KI-Modul, nicht die nächste Volltextsuche.
Der Unterschied zwischen einem Modewort und etwas, das tatsächlich funktioniert? Riesig. Viele Firmen schreiben “KI” in ihre Produktbeschreibung, weil es modern klingt. Realer Nutzen entsteht aber erst dann, wenn das Modell ein konkretes Problem der Nutzer löst. In unserer Praxis sind das meistens Frage-Antwort-Systeme auf Basis einer firmeneigenen Wissensdatenbank, intelligente Produktempfehlungen oder die automatische Kategorisierung von Inhalten. Jedes dieser Szenarien verlangt einen anderen technischen Ansatz. Und eine andere Architektur.
Die Entscheidung für RAG (Retrieval-Augmented Generation) ergab sich ganz natürlich. Ein klassisches LLM erzeugt Antworten auf Basis seiner Trainingsdaten – und das bedeutet ein Risiko von Halluzinationen und veralteten Informationen. RAG beseitigt dieses Problem, weil das Modell sein Wissen aus einer konkreten, kuratierten Dokumentenbasis des Kunden bezieht. Doch nicht jedes Projekt braucht eine so fortgeschrittene Lösung. Einfachere Fälle? Die erledigen wir mit gut zugeschnittenem Prompt Engineering, ohne zusätzliche Infrastruktur für semantische Suche.
„Der Retrieval-Mechanismus in RAG ist von entscheidender Bedeutung. Sie brauchen die beste semantische Suche auf einer kuratierten Wissensdatenbank, damit die abgerufenen Informationen wirklich zur Anfrage oder zum Kontext passen. Sind die abgerufenen Informationen irrelevant, kann Ihre Generierung zwar in Quellen verankert, aber trotzdem am Thema vorbei oder schlicht falsch sein.”
Dieses Zitat trifft genau das, was wir in Projekten sehen. Die Qualität der KI-Antworten hängt vor allem von der Qualität des Suchmechanismus und der Wissensdatenbank selbst ab. Die Investition in die Kuratierung der Daten zahlt sich vielfach aus. Und der Versuch, schwache Quellen durch ein besseres Sprachmodell auszugleichen? Der führt ins Leere. Ich habe es ausprobiert.
Mobile Architektur, die für Künstliche Intelligenz bereit ist
Die Wahl des Technologie-Stacks für eine mobile App mit KI-Komponente ist eine der ersten Entscheidungen, die über den Erfolg des gesamten Projekts bestimmt. Bei Web Systems arbeiten wir mit nativen Lösungen (Kotlin, Swift) und plattformübergreifenden Ansätzen (Flutter, React Native). Bei KI-Integrationen bevorzugen wir ein Vorgehen, bei dem die Logik der Kommunikation mit den Modellen im Backend liegt und die mobile App ein leichter Präsentationsclient bleibt. Warum? Weil das die Flexibilität gibt, das KI-Modell zu wechseln, ohne die App im Store aktualisieren zu müssen. Und Modelle wechseln wir häufig.
Das Fundament einer skalierbaren mobilen App ist die Trennung der Schichten. Die UI-Schicht ist ausschließlich für Darstellung und Interaktion zuständig. Die Datenschicht verwaltet die Kommunikation mit dem API, das Caching und die Offline-Synchronisierung. Dazwischen liegt optional eine Domänenschicht, die komplexe Geschäftslogik kapselt. Und was bringt diese Aufteilung? Das Hinzufügen eines KI-Moduls – eines Chatbots, eines Empfehlungssystems, einer Bildanalyse – erfordert keinen Umbau der bestehenden Anwendung. Sie stecken einfach ein neues Element ein.
„Die App-Architektur ist das Fundament einer hochwertigen Android-Anwendung. Eine klar definierte Architektur erlaubt es Ihnen, eine skalierbare, wartbare App zu bauen, die sich an das ständig wachsende Ökosystem der Android-Geräte anpassen kann. (…) Das wichtigste Prinzip ist die Trennung der Zuständigkeiten: die Aufteilung der App in Methoden, Klassen, Dateien, Pakete, Module und Schichten mit klar definierten Verantwortlichkeiten und Grenzen.”
Zwanzig Jahre Softwareentwicklung. Ich bestätige dieses Prinzip ohne Einschränkung. Projekte, in denen der Kunde auf schnelles Prototyping auf Kosten der Architektur bestand, erzeugten technische Schulden, die später ein Vielfaches jener anfänglichen “Zeitersparnis” gekostet haben. Gerade bei der Integration von KI – wo sich die Anforderungen mit jeder neuen Modellversion dynamisch ändern – ist eine solide Architektur kein Luxus. Sie ist die Bedingung dafür, dass das Projekt überlebt.
Tipp: Wenn Sie eine mobile Architektur für künftige KI-Module entwerfen, führen Sie von Anfang an eine Abstraktionsschicht für die Kommunikation mit Inferenzdiensten ein. Definieren Sie eine Schnittstelle, über die sich der Modellanbieter (OpenAI, Anthropic, lokale Modelle) austauschen lässt, ohne die Präsentationsschicht zu verändern. In der Praxis heißt das: ein eigenes Daten-Repository für KI-Antworten mit einem einheitlichen Vertrag, unabhängig vom konkreten API.
Herausforderungen bei der Integration von KI-Modellen in eine mobile App
Die erste Frage zu Beginn jedes Projekts mit KI-Komponente lautet: Wo soll das Modell laufen? Inferenz auf dem Gerät (Edge) beseitigt die Netzwerklatenz und ermöglicht den Offline-Betrieb, begrenzt aber die Modellgröße drastisch. Man muss auf konkrete mobile Chips hin optimieren. Die Cloud gibt Zugang zu den leistungsstärksten Modellen, erzeugt aber Kosten proportional zur Zahl der Anfragen und macht abhängig von der Stabilität der Verbindung. In den meisten unserer Projekte wählen wir einen hybriden Ansatz. Einfache Aufgaben (Klassifizierung, Extraktion von Schlüsselwörtern) laufen lokal. Komplexe Textgenerierung geht in die Cloud.
Datensicherheit ist das Thema, das bei Unternehmenskunden die größten Bedenken weckt. Und das zu Recht. Nutzeranfragen an ein externes API eines Sprachmodells zu senden bedeutet, dass sensible Informationen die kontrollierte Infrastruktur des Unternehmens verlassen. Wir setzen mehrere Strategien ein – Anonymisierung der Daten vor dem Versand, dedizierte Modellinstanzen mit der Garantie, dass die Daten nicht für das Training verwendet werden, Ende-zu-Ende-Verschlüsselung sowie eine lokale Vorverarbeitung, die personenbezogene Daten herausfiltert, bevor sie das LLM erreichen. Jede Lösung wählen wir individuell nach den regulatorischen Anforderungen des Kunden. Einen universellen Ansatz gibt es hier nicht.
Der Umgang mit Offline-Zuständen ist eine weitere Besonderheit mobiler Plattformen. Ein Nutzer im Außendienst (Vertriebsmitarbeiter, Prüfer, Servicetechniker) verliert den Empfang und erwartet, dass die App weiterhin funktioniert. Und was dann? Wir entwerfen Systeme zum Zwischenspeichern von KI-Antworten, zum Einreihen von Anfragen für die spätere Verarbeitung und zum intelligenten Prefetching der am häufigsten benötigten Informationen. Diese Mechanismen erfordern eine sorgfältige Verwaltung des Gerätespeichers, denn Modelle brauchen viel Platz und ältere Telefone haben begrenzte Ressourcen.
Die typischen Fehler, die wir bei den ersten Integrationen zu vermeiden gelernt haben? Keine Behandlung von Timeouts bei Anfragen an das Modell-API. Das Ignorieren der Eingabe-Token-Limits (was dazu führt, dass der Kontext abgeschnitten wird). Das Nicht-Protokollieren der Kosten pro Anfrage. Und mein Favorit: Tests ausschließlich im schnellen Büro-WLAN statt unter realen Bedingungen eines Mobilfunknetzes. Jedes dieser Probleme haben wir in der Produktion entdeckt. Schmerzhafte Lektionen, aber wirksame.
RAG, Fine-Tuning und Prompt Engineering in der Projektpraxis
Die Wahl der KI-Technik für einen konkreten Geschäftsfall sollte sich aus der Analyse der Daten und der Bedürfnisse ergeben. Nicht aus der Faszination für Technologie. Prompt Engineering bewährt sich, wenn der Kunde standardisierte Anfragen hat und vorhersehbare Antwortformate braucht – Erzeugen von Produktbeschreibungen, Übersetzungen, Extraktion von Daten aus Formularen. Fine-Tuning kommt ins Spiel, wenn das Modell spezifisches Branchenvokabular oder die Tonalität der Unternehmenskommunikation verstehen muss. RAG wiederum ist dort unersetzlich, wo Antworten auf einer aktuellen, firmeneigenen Wissensdatenbank beruhen müssen – technische Dokumentation, Geschäftsbedingungen, Produktkataloge.
Der Ansatz RAG Ops, also das metrikgestützte Qualitätsmanagement eines Retrieval-Augmented-Generation-Systems, hat verändert, wie wir KI-Projekte führen. Statt eines subjektiven “die Antwort sieht gut aus” messen wir konkrete Kennzahlen jeder erzeugten Antwort. Das erlaubt es, die gesamte Pipeline systematisch zu optimieren – vom Parsen der Quelldokumente über die Chunking-Strategie bis zum Prompt, der die Generierung steuert. Ohne Metriken ist jede Iteration ein Schuss ins Dunkle. Mit ihnen wird daraus ein ingenieurmäßiger Prozess.
Die Kennzahlen zur Bewertung von KI-Antworten, die wir in Projekten einsetzen:
- Coherence – logische Stimmigkeit der Antwort, keine inneren Widersprüche
- Groundedness – Verankerung in den Quellen, das Maß, in dem die Antwort auf den gelieferten Dokumenten beruht
- Fluency – sprachliche Flüssigkeit und Natürlichkeit des erzeugten Textes
- Safety – Sicherheit der Inhalte, keine schädlichen oder unangemessenen Antworten
- Instruction following – Übereinstimmung mit den gegebenen Anweisungen und dem Antwortformat
- Question answering quality – Treffsicherheit der Antwort in Bezug auf die gestellte Frage
Die Kuratierung der Wissensdatenbank ist der Punkt, den Kunden am häufigsten unterschätzen. Chunking-Strategien, also die Art, wie Dokumente in Fragmente zerlegt werden, die die semantische Suche indexiert, wirken sich unmittelbar auf die Antwortqualität aus. Zu große Fragmente verwässern die Präzision der Suche. Zu kleine verlieren den Kontext. In unseren Projekten experimentieren wir mit semantischem Chunking (Teilung entlang logischer Absätze), überlappendem Chunking (overlapping chunks) und hierarchischem Chunking (Erhalt der Dokumentstruktur). Die optimale Variante? Die ermitteln wir empirisch für jeden Dokumentationstyp. Eine Abkürzung gibt es hier nicht.
Kosten, Zeitplan und MVP – was man dem Kunden offen sagen sollte
Kostentransparenz wird in der IT-Branche gerne selektiv gehandhabt. Bekanntes Bild. Bei Web Systems gilt der Grundsatz, dass der Kunde das vollständige finanzielle Bild eines Projekts kennen sollte, bevor er entscheidet. Ein realistisches Budget für eine mobile App mit KI-Komponente beginnt bei 80.000 bis 150.000 PLN für ein MVP und wächst proportional zur Komplexität des Modells, zum Umfang der Wissensdatenbank sowie zu den Anforderungen an Leistung und Sicherheit. Allein die Einführung von RAG mit einer eigenen Vektordatenbank und einem API für die Anfragen macht in der Regel 30 bis 50 Prozent dieses Budgets aus.
Die MVP-Strategie ist sinnvoll, weil sie den geschäftlichen Nutzen der KI überprüfen lässt, bevor der Kunde in die Vollversion investiert. Für die erste Iteration wählen wir eine einzige, wichtigste KI-Funktion – meistens einen Frage-Antwort-Chatbot auf der firmeneigenen Wissensdatenbank oder eine intelligente Produktsuche. Bildanalyse, Berichtserzeugung, Prognosen? Die heben wir uns für spätere Iterationen auf, wenn wir wissen, dass die Nutzer die KI-Komponente tatsächlich verwenden und sie messbaren Nutzen bringt.
Versteckte Betriebskosten eines KI-Projekts sind ein Thema, über das viele Dienstleister schweigen. Ein Sprachmodell braucht regelmäßige Aktualisierungen. API-Anbieter wechseln Versionen, stellen Endpunkte ab, ändern Preislisten. Die Wissensdatenbank braucht Pflege, weil sich die Dokumente des Kunden ändern und alte Chunks veralten. Das Monitoring der Antwortqualität verursacht Infrastrukturkosten, und allein die Token-Kosten können bei vielen Nutzern so manchen Product Owner überraschen. Wir schätzen die jährlichen Betriebskosten eines KI-Systems auf 15 bis 25 Prozent der Anfangsinvestition.
Warum schreiben wir darüber so offen? Weil ein Kunde, der die Kostenstruktur versteht, bessere Entscheidungen trifft. Und weil er das Vertrauen in den Dienstleister nicht verliert, wenn nach einem halben Jahr die Rechnungen für das API kommen oder die Wissensdatenbank neu indexiert werden muss. Transparenz schützt beide Seiten vor Enttäuschung. Sie baut eine partnerschaftliche Beziehung auf, die sich auf lange Sicht bewährt. Ich habe beide Wege ausprobiert – ich weiß, welcher funktioniert.
FAQ
Was kostet eine mobile App mit KI in einem polnischen software house?
Ein MVP einer mobilen App mit KI-Komponente in einem polnischen software house kostet ab etwa 80.000 bis 150.000 PLN netto. Der endgültige Betrag hängt von der Komplexität des KI-Modells, dem Umfang der Wissensdatenbank, den Sicherheitsanforderungen und der Zahl der Plattformen ab (iOS, Android oder beide). Dazu kommen die Betriebskosten – Modellaktualisierungen, Monitoring der Antwortqualität und Gebühren für die APIs der Sprachmodellanbieter. Das sind grob 15 bis 25 Prozent der Anfangsinvestition pro Jahr. Die MVP-Strategie erlaubt es, die anfänglichen Ausgaben zu begrenzen und das Projekt erst dann zu skalieren, wenn bestätigt ist, dass die KI tatsächlich geschäftlichen Nutzen bringt.
Braucht KI in einer mobilen App eine ständige Internetverbindung?
Nicht immer. Hybride Lösungen erlauben es, einfachere Modelle direkt auf dem Gerät auszuführen – Textklassifizierung, Extraktion von Schlüsselwörtern oder Bilderkennung lassen sich offline erledigen. Komplexe generative Aufgaben (Chatbot-Antworten, Erzeugung von Inhalten, Dokumentenanalyse per RAG) brauchen die Kommunikation mit einem Server, denn große Sprachmodelle benötigen Rechenressourcen, die ein durchschnittliches Smartphone nicht hat. Wir entwerfen Apps mit Anfrage-Warteschlangen und zwischengespeicherten Antworten – so können Nutzer offline arbeiten und die Ergebnisse synchronisieren, sobald die Verbindung zurück ist.
Wie lange dauert die Einführung eines MVP einer mobilen App mit Künstlicher Intelligenz?
Realistisch? Drei bis fünf Monate, je nach Komplexität. Der erste Monat umfasst die Anforderungsanalyse, den Entwurf der Architektur und die Vorbereitung der Wissensdatenbank. Die nächsten sechs bis acht Wochen entfallen auf die Umsetzung der mobilen App und die Integration mit dem KI-Modell. Den Rest verwenden wir auf Tests der Antwortqualität, die Optimierung der Prompts, Performance-Tests und die Einführung selbst. Projekte mit fortgeschrittenem Fine-Tuning des Modells oder mit komplizierten Sicherheitsanforderungen können länger dauern – den genauen Zeitplan legen wir nach einem Analyse-Workshop fest.
Fazit und der nächste Schritt
Der Bau mobiler Apps mit KI-Komponente verlangt die Verbindung von mobiler Ingenieurskunst, Architektur verteilter Systeme und praktischer Kenntnis des Ökosystems der Sprachmodelle. Nach zwanzig Jahren in der Branche sehe ich, dass der Erfolg solcher Projekte von drei Dingen abhängt – einer soliden Schichtenarchitektur, einem metrikgestützten Umgang mit der Qualität der KI und einer ehrlichen Kommunikation über Kosten gegenüber dem Kunden. Keines dieser Elemente ist optional.
Die Partnerschaft mit einem erfahrenen technischen Team zählt nicht nur in der Bauphase. Vor allem zählt sie beim Betrieb und der Weiterentwicklung des Systems. KI-Modelle entwickeln sich weiter, APIs ändern sich, Wissensdatenbanken wachsen – und dann zeigt sich, wie gut die Architektur und wie reif die Prozesse sind, die der Dienstleister am Anfang eingeführt hat. Billige Prototypen, die ohne Trennung der Schichten und ohne Teststrategie geschrieben wurden, werden nach einigen Monaten im Betrieb zu teuren Problemen. Ich habe das oft genug gesehen.
Denken Sie über eine mobile App mit Elementen Künstlicher Intelligenz nach? Suchen Sie einen Partner für den Bau eines MVP oder wollen Sie RAG in ein bestehendes System integrieren? Melden Sie sich bei uns. Bei Web Systems verbinden wir Projekterfahrung mit praktischer Kenntnis von KI – wir sprechen gerne über Ihren Geschäftsfall, die realen Kosten und einen Zeitplan, der Sinn ergibt.
