KI in Webprojekten ist 2026 keine Magie mehr — es ist Engineering. Ein API-Call zu OpenAI oder Claude, ein bisschen Glue-Code, vielleicht eine Vektor-Datenbank für RAG. Trotzdem entstehen viele Implementierungen, die nach drei Wochen Pilotbetrieb wieder still abgeschaltet werden. Dieser Artikel beschreibt, was bei uns in der Praxis funktioniert hat — und wo wir gelernt haben, vorsichtig zu sein.
Was wir produktiv einsetzen
Unsere KI-Integrationen drehen sich primär um zwei APIs: OpenAI und Anthropic Claude. Beide sind reif, gut dokumentiert, mit DSGVO-konformen Optionen erreichbar (Azure OpenAI Service oder Anthropic via EU-Endpunkte). Den Hype-Werkzeugkasten — LangChain als Universal-Framework, Pinecone und Weaviate als Vektor-DBs, LlamaIndex als RAG-Layer — nutzen wir nur, wo es einen klaren Engineering-Grund gibt. Sehr oft tut es ein direkter API-Call oder eine einfachere Lösung.
Use-Cases, die in unserer Erfahrung tatsächlich liefern:
- Chat- und Support-Bots, die auf eine kuratierte Wissensbasis zugreifen
- Content-Assistenz im Redaktions-Workflow (Vorschläge, Umformulierungen, Übersetzungen)
- Strukturierte Extraktion aus Dokumenten (PDFs, E-Mails, Verträge → strukturierte Daten)
- Klassifikation und Routing (eingehende Anfragen → Kategorien, Prio, Empfänger)
- Such-Verbesserung durch Embedding-basierte Ähnlichkeitssuche
Wo Vorsicht angesagt ist
Es gibt einen Unterschied zwischen "demo-tauglich" und "produktionsreif". Im Demo-Modus klappt fast alles. In Production scheitern KI-Features oft an Halluzinationen, Latenz, Kosten oder fehlender Fehlerbehandlung.
Typische Fallen:
- Halluzinationen: das Modell erfindet Fakten — bei rechtlich oder fachlich kritischen Antworten ein Showstopper ohne klare Quellen-Verankerung (z. B. via RAG mit Zitaten)
- Latenz: Streaming hilft, aber komplexe Prompts und große Context-Windows werden schnell zu langsamen Interaktionen
- Kosten: bei nicht-trivialen Apps mit hohem Volumen sind die Token-Kosten oft die größte einzelne Betriebsausgabe
- Prompt-Drift: kleine Modell-Updates ändern Outputs subtil — ohne Versionierung und Tests merkt man das spät
- Datenschutz: User-Eingaben an externe APIs ohne klare Vereinbarung sind ein DSGVO-Risiko
RAG ist nützlich — aber kein Selbstzweck
Retrieval-Augmented Generation (RAG) — die Idee, einem LLM relevante Snippets aus eigenen Daten mit dem Prompt mitzugeben — ist berechtigt, wo das Modell auf Fakten zugreifen muss, die nicht in seinen Trainingsdaten stehen. Aber RAG ist nicht "die Lösung für alles".
Wann RAG Sinn macht:
- Wissensbasen mit relativ stabilen Inhalten (Produktinfos, Dokumentationen, FAQ-Bestände)
- Anforderungen an nachvollziehbare Quellen (das Modell soll zitieren können)
- Sehr große Wissensmengen, die das Kontextfenster sprengen würden
Wann es zu viel ist:
- Kleine, statische Wissensbasen — die passen oft komplett in den Prompt als System-Kontext
- Dynamische Daten — eine direkte Datenbank-Abfrage ist schneller, billiger und korrekter als Embeddings
- Wenn der eigentliche Schmerz im Prompting liegt, nicht in der Wissensbasis
Faustregel: Wir starten ohne RAG. Wenn der Prompt-Only-Ansatz an Kontextgröße oder Aktualität scheitert, kommt RAG dazu — selten umgekehrt.
Architektur einer KI-Integration: was wir typisch bauen
Bei einem Chatbot oder einem KI-gestützten Feature in einer Web-App sieht unsere typische Architektur so aus:
Standard-Bausteine:
- Frontend (Next.js, Nuxt oder SvelteKit) mit Streaming-Antworten via Server-Sent Events
- Server-seitiger API-Layer (Next.js API-Route, Nuxt Server-Route oder SvelteKit Endpoint) — der direkte LLM-API-Call passiert nie im Browser
- Eingabe-Validierung und Rate-Limiting auf dem Server
- System-Prompt-Versionierung (Prompts liegen im Code, nicht hartcodiert in der UI)
- Optional: Embedding-Layer für Suche/RAG, oft mit Postgres-pgvector statt eigener Vektor-DB
- Logging der Anfragen für Auswertung — pseudonymisiert, mit Aufbewahrungsfristen
Kosten: realistisch kalkulieren
Bei kleineren Bots mit ein paar tausend Konversationen im Monat liegen die API-Kosten oft bei 30–150 € — überschaubar. Bei einem viel genutzten Feature in einer Endkunden-Webapp kann das schnell vier- bis fünfstellig werden, vor allem mit großen Modellen und langen Kontexten.
Hebel zur Kostenkontrolle:
- Modell-Auswahl: das günstigere Modell ist oft "gut genug" für 70–80 % der Anfragen
- Kontext-Disziplin: nur das mitgeben, was wirklich gebraucht wird
- Prompt-Caching, wenn API-seitig unterstützt (signifikante Kostensenkung bei langen System-Prompts)
- Antwort-Caching für deterministische Anfragen
- Klare Rate-Limits pro Nutzer/IP — auch um Missbrauch zu verhindern
Datenschutz und DSGVO
Wer personenbezogene Daten in einen LLM-Call gibt, ist in DSGVO-Land. Wir empfehlen drei Maßnahmen: erstens, Daten vor dem Versand minimieren oder pseudonymisieren; zweitens, EU-konforme Endpunkte (Azure OpenAI, Anthropic EU-Hosting) wenn möglich; drittens, klare Auftragsverarbeitungsverträge (AVV) mit dem Anbieter. Bei sensiblen Daten (Gesundheit, Finanzdaten) prüfen wir gemeinsam mit dem Datenschutzbeauftragten des Kunden, ob die LLM-API der richtige Weg ist — oder ob ein selbst gehostetes Open-Source-Modell die bessere Option ist.
Implementierungsstrategie
Unser typischer Ablauf für KI-Features:
- Use-Case klar definieren — was soll das Feature konkret leisten? Welche Inputs, welche Outputs?
- Datenfluss prüfen — was sind die Quellen? Sind sie für RAG geeignet oder reicht ein Prompt?
- Kleinster sinnvoller Prototyp — meist ein einfacher API-Call in einem Server-Endpoint, kein Framework
- Mit echten Test-Inputs evaluieren — nicht mit dem "Demo-Beispiel", sondern mit echten Kunden-Anfragen
- Schrittweise Härtung: Validierung, Rate-Limits, Logging, Tests gegen Halluzinationen
- Go-Live mit klarem Monitoring — und einem Plan B, wenn die API mal ausfällt
Fazit: Engineering schlägt Hype
KI macht in Web-Projekten genau dort Sinn, wo sie ein konkretes Problem löst, das anders schwerer zu lösen wäre — und wo die Architektur stabil genug ist, dass das Feature auch in Production funktioniert. Wer KI als Engineering-Aufgabe begreift, nicht als Hype-Spielwiese, baut Features, die ihren Platz im Produkt verdienen und behalten.