Wir haben unserer Datenbank ein Chatfenster gegeben. Seitdem habe ich keinen Entwickler mehr nach einem Report gefragt.

Der teuerste Teil der Produktanalytik war nie das Tooling. Es war, jedes Mal einen Entwickler zu unterbrechen, wenn ich eine Zahl brauchte.

An einem Dienstag im August habe ich eine Frage in ein neues Chatfenster in unserem internen Admin-Dashboard getippt: Wie viele Nutzer, die den Studio-Modus ausprobiert haben, haben am Ende ein Item gespeichert? Der Agent überlegte, was er abfragen muss, prüfte, wie unsere Daten strukturiert sind, und führte seine Read-only-Queries aus. Zwanzig Sekunden später hatte ich die Antwort als Diagramm, plus ein paar vorgeschlagene Anschlussfragen. Für diesen Report wurde kein Entwickler unterbrochen.

Was sich in unserem Arbeitsalltag geändert hat

Ich bin Produktmanager bei LI Solutions. Wir betreiben Shop Minis, vier KI-Shopping-Apps in Shopifys Shop app, und dieses Chatfenster hat uns einen Datenanalysten gegeben, der rund um die Uhr auf Abruf ist.

Bevor wir es gebaut haben, hieß jede Zahl: einen Entwickler fragen. Rund zwanzig Minuten Kontextwechsel auf seiner Seite, eine Stunde bis ein Tag Warten auf meiner. Diese Reibung hat mich darauf trainiert, keine kleinen Fragen mehr zu stellen. Ich habe nur noch nach Daten gefragt, wenn ich einen großen Vorschlag verteidigen musste.

Heute stelle ich vielleicht zehnmal mehr Fragen als im Frühjahr. Manche führen ins Leere und sind bis mittags vergessen. Ein paar wurden zu echten Roadmap-Punkten, die ich in keinem Quartalsreport gefunden hätte. Die monatliche Modellrechnung für all das ist ein Mittagessen.

Sicherheit war die erste Sorge, als wir einen Agenten mit einer Produktionsdatenbank verbunden haben. Der Agent kann physisch nichts verändern: Sein Zugriff ist read-only, und jede Query wird vor der Ausführung geprüft. Das Schlimmste, was eine schlechte Query anrichten kann, ist eine falsche oder langsame Antwort. Eine falsche Antwort fange ich ab. Eine gelöschte Tabelle nicht.

Dem Agenten unsere Geschäftsregeln mitgeben

Generische Text-to-SQL-Tools werben mit über 85% Genauigkeit auf Benchmarks und fallen auf realen Unternehmensdaten auf 10-20%. Sie scheitern, weil ihnen der Geschäftskontext fehlt: Sie wissen nicht, was im Produkt zählt oder wie Erfolg definiert ist.

Unserem Agenten haben wir genau diesen Kontext mitgegeben. Er kennt das komplette Datenmodell, den Event-Funnel in kanonischer Reihenfolge und die Geschäftsregeln. In den Favoriten speichern ist die eigentliche Conversion, und Save-Raten zählen mehr als rohe Zahlen. Dieses Wissen lebt beim Code. Ändern die Entwickler, was die Apps aufzeichnen, wandert das Bild des Agenten von der Realität mit, Eigenheiten und Sonderfälle inklusive.

Die ML-Schicht läuft heute auf denselben Schienen. Ein trainiertes Modell bewertet jede Generierung danach, wie wahrscheinlich sie in einem Save endet, und zeigt, welche Faktoren diese Wahrscheinlichkeit nach oben oder unten schieben. Daneben laufen Projektionen: geschätzte tägliche Nutzung und KI-Kosten pro App, Wochen im Voraus, damit Kapazitäts- und Budgetplanung mit einer Prognosekurve startet statt mit einer Schätzung.

Die Vorhersagen landen im selben Chat-Gespräch. Ich frage, welcher Modus laut Modell mehr Saves bringt, und die Antwort kommt mit seinen Zahlen im Rücken statt mit einem Bauchgefühl. Und die ML-Seite bleibt strikt additiv. Fällt sie aus, merken die Apps, die unsere Nutzer in der Hand haben, nichts davon.

Die Modelle auf eigener Hardware betreiben

Der wichtigste Teil dieser Architektur ist, wo sie lebt. Die ML-Modelle können komplett auf eigener Hardware laufen, und lokale LLMs sind für Analytics-Arbeit inzwischen gut genug. Der ganze Analyst, Agent und Modelle zusammen, kann also in der eigenen Infrastruktur sitzen, und sensible Datensätze verlassen sie nie.

Für uns ist das Praxis, keine Theorie. Wir bauen Healthcare-Produkte unter strengen NDAs, bei denen es schlicht keine Option ist, Nutzungsmuster an eine externe API zu schicken. Dass die Modelle lokal laufen, ist der Grund, warum diese Projekte überhaupt Analytik bekommen. Dieselbe Logik gilt für Fintech und jedes Produkt unter ernsthaften Datenregeln.

Lokale Modelle haben auch weniger dramatische Vorteile. Man weiß, was die eigene Hardware pro Monat kostet, eine Preisänderung des Anbieters kann das Analytics-Budget also nicht sprengen. Ein externer Ausfall kann das Dashboard nicht lahmlegen. Und wenn ein besseres offenes Modell erscheint, aktualisiert man nach eigenem Zeitplan. Die Analytics-Infrastruktur gehört einem selbst.

Ein eigener Analyst hat verändert, wie ich mit meiner Neugier umgehe. Ich schaue nicht mehr, wie beschäftigt das Entwicklungsteam wirkt, bevor ich eine Frage stelle. Ich gehe einem Bauchgefühl sofort nach und lasse es fallen, wenn die Daten Nein sagen.

Wer eine Produktdatenbank und ein internes Dashboard hat, baut das als Feature in ein bis zwei Wochen. Dem Agenten Read-only-Zugriff geben. Das Stammeswissen dort aufschreiben, wo er es sieht, und beim Code halten. Jemand muss allerdings ein paar Tage investieren, um die Geschäftsregeln in Worte zu übersetzen. Bei uns war das ich.