← Back to Blog SOC 2 für KI-Anwendungen: So gelingt die Compliance
Enterprise AI 12 min read April 26, 2026

SOC 2 für KI-Anwendungen: So gelingt die Compliance

SOC-2-Compliance ist entscheidend für die Sicherheit Ihrer KI-Anwendungen. Erfahren Sie, wie Sie Kundendaten schützen und Vertrauen aufbauen können.

R
RAG Engine Team

Was ist SOC 2 und warum ist es für KI-Modelle im Jahr 2026 entscheidend?

In einer Welt, in der Künstliche Intelligenz (KI) zunehmend geschäftskritische Prozesse steuert und sensible Unternehmensdaten verarbeitet, wird der Nachweis von Sicherheit und Vertrauenswürdigkeit zur obersten Priorität. Hier kommt SOC 2 (Service Organization Control 2) ins Spiel. SOC 2 ist ein international anerkannter Audit-Standard, der von der American Institute of Certified Public Accountants (AICPA) entwickelt wurde, um die Sicherheit, Verfügbarkeit und Vertraulichkeit von Kundendaten bei Dienstleistungsunternehmen zu bewerten. Für KI- und SaaS-Plattformen, die komplexe Datenpipelines und proprietäre Modelle nutzen, stellt ein SOC-2-Bericht den Goldstandard dar, um Kunden zu versichern, dass ihre Daten nach höchsten Standards geschützt sind. Die Implementierung von robusten Sicherheitsmaßnahmen ist der erste Schritt auf diesem Weg.

Der Standard basiert auf fünf Trust Services Criteria (TSC), die den Rahmen für die Bewertung bilden:

  • Sicherheit (Security): Der Schutz von Systemressourcen vor unbefugtem Zugriff. Dies ist das grundlegende und für jedes SOC-2-Audit obligatorische Kriterium.
  • Verfügbarkeit (Availability): Die Sicherstellung, dass das System wie vereinbart zugänglich und nutzbar ist. Für KI-Dienste, die in Echtzeit-Anwendungen integriert sind, ist dies von entscheidender Bedeutung.
  • Verarbeitungsintegrität (Processing Integrity): Die Gewährleistung, dass die Systemverarbeitung vollständig, gültig, genau, zeitgerecht und autorisiert ist. Bei KI-Modellen betrifft dies die Korrektheit der Datenverarbeitung von der Eingabe bis zur Ausgabe.
  • Vertraulichkeit (Confidentiality): Der Schutz von Informationen, die als vertraulich gekennzeichnet sind, vor unbefugter Offenlegung. Dies ist besonders relevant, wenn KI-Modelle mit Geschäftsgeheimnissen oder proprietären Daten trainiert werden.
  • Datenschutz (Privacy): Die Erfassung, Nutzung, Aufbewahrung, Offenlegung und Entsorgung personenbezogener Daten gemäß den Datenschutzverpflichtungen einer Organisation.

Ein wesentlicher Unterschied besteht zwischen SOC 2 Typ I und Typ II Berichten. Ein Typ-I-Bericht bewertet das Design der Kontrollen zu einem bestimmten Zeitpunkt ("point-in-time"). Ein Typ-II-Bericht geht einen Schritt weiter und prüft die operative Wirksamkeit dieser Kontrollen über einen längeren Zeitraum (typischerweise 6-12 Monate). Für Kunden, die KI-Anwendungen nutzen, ist ein Typ-II-Bericht weitaus aussagekräftiger, da er beweist, dass die Sicherheitsmaßnahmen nicht nur existieren, sondern auch im Alltag konsequent funktionieren. Im Jahr 2026 wird das Kundenvertrauen in die Sicherheit von KI-Systemen kein "Nice-to-have" mehr sein, sondern ein entscheidender Wettbewerbsvorteil, der über den Erfolg oder Misserfolg am Markt entscheidet.

Preise ansehen →

Der Weg zur SOC-2-Konformität: Ein schrittweiser Prozess

