Your Candidates' Data Is Safe Here.
USP Series · No. 4 Because "we take data seriously" is something every software company says. Here's what it actually means in practice.
The question nobody wants to ask out loud
When a recruiter or TA leader first looks at a tool like /avlo:, there's usually a question sitting just beneath the surface that doesn't always make it into the demo call.
"What happens to the candidate data?"
It's a completely reasonable question. CVs contain personal information — names, addresses, employment history, sometimes phone numbers and dates of birth. Feeding that into an AI tool and hoping for the best isn't a compliance strategy. GDPR is central to how any responsible data processor should be operating, and with ICO enforcement very much a reality, "we didn't really think about it" isn't an answer anyone wants to be giving to their legal team.
So let's just answer the question properly.
Where your data lives
/avlo: stores all candidate and job data on UK-based servers — specifically in London. Not the US. Not "the cloud" (which, more often than not, means somewhere in Virginia).
This matters for UK GDPR compliance. Data processed and stored within the UK doesn't trigger the cross-border transfer considerations that come with US-based storage. It's one less thing to worry about, and it's baked into the architecture — not bolted on as an afterthought.
CVs go in. They don't wander off.
When a candidate CV is uploaded to /avlo:, it goes directly into secure storage. It doesn't pass through any third-party service on the way. It doesn't sit in someone's email inbox. It doesn't get copied to a system you didn't know about.
The pipeline is straightforward by design: browser to secure storage, directly. The CV is read for screening purposes and that's what it's used for. Nothing else.
We don't train on your data
This one matters more than people realise.
Some AI tools — not all, but some — use the data that passes through them to improve their models. Which means candidate CVs, job briefs, and hiring decisions could theoretically be feeding back into a system that other customers then benefit from. Or that the vendor uses for purposes you didn't agree to.
/avlo: doesn't do that. Candidate data is used to screen candidates for the role it was submitted against. It is not used to train models, improve algorithms, or anything else. It goes in, it does its job, and it stays where it's supposed to be.
There's a broader point worth making here too. If your recruitment team is currently using a public AI tool — pasting CVs into ChatGPT, running candidate profiles through a free consumer product — there's a reasonable chance that's already a GDPR problem. Personal data submitted to public models may be used for training purposes, is processed outside a formal data processing agreement, and candidates almost certainly haven't consented to their information ending up there. It's one of those things that feels harmless until someone asks the question officially.
/avlo: operates under a formal data processing framework. The boundaries of what happens to candidate data are defined, documented, and not left to chance.
Transparency about AI is built in
This is something we feel strongly about.
Where /avlo: contacts a candidate directly — as it does as part of the Clarification Loop — that communication makes clear that AI is involved in the screening process and that no automated decision is being made about their application. A human recruiter is involved. The AI is informing the process, not running it.
More broadly, recruiters using /avlo: should include a simple AI screening disclosure at the point of application — something candidates see before they apply. This is good practice under UK GDPR, straightforward to implement, and means the whole process is transparent from the start. /avlo: makes it easy to do the right thing; the recruiter just needs to make sure the right statement is in place when the role goes live.
Infrastructure you can trust
/avlo: is built on Supabase — the same database infrastructure trusted by PwC, Johnson & Johnson, Mozilla, and 1Password. SOC 2 and GDPR compliant, with all data encrypted at rest and in transit. Not a scrappy startup experiment — battle-tested infrastructure used at serious scale by serious organisations.
User accounts and login credentials are handled by Clerk — a dedicated authentication platform built specifically for this purpose. That means industry-standard security practices for credential management, session handling, and access control, without compromise.
No ads. No data sales. No funny business.
/avlo: is a recruitment screening tool. That's the product. The business model is straightforward: you pay for the tool, the tool does its job, your data isn't the product.
Candidate information is not sold. It is not shared with advertisers. It is not monetised in any way beyond the core screening function it was collected for. There's no secondary use, no data partnerships, no small print worth worrying about.
You're in control of your data
Most tools make data retention an afterthought — something buried in the settings nobody reads, or a support ticket you have to raise and wait on.
/avlo: gives you full flexibility. Set your own retention periods to match your organisation's policies. Request data deletion simply and directly, without jumping through hoops. If a candidate exercises their right to erasure under UK GDPR, you can action it. If your internal policy is to purge candidate records after six months, you can set that up.
Your data, your rules. We're not holding onto anything you don't want us to.
The short version
If your legal or compliance team asks — and they probably should — here's the summary:
Data stored on UK-based servers in London. CVs handled in a secure, direct pipeline. No third-party data sharing. No model training on candidate data. AI transparency built into candidate-facing communications and easy to implement at point of application. Full flexibility over data retention and deletion. No data sold or monetised.
That's not a list of promises. It's a description of how the product is built.
Candidate data is a responsibility, not a resource. /avlo: treats it accordingly.
Part of the /avlo: USP Series — a look at what makes us different, one feature at a time.
Early access is open at avlo.uk
