KI-Assistent-App entwickeln: Funktionen, Architektur und Kosten

Eine Aufgabe ist kalkulierbar, eine Vision nicht

Die erste Vorführung hat schnell einen gewissen Zauber. Eine Frage erscheint, die Antwort klingt klug, und plötzlich wirkt der persönliche Assistent beinahe marktreif. Am nächsten Dienstag sieht die Welt nüchterner aus: Zwei Kalender widersprechen sich, ein Termin wurde verschoben und niemand hat festgelegt, ob „verschieben“ nur einen Vorschlag oder bereits sechs Benachrichtigungen auslösen soll.

An diesem Punkt wird aus einem Chat ein Produkt. Es muss die richtige Person und Datenquelle erkennen, Erinnerungen begrenzen, Einwilligungen einholen und einen halb ausgeführten Vorgang wieder verständlich machen. Nach unserer Erfahrung steckt in diesen unscheinbaren Regeln mehr Arbeit als in der Oberfläche, die bei einer Präsentation die meiste Aufmerksamkeit erhält.

Damit erklärt sich auch die große Spannweite. Eine Zusammenfassung aus eingefügtem Text bleibt überschaubar. Kalender prüfen, einen Termin anlegen und eine Vorliebe für später behalten bedeutet Konten, Rechte, Zustände und Fehlerbehandlung. In der Demo liegen beide Varianten nah beieinander; im Verantwortungsumfang trennen sie Welten.

Der Beitrag grenzt den persönlichen Assistenten bewusst von einer allgemeinen KI-Funktion ab. Einen breiteren Überblick gibt unser Artikel zu den Kosten einer App mit KI. Mögliche Anwendungsfälle finden Sie unter KI-Funktionen in mobilen Apps.

„Der Assistent organisiert den Alltag“ klingt als Vision gut, lässt ein Team bei der Umsetzung aber allein. Belastbar wäre: Der Nutzer spricht eine Notiz ein, die Anwendung erkennt den Terminwunsch, liest freie Zeiten und zeigt drei Vorschläge. Erst nach der Auswahl wird der Termin angelegt. Die kleinere Formulierung ist nicht weniger ambitioniert; sie lässt sich nur endlich ehrlich überprüfen.

Weitere brauchbare Startaufgaben sind Antworten aus freigegebenen Kursunterlagen, die Vorbereitung einer Kundenantwort mit aktuellem Bestellstatus oder eine Einkaufsliste aus gespeicherten Vorlieben. In jedem Fall muss feststehen, welche Eingabe erwartet wird, welche Quelle maßgeblich ist und woran ein korrektes Ergebnis zu erkennen ist.

Die wichtigste Grenze klingt banal: Vorschlag oder Ausführung? Einen Entwurf zu erzeugen ist etwas anderes, als eine Nachricht zu versenden. Wir würden die letzte Freigabe im MVP meist beim Nutzer lassen, bis reale Fehlerbilder bekannt sind. Das bremst den Nutzen kaum, verhindert aber, dass das Team Autonomie verspricht, deren Folgen es noch nicht beherrscht.

Drei Ausbaustufen für die Planung

Die mittlere Stufe ist für viele Produkte ein sinnvoller Ausgangspunkt. Der Assistent kann personalisierte Vorschläge auf Basis aktueller Daten machen, während folgenreiche Änderungen sichtbar bestätigt werden. Damit entsteht Nutzen, ohne unkontrollierte Autonomie zu versprechen.

Die Architektur hinter dem Gespräch

Ein belastbares System trennt mehrere Aufgaben. Das Modell deutet die Anfrage. Der Server prüft die Identität und die Rechte. Eine Gedächtniskomponente stellt ausgewählte Präferenzen bereit. Schnittstellen lesen oder verändern andere Systeme. Protokollierung und Messung zeigen, was passiert ist, wie lange es dauerte und welche Kosten entstanden.

Geschäftsregeln gehören nicht ausschließlich in eine Anweisung an das Modell. Das Modell darf beispielsweise vorschlagen, den Kalender aufzurufen. Vertrauenswürdiger Programmcode prüft aber Benutzerkonto, Berechtigung, Eingabedaten und notwendige Bestätigung, bevor die Aktion ausgeführt wird.

Auch Zugangsschlüssel von Modellanbietern oder Fremdsystemen gehören nicht in die installierte App. Eine Serverkomponente schützt die Schlüssel, begrenzt die Nutzung und entfernt Daten, die für die Anfrage nicht erforderlich sind. Mehr zu diesem Aufwand steht im Leitfaden zu Kosten von API-Schnittstellen in mobilen Apps.

Gedächtnis braucht Herkunft, Ablaufdatum und Löschung

Ein persönlicher Assistent wird nützlich, wenn er nicht bei jeder Sitzung von vorn beginnt. Er kann sich an die bevorzugte Besprechungsdauer, eine Ernährungsform oder die gewünschte Struktur eines Wochenberichts erinnern. Gleichzeitig darf aus einem beiläufigen Satz nicht unbemerkt ein dauerhaftes Profilmerkmal werden.