Die Erlangung der SOC-2-Konformität ist kein Sprint, sondern ein Marathon, der eine sorgfältige Planung und die Zusammenarbeit verschiedener Teams erfordert. Der Prozess lässt sich in mehrere klar definierte Phasen unterteilen.

  1. Scoping (Festlegung des Geltungsbereichs): In der ersten Phase wird definiert, welche Systeme, Prozesse und Daten im Geltungsbereich des Audits liegen. Entscheidend ist hier auch die Auswahl der relevanten Trust Services Criteria. Während "Sicherheit" immer verpflichtend ist, werden die anderen vier (Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit, Datenschutz) basierend auf den vertraglichen Verpflichtungen und den spezifischen Dienstleistungen des Unternehmens ausgewählt.
  2. Readiness Assessment (Lückenanalyse): Bevor das offizielle Audit beginnt, führen die meisten Unternehmen ein Readiness Assessment durch, oft mit Hilfe externer Berater. Dabei werden die bestehenden Kontrollen mit den SOC-2-Anforderungen verglichen, um Lücken, Schwachstellen und fehlende Dokumentationen zu identifizieren.
  3. Implementierung und Behebung (Remediation): Basierend auf den Ergebnissen der Lückenanalyse werden nun die fehlenden Kontrollen implementiert und Schwachstellen behoben. Dies kann technische Maßnahmen (z.B. Implementierung von Zwei-Faktor-Authentifizierung), prozessuale Änderungen (z.B. Einführung eines formalen Change-Management-Prozesses) und die Erstellung umfassender Dokumentationen umfassen.
  4. Das finale Audit: Ein unabhängiger, zertifizierter Wirtschaftsprüfer (CPA) führt das eigentliche Audit durch. Der Auditor prüft die Dokumentation, führt Interviews mit Mitarbeitern und testet die Wirksamkeit der implementierten Kontrollen. Für einen Typ-II-Bericht erstreckt sich diese Prüfung über einen Beobachtungszeitraum von mehreren Monaten.

Die Rollenverteilung ist dabei klar: Das Management muss den Prozess unterstützen, die notwendigen Ressourcen bereitstellen und die strategische Richtung vorgeben. Die Entwickler- und MLOps-Teams sind für die technische Implementierung der Kontrollen in der KI-Architektur verantwortlich. Die externen Auditoren agieren als unabhängige Prüfinstanz. Entscheidend ist das Verständnis, dass SOC 2 keine einmalige Aufgabe ist. Es erfordert eine Kultur der Continuous Compliance, bei der Sicherheitskontrollen kontinuierlich überwacht, bewertet und verbessert werden, um auch zukünftigen Bedrohungen und sich ändernden Anforderungen gerecht zu werden.

Technische Implementierung: SOC 2 in Ihrer KI-Architektur verankern

Die Umsetzung von SOC-2-Anforderungen in einer KI-Umgebung erfordert eine ganzheitliche Betrachtung der gesamten Daten-Pipeline – von den rohen Trainingsdaten über die Verarbeitungsschritte bis hin zu den Inferenz-Endpunkten, die den Nutzern zur Verfügung stehen. Jede Komponente muss abgesichert und überwacht werden.

Besondere Aufmerksamkeit erfordern moderne Architekturen wie Retrieval-Augmented Generation (RAG). Bei RAG-Systemen, die ein Large Language Model (LLM) mit einer externen Wissensbasis kombinieren, ergeben sich spezifische Sicherheitsanforderungen:

  • Schutz der Vektordatenbank: Vektordatenbanken enthalten die numerischen Repräsentationen (Embeddings) Ihrer sensiblen Dokumente. Der Zugriff muss streng kontrolliert und verschlüsselt sein, sowohl im Ruhezustand als auch während der Übertragung.
  • Absicherung der Dokumenten-Chunks: Die ursprünglichen Textabschnitte (Chunks), die in der Datenbank gespeichert sind, müssen ebenfalls geschützt und ihr Zugriff protokolliert werden. Es muss sichergestellt sein, dass ein Benutzer nur auf Chunks zugreifen kann, für die er eine Berechtigung hat.
  • Kontrolle des Datenflusses: Der Austausch von Daten zwischen dem LLM und der Wissensbasis muss abgesichert sein. Dies beinhaltet die Sicherung von Prompts und Antworten sowie die Verhinderung von Datenlecks oder unbefugten Zugriffen auf die Wissensbasis über manipulierte Prompts. Eine sichere Verwaltung der Wissensbasis ist hierbei zentral, wie sie beispielsweise durch fortschrittliche Knowledge-Graph-Funktionen unterstützt wird.

Darüber hinaus müssen die Prozesse für das Modelltraining und das Fine-Tuning sicher und nachvollziehbar gestaltet sein. Dies umfasst die Versionierung von Datensätzen und Modellen, die Dokumentation der Trainingsparameter und die Sicherstellung, dass während des Trainings keine unautorisierten Daten einfließen.

Code-Level-Sicherheit und Zugriffskontrollen

