KI-Integration in Web-Apps: Kostenfaktoren, Budgetplanung und ehrliche Einschätzungen

Kurzantwort: KI-Integration in Web-Apps bezeichnet das Einbinden von KI-Modellen oder APIs in eine Webanwendung. Die Kosten setzen sich aus vier Blöcken zusammen: Entwicklungsaufwand, laufende API-Kosten, Infrastruktur und Wartung. Eine seriöse Zahl ist ohne Projektkontext nicht möglich.

Die Kosten für KI-Integration in einer Web-App – dieser Begriff bezeichnet alle Aufwände, die entstehen, wenn eine Webanwendung um KI-gestützte Funktionen erweitert wird: von der technischen Anbindung einer externen API bis zur Konzeption einer eigenen Retrieval-Architektur. Wer ein realistisches Budget planen will, muss zuerst verstehen, aus welchen Blöcken diese Kosten bestehen – und welche Fragen vor dem ersten Angebot beantwortet sein müssen.

Was KI-Integration in einer Web-App konkret bedeutet

Viele Entscheider denken bei „KI in der Web-App" zuerst an einen Chatbot-Button. Technisch ist das nur ein Sonderfall. KI-Integration reicht von einem einzelnen API-Call bis zu einer vollständigen RAG-Architektur mit eigener Vektordatenbank – und dieser Unterschied hat direkte Auswirkungen auf Aufwand und laufende Kosten.

Zentrale Begriffe, die in Angeboten und Gesprächen relevant sind:

API-Call vs. eigenes Modell: Der wichtigste Unterschied

Der Einstieg in KI-Features erfolgt in den meisten Web-App-Projekten über eine externe API: Text-Request an einen Anbieter, Antwort empfangen, in der Applikation verarbeiten. Das ist technisch überschaubar, wenn der Stack – etwa Next.js mit TypeScript – bereits steht.

Ein eigenes Modell zu trainieren oder zu hosten ist ein anderes Vorhaben: Es erfordert GPU-Infrastruktur, ML-Expertise und einen Datensatz, der groß genug ist, um einen Mehrwert gegenüber einem Basismodell zu rechtfertigen. Für die meisten mittelständischen Web-App-Projekte ist das weder nötig noch wirtschaftlich sinnvoll.

Die Unterscheidung hilft, den Scope realistisch einzugrenzen: „KI-Funktion" (ein Feature, das einen API-Dienst nutzt) vs. „KI-Produkt" (eine Plattform, die ein eigenes Modell betreibt).

Typische KI-Features in produktiven Web-Apps

• Semantische Suche: Nutzer finden Inhalte auch ohne exakten Suchbegriff.
• Zusammenfassung: Lange Dokumente, Reports oder Protokolle werden automatisch verdichtet.
• Empfehlungen: Produkte, Artikel oder nächste Schritte werden kontextbasiert vorgeschlagen.
• Generierung: Textentwürfe, E-Mails oder strukturierte Ausgaben entstehen auf Basis von Nutzereingaben.

Wann RAG sinnvoll ist – und wann nicht

RAG ist sinnvoll, wenn das KI-Feature auf eigene, sich verändernde Daten zugreifen soll – etwa eine interne Wissensdatenbank, Produktkataloge oder Patientendokumente. Ohne RAG kennt das Modell nur, was in seinem Trainingsdatensatz stand.

RAG ist nicht sinnvoll, wenn der Use Case vollständig mit einem generischen Prompt abgedeckt werden kann (z. B. einfache Textzusammenfassung ohne Firmenbezug) oder wenn die Datenmenge zu klein ist, um eine Vektordatenbank zu rechtfertigen. RAG erhöht Komplexität, Infrastrukturkosten und Wartungsaufwand – dieser Mehraufwand muss durch den konkreten Nutzen gedeckt sein.

Die vier Hauptkostenblöcke bei KI-Projekten

Wer ein Budget für KI-Integration plant, braucht kein pauschales Angebot – sondern ein Modell, das die vier Kostenblöcke getrennt ausweist. Nur so lassen sich Angebote vergleichen und Nachträge vermeiden.

1. Einmaliger Entwicklungsaufwand: Was ihn hochtreibt

Der Entwicklungsaufwand ist der größte Einzelposten bei der Erstintegration. Relevante Einflussfaktoren:

Integrationstiefe: Ein neues KI-Feature in eine bestehende Codebasis einzubauen ist aufwändiger als ein Greenfield-Projekt. Bestehende Datenbankstrukturen, Auth-Logik und API-Routen müssen berücksichtigt werden.

