Data security, designed in from the start

Multi-tenant isolation — row-level security (RLS)

RAQS is a managed (hosted) cloud; many customers share the same infrastructure. The most critical promise here is that one customer's data never leaks to another. We do not leave that to a filter in application code that someone could forget: isolation is enforced directly at the database layer, with PostgreSQL Row-Level Security (RLS).

Every row in every table belongs to a tenant. The active session's tenant identity is set at the connection level, and RLS policies return only that tenant's rows no matter which path a query takes. So even if a developer forgets to write a WHERE clause, the database will not return the wrong tenant's row. Isolation lives at the lowest, most trustworthy layer of defense.

In practice this means your knowledge base, crawled pages, uploaded files, conversation logs and analytics are all kept in a space that belongs only to you. It is technically impossible to see another customer's site, content or conversation in the dashboard.

SSRF-guarded crawler — when building your knowledge base

So it can answer only from your content, RAQS crawls your site (sitemap + pages; JS-rendered SPA sites are processed with a headless browser; content is extracted cleanly with trafilatura). Any system that takes a URL and makes a server-side request is exposed, when abused, to Server-Side Request Forgery (SSRF): an attacker might try to point the crawler at internal network addresses or cloud metadata endpoints.

Our crawler is hardened against this. Only http/https schemes are allowed; resolved IP addresses are checked and private/local ranges (such as 127.0.0.0/8, 10/8, 172.16/12, 192.168/16, link-local 169.254/16 and cloud metadata addresses) are rejected. Redirects are re-validated, so an attacker cannot hide an external-to-internal hop behind a redirect. We also respect robots.txt and enforce a per-plan page quota — crawling tires neither your server nor ours.

The same discipline applies to files: PDF, Word, TXT, MD and CSV uploads are chunked, embedded with Azure embeddings (text-embedding-3-small) and stored in pgvector. Content is processed as text; the files you upload are used only to feed your knowledge base.

Origin allowlist + Turnstile — against abuse

The assistant widget should only run on sites you have authorized. In the RAQS dashboard you define an allowed-domain list (origin allowlist) for each site. Incoming requests are validated against this allowlist; a copy embedded on another domain cannot use your quota or your brand. This matters for both cost and trust: your site key is pinned to your site.

Against abstract bot traffic and automated abuse, Cloudflare Turnstile is in place. Unlike classic CAPTCHAs, Turnstile distinguishes human from bot in a privacy-friendly way without forcing visitors to solve puzzles. Together these two layers prevent your assistant from being exploited by malicious automation and your usage cost from being inflated.

All traffic flows over the single domain raqs.ai behind Cloudflare, which adds an extra layer of edge-level protection and speed.

Azure (EU-region) infrastructure and data residency

RAQS's brain and voice layer run entirely on Azure: Azure Speech for speech-to-text and text-to-speech, Azure OpenAI (gpt-4o-mini) for the language model, and Azure text-embedding-3-small for embeddings. Data and processing are hosted in an EU region — directly relevant for organizations operating in Europe that want their data to stay within the EU.

The architecture is a Python/FastAPI backend, a Pipecat voice pipeline and a static Next.js site; everything sits behind Cloudflare under a single domain (raqs.ai). Because it is a managed cloud, we take on patching, scaling and infrastructure hardening; you focus on the dashboard.

Data handling — what is collected, why, how it is used

RAQS works with two kinds of data. The first is your knowledge base: the pages you crawl, the text you paste and the files you upload. This content is processed only so the assistant can answer questions correctly — it is chunked, embedded and used in retrieval. The second is conversation data: the visitor's question and the assistant's answer, stored for conversation review and analytics in the dashboard, so you can see whether the assistant is working correctly and close gaps in your content.

RAQS does not make things up; it produces an answer only from your knowledge base, and if it is not in your content it plainly says 'I don't know.' This directly reduces the risk of misinformation (and the liability that comes with it). Sensitive agent operations — payment, account actions, deletion — always require user confirmation; the assistant does not carry them out on its own.

In the managed-cloud model, deletion and data-removal requests are supported: when you remove a site or knowledge base, the related content and embeddings are purged. Transparency about which data is kept where forms the foundation of KVKK and GDPR compliance.

KVKK and GDPR — compliant by design

For an organization operating in Turkey, KVKK (Law No. 6698 on the Protection of Personal Data) is the core framework; for those operating in Europe, it is GDPR. RAQS is designed with both in mind: data minimization (we process only what is needed), purpose limitation (your content data is for answer generation, your conversation data for review/analytics), EU-region hosting, and clear deletion paths.

When evaluating a gdpr voice ai solution, the classic questions you should ask — where does my data sit, who can access it, how do I delete it, is it scattered to third parties — all have concrete answers in RAQS: your data is in Azure in the EU, isolated to you with RLS, deletable from the dashboard, and model/voice processing is consolidated on a single managed cloud (Azure). For contractual and administrative details (a data processing agreement, etc.) you can reach out to our team; the purpose of this page is to convey the technical mechanisms transparently.