LLM- und RAG-Agentur Berlin auswählen: Scope, Sicherheit und Abnahme

Kurzurteil: Wählen Sie keine LLM- oder RAG-Agentur nach einer Liste bekannter Frameworks aus. Klären Sie zuerst, ob Sie öffentliche Website-Inhalte retrieval-fähiger machen, einen internen Wissensassistenten pilotieren oder eine produktive Anwendung betreiben wollen. Diese drei Aufträge unterscheiden sich bei Datenzugriff, Engineering, Sicherheit, Evaluation und Haftung deutlich. Scope vor Stack.

Der Begriff „RAG-Agentur“ wird für sehr verschiedene Leistungen verwendet. Manchmal geht es um bessere öffentliche Inhalte für Suchmaschinen und generative Antwortsysteme. Manchmal soll eine interne Suche über Handbücher entstehen. In anderen Fällen ist ein geschäftskritischer Assistent mit Nutzerrechten, CRM-Anbindung und laufendem Betrieb gemeint. Wer diese Aufgaben in einem Angebot vermischt, kann Preis, Risiko und Ergebnis nicht sinnvoll vergleichen.

Diese Seite ist deshalb kein weiterer allgemeiner RAG-Erklärtext. Sie ist eine Entscheidungshilfe für Einkauf, Marketing, Produkt, IT und Informationssicherheit. Mit der LLM-/RAG-Scope-Scorecard als CSV können Sie Anforderungen, Nachweise, Verantwortliche und Abnahmekriterien vor einem Anbietertermin festhalten.

Die wichtigste Grenze: Website-Readiness ist kein RAG-Build

Unsere RAG-Optimierung für Websites betrifft primär den öffentlichen Informationslayer: crawlbare Seiten, eindeutige Entitäten, konsistente Leistungs- und Produktdaten, belastbare Quellen, interne Verlinkung, strukturierte Daten und messbare Zielseiten. Diese Arbeit kann die Voraussetzungen für klassisches Suchen und für Retrieval verbessern. Sie konfiguriert aber keinen fremden Suchindex und baut nicht automatisch eine interne KI-Anwendung.

Ein interner RAG-Build braucht zusätzliche Bausteine: Datenkonnektoren, Dokumentverarbeitung, Zugriffsrechte, Suchindex oder Vector Store, Retrieval- und Rankinglogik, Modellanbindung, Antwortregeln, Evaluation, Protokollierung, Sicherheit, Schnittstellen und Betrieb. Diese Leistungen werden nur als separat definierter Engineering-Scope angeboten oder gemeinsam mit einem zuständigen Technikpartner abgegrenzt.

Was RAG tatsächlich leistet – und was nicht

Das ursprüngliche RAG-Paper von Lewis et al. beschreibt die Verbindung parametrischen Modellwissens mit einer abrufbaren, nicht-parametrischen Wissensquelle. Vereinfacht: Vor der Antwort sucht das System passende Inhalte und gibt sie dem Sprachmodell als Kontext. Schon die Forschung benennt Provenienz und die Aktualisierung von Wissen als offene Herausforderungen.

RAG kann Antworten besser mit einem kontrollierten Datenbestand verbinden. Es ist aber kein Wahrheits- oder Sicherheitsautomat. Ein System kann die falschen Passagen abrufen, eine richtige Passage falsch interpretieren, veraltete Dokumente priorisieren oder Informationen anzeigen, für die der aktuelle Nutzer keine Berechtigung hat. Auch eine sauber zitierte Antwort kann geschäftlich falsch sein, wenn die Quelle selbst nicht freigegeben oder überholt ist.

Die OpenAI-Dokumentation zu Retrieval zeigt beispielhaft, wie Dateien in Vector Stores verarbeitet, gesucht und für Antworten verwendet werden können. Das ist eine technische Komponente. Die geschäftliche Frage bleibt: Welche Quelle darf für welchen Nutzer, Zweck und Zeitpunkt als gültig gelten?

Wann ein RAG-Projekt überhaupt sinnvoll ist

Ein RAG-Pilot passt, wenn fünf Bedingungen gemeinsam erfüllt sind:

1. Wiederkehrende Frage: Eine klar benannte Nutzergruppe sucht regelmäßig Antworten in einem abgrenzbaren Wissensbestand.
2. Freigegebene Quellen: Es gibt Dokumente oder Daten mit Owner, Gültigkeit und nachvollziehbaren Zugriffsregeln.
3. Prüfbarer Nutzen: Das gewünschte Ergebnis lässt sich gegenüber einem heutigen Prozess oder einer einfacheren Suchlösung testen.
4. Kontrollierbarer Fehler: Für falsche, fehlende oder unzulässige Antworten existieren Ablehnungs- und Eskalationswege.
5. Betriebsverantwortung: Nach dem Pilot besitzt jemand Datenpflege, Evaluation, Sicherheit, Kosten und Weiterentwicklung.