Prompt-Entwicklung: Ein funktionierender Prompt für einen produktiven Use Case entsteht nicht in einer Stunde. Iteratives Testen, Edge-Case-Handling und Ausgabe-Validierung kosten Zeit – und diese Zeit taucht in vielen Angeboten nicht explizit auf.

Datenaufbereitung: Wenn eigene Daten in eine Vektordatenbank überführt werden sollen (RAG), müssen diese zunächst bereinigt, strukturiert und eingebettet werden. Je nach Datenqualität ist das ein eigenständiges Teilprojekt.

Fehlerbehandlung und Fallback-Logik: Eine produktive Anwendung braucht definiertes Verhalten, wenn die KI-API nicht antwortet oder unbrauchbare Ergebnisse liefert. Dieser Teil wird in Angeboten regelmäßig unterschätzt.

Stack-Kompatibilität: Die Anbindung einer OpenAI-API an eine Next.js-App mit Supabase-Backend ist ein anderer Aufwand als die Integration in ein Legacy-PHP-System ohne Typisierung.

Weitere Faktoren, die den Aufwand erhöhen: mehrere Modelle parallel, Streaming-Ausgaben, komplexe Prompt-Chains, Nutzerpersonalisierung und Audit-Logging für Datenschutzzwecke.

2. Laufende API-Kosten: Token-Verbrauch verstehen und schätzen

KI-APIs werden typischerweise nach Token abgerechnet – getrennt für Input (Prompt + Kontext) und Output (Modellantwort). Aktuelle Preise variieren je nach Anbieter, Modell und Vertragsvolumen; maßgeblich sind die jeweiligen Pricing-Seiten der Anbieter (z. B. platform.openai.com/pricing oder cloud.google.com/vertex-ai/pricing).

Für die Budgetplanung relevanter als der aktuelle Preis ist das Verständnis der Kostentreiber:

• Kontextlänge: RAG-Architekturen schicken bei jeder Anfrage zusätzliche Dokument-Chunks mit. Das multipliziert den Token-Verbrauch pro Request erheblich.
• Anfragevolumen: Wie viele Nutzer, wie oft, mit welcher durchschnittlichen Eingabelänge?
• Modellwahl: Leistungsfähigere Modelle kosten pro Token mehr. Für viele Anwendungsfälle reicht ein kleineres Modell aus.
• Caching: Identische oder ähnliche Prompts können gecacht werden, um redundante API-Calls zu vermeiden.

Beispiel (fiktive Werte – aktuelle Preise beim jeweiligen Anbieter prüfen): Eine App mit 1.000 Anfragen pro Tag, je 500 Token Input und 200 Token Output, ergibt 700.000 Token täglich – hochgerechnet etwa 21 Millionen Token pro Monat. Bei einem angenommenen Preis von 1 € pro Million Token (Mittelklasse-Modell, fiktiver Wert) wären das rund 21 € monatlich; bei 10.000 Anfragen täglich entsprechend das Zehnfache. Dieses Rechenmodell zeigt die Skalierungslogik – nicht reale Marktpreise.

3. Infrastruktur: Hosting, Vektordatenbank, Caching

Ohne RAG-Architektur sind die Infrastrukturkosten überschaubar: Die KI-Logik läuft als Serverless Function (z. B. Next.js API Route auf Vercel), die Datenbank bleibt unverändert.

Mit RAG kommen hinzu:

• Vektordatenbank: Entweder als separate Lösung oder als Erweiterung der bestehenden PostgreSQL-Datenbank via pgvector – letzteres ist bei Supabase direkt verfügbar und spart einen weiteren Dienst.
• Embedding-Kosten: Das Umwandeln von Texten in Vektoren kostet ebenfalls Token, auch wenn dieser Schritt einmalig oder selten erfolgt.
• Caching-Layer: Redis oder vergleichbare Dienste können häufige Anfragen abfangen und API-Kosten reduzieren.

4. Wartung und Modellpflege: Der unterschätzte Posten

KI-Integration endet nicht mit dem Go-Live. Folgende Wartungsaufwände entstehen regelmäßig:

• Prompt-Anpassungen: Wenn das Modell nach einem Anbieter-Update anders reagiert, müssen Prompts überarbeitet werden.
• Modellwechsel: Anbieter stellen Modelle ein oder ändern deren Verhalten. Ein Wechsel auf ein Nachfolgemodell erfordert Retesting aller Prompts und ggf. Anpassungen in der Ausgabeverarbeitung.
• Monitoring: Token-Verbrauch, Fehlerquoten und Antwortqualität müssen beobachtet werden.
• Datenaktualisierung (RAG): Wenn sich die zugrundeliegenden Dokumente ändern, müssen Vektoren neu generiert werden.

