What happens to a CV you upload.

Step by step

1. You upload a CV. It travels over TLS and is held in memory only.
2. Text is extracted from the file locally — no third party is involved in reading the document itself.
3. The candidate's name, email, phone, links and street address are removed on our server, and what is left is sent to Google's Gemini API to be turned into structured fields. This is the one point where a third party sees the content, and it is named here rather than buried in a sub-processor list. A scanned CV has no text to remove anything from, so its page images are sent as they are.
4. A Word document is built from those fields and returned to your browser.
5. Everything from steps 1 to 4 is discarded when the request finishes.

What we do keep

Only what's needed to run the business, and none of it is about a candidate:

• Your email address and agency name, so we know who is using it and can reach you.
• A count of how many CVs you've run, for the daily limit and billing.
• A salted hash of your IP address for rate limiting. Not the address itself — we need to count requests, not identify people, and a hash without a salt can be reversed by brute force.
• A salted hash of your email address, so the trial counts the mailbox rather than the spelling. Same reasoning, same treatment: the counter never holds an address.

Redaction, and why we verify it

Contact details are removed by default: name, email, phone, personal links and street address, replaced with a reference code. The town and postcode district survive, because a client needs to know where the candidate is; the street, house number and full postcode do not.

The part worth knowing: after the document is built, it is read back and checked for those details. If any would still be visible, the request fails and you get an error instead of a file. Returning nothing is better than returning a CV that costs you a placement.

Where things run

• Application and processing: Vercel, in the United States.
• Account and usage records: Supabase, on AWS.
• Field extraction: Google Gemini API.
• The business is operated from India.

If you need this in a signed agreement, the data processing agreement covers it.

What we don't do

• No training on your data by us. We build no models from anything you upload.
• No selling or sharing of your details with anyone.
• No candidate database being quietly accumulated behind the product.

One qualification, because it matters: we use Gemini on Google's free tier, and Google's terms for that tier let Google use what is sent to it to improve its products, including human review. That is exactly why the identifiers come off before anything is sent. What reaches Google is a work history with the person taken out, which can still count as personal data, so we say so rather than promise more than we can keep.

Honest limitations

Stated here rather than discovered later, because you'll find them anyway and it's better you hear them from us:

• This is a young product run by one person. It has not been through a SOC 2 audit or a penetration test. If your procurement requires either, we're not there yet — say so and we'll tell you honestly where we are.
• Output is machine-generated and should be read before it goes to a client. Extraction is deliberately conservative and copies the candidate's own wording rather than rewriting it, but no automated process is perfect.
• Sub-processors are third parties. Google and Supabase have their own terms and their own track records, and we depend on both.

Reporting something

If you find a security problem, email founder@venditas.in. It reaches the person who wrote the code, not a queue, and you'll get a reply the same day.