Fehlt bereits der kontrollierte Wissensbestand, ist ein Daten- und Governance-Projekt oft sinnvoller als ein schneller Chatbot. Fehlt ein repräsentatives Testset, können Anbieter nur eine Demo zeigen, aber keine für Ihren Use Case relevante Qualität belegen. Und wenn eine normale Suche mit Filtern das Problem zuverlässig löst, muss ein generierendes Modell seinen zusätzlichen Nutzen erst beweisen.

Drei Scopes, die ein Angebot getrennt ausweisen sollte

1. Öffentliche Retrieval- und Content-Readiness

Hier werden veröffentlichte Informationen so organisiert, dass Menschen, Suchcrawler und automatisierte Systeme sie zuverlässig finden und einordnen können. Ein belastbarer Scope umfasst beispielsweise:

• ein freigegebenes Truth Set für Organisation, Leistungen, Standorte, Ansprechpartner und Grenzen,
• eine URL- und Intent-Map statt vieler sich überschneidender Artikel,
• Primärquellen, Prüfdatum und fachliche Owner für veränderliche Aussagen,
• Crawl-, Rendering-, Canonical- und interne-Link-Prüfung,
• strukturierte Daten, die zum sichtbaren Seiteninhalt passen,
• Pilotseiten mit fachlicher und technischer Abnahme,
• einen Messpfad von Sichtbarkeit über Website-Interaktion bis appointment_booked.

Der Leistungsnachweis ist eine umgesetzte und geprüfte Informationsarchitektur. Eine Nennung oder Citation in einem externen KI-System kann keine Agentur garantieren, weil Modell, Index, Suchlogik und Oberfläche nicht unter ihrer Kontrolle liegen.

2. Interne RAG-Discovery und Pilot

Der Pilot soll nicht „RAG funktioniert“ beweisen, sondern eine konkrete Kaufentscheidung ermöglichen. Dazu gehören:

• Nutzer, Aufgaben und ausgeschlossene Anwendungsfälle,
• Datenquellen, Dokumenttypen, Aktualisierungswege und Löschregeln,
• Berechtigungen bis auf Dokument- oder Datensatzebene,
• Vergleich von Keyword-, semantischer und hybrider Suche,
• Chunking- und Metadatenvarianten auf Basis des echten Testsets,
• Regeln für Antworten, Zitate, Ablehnung und menschliche Eskalation,
• Messung von Retrieval-, Antwort-, Sicherheits-, Latenz- und Kostenergebnissen,
• dokumentierte Go-, Change- oder Stop-Entscheidung.

Ein Pilot ohne Negativfälle ist zu freundlich. Das Testset sollte auch fehlende Quellen, widersprüchliche Dokumente, alte Versionen, mehrdeutige Fragen, unberechtigte Nutzer und manipulierte Inhalte enthalten.

3. Produktionsbetrieb und Sicherheit

Eine Demo endet mit einer Antwort. Ein produktives System beginnt dort erst. Der Betriebs-Scope muss mindestens klären:

• Wer überwacht Datenimporte, Indexzustand und Modelländerungen?
• Wie werden Nutzerrollen und Quellberechtigungen durchgesetzt und getestet?
• Welche Logs sind für Diagnose nötig, und welche Inhalte dürfen nicht protokolliert werden?
• Welche Schwellen lösen eine menschliche Freigabe oder vollständige Ablehnung aus?
• Was passiert bei Ausfall eines Modells, Retrievers oder Datenlieferanten?
• Wie werden Kosten, Latenz, Qualität und Sicherheitsereignisse beobachtet?
• Wie können Daten, Prompts, Testsets und Konfigurationen beim Anbieterwechsel exportiert werden?

Das NIST AI Risk Management Framework strukturiert Risikomanagement in Govern, Map, Measure und Manage. Für den Einkauf besonders relevant: Rollen, Einsatzzweck, Grenzen, Drittanbieter, Tests und laufende Überwachung müssen dokumentiert werden. Ein einmaliger Penetrationstest oder eine Datenschutzfolie ersetzt diesen Lebenszyklus nicht.

Sicherheit: RAG macht ein LLM nicht automatisch vertrauenswürdig