Auf der Anwendungsebene beginnt die Sicherheit mit robusten Zugriffskontrollen. Die Implementierung des Least-Privilege-Prinzips ist fundamental: Jeder Benutzer und jedes System darf nur auf die Daten, Modelle und APIs zugreifen, die für die Erfüllung seiner Aufgaben absolut notwendig sind. Dies wird typischerweise durch rollenbasierte Zugriffskontrollen (RBAC) umgesetzt, die feingranulare Berechtigungen definieren.

Ein weiterer Eckpfeiler ist umfassendes Logging, Monitoring und Alerting. Jede relevante Aktion – von einem API-Aufruf über einen Datenzugriff bis hin zu einer Konfigurationsänderung – muss protokolliert werden. Monitoring-Systeme analysieren diese Logs in Echtzeit auf anomale Muster oder potenzielle Sicherheitsvorfälle und lösen bei Bedarf Alarme aus. Dies ermöglicht eine schnelle Reaktion auf Bedrohungen.


# Pseudo-Code zur Illustration einer RBAC-Prüfung
def access_model_endpoint(user_token, model_id, request_data):
    user_roles = get_roles_from_token(user_token)

    # Prüfen, ob der Benutzer die Berechtigung 'execute_model' hat
    if "execute_model" not in user_roles.get(model_id, []):
        log_event("access_denied", user=user_token.user, resource=model_id)
        raise PermissionError("Zugriff auf dieses KI-Modell verweigert.")

    # Zugriff protokollieren und Modell aufrufen
    log_event("access_granted", user=user_token.user, resource=model_id)
    result = model.predict(request_data)
    return result

Zusätzlich müssen Sicherheitspraktiken tief in den MLOps-Lebenszyklus integriert werden. Werkzeuge für die statische Code-Analyse (SAST), das Scannen von Abhängigkeiten auf bekannte Schwachstellen (Dependency Scanning) und die Container-Sicherheit sollten fester Bestandteil der CI/CD-Pipeline sein, um Sicherheitslücken frühzeitig zu erkennen und zu beheben.

Infrastruktur und Cloud-Sicherheit

Die zugrundeliegende Cloud-Infrastruktur (z.B. bei AWS, Azure oder GCP) bildet das Fundament der Sicherheit. Die Konfiguration muss den SOC-2-Anforderungen entsprechen. Dazu gehören Maßnahmen wie die Netzwerksegmentierung mittels Virtual Private Clouds (VPCs) und Subnetzen, um kritische Systeme voneinander zu isolieren, sowie die Konfiguration von strengen Firewall-Regeln, die nur den absolut notwendigen Datenverkehr erlauben.

Die Verschlüsselung von Daten ist nicht verhandelbar. Alle Daten müssen sowohl im Ruhezustand (at rest), z.B. in Datenbanken und S3-Buckets, als auch während der Übertragung (in transit) über Netzwerke mittels TLS verschlüsselt werden. Dies gilt für alle Komponenten der KI-Pipeline, einschließlich der LLM-Prompts und -Antworten, die zwischen verschiedenen Diensten ausgetauscht werden.

Ein oft übersehener, aber kritischer Aspekt ist das Management von Secrets. API-Schlüssel, Datenbank-Passwörter und andere sensible Anmeldeinformationen dürfen niemals im Code oder in Konfigurationsdateien hartcodiert werden. Stattdessen sollten spezialisierte Dienste wie AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault verwendet werden, um diese Secrets sicher zu speichern, zu rotieren und den Zugriff darauf streng zu kontrollieren und zu protokollieren.

Preise ansehen →

SOC 2 im Vergleich zu anderen relevanten Sicherheitsstandards

SOC 2 ist ein wichtiger Standard, aber er existiert nicht im luftleeren Raum. Es ist hilfreich, ihn von anderen gängigen Frameworks und Vorschriften abzugrenzen, um seine einzigartige Rolle zu verstehen.

Kriterium SOC 2 ISO 27001 DSGVO (GDPR)
Fokus Operative Wirksamkeit von Kontrollen bei Dienstleistern, basierend auf den Trust Services Criteria. Aufbau und Betrieb eines umfassenden Informationssicherheits-Managementsystems (ISMS). Gesetzliche Anforderungen an den Schutz personenbezogener Daten von EU-Bürgern.
Ergebnis Detaillierter Audit-Bericht (Typ I oder Typ II) für Kunden und Partner. International anerkanntes Zertifikat, das die Konformität des ISMS bestätigt. Gesetzeskonformität; keine formelle Zertifizierung, aber hohe Bußgelder bei Nichteinhaltung.
Zielgruppe SaaS-Anbieter, Cloud-Hoster und andere Dienstleistungsorganisationen. Jede Organisation, unabhängig von Größe oder Branche, die ihr ISMS zertifizieren lassen möchte. Jede Organisation weltweit, die personenbezogene Daten von EU-Bürgern verarbeitet.