Deshalb sollte das Produkt zwischen dem Kontext der aktuellen Unterhaltung, ausdrücklich gespeicherten Präferenzen, live abgerufenen Geschäftsdaten und dem Zwischenstand einer laufenden Aufgabe unterscheiden. Für jede Kategorie braucht es Regeln zur Speicherung, Korrektur, Gültigkeit und Löschung.

Eine Seite „Was der Assistent über mich gespeichert hat“ schafft Kontrolle. Nutzer sollten dort Einträge berichtigen und löschen können. Antworten aus Kursen, Dokumenten oder Bestellungen sollten ihre Quelle erkennen lassen. So bleibt nachvollziehbar, ob die Aussage aus einem aktuellen Datensatz oder aus einer gespeicherten Präferenz stammt.

Der Google-Kurs zu zustandsbehafteten, personalisierten Agenten zeigt Gedächtnis als mehrere Ebenen statt als endloses Chatprotokoll. Microsoft beschreibt in Guarding AI memory, weshalb langfristig gespeicherter Kontext auch eine eigene Sicherheitsgrenze bildet.

Für jede Schnittstelle gelten vier Regeln

Bei Kalender, E-Mail, Warenkorb, Buchungssystem oder CRM sollte vor der Umsetzung feststehen: Was darf der Assistent lesen? Was darf er vorschlagen? Was darf er selbst ausführen? Was muss ein Mensch bestätigen?

Danach folgt der Fehlerfall. Ein Fremdsystem kann langsam sein, veraltete Daten liefern oder eine Aktion erfolgreich ausführen, obwohl die App wegen einer Zeitüberschreitung bereits einen Fehler zeigt. Jede schreibende Aktion braucht deshalb eine eindeutige Kennung, einen überprüfbaren Status und möglichst eine Rücknahme oder einen verständlichen Reparaturweg.

OWASP nennt in seiner Übersicht zu Risiken generativer Anwendungen unter anderem Prompt Injection, Offenlegung sensibler Informationen, übermäßige Handlungsbefugnis und unbegrenzten Verbrauch. Für ein Produkt bedeutet das: Inhalte aus dem Internet erhalten keine Berechtigung, Modellausgaben werden vor der Weitergabe geprüft, und Konten bekommen klare Nutzungslimits.

Zahlungen, öffentliche Veröffentlichungen, Zugriffsrechte und Kontoveränderungen sollten im MVP nicht still ausgeführt werden. Eine sichtbare Zusammenfassung mit Bestätigung ist meist die bessere Erfahrung.

Sprache und proaktive Hinweise sind eigene Funktionen

Spracheingabe erfordert mehr als eine Mikrofontaste. Aufnahme, Transkription, Unterbrechung, Wiedergabe, Berechtigungszustände und Korrektur müssen gestaltet werden. Tests sollten Nebengeräusche, Dialekte, Pausen und eine schlechte Verbindung berücksichtigen. Zusätzlich steigen Latenz und Verbrauch, weil mehr Dienste an einer Aufgabe beteiligt sind.

Auch proaktive Unterstützung vergrößert den Umfang. Eine vom Nutzer eingestellte Erinnerung ist eindeutig. Ein Assistent, der selbst entscheidet, wann er sich meldet, benötigt Ruhezeiten, Häufigkeitsgrenzen, Relevanzregeln und Feedback nach einer abgelehnten Benachrichtigung. Für den Anfang eignen sich feste Ereignisse wie ein nahender Termin oder eine fehlgeschlagene Zahlung.

Wenn Sprache den Kern des Produkts bildet, sollte bereits der Prototyp mit realistischer Wartezeit und fehlerhaften Erkennungen getestet werden. Ein schneller Textchat belegt noch keine gute Sprachbedienung.

Mit welchen Kosten ist zu rechnen?

Appfyl schätzt ein umgesetztes Gesamtprodukt anhand des Verhaltens, der Daten, der Schnittstellen und der notwendigen Kontrollen statt anhand einer allgemeinen Marktspanne.

Ein Assistent bleibt vergleichsweise fokussiert, wenn er eine Aufgabe löst, ein vorhandenes Modell nutzt, nur wenige Daten abruft und keine riskanten Aktionen ausführt. Dauerhafte Personalisierung, mehrere Benutzerrollen, Sprache, Abonnements, ein Administrationsbereich und mehrere Fremdsysteme erhöhen den Aufwand deutlich. Sensible Daten, zahlreiche Werkzeuge, komplexe Freigaben oder ein eigenes Modell machen das Produkt noch umfangreicher.

Neben Entwicklung und Produkteinführung entstehen laufende Ausgaben für Modellaufrufe, Hosting, Suche, Sprache, Speicher und Überwachung. Sie sollten mit nachvollziehbaren Nutzungsannahmen separat geplant und später anhand echter Daten aktualisiert werden.