RAG erweitert die Angriffsfläche, weil neben dem Modell auch Dokumente, Konnektoren, Indizes, Metadaten, Berechtigungen und externe Inhalte Teil des Systems werden. Die OWASP-Dokumentation zu Prompt Injection weist ausdrücklich darauf hin, dass RAG und Fine-Tuning Prompt Injection nicht vollständig verhindern.

Prüfen Sie im Anbietertermin deshalb konkrete Kontrollpunkte:

„On-Premise“ allein beantwortet diese Fragen nicht. Auch eine intern betriebene Anwendung kann zu breite Rechte, unsichere Konnektoren oder schlechte Löschprozesse haben. Umgekehrt ist eine Cloud-Komponente nicht automatisch ungeeignet; ihre Eignung hängt von Datenklasse, Vertrags- und Konfigurationslage, technischen Kontrollen und dem konkreten Einsatz ab. Eine verbindliche Datenschutz- und Rechtsprüfung muss durch die dafür verantwortlichen Stellen erfolgen.

Evaluation: zuerst Testset, dann Anbieter-Demo

Die zentrale Frage lautet nicht: „Klingt die Antwort gut?“ Sondern: „Hat das System für die definierte Aufgabe die richtige Quelle gefunden, Berechtigungen eingehalten und eine zulässige Antwort erzeugt?“

Die OpenAI-Leitlinie zu Evaluationen empfiehlt aufgabenspezifische Evals, kontinuierliche Prüfung und eine Kalibrierung automatisierter Bewertungen an menschlichem Urteil. Für einen RAG-Piloten bedeutet das, die Kette getrennt zu messen:

1. Retrieval: Ist die benötigte Passage in den abgerufenen Treffern enthalten?
2. Berechtigung: Hätte dieser Nutzer diese Passage überhaupt sehen dürfen?
3. Grounding: Wird die Antwort durch die freigegebenen Passagen gedeckt?
4. Vollständigkeit: Enthält die Antwort die für die Aufgabe notwendigen Punkte?
5. Ablehnung: Lehnt das System ab, wenn Beleg oder Berechtigung fehlen?
6. Robustheit: Bleibt die Entscheidung bei Formulierungsvarianten und problematischen Dokumenten vertretbar?
7. Betrieb: Sind Latenz, Kosten und Fehlerrate für den vorgesehenen Ablauf akzeptabel?

Es gibt dafür keinen universellen Grenzwert. Ein interner Rechercheassistent mit menschlicher Prüfung braucht andere Kriterien als eine automatische Auskunft an Kunden. Die Agentur sollte die Schwellen nicht aus einem allgemeinen Benchmark übernehmen, sondern gemeinsam mit Fachbereich, IT, Sicherheit und Compliance festlegen.

Anbieter in Berlin vergleichen: neun belastbare Prüffelder

Ein guter Pitch zeigt Möglichkeiten. Eine gute Beschaffung macht Unterschiede prüfbar. Bewerten Sie Anbieter in diesen Feldern:

1. Problem- und Scope-Klarheit

Der Anbieter formuliert Nutzer, Geschäftsaufgabe, Datenraum, Ausschlüsse und Abnahme, bevor er Produkte auswählt. Website-Readiness, Pilot und Produktionsbetrieb stehen als getrennte Positionen im Angebot.

2. Daten- und Rechteverständnis

Er fragt nach Datenowner, Aktualität, Löschung, Schutzklasse und Nutzerrechten. „Wir laden die PDFs in eine Vektordatenbank“ ist kein Berechtigungskonzept.

3. Retrieval-Kompetenz

Er testet Suche, Metadaten, Filter, Chunking und Ranking gegen reale Fragen. Ein bestimmter Vector Store oder ein bestimmtes Framework ist kein Qualitätsnachweis.

4. Evaluationsdesign

Ein Testset mit Positiv-, Negativ-, Berechtigungs- und Grenzfällen entsteht vor der finalen Architekturentscheidung. Ergebnisfelder bleiben leer, bis echte Läufe erfolgt sind.

5. Sicherheit und Datenschutz

Threat Model, Datenfluss, Drittanbieter, Protokollierung und Incident-Prozess werden konkret dokumentiert. Marketingformulierungen wie „DSGVO-konform“ ohne Rollen, Konfiguration und Zweckprüfung genügen nicht.

6. Integration und Betrieb

Das Angebot benennt Verantwortliche für Authentifizierung, Schnittstellen, Monitoring, Release, Rollback, Kostenkontrolle und Support. Unklare Übergänge zwischen Agentur, interner IT und Plattformanbieter sind ein späteres Betriebsrisiko.

7. Transparente Abnahme

