Privacy Policy
Last updated: August 23, 2026
Privacy and data protection
Full adherence to GDPR and LGPD
We do not ask you to take that on faith. Every control below is published, and most are held in place by a test that fails when the product drifts from the promise.
Where your data goes, and where it does not
- the schema, annotated from your data
- the SQL comes back
- the result rows
- the written reading
That second crossing is yours to close on a connected database. Two switches govern it — one on your account, one on each connected source — and either one is enough on its own: with it off, the result rows never leave, and you get the table and the query that produced it instead of a written reading.
You can freeze processing
A restriction you can ask for at any time: the product's AI features refuse to run over your data, while reading, export, deletion and sign-in stay open. Most products only offer you the door.
Erasure is exercised, not asserted
A test seeds a full account against a real database, exports it, deletes it, then sweeps the schema for anything left behind. It runs on every change.
Retention runs, it is not just promised
Usage records are deleted after 12 months by a job this very sentence shares its constant with. Off-box backups expire after 30 days — there the deletion is our cloud provider’s lifecycle rule, and this number is a mirror of it, cross-checked by a test against our published retention matrix.
Backups are encrypted before they leave
The daily dump is encrypted on our machine, with our own key, before it is copied anywhere. No key, no upload — it fails closed rather than quietly.
In the cloud, encrypted, under US and EU frameworks
Hosted in São Paulo and reached only over TLS, with your database credentials sealed by AES-256-GCM. Transfers abroad rely on Standard Contractual Clauses, and on the EU-US Data Privacy Framework where the provider is certified. Every subprocessor is named in the published notice — and where one of them does not disclose who it routes onward to, the notice says that too.
The SQL can only read
The generated query passes a guard that admits reads and nothing else. A database you connect is checked against loopback, link-local and private ranges before we accept it, and checked again after its name is resolved.
Controller, subprocessors, transfers and your rights — in full.
1. Controller and DPO
Controller: KGPX Serviços Administrativos LTDA (trade name TalkWithData). CNPJ: 23.543.381/0001-50. Address: Rua Gustavo Ambrust, 464 — Campinas/SP CEP 13092-106, Brazil. Data Protection Officer (encarregado): Guilherme Favaron. Contact: [email protected].
2. Information We Collect
Account data: name, email address, and encrypted password (scrypt hash) when you register with email/password. Google account identifier (google_sub) when you sign in with Google.
Uploaded data: files you upload (CSV, XLSX, PDF, TXT), database schemas, and connection strings. Connection strings are encrypted at rest using AES-256-GCM.
Usage data: questions, AI responses, token consumption, and error logs for billing, debugging, and service improvement.
Technical data: IP address, browser type, and access timestamps for security and abuse prevention.
Consent records: timestamp and policy version when you accept the Terms and this Policy.
3. Legal Bases
We process personal data under the following legal bases (by purpose):
- Account creation and authentication: Performance of a contract (GDPR art. 6(1)(b) / LGPD art. 7, V).
- Aggregate usage analytics (Google Analytics, after opt-in): Consent (GDPR art. 6(1)(a) / LGPD art. 7, I) — refusable and revocable at any time.
- Provide the Service (upload, chat, SQL, artifacts): Performance of a contract.
- AI processing via OpenRouter (schema, rows, questions, results): Performance of a contract (necessary to deliver the product).
- Security, abuse prevention, rate limiting: Legitimate interests / legal obligation as applicable (GDPR art. 6(1)(f)/(c); LGPD art. 7, IX/II).
- Billing and usage metering (when billing is enabled): Performance of a contract / legal obligation.
- Respond to support and DSR requests: Legal obligation / contract.
4. How We Use Your Data
To provide the Service: process your files, generate SQL queries, and answer your questions.
To improve the Service: aggregate analytics on usage patterns, error rates, and performance (never individual data contents as marketing profiles).
To communicate with you: service notifications, security alerts, and responses to support or privacy requests.
To prevent abuse: rate limiting, fraud detection, and security monitoring.
To publish an artifact, when YOU ask for it: publishing turns one saved version of one artifact into a page anyone holding its link can read, without signing in. It is off until you ask, one artifact at a time, and the app states the consequence before it happens. The link is an unguessable token; the page shows the version you published rather than later edits, and carries no account name or email. Unpublishing revokes the link immediately, and deleting the artifact or your account revokes it too.
5. Data Sent to Third Parties (AI and processors)
AI processing happens at specific moments. The payloads below are what the current product sends to our AI gateway (OpenRouter), which may route to model providers (for example Moonshot AI, OpenAI, Anthropic, or Google). Which provider receives a given request is chosen by the gateway and is neither fixed by us nor disclosed to us, so we cannot name the onward recipient of an individual call — we name the gateway, and we say plainly that the hop beyond it is not one we can see. Each provider has its own retention practices; see also https://openrouter.ai/privacy.
On upload (before your first question): for a file with rows, we may send column names/types (schema), the rows of the file, and the file name to generate a dataset description and suggested questions. A document has no rows, and what is sent for it is described in the DOCUMENT paragraph below. Rows are sent whole up to what the AI model in use can hold — at most 60% of that model's context window — so a larger file is sent as the whole rows that fit. When we cannot establish that model's window size at all, a fixed ceiling of 128k tokens applies instead of the share.
When you ask a question (SQL planning): we send a system prompt with your schema and dataset description, the current question, and a bounded excerpt of the recent conversation in that same chat — at most 6 previous exchanges. Each one carries the earlier question, the SQL that ran, how many rows it returned, and a short excerpt of the answer.
The schema sent when planning includes a compact data profile computed from your data: for columns with few distinct values (at most 20), the list of those values; for date columns, the earliest and latest value; for other columns, up to 3 short example values. Columns whose name or values look like personal identifiers (emails, tax IDs, phone numbers) are excluded from this profile. For database sources the profile is built from a bounded sample read once, when you connect — and because a sample's earliest value is not the table's, and its distinct values are not the column's, a sampled profile carries example values ONLY: no date range and no list of distinct values is computed for it.
Result rows from earlier turns are NOT part of that conversation excerpt.
When interpreting query results: we may send the question, the SQL, and the rows your query returned — the RESULT of your query, not your full uploaded dataset. They are sent whole up to the same ceiling. When they do not all fit, we do NOT write a reading over part of them: the answer says the result is too large to read at once and offers you narrower questions to ask instead. If we already asked you that on the previous turn, the answer is written over the rows that fit and says how many were left out.
For DOCUMENT sources (PDF, TXT, MD) there are no rows: the data IS the text. When you ask a question in a chat that has a document attached, we send the AI provider the text of each document, together with each file name, spent in the order the documents were attached. What limits the amount is the context window of the AI model in use: at most 60% of that window across everything sent, documents and query results together, or a fixed ceiling of 128k tokens when that window cannot be established. That text is sent when planning the answer and again when writing it, and a call the provider cuts short may be retried once, so one question can transmit it more than once. Longer documents are cut and the answer tells you so. On upload, before your first question, the text of the document is sent once, together with the file name, to generate the document's description and its suggested questions. That call is bounded by the same rule and no other: at most the share of the context window stated above, or a fixed ceiling of 128k tokens when that window cannot be established at all. The model that writes the description is configured separately from the ones that answer your questions, so when it is a different model its window is a different size, and the amount of text that fits differs accordingly; whenever it does not all fit, the description says so. That call is retried once if the provider cuts it short, and it is the only send a document makes before you ask anything. When an answer builds a table out of a document, each row carries the passage of the document it was read from, so you can check it: those passages are stored with the conversation, are included when you export the result as CSV, and are part of an artifact you save — including one you publish by link.
When a generated SQL statement fails to execute: we may ask the AI provider to correct it. That call sends the question, your schema and dataset description, the SQL that failed, and the database engine's error message — which can quote individual values from your data (for example, a value that did not match a column's type). At most 2 correction attempts per question.
When a result is too large for the AI model to read at once: we may ask the AI provider to write the narrower questions we then offer you. That call sends your question, the SQL that ran, how many rows it returned, and the NAMES and coarse types of the result's columns. It sends no cell value of yours. At most one such call per question.
When you save an answer as an artifact, or refine a saved artifact: we send the question, the assistant answer being saved, the SQL that ran, and the rows of its result under the same ceiling, so the AI can propose a title, a type and the document blocks. For a connected database whose owner has turned off sending rows to the AI provider (account-wide in Settings, or on that source's card), the rows are NOT sent here either: the artifact is proposed from the answer text alone. REFINING sends a different payload: the artifact's own text blocks and your instruction, plus a description of the blocks the AI may not rewrite. It does not send the question, the answer, the SQL or the rows again. Nothing is sent when you edit an artifact by hand.
Apart from the rows and the data-profile values described above (including the rows sent when an artifact is generated or refined), and any individual values a database error message may quote when a statement fails, no data of yours is sent to the AI provider; SQL against uploaded data runs in our application dataplane.
Transactional email (Resend) may receive your name and email for account messages, and receives the email you send to our privacy contact — address, subject and content — transiently, to deliver it to us.
Cloudflare processes request metadata at the edge (DNS/TLS/proxy).
6. Subprocessors
We use the following subprocessors to operate the Service:
- Hostinger: Application and database hosting (VPS/KVM). Region: São Paulo, Brazil. Transfers: Processing in Brazil (controller establishment).
- Cloudflare: DNS, TLS termination, reverse proxy, WAF. Region: Global edge. Transfers: DPA / Standard Contractual Clauses (SCCs).
- Resend: Transactional email (account, verification, notices) and inbound delivery of mail sent to the privacy contact. Region: United States. Transfers: DPA / SCCs.
- OpenRouter: LLM API gateway for AI features (schema analysis, SQL, answers). Region: United States (routes to model providers). Transfers: DPA / privacy terms / SCCs as applicable.
- Google Analytics: Aggregate, pseudonymized usage analytics (GA4). Region: United States. Transfers: DPA / SCCs.
- Google Cloud Storage: Off-box daily database backups — the complete PostgreSQL dump of the Service. Region: United States (multi-regional). Transfers: Google Cloud DPA; Google LLC self-certifies under the EU-US Data Privacy Framework / SCCs as applicable.
- Google Cloud Secret Manager: Escrow of the data encryption key, so a restored backup can decrypt connected-database credentials. Region: Multi-region (Google-selected). Transfers: Google Cloud DPA; Google LLC self-certifies under the EU-US Data Privacy Framework / SCCs as applicable.
- Stripe: Payment processing for paid plans. Region: United States / EU. Transfers: DPA / SCCs.
Material new subprocessors will be announced with reasonable advance notice via the Service or email.
7. Storage, Security, and Location
Primary hosting: Hostinger KVM in São Paulo, Brazil. Your account data, uploaded sources, conversations, and artifacts are stored in PostgreSQL on that infrastructure.
Database connection strings (for connected databases) are encrypted at rest using AES-256-GCM with a dedicated encryption key.
Access to the database is restricted to a dedicated application role with least-privilege permissions.
All API communications are encrypted via HTTPS/TLS.
We use SSRF protection on database connections to prevent access to internal networks.
SQL queries executed against your data are restricted to read-only statements with transaction-level enforcement.
Query result previews: when a question returns rows, we store a bounded preview with the assistant message. No fixed number of rows or columns is applied to a query result — what bounds each preview is size, up to 8 MiB of serialized result per statement's result set, plus a 4 KiB serialization envelope for JSON punctuation and the always-kept first row. One answer may run up to 10 SQL statements, and each statement's preview carries its own ceiling, so a single stored answer may hold up to 10 such previews; an answer read from an attached document may add one more preview — the table of values found in the text — under limits of its own rather than that budget: at most 50 rows, each carrying a short excerpt of the source document, up to 160 characters, as the evidence for that row. Within the byte budget, each cell is kept up to 10,000 characters; column names are bounded the same way, and two names that become identical once shortened are disambiguated rather than one of them being dropped; rows that do not fit are left out; individual values inside a row we do keep may be shortened when the remaining budget is tight; and a result that still does not fit is narrowed by dropping trailing columns until it does — a limit of the storage and transport, not a judgement about which columns matter, reached only by extreme results (a defect that made ordinary large results lose columns was fixed in this revision). The preview is marked as truncated when rows were left out or values inside the rows we kept were shortened by that budget; a preview that lost columns records that separately.
8. International Transfers
Your primary data store is in Brazil. Some subprocessors (for example Cloudflare edge, Resend, OpenRouter and model providers, and Google Cloud, which holds the off-box backup of the database and the escrowed encryption key) process data outside Brazil, including in the United States and other jurisdictions.
Where required, international transfers rely on appropriate safeguards such as Standard Contractual Clauses (SCCs) and/or the subprocessors' Data Processing Agreements — not on a blanket 'consent to transfer' click.
By using AI features you acknowledge that the payloads described in section 5 will be processed by those providers under their terms and our contracts with them.
9. Data Retention
Uploaded files and data: retained until you delete the source or your account.
Chat history and result previews: retained until you delete the conversation, source, or account.
Usage logs (tokens, costs): retained for up to 12 months for billing and analytics; an automatic purge job deletes older entries daily.
Published artifact links: a published page stays readable while its link exists. It stops the moment you unpublish, the moment an expiry you chose at publish time is reached, or when you delete the artifact or your account.
Account data: retained until account deletion. When you delete your account, associated application data is removed from the live database as part of that deletion flow.
Backups: once a day the complete database is dumped and a copy is sent off-box to Google Cloud Storage (United States), so the Service can be recovered after a failure. Each snapshot expires from the backup set 30 days after it is uploaded — the copy is sent shortly after the dump, and an object is never overwritten, so its expiry clock never restarts; the storage provider then deletes expired objects in its own asynchronous process, which carries no exact deadline. This is what a deletion means in practice: deleting your account, a source, a conversation or an artifact — and unpublishing a published link, which deletes the publication itself — removes the data from the live database straight away; every snapshot that still contains it expires within about 30 days, as those uploads age out, and is deleted by that process. Backups are not edited to remove one person — doing so would compromise the recovery set for everyone. A restore performed inside that window reinstates deleted data; when that happens we re-apply the deletions we can identify: every erasure recorded through our privacy contact, and — when the database that served traffic until the restore is still readable — every account, source, conversation and artifact deleted, and every published link unpublished, since the snapshot was taken. A restore that reinstated a publication would put a revoked public link back online, so the published links are part of that comparison and not an afterthought to it. We do not yet keep a record of self-service deletions that survives the database itself, so after a total loss of the live database, a self-service deletion made after the last snapshot cannot be identified and may be reinstated by the restore.
Beyond account/source/conversation deletion, the automatic cleanups we run are the usage-log purge above (entries older than 12 months) and a housekeeping deletion of expired rate-limit counters; retention statements above describe product behavior, not aspirational jobs.
10. Your Rights (DSR)
Under LGPD and, where applicable, GDPR, you may request access, correction, deletion, portability, information about sharing, restriction of processing, and withdrawal of consents that rely on consent.
Restriction of processing is a state we can put your account into, not only a request we answer: while it stands, the AI features of the product refuse to run — asking a question, generating or refining an artifact, and describing a source. Adding a NEW source is refused with them, and refused outright rather than stored without its description, so a restriction never leaves you with a silently degraded source. Signing in, reading what you already have, exporting it, deleting it and your billing all continue to work. One thing is deliberately outside that refusal: the administrative console we use to diagnose the Service runs under an administrator's own session rather than yours, and is not gated by your restriction. We impose and lift the restriction on your request, we record both acts, and your data export states it while it is in force.
In-product: view and delete sources/conversations; export and delete account from Settings (GET/DELETE account APIs).
Privacy requests: email [email protected]. We aim to respond within 15 days under LGPD and within 30 days under GDPR (extendable as permitted by law).
You may lodge a complaint with ANPD (Brazil) and, where applicable, your local EU/EEA data protection authority.
11. Cookies
We use essential cookies for authentication (session management via NextAuth JWT).
We use Google Analytics (GA4) for aggregate, pseudonymized usage analytics: page views, sessions and approximate region/browser, tied to a client identifier (the _ga cookies, which persist for up to two years and are personal data under the GDPR/LGPD). The GA4 script itself only loads AFTER you opt in — before that, nothing is loaded, and a refusal stops collection entirely. We do not use advertising cookies or cross-site tracking, and we do not build individual marketing profiles.
Google sign-in is started only when you click the Google button (OAuth). We do not load Google One Tap or other GIS scripts before consent.
Your theme preference (dark/light) is stored in localStorage on your device.
12. Children's Privacy
The Service is not directed to children under 16. We do not knowingly collect data from children. If you believe a child has registered, contact us immediately.
13. Changes to This Policy
We may update this Privacy Policy from time to time. We will notify users of material changes via the Service or email.
Where required, we will ask for a new affirmative acceptance of the updated Terms and Policy.
14. Contact
For privacy questions or data requests: [email protected] (DPO: Guilherme Favaron).