Laufende Kosten aus echter Nutzung ableiten

Die Rechnung beginnt mit aktiven Assistentennutzern, Aufgaben pro Nutzer, Modellaufrufen pro Aufgabe und durchschnittlichen Kosten pro Aufruf. Hinzu kommen Sprachverarbeitung, Suche, Dokumentenspeicher, Hosting, Protokolle und kostenpflichtige Schnittstellen.

Monatskosten = aktive Nutzer x Aufgaben x Aufrufe je Aufgabe x Durchschnittskosten je Aufruf

Ein niedriger, erwarteter und hoher Fall macht die Unsicherheit sichtbar. Auch fehlgeschlagene Abläufe gehören hinein. Ein Assistent kann bei einer unklaren Anfrage mehrere Modellaufrufe und Schnittstellenversuche auslösen, bevor er an den Support verweist.

Von Anfang an sinnvoll sind Grenzen pro Konto, maximale Kontextlänge, eine Höchstzahl von Werkzeugschritten und Warnungen bei ungewöhnlichem Verbrauch. Ein günstigeres Modell kann einfache Klassifikationen übernehmen, während ein leistungsfähigeres Modell nur bei begründeten Aufgaben eingesetzt wird.

So sieht ein überprüfbarer MVP aus

Das Team sammelt zunächst zwanzig bis fünfzig echte Anfragen. Zu jeder Anfrage werden erlaubte Daten, gewünschtes Ergebnis, unzulässiges Ergebnis und Freigabepunkt notiert. Diese Sammlung wird zur Prüfbasis und wächst nach dem Start um reale Fehlerfälle.

Anschließend wird nur die Datenquelle angeschlossen, die für die erste Aufgabe notwendig ist. Ein Lernassistent beantwortet Fragen aus freigegebenen Lektionen und öffnet die passende Stelle. Ein Terminassistent findet freie Zeiten und bereitet den Eintrag vor. Zusätzliche Werkzeuge kommen erst hinzu, wenn der Nutzen messbar ist.

Gemessen werden angenommene Vorschläge, Korrekturen, abgeschlossene Aktionen, Rücknahmen und Übergaben an Menschen. Eine hohe Zahl von Nachrichten allein sagt wenig darüber aus, ob die Funktion Zeit spart.

Automatisierungsplattformen können einen Prototyp beschleunigen. Rechte, Protokolle, Limits und Fehlerbehandlung bleiben trotzdem erforderlich. Anthropic empfiehlt in Building effective agents, mit dem einfachsten verlässlichen Muster zu beginnen und vorhersehbare Abläufe von offenen Agenten zu unterscheiden. Für einen MVP ist das eine vernünftige Produktregel.

Datenschutz und Vertrauen nicht nachträglich ergänzen

Ein persönlicher Assistent kann Nachrichten, Sprache, Standort, Kontakte, Dateien und Kontodaten verarbeiten. Für jede Datenart muss klar sein, wozu sie benötigt wird, ob ein Modellanbieter sie erhält, wie lange sie gespeichert bleibt und wie Nutzer sie löschen können. Eine Mikrofonberechtigung rechtfertigt nicht automatisch die dauerhafte Speicherung der Aufnahme.

Die Datenschutzplanung für mobile Apps und die Sicherheitscheckliste für mobile Apps sollten deshalb während der Architekturarbeit geprüft werden. Weniger Daten und engere Rechte sind am Anfang meist günstiger als eine Korrektur kurz vor Veröffentlichung.

Vertrauen entsteht auch durch klare Zustände. Die App sollte anzeigen, ob etwas nur vorgeschlagen oder bereits ausgeführt wurde. Bei kontobezogenen Antworten sollte die Quelle erkennbar sein. Kann der Assistent das Ergebnis nicht prüfen, braucht der Nutzer einen normalen Weg über Suche, Formular oder Support.

So kalkuliert Appfyl einen KI-Assistenten

Appfyl beginnt mit einer Aufgabe, den erlaubten Daten und der Folge eines Fehlers. Die Schätzung trennt mobile Oberfläche, Serverablauf, Gedächtnis, Datenquellen, Schnittstellen, Freigaben, Prüfung, Analyse und laufende Dienste. Ebenso wichtig ist die Liste der Handlungen, die der Assistent im MVP ausdrücklich nicht ausführen darf.

Beschreiben Sie diese Grenze im Appfyl-Schätzwerkzeug. Eine konkrete Aufgabe, eine Datenquelle und ein gewünschter nächster Schritt reichen für ein erstes Gespräch deutlich besser aus als der Wunsch nach einem „Assistenten für alles“.

Sehen Sie, wie Appfyl Funktionsumfang in veröffentlichte Produkte übersetzt. Appfyl Cases ansehen.

Häufige Fragen