Lieferobjekte besitzen Akzeptanzkriterien und Rohbelege. Dazu gehören nicht nur durchschnittliche Scores, sondern konkrete Fehlerklassen, offene Risiken und bekannte Grenzen.

8. Portabilität und Übergabe

Prompts, Testsets, Konfiguration, Datenmodell und Dokumentation bleiben nutzbar. Der Exit-Plan beschreibt, welche Artefakte exportiert werden können und welche Abhängigkeiten bestehen bleiben.

9. Geschäftliche Messung

Die technische Qualität wird nicht vorschnell als Umsatz ausgegeben. Bei öffentlichen Inhalten bleiben Citation, Klick, Formular, Kalender und bestätigter Termin getrennte Evidenzstufen. Bei internen Anwendungen werden Prozessnutzen und Fehlerrisiko gegenüber dem bisherigen Ablauf geprüft.

Was an einer Berliner Agentur lokal relevant ist

Vektoren funktionieren in Berlin nicht anders als in Hamburg oder München. Lokal relevant sind Zusammenarbeit und Verantwortlichkeit: Workshops mit Fachbereichen, Abstimmung mit dem Berliner Team, gemeinsame Test-Sessions und eine klar erreichbare Vertragspartnerin können die Umsetzung erleichtern.

LLMO Agentur Berlin ist ein spezialisierter Service von famefact, einer Marke der track by track GmbH mit Sitz in der Schliemannstraße 23, 10437 Berlin. Mehr zur organisatorischen Einordnung und zu den Personen hinter dem Angebot steht auf Über uns. Für Website- und Wissensinhalte ist unser Scope auf der Seite RAG-Optimierung beschrieben. Ein interner Build wird separat abgegrenzt, statt ihn durch eine allgemeine „RAG-Optimierung“ zu suggerieren.

Wenn Sie Anbieter deutschlandweit prüfen, nutzen Sie zusätzlich den Leitfaden Retrieval-Augmented-Generation-Dienstleister auswählen. Die fachliche Trennung zwischen öffentlicher Suchoptimierung und interner Retrieval-Architektur vertieft der Beitrag RAG-Optimierung versus klassische SEO.

Welche Ergebnisse vor der Beauftragung schriftlich feststehen sollten

Ein vergleichbares Angebot beantwortet mindestens diese Fragen:

• Welches Nutzerproblem und welcher Datenbestand sind im Scope?
• Welche Anwendungsfälle, Datenquellen und Integrationen sind ausdrücklich ausgeschlossen?
• Wer ist für Inhalt, Daten, Sicherheit, Technik, Freigabe und Betrieb verantwortlich?
• Welche Dokumente oder Datensätze gelten als freigegebene Wahrheit?
• Welche Testfragen und Fehlerklassen bilden die Abnahmegrundlage?
• Wie werden Zugriffsrechte bis zur abgerufenen Quelle geprüft?
• Welche Modell-, Hosting- und Monitoringanbieter verarbeiten welche Daten?
• Wie werden Änderungen an Quelle, Index, Retriever, Prompt und Modell versioniert?
• Welche Artefakte entstehen nach Discovery, Pilot und Produktionsrelease?
• Wie lauten Go-, Change- und Stop-Kriterien?
• Wie wird eine fehlerhafte Antwort gemeldet, untersucht und korrigiert?
• Was wird bei Übergabe oder Anbieterwechsel exportiert?

Tragen Sie die Antworten in die LLM-/RAG-Scope-Scorecard ein. Die Vorlage enthält bewusst keine vorbefüllten Anbieterbewertungen. Sie zwingt beide Seiten, Nachweis, Owner, Abnahmekriterium, Risiko und nächsten Schritt getrennt zu dokumentieren.

Fazit: Erst den Auftrag beweisbar machen, dann Technologie einkaufen

Eine seriöse LLM- und RAG-Agentur beginnt nicht mit „Welchen Vector Store möchten Sie?“, sondern mit Zweck, Nutzern, Quellen, Rechten, Fehlerfolgen und Abnahme. Erst danach lässt sich entscheiden, ob öffentliche Website-Readiness, ein interner Pilot oder ein vollständiger Produktions-Scope notwendig ist.

Für den ersten Termin benötigen Sie keine fertige Architektur. Domain oder Anwendungsidee, Nutzergruppe, wichtigste Datenquellen, Schutzbedarf und drei repräsentative Fragen genügen. Im RAG-Scope-Termin klären wir, welche Arbeit sinnvoll ist, was separat verantwortet werden muss und woran ein Ergebnis abgenommen werden kann. Der Funnel erfasst den Erfolg erst bei einem bestätigten appointment_booked – nicht bereits beim Klick auf den Kalender.