Während sich ISO 27001 auf den Aufbau eines Managementsystems konzentriert (das "Wie" der Organisation von Sicherheit), fokussiert sich SOC 2 auf die tatsächliche operative Umsetzung und Wirksamkeit spezifischer Kontrollen. Die beiden Standards ergänzen sich oft gut.

Die DSGVO ist ein Gesetz, kein freiwilliger Standard. Sie schreibt vor, dass Unternehmen "geeignete technische und organisatorische Maßnahmen" (TOMs) zum Schutz personenbezogener Daten ergreifen müssen. Ein SOC-2-Bericht, insbesondere mit den Kriterien Vertraulichkeit und Datenschutz, kann als starker Nachweis dienen, dass ein Unternehmen diese TOMs implementiert hat und deren Wirksamkeit von einer unabhängigen Stelle geprüft wurde.

Mit Blick auf die Zukunft wird auch der EU AI Act immer relevanter. Dieses Gesetz wird strenge Anforderungen an KI-Systeme mit hohem Risiko stellen, insbesondere in Bezug auf Robustheit, Sicherheit und Datenschutz. Ein bestehender SOC-2-Bericht kann Unternehmen dabei helfen nachzuweisen, dass sie bereits über die notwendigen Kontrollen und Prozesse verfügen, um die Sicherheitsanforderungen des AI Acts zu erfüllen. Plattformen wie rag-engine.cloud, die für den Einsatz in regulierten Branchen konzipiert sind, können die technische Grundlage für solche Nachweise liefern und die Unterstützung bei Compliance-Audits erheblich vereinfachen.

Best Practices für eine erfolgreiche SOC-2-Zertifizierung 2026

Eine erfolgreiche SOC-2-Zertifizierung erfordert mehr als nur die Implementierung technischer Kontrollen. Es ist ein strategisches Projekt, das eine durchdachte Herangehensweise verlangt.

  • Automatisierung der Compliance-Überwachung: Verlassen Sie sich nicht auf manuelle Tabellen und periodische Checks. Nutzen Sie spezialisierte Compliance-Automatisierungstools, die Ihre Cloud-Infrastruktur und Code-Repositories kontinuierlich scannen, Fehlkonfigurationen erkennen und die Einhaltung Ihrer Richtlinien in Echtzeit überprüfen. Dies reduziert den manuellen Aufwand drastisch und macht Compliance zu einem fortlaufenden Prozess.
  • Aufbau einer "Culture of Security": Sicherheit ist die Verantwortung aller. Führen Sie regelmäßige Sicherheitsschulungen für alle Mitarbeiter durch, von Entwicklern bis zum Vertrieb. Sensibilisieren Sie das Team für Themen wie Phishing, sicheres Passwortmanagement und den verantwortungsvollen Umgang mit Kundendaten. Wenn jeder Mitarbeiter Sicherheit als Teil seiner Aufgabe versteht, wird die Einhaltung der Kontrollen zur Selbstverständlichkeit.
  • Frühzeitige und lückenlose Dokumentation: Die goldene Regel im Audit-Prozess lautet: "If it's not documented, it didn't happen." Dokumentieren Sie von Anfang an alle relevanten Prozesse, Richtlinien, Architekturentscheidungen und Kontrollen. Eine klare und strukturierte Dokumentation beschleunigt nicht nur das Audit, sondern dient auch als wertvolle Wissensbasis für Ihr Team. Die Nutzung von Systemen, die detaillierte Audit-Protokolle automatisch erstellen, ist hier von unschätzbarem Wert.
  • Mit einem klaren Scope beginnen: Versuchen Sie nicht, von Anfang an alles abzudecken. Beginnen Sie mit einem klar definierten, überschaubaren Scope und konzentrieren Sie sich auf das wichtigste Trust Service Criterion: Sicherheit. Sobald Sie diesen Meilenstein erreicht haben, können Sie den Scope schrittweise um weitere Systeme oder TSCs wie Verfügbarkeit oder Vertraulichkeit erweitern.

