Privacy Policy

Varta runs phone calls. That means we handle recordings of conversations — yours and those of people who call you — which is about as sensitive as consumer data gets. This document is specific about what happens to it, because a vague privacy policy for a product like this would be worthless.

1. Who we are

Shivankit Technologies(“Varta”, “we”) operates the Varta platform and the Varta Android app, from India.

Under India's Digital Personal Data Protection Act, 2023 (DPDPA), we are the Data Fiduciary for your account information. When your agents handle calls or messages with third parties, you are the Data Fiduciary for that conversation and we act as a Data Processor on your behalf. For users in the EEA or UK, read those roles as controller and processor respectively.

Questions, requests, or complaints: common@shivankit.com. Our Grievance Officer under §13 of the DPDPA is reachable at the same address with “Grievance” in the subject line.

2. What we collect

From your account

• Email address, and a display name if you give one. Sign-in is handled by Supabase Auth; we store the tokens it issues, never your password in readable form.
• Phone numbers you register, SIM and gateway configuration, agent prompts, and the voices you configure or clone.
• Billing details, processed by Stripe. Card numbers go to Stripe directly and never reach our servers.
• Usage and diagnostic logs: call counts, durations, error traces, IP address, browser or device type.

From calls and messages your agents handle

• The phone numbers of both parties, and call timing.
• Audio recordings of the call, encrypted at rest.
• Transcripts, and the AI-generated summaries, topics and sentiment scores derived from them.
• The content of WhatsApp or SMS messages you route through the platform.
• Contacts you import, so the agent can tell your landlord from your mother.

From the Android app specifically

This section maps one-to-one onto the app's Play Data safety declaration.

• Microphone audio — captured only while a call is active, and only with a foreground-service notification visible for the whole duration. The app does not record in the background and has no wake-word listener.
• A push token from Firebase Cloud Messaging, so the server can wake the app when an agent needs a decision. Firebase Messaging is the only Firebase product in the app — there is no Analytics and no Crashlytics SDK.
• Crash and error information, reported to our own servers, not to a third-party analytics vendor.
• Your session token, stored on the device in Android's EncryptedSharedPreferences. That token can drive real machines, so plaintext storage was never an option.

The app does not collect location, does not read your contacts from the device, does not read your SMS inbox, and carries no advertising or analytics SDK of any kind.

If you use the on-device model, the prompt, the conversation history and the generated reply stay on your phone. That code path makes no network calls at all.

3. Why we collect it

• To run the service — route calls, transcribe them, let your agent answer sensibly, and bill you correctly.
• To keep it working — debug failures, monitor latency, find the call that broke.
• To prevent abuse — spam, fraud, harassment, and uses that would put our telephony providers in breach.
• To meet legal obligations — tax records, and lawful requests from Indian authorities.

We do not sell your data and we do not share it with data brokers. Our model providers are contractually bound not to train on the data we send them.

4. Improving our models

We are building AI models of our own, and conversations are what they learn from. This section says exactly which conversations, and what we do to them first.

It is off unless it is turned on. Nothing is used to improve our models unless the organisation the account belongs to has opted in, and no organisation is opted in by default. It can be turned off again at any time, and doing so stops any further use immediately.

The decision sits with the organisation, and we tell you when you join one. Accounts on Varta belong to organisations, and the setting is held there rather than on each individual account. That is a real transfer of a choice away from you, so we do not bury it: when you are invited into an organisation you are told, before you accept, whether that organisation has turned model improvement on. If it is on and you would rather it were not, that is a conversation with your administrator — but you will never find out afterwards.

Only your own conversations with your own agents. If you talk to an agent you configured, that exchange is yours to share with us. Calls from other people are excluded — when a customer rings a number you operate, you are the Data Fiduciary for that conversation and they agreed to nothing with us. We do not use it, whatever your setting says.

It is redacted before it is stored, not before it is used. The redacted form is what lands in our training store; the original never does. We do this at capture rather than later because an unredacted copy that exists anywhere is a copy that can leak, and no amount of subsequent cleaning undoes that.

We keep a short list of things, not everything except a list of things.This is the part most privacy policies get backwards, so it is worth being exact. We do not scan for personal data and remove what we find. We keep a small set of fields that cannot identify anyone — whether a request succeeded, a status, a quantity, a price, a currency, what you asked to search for — and everything else is replaced by a description of its shape, such as “a list of six entries” or “a string of 40 characters”.

That removes considerably more than your name and address. It also removes product names, delivery notes, free text, and any field we did not anticipate. We do it this way because a list of dangerous field names can never be complete: a connector can call a field anything, and every name we failed to think of would be a leak. Keeping a list of safe ones means a field we have not seen before loses its contents instead of escaping.

What the agent did, not only what it said.When your agent uses a tool — checking a cart, looking up a train, reading a balance — we keep the name of the tool, the request it made, and what came back, all redacted as above. This is the part we most need and the part carrying the most of other people's data, so it is worth being plain: the results of those tools are the bulk of what is stored, not the words spoken.

We keep a description of what we removed.Alongside the redacted text we store a structural note — how many entries a list had, how long a field was, what kind of value it held — and never the values themselves. It exists so that redaction can be audited by us and questioned by you: “we removed a list of six addresses” is checkable in a way that a bare placeholder is not.

The honest limits of that redaction. Identifiers are replaced one at a time and not consistently, so a reference that appeared twice in one conversation does not remain recognisably the same reference — which costs us some ability to analyse a conversation, and is the trade we prefer. And redaction protects what is stored; it is not a claim that the result is anonymous or safe to publish. Nothing we store is published.

