Eine Chat-Demo auf einem Sprachmodell ist in etwa einer Woche gebaut. Die Schwierigkeiten beginnen danach, wenn dieselbe Funktion auf Produktivdaten laufen muss, unter echtem Verkehr, mit planbaren Kosten und ohne Halluzinationen, die die Marke blamieren. Für einen CTO, Head of Product oder Head of AI lautet die eigentliche Frage nicht, ob man AI ergänzt, sondern wo, wie und mit wessen Händen - so, dass die Funktion den Kontakt mit Nutzern übersteht. Genau an diesem Punkt hören AI-Funktionen in einem Produkt auf, eine Demo zu sein, und werden zu einem Stück Architektur, das Sie jahrelang pflegen.
Aus unserer Erfahrung ist der schwierigste Teil nicht die Integration mit dem Modell, sondern das Engineering darum herum: die Wahl der Daten, die Bewertung der Qualität, die Kostenkontrolle und der Umgang mit Datenschutz. In der RITS Group bauen wir echte AI- und Data-Kompetenz auf, darunter unsere AI-, LLM- und Datenteams, und wir haben GenAI-, RAG- und LLM-Projekte geliefert, unter anderem einen AI-gestützten Wissensassistenten für einen Kunden aus der Versicherungsbranche. Diese Erfahrung tragen wir in Tech-Produkte und besetzen die Rollen, die auf Kundenseite meist fehlen.
Wo schafft AI in einem Produkt tatsächlich Wert?
Vor der Frage nach dem Modell steht die Frage nach der Stelle. AI zahlt sich dort aus, wo ein Produkt viel unstrukturierten Text oder repetitive kognitive Arbeit hat, nicht überall. Der reale Wert zeigt sich meist in einigen wenigen Mustern:
- Suche und Beantwortung von Fragen über Dokumentation, Wissensbasis oder Ticket-Historie,
- Zusammenfassung und Extraktion aus langen Dokumenten, E-Mails und Transkripten,
- Entscheidungsunterstützung für Bearbeitende: Vorschläge, Klassifizierung, erste Antwortentwürfe,
- Automatisierung mühsamer Schritte in einem Prozess, den heute ein Mensch von Hand erledigt.
Eine gut gewählte erste Funktion hat eine Eigenschaft gemeinsam: Sie ist messbar und lässt sich zurücknehmen, wenn sie scheitert. Dort beginnen wir, denn das begrenzt das Risiko und verschafft der Organisation Vertrauen für die nächsten Schritte.
Worin unterscheiden sich LLM- und RAG-Funktionen in einem Produkt?
Diese Unterscheidung treibt sowohl die Architektur als auch die Kosten. Ein reines LLM arbeitet mit dem, was das Modell aus dem Training „weiß”, und mit dem, was Sie in den Prompt geben; es ist stark im Erzeugen, Umformulieren und Klassifizieren, kennt aber Ihre Daten nicht. RAG (Retrieval-Augmented Generation) ergänzt eine Retrieval-Schicht: Sie findet zuerst die passenden Ausschnitte Ihres Wissens, und erst dann antwortet das Modell auf deren Grundlage, mit Verweis auf die Quelle.
In der Praxis sind die meisten Produktfunktionen, die einem Nutzer wirklich helfen, RAG und kein nacktes LLM. Der Grund ist banal: Ein Unternehmen will die Antwort in den eigenen Dokumenten verankert und überprüfbar haben, nicht im Allgemeinwissen des Modells. Genau dieses Muster haben wir im Wissensassistenten für den Versicherungskunden eingesetzt, wo das Modell aus einer konkreten, unternehmenseigenen Basis antworten musste, statt zu raten.
Wie integrieren und evaluieren Sie AI-Modelle?
Die Integration ist der leichtere Teil. Der schwerere ist die Evaluation, die Antwort darauf, ob eine Funktion gut genug für die Auslieferung ist. Ohne sie arbeitet das Team blind und reagiert erst, wenn Nutzer sich beschweren.
- Ein Testsatz aus realen Fragen und erwarteten Antworten, gemeinsam mit Fachleuten aufgebaut.
- Qualitätskennzahlen, passend zur Aufgabe: Relevanz der Antwort, Quellenangabe, Halluzinationsrate.
- Ein Vergleich von Modellen und Konfigurationen (verschiedene Modelle, Prompts, Parameter) auf demselben Satz, statt einer Wahl aus dem Bauch heraus.
- Regression vor jedem Release, damit eine Prompt-Änderung nicht zerstört, was bereits funktioniert hat.
Wir behandeln das Modell als Komponente, die getestet und versioniert wird, nicht als Zauberkasten. So beruht die Entscheidung zur Auslieferung auf Zahlen und nicht auf einer einzelnen glücklichen Demo.
Wie fügen Sie AI-Agenten in Delivery-Prozesse und das Produkt ein?
Ein AI-Agent ist ein Modell, das nicht nur antwortet, sondern Schritte unternimmt: zu Werkzeugen greift, APIs aufruft, mehrere Aktionen zu einem Ablauf verkettet. In einem Produkt wirkt er dort, wo die Aufgabe ein klares Ziel und ein messbares Ergebnis hat, etwa die Bearbeitung eines Tickets oder der erste Entwurf eines Dokuments.
Wir setzen Agenten auch auf unserer Seite ein, im Delivery-Prozess, um Routineteile der Engineering-Arbeit zu beschleunigen. Das Prinzip ist in beiden Fällen dasselbe: Ein Agent bekommt einen eng definierten Umfang und harte Berechtigungsgrenzen, keine freie Hand. Je autonomer der Schritt, desto stärker die Kontrollen darum herum, denn die Kosten eines Fehlers wachsen schneller als die Bequemlichkeit der Automatisierung.
Wie steuern Sie die Qualität von Prompts und Ausgaben?
Ein Prompt ist keine Notiz; er ist ein Produktartefakt, das Sie wie Code pflegen. Deshalb halten wir ihn in einem Repository, versionieren und testen ihn, statt ihn in den Köpfen einiger Leute zu lassen. Um die Ausgaben herum bauen wir eine Sicherheitsschicht, die abfängt, was das Modell nicht zurückgeben soll.
- Versionierung der Prompts, gekoppelt an die Evaluationsergebnisse.
- Validierung des Ausgabeformats (z. B. erzwungenes JSON), damit sich das Ergebnis sicher weiterverarbeiten lässt.
- Content-Safety-Regeln und Filter für sensible Daten, bei Eingabe wie Ausgabe.
- Monitoring in der Produktion: Protokollierung von Anfragen, Kosten und Signalen für Antworten geringer Qualität.
Diese Schicht entscheidet darüber, ob eine AI-Funktion wiederholbar ist oder vom Glück mit einer bestimmten Anfrage abhängt.
Was kostet das, und wie gehen Sie mit Datensicherheit und Datenschutz um?
Die Kosten von AI in einem Produkt sind keine einzelne Rechnung, sondern die Summe aus Modellaufrufen, Vektorspeicher und Wartung. Wir können sie schon im Entwurf realistisch halten, indem wir das Modell auf die Aufgabe abstimmen (kleiner und günstiger, wo das reicht), Prompts kürzen, wiederkehrende Antworten zwischenspeichern und entscheiden, was überhaupt ein Modell erreichen muss.
Sicherheit und Datenschutz behandeln wir als Eintrittsbedingung, nicht als Zusatz. Bei der Arbeit mit Kundendaten klären wir früh, wo die Daten physisch verarbeitet werden, ob sie an ein öffentliches Modell oder eine private Variante gehen und wie sie anonymisiert und aufbewahrt werden. In regulierten Projekten, etwa in der Versicherung, entscheiden genau diese Festlegungen und nicht die Modellwahl darüber, ob eine Funktion überhaupt ausgeliefert werden darf.
Warum brauchen AI-Funktionen einen Menschen in der Schleife?
Weil ein Modell selbstsicher sein kann, auch wenn es irrt. Für Funktionen, die Geld, Recht, Gesundheit oder den Ruf der Marke berühren, legen wir einen Menschen in der Schleife als bewusste Entscheidung an und nicht als nachträglich angeflanschte Absicherung. In der Praxis heißt das: Bei Antworten mit geringer Konfidenz schlägt das Produkt vor, statt zu handeln, und überlässt den letzten Schritt einem Menschen. Dieser Aufbau erlaubt es, AI schneller und sicherer auszuliefern, denn die Organisation muss dem Modell nicht über Nacht hundertprozentig vertrauen.
Welche AI-Kompetenzen stellen wir für das Projekt?
Auch wenn wir genau Ihren Produkttyp noch nicht gebaut haben, liefern wir Menschen, die das bereits getan haben, in anderen GenAI-, RAG- und LLM-Projekten. Wir formen das Team um die konkrete Aufgabe, nicht „auf Vorrat”:
- AI-/ML- und LLM-Engineers, die Funktionen, Prompts und die RAG-Schicht bauen,
- Data Engineers, die das Wissen für das Retrieval bereinigen und aufbereiten,
- Architekten, die Modell, Backend und Infrastruktur zu einem wartbaren Ganzen verbinden,
- DevOps/MLOps, die Deployments, Monitoring und Modellkosten verantworten.
Dieses Team binden wir als Team-Verstärkung oder dediziertes Team in Ihr Produkt ein, unter Ihrer Führung, und ergänzen Kompetenzen genau dort, wo sie fehlen.
Wie machen wir das bei RITS?
Wir tun das als Nearshore-Partner aus Polen, mit echter AI- und Data-Kompetenz innerhalb der RITS Group (darunter unsere AI-, LLM- und Datenteams). Wir beginnen mit einer messbaren Funktion, nicht mit einer ganzen AI-Plattform auf einmal. Wir bauen sie auf RAG und den eigenen Daten des Kunden, mit Evaluation und Monitoring von Anfang an und nicht erst nach den ersten Beschwerden. Datenschutz und Datensicherheit legen wir vor dem ersten Modellaufruf fest, denn in regulierten Projekten entscheiden sie darüber, ob eine Funktion ausgeliefert wird. Wir haben GenAI-, RAG- und LLM-Projekte geliefert, darunter einen AI-gestützten Wissensassistenten für einen Kunden aus der Versicherungsbranche, und tragen diese Erfahrung in Tech-Produkte, indem wir die fehlenden Rollen mit geprüften Menschen besetzen.
Womit beginnen Sie, wenn Sie AI-Funktionen ergänzen?
Beginnen Sie mit einem konkreten Nutzerproblem, das Sie messen können, und mit der Frage, welches Wissen AI braucht, um sinnvoll zu antworten. Das entscheidet, ob Sie ein reines LLM oder RAG brauchen, welche Daten Sie aufbereiten müssen und welche Rollen zu besetzen sind. Wenn Sie abwägen, in welchem Kooperationsmodell Sie starten, haben wir die Unterschiede in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Ergänzen Sie AI-Funktionen (LLM/RAG) in Ihrem Produkt? Sprechen wir darüber - wir stimmen Kompetenzen und Architektur auf Ihren Fall ab.