Häufige Fallstricke und wie man sie vermeidet

Der Weg zur SOC-2-Konformität ist mit potenziellen Hindernissen gepflastert. Wer sie kennt, kann sie gezielt vermeiden.

Unterschätzung des Aufwands: Viele Unternehmen unterschätzen den Zeit- und Ressourcenaufwand, der für die Vorbereitung und das Audit erforderlich ist. Planen Sie realistisch und stellen Sie sicher, dass dedizierte Mitarbeiter oder Teams für das Projekt verantwortlich sind. Ein SOC-2-Projekt ist keine Nebenaufgabe.

Unzureichende Dokumentation: Unstrukturierte, unvollständige oder veraltete Dokumentation ist ein häufiger Grund für Verzögerungen im Audit-Prozess. Auditoren müssen sich mühsam durch unklare Unterlagen arbeiten. Vermeiden Sie dies, indem Sie von Beginn an ein zentrales, gut organisiertes Repository für alle Compliance-Dokumente einrichten.

Mangelndes Engagement der Führungsebene: Ohne die volle Unterstützung des Managements wird ein SOC-2-Projekt scheitern. Die Führungsebene muss die strategische Bedeutung erkennen, die notwendigen Budgets und Ressourcen freigeben und bei Priorisierungskonflikten hinter dem Projekt stehen.

Compliance als einmaliges Projekt sehen: Der größte Fehler ist die Annahme, dass die Arbeit nach Erhalt des Berichts getan ist. SOC 2 ist ein kontinuierlicher Prozess. Richten Sie Mechanismen zur ständigen Überwachung, regelmäßigen internen Überprüfung und kontinuierlichen Verbesserung Ihrer Kontrollen ein, um auch für das nächste jährliche Audit gerüstet zu sein.

Häufig gestellte Fragen (FAQ)

Was sind die fünf Trust Services Criteria (TSC) für SOC 2?

Die fünf Trust Services Criteria sind die Säulen des SOC-2-Frameworks. Sie umfassen:

  • Sicherheit (Security): Schutz vor unbefugtem Zugriff (obligatorisch).
  • Verfügbarkeit (Availability): Sicherstellung der Systemverfügbarkeit.
  • Verarbeitungsintegrität (Processing Integrity): Gewährleistung der genauen und vollständigen Datenverarbeitung.
  • Vertraulichkeit (Confidentiality): Schutz sensibler, als vertraulich eingestufter Informationen.
  • Datenschutz (Privacy): Schutz personenbezogener Daten.

Ein Unternehmen wählt die für seine Dienstleistungen relevanten Kriterien aus. Ein reiner Infrastrukturanbieter benötigt vielleicht nur Sicherheit und Verfügbarkeit, während eine KI-Plattform, die sensible Kundendaten verarbeitet, wahrscheinlich auch Vertraulichkeit und Datenschutz abdecken muss.

Wie lange dauert eine SOC-2-Zertifizierung für eine KI-Anwendung?

Der Zeitrahmen kann stark variieren, aber eine realistische Schätzung liegt zwischen 6 und 18 Monaten. Dies hängt von mehreren Faktoren ab: dem Reifegrad der bestehenden Sicherheitskontrollen, der Komplexität der KI-Architektur, der Größe des Unternehmens und den verfügbaren Ressourcen. Die Vorbereitungsphase (Readiness Assessment und Implementierung) dauert in der Regel am längsten (3-12 Monate), während das Audit selbst (insbesondere der Beobachtungszeitraum für Typ II) weitere 3-6 Monate in Anspruch nehmen kann.

Ist SOC 2 für alle KI-Unternehmen obligatorisch?

Nein, SOC 2 ist keine gesetzliche Pflicht wie die DSGVO. Es ist ein freiwilliger Audit-Standard. In der Praxis hat es sich jedoch zu einem De-facto-Standard für B2B-SaaS- und KI-Unternehmen entwickelt. Große Unternehmenskunden fordern in ihren Verträgen fast immer einen SOC-2-Bericht als Nachweis, dass ein Anbieter ihre Daten sicher handhabt. Ohne SOC-2-Konformität ist es oft schwierig, im Enterprise-Segment Fuß zu fassen und das notwendige Vertrauen bei kritischen Anwendungsfällen aufzubauen.

Welche Rolle spielt Datenverschlüsselung bei der SOC-2-Compliance für KI?