Dieser Block fehlt in vielen Erstangeboten vollständig – er sollte explizit im Vertrag adressiert sein.

Kostenfallen, die in Angeboten oft fehlen

Ein Angebot, das nur Entwicklungstage und API-Kosten nennt, ist unvollständig. Die folgenden Punkte sind in der Praxis häufige Quellen für Nachträge – nicht weil Entwickler sie verstecken, sondern weil sie in der Anforderungsphase nicht besprochen wurden.

Prompt-Drift: Wenn Modell-Updates das Verhalten ändern

KI-Modelle werden von ihren Anbietern regelmäßig aktualisiert. Diese Updates können das Verhalten eines Modells auf denselben Prompt hin spürbar verändern – Tonalität, Ausgabestruktur, Länge oder inhaltliche Schwerpunkte. Ein Prompt, der heute zuverlässig strukturierte JSON-Ausgaben liefert, kann nach einem Modell-Update plötzlich abweichende Formate produzieren, die nachgelagerte Verarbeitungslogik brechen.

Dieser Effekt – oft als Prompt-Drift bezeichnet – ist kein Fehler im Code, sondern eine Eigenschaft externer Abhängigkeiten. Er lässt sich durch automatisierte Prompt-Tests und Versionierung abmildern, aber nicht vollständig eliminieren. Der Aufwand für diese Tests gehört in jedes seriöse Angebot. Wenn er fehlt, ist er ein Nachtrag.

Prüfen Sie beim Anbieter: Welche Modellversion wird genutzt? Gibt es eine Option, auf einer bestimmten Version zu bleiben (Pinned Model Version)? Wie wird mit Breaking Changes umgegangen?

DSGVO-Prüfung als Nachgedanke – und warum das teuer wird

Wenn Nutzerdaten – auch nur Texteingaben – an eine externe KI-API gesendet werden, verlassen diese Daten unter Umständen den EU-Rechtsraum. Ob das zulässig ist, hängt von der Art der Daten, dem Vertragsverhältnis mit dem Anbieter (insbesondere einem Auftragsverarbeitungsvertrag, AVV) und dem konkreten Verarbeitungszweck ab.

Diese Prüfung ist kein Entwicklungsthema, sondern ein rechtliches – aber sie hat direkte technische Konsequenzen: Manche Anbieter bieten EU-Hosting oder Datenschutzoptionen an, die andere Modelle oder veränderte Kostenstrukturen bedeuten. Wird die Datenschutzfrage erst nach der Entwicklung gestellt, kann das zu einer vollständigen Umarchitektur führen.

Empfehlung: Klären Sie vor Projektstart, welche Daten die KI-Funktion verarbeitet, und lassen Sie die datenschutzrechtliche Einordnung von einem qualifizierten Datenschutzbeauftragten oder Anwalt prüfen – nicht vom Entwickler. Der Entwickler kann die technischen Optionen (EU-Endpunkte, Anonymisierung, On-Premise-Modelle) umsetzen, aber nicht die rechtliche Bewertung vornehmen.

Fehlende Fallback-Logik als Stabilitätsrisiko

Externe KI-APIs haben – wie jeder externe Dienst – Ausfallzeiten, Rate Limits und gelegentlich unbrauchbare Antworten. Eine Web-App ohne Fallback-Logik zeigt dem Nutzer in diesen Momenten entweder einen Fehler oder produziert stille Fehler, die schwer zu debuggen sind.

Fallback-Logik bedeutet: Was passiert, wenn die API nicht antwortet? Gibt es eine Retry-Logik? Wird auf ein Backup-Modell ausgewichen? Wird dem Nutzer ein sinnvoller Hinweis angezeigt? Wird der Fehler geloggt?

Dieser Teil kostet Entwicklungszeit und taucht in Schnellangeboten selten auf – ist aber entscheidend für die Produktionsstabilität, besonders wenn das KI-Feature ein zentraler Bestandteil des Workflows ist.

Festpreis vs. Time & Material bei KI-Projekten

KI-Projekte haben eine explorative Phase, die andere Software-Projekte oft nicht haben: Ob ein Prompt die gewünschten Ergebnisse liefert, ob RAG den erhofften Mehrwert bringt, ob das gewählte Modell für den Use Case geeignet ist – das lässt sich vor Projektstart nicht mit Sicherheit sagen. Das stellt klassische Festpreismodelle vor eine Herausforderung.

