RAQSBlog · Compliance
A KVKK/GDPR-compliant AI assistant: what should you watch for?
Adding a voice AI assistant to your site also means building a new chain of data processing over your visitors' personal data. Under Turkey's KVKK (Law No. 6698) and the closely aligned GDPR, every link in that chain has to be compliant. This article lays out the questions to ask when buying or deploying an AI assistant, which technical mechanisms actually make a difference, and how RAQS addresses each one in concrete terms.
Why is an AI assistant a KVKK/GDPR matter?
A voice assistant touches personal data at three points: the visitor's voice (raw audio that can be biometric), the transcribed text of the conversation, and identifiers that may appear inside that text such as names, phone numbers or order references. On top of that, when the assistant answers from your content it runs a speech-to-text (STT), a large language model (LLM) and a text-to-speech (TTS) service in the background. Each of these raises the questions of where the data goes, how long it is retained, and whether it is used to train models.
Under KVKK you, as the site owner, are in most cases the data controller; the platform providing the assistant acts as the data processor. Going live without a data processing agreement governing this relationship (security obligations under KVKK Article 12; a DPA under GDPR) is one of the most common gaps found in audits. So before any technical feature, the first question is simple: what contractual and technical guarantees does this vendor give me as my processor?
Raw audio
Microphone capture; potentially biometric, sensitive data.
Transcript
Text of the conversation; identifiers may appear in it.
Sub-services
Every link of the STT + LLM + TTS chain is a processor.
Roles
Site owner = controller, platform = processor; a contract is required.
Data residency: where does your data physically live?
KVKK's regime for cross-border data transfers makes the country where data is processed directly relevant. Keeping data inside the EU greatly simplifies the transfer question thanks to GDPR adequacy, whereas an architecture that sends raw data to a US-based LLM provider typically needs an additional legal basis and often explicit consent. That is why 'it runs in the cloud' is not a sufficient answer; you must ask which specific region it runs in.
RAQS hosts its speech-to-text, language model and text-to-speech components on Azure, in an EU region. The enterprise mode of Azure OpenAI does not use submitted data to train the foundation model — which is the most critical part of the 'is my data used for training?' question. When evaluating residency, clarify the region not just of the application but of every sub-service it calls (STT/LLM/TTS) separately.
Region must be specific
Not 'the cloud' — which region, e.g. the EU.
Sub-services included
Ask the region of STT/LLM/TTS each separately.
Training use
Enterprise LLM mode: data is not used for foundation-model training.
Transfer basis
Any transfer outside the EU needs a legal basis + consent.
Consent and notice: what is the visitor agreeing to?
The moment a voice assistant accesses the microphone, the visitor must be informed and, where appropriate, give explicit consent. KVKK's notice obligation requires clearly stating the purpose of processing, who processes the data, for how long, and the visitor's rights (deletion, objection, access). A well-designed assistant ties microphone access to a visitor action (tapping the orb) — meaning it does not listen silently in the background; the session starts by the visitor's own choice.
In RAQS, a voice session opens via tap-to-talk, i.e. an explicit click by the visitor; the wake word is listened for locally through the browser's own Web Speech API, and no audio streams to the server until a session is triggered. This is different from an 'always listening in the background' design and simplifies your notice text. Integrating your notice text and consent flow into your site remains your responsibility as the controller; the platform is built so that this is technically possible.
Starts on intent
Tap-to-talk; no silent background listening.
Local wake word
Wake-word in the browser; no audio until a session opens.
Notice
Purpose, retention period and rights must be stated clearly.
Rights
Access, deletion and objection paths must actually work.
Data minimization: less data, less risk
A core principle of both KVKK and GDPR is processing that is relevant, limited and proportionate to its purpose. An assistant does not need to keep raw audio forever to answer a visitor; the transcript and the reply are enough for nearly any purpose. The clear question for the vendor is: how long is raw audio kept, how long are transcripts retained, and can they be deleted?
RAQS's answer architecture supports minimization naturally: the assistant answers only from your knowledge base; if the answer isn't there it says it doesn't know and never makes one up. The knowledge base is content you crawl and upload — meaning its purpose is not to collect visitors' personal data, but to answer a product/page question. Conversations can be reviewed in the dashboard, so you can set your retention and deletion policy accordingly. Not accidentally placing personal data (e.g. customer lists) into the knowledge base is itself part of minimization.
Purpose-bound
Only the data needed to answer is processed.
No hallucination
Answers only from the knowledge base; otherwise 'I don't know'.
Retention
Raw-audio and transcript retention periods must be clarified.
Clean knowledge base
Avoid putting unnecessary personal data in the KB.
Tenant isolation and security: your data does not mix
On a multi-tenant platform, the biggest technical risk is one customer's data leaking to another. The mechanism that prevents this is row-level security (RLS): at the database level, every query can only see the rows of the relevant tenant, so even if the application code makes a mistake, no other tenant's data is returned. This is a far stronger guarantee than saying 'we filter in the application', because the protection is enforced in the database itself.
RAQS enforces tenant isolation with RLS in its multi-tenant architecture. Alongside this, the crawl infrastructure is SSRF-guarded — meaning the assistant's site crawler cannot be steered toward internal-network addresses or unauthorized targets. The assistant's loading is restricted with an origin allowlist, and Cloudflare Turnstile is in place against abuse. Sensitive actions (payment, account, delete) are never performed automatically by the assistant; they always require the visitor's explicit confirmation. When evaluating a vendor, ask about these three layers separately: isolation in storage, abuse protection at the edge, and confirmation on actions.
RLS isolation
Tenant separation enforced at the database level.
SSRF-guarded crawler
Crawler can't be steered to internal/unauthorized targets.
Origin allowlist
The assistant loads only on permitted domains.
Confirm on action
Explicit user consent for payment/account/delete.
Questions to ask your vendor (a checklist)
The questions below let you genuinely evaluate an AI assistant from a KVKK/GDPR standpoint. 'KVKK compliant' written in a marketing page is not enough; you want to see the mechanisms behind that sentence. The answers should be concrete (region name, retention period, contract type); vague phrasing like 'you're safe' is not an answer.
In summary: where is data processed, who can access it, how long is it retained, is it used for model training, how are tenants isolated, and what contract is signed with you. Once these six axes are clear, the technical foundation of your compliance assessment is complete; the rest is your notice text, your consent flow and your retention policy.
Data residency
In which region do STT/LLM/TTS run?
Training use
Is my data used for foundation-model training?
Retention
How long are raw audio and transcripts kept; can they be deleted?
Isolation
Is tenant separation enforced at the database level (RLS)?
Contract
Is a data processing agreement (DPA) signed?
Abuse
Are origin allowlist + anti-abuse protections in place?
FAQ
Is RAQS KVKK/GDPR compliant?
RAQS is designed with KVKK and GDPR awareness: Azure hosting in an EU region, row-level security (RLS) for tenant isolation, an SSRF-guarded crawler, an origin allowlist and anti-abuse protection. To complete compliance, integrating the notice text and consent flow into your site is your responsibility as the site owner (controller).
Where is the visitor's voice processed?
Speech-to-text and text-to-speech run on Azure Speech, and the language model on Azure OpenAI, in an EU region. In enterprise LLM mode, submitted data is not used to train the foundation model.
Does the assistant listen in the background all the time?
No. A voice session opens when the visitor taps the orb (tap-to-talk); the wake word is listened for locally in the browser, and no audio streams to the server until a session is triggered.
Can data mix between different customers?
No. In the multi-tenant architecture, tenant separation is enforced at the database level with row-level security (RLS); one tenant's query cannot see another tenant's rows.
Does the assistant perform payment or account actions on its own?
No. Sensitive operations (payment, account changes, deletion) always require the visitor's explicit confirmation; the safety layer does not perform these actions automatically.
Make your site talk without compromising compliance
EU-region hosting, tenant isolation and security layers — try it free with one line of code.
Start free