How your CV is de-identified before it reaches us

The starting point

A CV is one of the most concentrated pieces of personal information most people ever hand over: your name, your phone number, where you live, every employer, every date. The standard design for a tool like this is to upload all of it, keep it, and send it onward to a model.

We wanted to build this product without holding that. Not “we’ll encrypt it” and not “we’ll delete it on request” - we did not want the identifying parts to arrive at all, because data nobody holds is the only data that cannot leak.

Your file never leaves your device

When you upload a CV, the file itself is never transmitted. It is opened and read in your browser: Word documents through a document parser compiled for the browser, PDFs through a PDF reader that runs on the page, plain text read directly. Only the extracted text goes any further, and only after the step below.

One detail we went out of our way for: the PDF reader normally fetches part of itself from a public content network. We serve that piece from our own site instead. That request would never have carried your CV - but it would have told a third party that someone at your address was reading a PDF on our site, and the whole exercise is about not making those small disclosures one convenience at a time.

If we can’t read a file in the browser - a scanned image, an older Word format - we do not quietly fall back to reading it on our servers. We ask you to paste the text instead. The fallback for “we can’t do this privately” has to be “we don’t do it”, or the promise is decorative.

What the scan looks for

The extracted text is checked before anything is sent, at two levels of seriousness. Blocking findings refuse the upload outright. Warnings are flagged for you to decide about.

• Refused: email address, phone number, IRD number, NHI number, passport number, bank account number, date of birth, street address, and links to profiles that identify you.
• Flagged: driver licence number, social handles, a referee block that contains contact details, protected attributes such as nationality or marital status, and what looks like your name.

Several of those are specific to New Zealand, because a scanner built elsewhere does not watch for them. An IRD number is eight or nine digits, conventionally written in three groups. An NHI number is three letters and four digits. A bank account has its own four-part shape. None of those look like anything a generic detector is hunting for.

The ones that are harder than they look

Most of the detectors are unremarkable. Four were not, and they are the reason this took longer than an afternoon.

• Street addresses. A CV that says “I worked on the Queen Street redevelopment” must not be treated as containing your home address. So an address is only flagged when a street number and a street type appear together. 42 Rimu Street is caught; Queen Street projects is not.
• NHI numbers. The shape - three letters, four digits - collides with product codes, course codes and half the reference numbers in a procurement CV. So it only counts if the document mentions NHI somewhere. A health worker’s CV gets the check; a warehouse manager’s doesn’t get the false alarm.
• Referees. “References available on request” identifies nobody and is left alone. Referee names beside phone numbers are flagged - and note whose information that is. Your referees never agreed to have their contact details uploaded anywhere, which makes this the one detector that protects someone who isn’t you.
• Your name. Names aren’t a pattern, they’re a position: alone on one of the first few lines, in title case, no digits, none of the vocabulary a CV heading uses. That shape is specific enough to be worth flagging and far too rough to refuse an upload over - which is exactly why it is a warning. It will miss a name in a footer, and it will occasionally flag a job title sitting on its own. Both are acceptable outcomes; silently deleting the wrong line is not.

We offer the redaction. We don’t apply it

The scan can produce a cleaned copy, with each finding replaced by a visible label - [EMAIL REMOVED], [IRD NUMBER REMOVED]. We show you that copy and you accept it. We never substitute it behind your back.

This matters more than it sounds. An automatic redactor that gets something wrong removes part of your document without telling you, and you find out when the generated letter is missing something it should have had. Showing you the change and asking is slower, and it is the only version that is honest about how often a detector is wrong.

The check in your browser is not the real check

Everything above happens on your machine, which means anyone determined could skip it. So the same checks run again on our side when the document arrives, and that second answer is the one that decides what gets stored.

Both sides run the same checking code rather than two implementations that have to be kept in step - a second copy would drift, and it would drift in whichever direction was easier. The browser check exists so you get an instant answer and can clean your document up while the file is still only ever on your own computer.

What this does not do

Being straight about the limits is the only thing that makes the rest worth reading.

• It is not anonymisation. A CV with the name gone still holds your employers, your dates, your job titles and your achievements - enough for someone determined to work out who you are. We also hold your email address, because you need an account. This is still personal information under the Privacy Act 2020 and we treat it that way. Removing identifiers shrinks how much a breach would expose. It does not put us outside the rules, and we don’t pretend it does.
• It cannot detect company names. Nothing automatic can know that a particular consultancy is your own company and identifies you. That is why the upload step asks you to generalise your employers yourself, and why the automatic pass is described as a first filter rather than a guarantee.
• It cannot reliably catch exact dates. Date ranges are kept on purpose - tailoring a CV without them is useless - and dates are re-identifying in combination. That is a genuine trade-off we resolved in favour of the product working, not a problem we have solved.
• The text still goes overseas. The de-identified text is sent to Anthropic in the United States to write your letter. They do not train on it - that is a term of their commercial agreement, not a setting - and they hold a copy for up to 30 days to monitor for misuse. A shorter zero-retention arrangement exists and starts at a six-figure annual commitment, which a service at our scale does not spend. Our privacy policy says so plainly rather than implying something better is coming.

Why go to the trouble

Honestly? Because it is not much more work when you do it first. The detectors are an afternoon. Reading files in the browser is a library choice. Sharing one set of checks between your site and your server is less code than writing two.

The expensive part is the decision, and it has a deadline. Retrofitting this onto a product that already collects everything is a migration, and migrations lose to features. The version of Rolebird that asked for your full CV first and tidied up later would still be asking for it.

The same reasoning runs through the rest of the product: we show you a list of suggested CV changes instead of rewriting your CV, we never apply for anything on your behalf, and we test that the model isn’t inventing your experience - here is how we check that. Or read exactly what we hold and how to delete it.