Wann ein Festpreis bei KI realistisch ist

Ein Festpreis ist realistisch, wenn der Scope klar definiert ist. Beispiel: „Zusammenfassung von Kundenfeedback via OpenAI API, Ausgabe als strukturiertes JSON, Integration in bestehendes Next.js-Dashboard." Voraussetzung: Der Use Case ist beschrieben, die Datengrundlage ist bekannt, und die technische Umgebung ist dokumentiert.

Ein Festpreis ist unrealistisch, wenn das Projektziel lautet: „Wir wollen irgendwie KI einsetzen, mal sehen was funktioniert." Solche Projekte brauchen eine explorative Phase – und die gehört nicht in einen Festpreis.

Warum ein Proof of Concept das Gesamtbudget schützt

Ein Proof of Concept (PoC) ist ein zeitlich und scopemäßig begrenztes Teilprojekt, das eine zentrale Annahme testet: Funktioniert das KI-Feature so, wie es sich der Auftraggeber vorstellt? Liefert das Modell brauchbare Ausgaben? Ist die Latenz akzeptabel?

Ein PoC kostet einen Bruchteil der Vollintegration – und macht Fehlentscheidungen früh sichtbar, bevor sie teuer werden. Wer direkt mit der Vollintegration startet, riskiert, nach mehreren Monaten festzustellen, dass der gewählte Ansatz nicht funktioniert.

Für mittelständische Projekte und Praxen ist ein PoC als erste Projektphase – mit eigenem Festpreis und definierten Abnahmekriterien – in den meisten Fällen die wirtschaftlich sinnvollere Entscheidung.

Hybridmodell: Pilot fest, Ausbau iterativ

Das pragmatischste Modell für KI-Projekte kombiniert beide Ansätze: Die Pilotphase (PoC oder MVP mit einem KI-Feature) wird als Festpreis vereinbart. Nach Abnahme und Auswertung wird der weitere Ausbau iterativ und nach Aufwand abgerechnet – mit klar definierten Sprint-Budgets oder monatlichen Kontingenten. (iterativen und nach Aufwand abgerechnet)

Dieses Modell gibt Auftraggebern Budgetsicherheit für die kritische erste Phase und Entwicklern den nötigen Spielraum für die explorativen Folgeschritte. Es setzt voraus, dass beide Seiten bereit sind, nach dem PoC offen über Ergebnisse und Anpassungen zu sprechen – was ein weiteres Argument für direkten Entwicklerkontakt ohne Agentur-Zwischenschicht ist.

10 Fragen, die Sie vor jedem KI-Angebot klären sollten

Bevor Sie ein Angebot einholen, sollten Sie diese zehn Fragen intern beantworten können. Jede unbeantwortete Frage ist eine potenzielle Nachtragquelle.

Fragen zur Use-Case-Klarheit und Datengrundlage

Fragen zu Volumen, Datenschutz und Integrationstiefe

Fragen zu Wartung, Fallback und Erfolgsmessung

Hinweis zur Verwendung: Dieses Framework ist unabhängig vom gewählten KI-Anbieter und Stack nutzbar. Beantworten Sie die Fragen schriftlich, bevor Sie Entwickler oder Agenturen kontaktieren. Ein Entwickler, der diese Fragen nicht stellt, wird sie später als Nachtrag stellen.

Wie ein realistisches KI-Angebot aussieht – und woran Sie es erkennen

Ein Angebot für KI-Integration ist kein Angebot für Standard-Webentwicklung. Es sollte die spezifischen Unsicherheiten und Kostenblöcke von KI-Projekten explizit adressieren – nicht in einem Pauschalpreis verstecken.

Merkmale eines transparenten Angebots

Ein seriöses Angebot für KI-Entwicklung enthält:

• Aufschlüsselung nach den vier Kostenblöcken: Entwicklung, API-Kosten (als Schätzbereich mit Annahmen), Infrastruktur, Wartung – getrennt ausgewiesen.
• Explizite Annahmen: „Dieses Angebot basiert auf X Anfragen pro Monat, Y Token pro Request und dem Modell Z." Wenn sich diese Annahmen ändern, ändert sich der Preis – das sollte im Angebot stehen.
• Definierte Leistungsgrenzen: Was ist nicht im Scope? Datenaufbereitung, Datenschutzberatung, Monitoring-Setup – wenn diese Punkte nicht erwähnt werden, sind sie entweder nicht enthalten oder werden später nachberechnet.
• Pilotphase als Option: Ein gutes Angebot bietet einen PoC als eigenständige erste Phase an, mit definierten Abnahmekriterien.
• Dokumentation und Übergabe: Wie wird das Projekt dokumentiert? Gibt es ein Übergabedokument für internes Personal oder Folgeentwickler? (Übergabedokument für internes Personal)