Audio is used to improve speech recognition, and for nothing else. Recognising Indian speech — Hindi, English, and the mixture of the two that most people actually speak — is not a problem you can solve with text alone. So for organisations that turn this on, recordings of their own calls are used to measure how accurately we transcribe, and to improve it.

It is never used to build a voice. We do not train voice clones on it, and a cloned voice is never a model input. It is not published and not sold.

Everything beyond transcription is still text — the transcript, the tools the agent called, and what they returned — because what we are optimising for there is whether an agent chose the right tool and asked the right question, which is a text problem. Being specific about that is the point: “we may use your data to improve our services” is the sentence this section exists to avoid.

5. Recognising a returning caller

This one is about your voice as a biometric, so it gets its own section.If an organisation has Voice ID switched on, our system can recognise that the person speaking is someone it has heard before — independently of which phone they are calling from. It does that by turning a few seconds of speech into a mathematical summary, called an embedding, and comparing it against summaries it has stored before.

An embedding is not a recording and cannot be played back, but it is still biometric information about you, and we treat it that way. It is stored per organisation and never shared between organisations, so being recognised by one agent does not make you recognisable to another.

What it is used for, and only this: so an agent knows it is speaking to the same person again, and so it can tell when a familiar phone is being used by somebody different. It is never used to identify you to anyone else, never matched against anyone outside that organisation, never used to build a synthetic copy of your voice, and never sold or published.

How to be left out.An organisation can turn Voice ID off for all of its calls. You can ask for your stored voice profile to be deleted at any time, using the contact details in section 13 — deletion removes the profile and any pending samples, and the system starts over as if it had never heard you.

6. Telling the other party

Every call your agent answers opens with a spoken disclosure that the call is recorded and AI-assisted. This is not removable. The wording and the language it's spoken in are configurable; its presence is not.

Indian law generally treats single-party consent as sufficient for recording. If your use case falls under sectoral rules — lending, insurance, healthcare, debt collection — obtaining any further consent is your responsibility as the Data Fiduciary for that conversation.

7. Who else touches the data

Each of these receives only what its job requires. None of them receive your data for their own purposes.

• Supabase — account records, application database, authentication.
• Deepgram — speech-to-text, unless you have configured a local recogniser.
• OpenAI — language model inference. Sent per call under an API agreement that excludes training on submitted data.
• Cartesia — voice synthesis, including cloned voices.
• Google Firebase Cloud Messaging — push notifications to the Android app.
• Stripe — payments and invoicing.
• Resend — transactional email such as beta invites and deletion confirmations.
• Langfuse — model call tracing, used to debug agent behaviour.
• LiveKit — real-time audio transport for in-browser calls.

Speech recognition on our own infrastructure runs on GPUs in India. Some processors above operate outside India, so your data may be processed abroad; we rely on their contractual data-protection terms for those transfers. If you configure local providers for speech, language and voice, no call content leaves your own hardware at all.

8. How long we keep it

• Call recordings and transcripts — until you delete them, or until your account is deleted.
• Account records — for the life of the account.
• Diagnostic logs — 90 days, then rotated out.
• Billing records — eight years, as Indian tax law requires. These contain no call content.
• Encrypted backups — a rolling 90-day cycle. Deleted data ages out of backups on that schedule and is never restored into the live system.

Redacted training text is kept for as long as we are improving models with it, and is deleted when you turn model improvement off. It carries no recording, no audio, and no direct identifiers — those are replaced before it is stored.

9. Your rights

Under the DPDPA — and, where they apply, the GDPR — you can:

• Ask what personal data we hold about you, and get a copy.
• Correct anything inaccurate or incomplete.
• Delete your account and its data. There is a form for exactly that; it needs no sign-in and works after you've uninstalled the app.
• Withdraw consent, which ends the processing that relied on it.
• Turn off model improvement, in your account settings, at any time. It stops immediately. Conversations already redacted and folded into a training set cannot be pulled back out of a model that has already learned from them — which is the honest limit of this right, and the reason the setting starts off.
• Nominate someone to exercise these rights on your behalf in the event of death or incapacity (DPDPA §14).
• Complain to us first, and then to the Data Protection Board of India if we haven't resolved it.

We answer rights requests within 30 days. Write to common@shivankit.com.

10. How we protect it

• Call audio is encrypted at rest; all transport is TLS.
• Database access is governed by row-level security, so one account's data is not reachable from another's session.
• On the phone, session tokens live in EncryptedSharedPreferences, backed by the Android keystore.
• The app refuses any server-supplied URL that could point at another host — a bearer token that can be aimed anywhere is an exfiltration primitive, so the client enforces this itself rather than trusting the server to behave.
• Administrative access is limited to named people who need it.

No system is perfect. If a breach affects your personal data we will notify you and the Data Protection Board of India as the DPDPA requires.

11. Children

Varta is not for anyone under 18. We do not knowingly collect data from children. If you believe a child has created an account, write to common@shivankit.com and we will remove it.

12. Changes to this policy

If we change how we handle your data in any material way, we'll email registered users before it takes effect and update the date at the top. Continuing to use Varta after that means the new version applies.

13. Contact

Shivankit Technologies · common@shivankit.com
Grievance Officer: same address, subject line “Grievance”.

This policy describes a product in closed beta and will be revised before general availability. It is a description of our practices, not legal advice.