Assistent im Produkt
Ein Chat, der Fragen zu deinem Produkt, deinen Daten oder dem aktuellen Bildschirm beantwortet. Nicht als Gimmick, sondern dort, wo Nutzer heute in der Hilfe suchen oder den Support anrufen.
Assistenten, Dokumentenverständnis, Suche über eigene Inhalte – wir bauen Sprachmodelle in Apps ein, die dann auch im Betrieb funktionieren: mit Kostendeckel, Datenschutz und einer Architektur, in der das Modell austauschbar bleibt.
Unverbindlich · Antwort innerhalb von 24 Stunden (Mo–Fr) · Direkt aus der Entwicklung, nicht vom Vertrieb
Vier Muster – einzeln oder kombiniert.
Ein Chat, der Fragen zu deinem Produkt, deinen Daten oder dem aktuellen Bildschirm beantwortet. Nicht als Gimmick, sondern dort, wo Nutzer heute in der Hilfe suchen oder den Support anrufen.
Rechnungen, Verträge, Formulare, Fotos von Zetteln: Das Modell liest, ordnet zu und füllt Felder vor. Die Freigabe bleibt beim Menschen, die Tipparbeit nicht.
Fragen in normaler Sprache an Handbücher, Wissensdatenbanken oder Protokolle – mit Zitat der Fundstelle. Das Verfahren heißt RAG: Das Modell soll nur auf Basis der mitgegebenen Dokumente antworten und die Fundstelle zitieren – wie oft es das nicht tut, messen wir vor dem Start.
Support-Anfragen nach Anliegen sortieren, Stimmung erkennen, Strukturdaten aus Freitext ziehen. Unspektakulär, aber oft der Einsatz mit dem schnellsten Effekt.
Der Zugangsschlüssel zum Modellanbieter (API-Schlüssel) gehört nicht in eine App, die auf tausend fremden Telefonen läuft. Deshalb sitzt zwischen App und Modell immer dein Backend – der Server-Teil deiner App: Es hält den Schlüssel, protokolliert die Anfragen, setzt Limits je Nutzer und Tag – und es entscheidet, welches Modell antwortet. Wechselt der Anbieter das Preismodell oder erscheint ein besseres Modell, ändern wir eine Stelle im Backend, nicht die App in beiden Stores.
Beim Modell gilt: so einfach wie möglich. Die meisten Funktionen sind ein einzelner Aufruf mit gut formulierter Anweisung. Erst wenn ein Ergebnis mehrere Schritte braucht, wird daraus ein Ablauf, den dein Backend steuert. Einen Agenten – das Modell entscheidet selbst, welche Werkzeuge es aufruft – bauen wir nur, wenn die Aufgabe offen ist. Das ist die teuerste und am schwersten zu testende Stufe; die wenigsten Anwendungsfälle brauchen sie.
Modellwahl nach Aufgabe: Für Textverständnis und Assistenten ein großes Sprachmodell über die API von Anthropic, OpenAI oder Google; für Klassifikation oft ein kleineres. Wenn Daten das Haus nicht verlassen dürfen, ein offenes Modell auf eigener Infrastruktur in der EU. Die konkrete Modellwahl treffen wir im Projekt mit dem dann aktuellen Stand.
Über 500.000 Downloads über alle Apps, Flutter für iOS und Android aus einer Codebasis, Backends in Go und .NET im produktiven Betrieb. Unsere Apps verarbeiten Live-Daten aus fremden Quellen – Ladepunkte, Strompreise, Geodaten von Wearables – über sauber gekapselte Schnittstellen. Ein Sprachmodell ist für dein Backend eine weitere solche Quelle: eine externe API, deren Ausfälle, Kosten und Antwortzeiten es im Griff behalten muss.
Was im Prompt steht – der Anfrage an das Modell samt allem, was mitgeschickt wird – verlässt deine Systeme. Deshalb beginnt Datenschutz bei der Frage, was überhaupt ins Modell muss: Oft reicht ein Ausschnitt statt des ganzen Datensatzes, oft lassen sich Namen vorher entfernen. Den Auftragsverarbeitungsvertrag nach Art. 28 DSGVO schließt du mit dem Anbieter – wir bereiten ihn vor und prüfen die Bedingungen des konkreten Anbieters. Wo verfügbar, wählen wir eine EU-Region; wo nicht, sagen wir dir, wo die Verarbeitung stattfindet. Gesundheitsdaten nach Art. 9 DSGVO brauchen zusätzlich eine Ausnahme nach Art. 9 Abs. 2 – in Endnutzer-Apps in der Regel die ausdrückliche Einwilligung – dazu mehr auf unserer Seite zur Gesundheits-App-Entwicklung.
In der App selbst heißt Transparenz nach Art. 50 der EU-KI-Verordnung, gültig seit 2. August 2026: Wo Nutzer mit der KI interagieren, ein klarer Hinweis auf den Assistenten; erzeugte Inhalte tragen eine maschinenlesbare Markierung. Beides bauen wir mit, es ist im Festpreis enthalten. Risikoklasse, Dokumentation und Mitbestimmung, also alles, was für App und Unternehmenssysteme gleichermaßen gilt, steht unter KI-Beratung → Regeln.
Welche Aufgabe soll das Modell übernehmen, woran messen wir, ob es klappt, und was kostet ein Fehler? Ergebnis: eine schriftliche Einschätzung samt Budgetspanne – kostenlos.
Eine Funktion, deine Daten, in der Regel zwei bis drei Wochen ab Datenzugang. Du siehst, wie das Modell auf deine Eingaben antwortet – und wir messen, wie oft es danebenliegt.
Backend, Limits, Protokollierung, Oberfläche in der App. Nach jedem Meilenstein eine lauffähige Version, die du selbst ausprobierst.
Kosten je Anfrage, Antwortzeiten, Fehlerquote – im Betrieb sichtbar, nicht nur beim Launch. Modellwechsel bleiben ein Backend-Update.
Drei Spannen als Orientierung. Bei einer klar umrissenen Funktion ist der Prototyp die erste Etappe – jede Etappe mit eigenem Festpreis, vorab schriftlich.
Alle Preise zzgl. gesetzlicher Umsatzsteuer. Grundlage des Festpreises ist der im Erstgespräch abgestimmte Leistungsumfang. Laufende Modellkosten des Anbieters fallen zusätzlich an und werden getrennt ausgewiesen.
Das entscheidet die Aufgabe, nicht der Markenname. Für Textverständnis, Zusammenfassen und Assistenten nehmen wir ein großes Sprachmodell über die API eines Anbieters – Claude, GPT oder Gemini –, für Klassifikation reicht oft ein kleineres und günstigeres. Wenn Daten das Haus nicht verlassen dürfen, kommt ein offenes Modell auf eigener Infrastruktur infrage.
Die Anbieter rechnen pro verarbeiteter Textmenge ab – je Anfrage sind das typischerweise Bruchteile eines Cents bis wenige Cent, abhängig von Modell und Textlänge. Was du dafür brauchst, ist keine Schätzung, sondern ein Deckel: Wir bauen Limits je Nutzer und je Tag ins Backend, damit eine Funktion bei unerwarteter Nutzung nicht zur Kostenfalle wird. Die konkreten Preise nennen wir im Erstgespräch mit dem dann aktuellen Stand, weil sie sich häufig ändern.
Das passiert, und eine gute Integration rechnet damit. Drei Mittel: Das Modell bekommt deine eigenen Dokumente als Grundlage und zitiert die Stelle, statt frei zu antworten. Kritische Ausgaben – Preise, Fristen, medizinische Aussagen – laufen durch Regeln oder eine menschliche Freigabe. Und wir messen vor dem Start an konkreten Beispielen, wie oft es danebenliegt, statt es zu vermuten.
Nur das, was du hineinlegst – und das legen wir vorher fest. Ein Beispiel aus einem Support-Assistenten: Der Text der Anfrage geht zum Modell, der Kundenstamm nicht; Namen und Kundennummern werden vorher entfernt, weil das Modell sie für die Antwort nicht braucht. Der Rest ist Vertragssache mit dem Anbieter – siehe den Abschnitt „Datenschutz und Kennzeichnung“ oben.
Wenn Nutzer direkt mit einer KI interagieren – Assistent, Chat – braucht es einen klaren Hinweis darauf; Inhalte, die das Modell erzeugt, bekommen eine maschinenlesbare Markierung. Beides bauen wir mit, es kostet nichts extra. Klassifikation oder Feld-Vorbefüllung im Hintergrund löst die Hinweispflicht in der Regel nicht aus. Was darüber hinaus gilt, hängt vom Einsatzbereich ab und steht unter KI-Beratung → Regeln.
Ja. Die KI-Logik liegt im Backend und wird über eine Schnittstelle angesprochen – die bestehende App braucht dafür nur einen neuen Aufruf und eine Oberfläche für die Funktion. Wir sehen uns vorher den Code oder die Schnittstellen an und sagen dir, ob es sauber geht oder wo es hakt.
Wir melden uns Mo–Fr innerhalb von 24 Stunden mit einer ehrlichen Einschätzung zu Aufwand, Budget und der Frage, dem Vorschlag, womit wir anfangen würden. Die Erstberatung ist kostenlos und unverbindlich.