Red Flags: Was in schlechten Angeboten fehlt

• Pauschalpreis ohne Aufschlüsselung der Kostenblöcke
• Keine Erwähnung von laufenden API-Kosten oder Wartung
• Kein Wort zu Datenschutz bei der Verarbeitung von Nutzerdaten
• Keine Fallback-Logik im Scope
• Keine Annahmen zu Nutzungsvolumen
• Kein Angebot einer Pilotphase

Dokumentation und Übergabe als Kostenfaktor

Dokumentation ist kein Bonus – sie ist ein eigenständiger Arbeitsaufwand und sollte im Angebot erscheinen. Eine gut dokumentierte KI-Integration ermöglicht es internem Personal oder einem Folgeentwickler, Prompts anzupassen, Modellversionen zu wechseln und Monitoring-Alerts zu interpretieren. Fehlt die Dokumentation, entsteht eine Abhängigkeit vom ursprünglichen Entwickler – was langfristig teurer ist als der einmalige Dokumentationsaufwand.

Ein strukturiertes Übergabedokument gehört zum Standard: Stack-Übersicht, API-Konfiguration, Prompt-Versionierung und Monitoring-Setup – damit Auftraggeber nach dem Projekt handlungsfähig bleiben, nicht abhängig.

FAQ

Kann ich KI-Kosten pauschal pro Feature angeben?

Nein – zumindest nicht ohne Kontext. Die Kosten hängen von Integrationstiefe, Nutzungsvolumen, gewähltem Modell und Wartungsaufwand ab. Sinnvoller als eine Pauschale ist eine Aufschlüsselung nach den vier Kostenblöcken (Entwicklung, API, Infrastruktur, Wartung) mit expliziten Annahmen. Ohne diese Annahmen ist jede Zahl eine Schätzung ohne Aussagekraft.

Welche laufenden Kosten entstehen nach der Entwicklung?

Typischerweise: API-Kosten (token-basiert, je nach Nutzungsvolumen), Infrastrukturkosten (Hosting, ggf. Vektordatenbank) und Wartungsaufwand für Prompt-Anpassungen und Modellpflege. Wie hoch diese Kosten konkret sind, hängt vom Volumen und vom gewählten Anbieter ab – aktuelle Preise direkt auf den Pricing-Seiten der Anbieter prüfen.

Muss ich ein eigenes KI-Modell trainieren?

In den meisten Fällen nein. Für produktive Web-App-Features reicht die Anbindung einer externen API (z. B. OpenAI, Anthropic, Google Gemini) aus. Ein eigenes Modell zu trainieren oder zu hosten ist aufwändig und erfordert ML-Expertise. Sinnvoll ist es nur, wenn spezifische Anforderungen – Datenschutz, Domänenwissen, Latenz – durch keine externe API erfüllt werden können.

Was ist bei DSGVO und KI-APIs zu beachten?

Wenn Nutzerdaten an externe KI-APIs gesendet werden, verlassen diese Daten möglicherweise den EU-Rechtsraum. Relevant sind: Art der Daten (personenbezogen, besondere Kategorien), Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter und ob EU-Hosting-Optionen verfügbar sind. Die rechtliche Einordnung sollte ein qualifizierter Datenschutzbeauftragter oder Anwalt vornehmen – nicht der Entwickler.

Was kostet ein Proof of Concept für ein KI-Feature?

Das hängt vom Use Case ab. Ein PoC ist per Definition begrenzt: Er testet eine zentrale Annahme mit minimalem Scope und ist deutlich günstiger als die Vollintegration. Konkrete Zahlen sind ohne Projektbeschreibung nicht seriös; nach einem kostenlosen Erstgespräch lässt sich eine fundierte Einschätzung geben.

Wie vergleiche ich Angebote verschiedener Entwickler?

Prüfen Sie: Sind die vier Kostenblöcke getrennt ausgewiesen? Sind Annahmen zu Volumen und Modell explizit? Ist Wartung adressiert? Gibt es eine Pilotphase als Option? Ist Datenschutz erwähnt? Angebote ohne diese Punkte sind schwer vergleichbar – und bergen das Risiko versteckter Nachträge. Der Fragenkatalog aus diesem Artikel eignet sich direkt als Grundlage für das Briefing.