Datenverschlüsselung spielt eine absolut fundamentale Rolle und ist eine der wichtigsten technischen Kontrollen zur Erfüllung der SOC-2-Anforderungen, insbesondere für die Kriterien Sicherheit und Vertraulichkeit. Es wird erwartet, dass Daten sowohl "at rest" (im gespeicherten Zustand in Datenbanken, Speichersystemen etc.) als auch "in transit" (während der Übertragung über Netzwerke) durchgängig mit starken kryptografischen Verfahren verschlüsselt werden. Für KI-Pipelines bedeutet dies, dass von den Trainingsdaten über die in Vektordatenbanken gespeicherten Embeddings bis hin zu den Prompts und Antworten des LLM alles Ende-zu-Ende verschlüsselt sein muss.

Preise ansehen →

#SOC-2-Compliance #Trust Services Criteria #KI-Sicherheit #AICPA Standards #SaaS-Sicherheit #SOC-2-Audit

Related Articles

Ask your business anything.

An EU-hosted AI assistant that cites every answer. Type a question, or paste your website.

EU-hosted · every answer cited · free to start

scroll

One engine. Three products.

RAG Engine turns your website, documents and business data into AI answers your customers and teams can trust: every answer is grounded in your sources, cited inline, scored for confidence and written to an audit log. Hosted in the EU (Amsterdam). Your data is never used to train models.

Answers you can audit

Every reply ships with a receipt, so a compliance officer, a lawyer or a support lead can check it in seconds. Drag the score to see what the assistant does at each level.

  • Citations on every answer

    Each statement links to the exact source passage — a page on your site, a PDF, a ticket or a row in your data. How retrieval works →

  • Grounding score, 0–100

    A confidence score on every answer. Low-scoring answers ask for an email instead of guessing. Self-improving answers → · Lead capture →

  • Provenance log

    Model, region, sources and timing are logged per answer, with PII redaction, audit logs and SSO on higher plans. Audit logs → · Trust centre →

RAG ENGINE · RECEIPT
grounding
93 / 100 · high
behaviour
answered, cited
citations
2 sources
logged
yes · eu-amsterdam
next step
none
keep for your records
VERIFIED

High. Answered with inline citations and written to the audit log.

RAG Engine for

What does a first consultation cost?

$150 flat for 30 minutes — credited to your first invoice. 1

Book a consultation →

See the law firm demo →

How it works

From a URL to a cited, logged answer in three steps — no engineering project.

  1. Connect

    Paste a URL, upload documents or connect a source. Crawling, chunking, embedding and indexing run automatically — including JavaScript sites.

  2. Tune

    Choose the model, retrieval settings and tone. Add verified answers, metadata filters and your own OpenAI or Anthropic key.

  3. Deploy

    Embed the widget, connect Slack, Teams or WhatsApp, or call the API. Every answer is cited, scored and logged from day one.

Start free. No card.

€0Free — 1 assistant, 10 documents, 500 questions a month
€29Starter — 3 assistants, 50 documents
€49Pro — 10 assistants, 500 documents, API
€299Enterprise — SSO, audit logs, SLA, white label, on-prem

Bring your own LLM key on any plan. Prices per month; yearly saves about 17%.

Free
€0 /month
Start free

1 assistant, 10 documents, 500 questions a month. Bring your own key.

See RAG Engine in action

Connect a source, ask a question, get a cited answer — in one short film.

Build AI that actually knows your stuff. · 1:33

People ask

Is my data used to train AI models?
No. Your documents power only your own assistants. RAG Engine never uses customer data to train models, and on any plan you can bring your own OpenAI or Anthropic key. Security →
Where is my data hosted?
In the EU, in Amsterdam. RAG Engine is built for GDPR from day one, with PII redaction, audit logs and SSO/2FA on higher plans. Trust centre →
How is RAG Engine different from Chatbase or CustomGPT?
Every answer carries citations, a grounding score and a provenance log you can audit; hosting is EU-based; and the same engine powers data agents and an API, not only a chat widget. RAG Engine vs Chatbase →
What can I connect?
Websites, PDFs and documents, Google Drive, Notion, Slack, HubSpot, Salesforce, Zendesk, Intercom, Google Analytics, Search Console, Snowflake, BigQuery, PostgreSQL and more — 29+ integrations. All integrations →
Does it work in my language?
Yes. Assistants answer in 50+ languages, and the interface is localized in English, German, French, Dutch, Portuguese and Spanish. Multi-language →
How much does it cost?
Start free with one assistant, 10 documents and 500 questions a month, no card required. Paid plans start at €29 per month. Pricing →