Candidate and employee data that stays out of the model

HR work almost always touches data about people. A job post draws CVs, and CVs hold names, addresses, work history and sometimes photos. Once a person is hired, the data grows: salary, bank account, social security number, national ID number (NIK), sick-leave records, performance reviews, disciplinary notes. All of this is personal data under the PDP Law, and some of it is specific personal data, such as health data, personal financial data and criminal records. The legal basis is covered in the PDP Law basics lesson; here we apply it to the HR desk.

The rule we keep is simple: employee salaries, health data, disciplinary records and ID numbers never go into a general AI service. A general AI service means one your organisation has not contracted to process employee data, including your own personal account. The reason is not that such services are surely malicious, but that you do not know where the data is stored, for how long, who can read it, or whether it is used to train a model. The employees whose data you paste were never asked either.

Candidate data is slightly different but still sensitive. Candidates send a CV for one purpose: to be considered for the opening they applied to. Using that CV in a new tool, especially one that processes data abroad, may need a new basis. This lesson covers three groups: data that never goes in, data that may go in after masking, and data that may go in only through a tool whose basis has been set up.

The good news is that most HR tasks you want AI help with do not need real data. The model needs the shape of the data, not its contents. If you want a formula for remaining leave, the model only needs the column names, the leave rule and two made-up sample rows. If you want a clear announcement of a pay rise, the model needs the structure of the rise, not a list of names and amounts per person. If you want to tidy an attendance report layout, send a table with made-up codes such as K-01 and K-02.

How it works: first write what you want to produce, then ask what the model minimally needs to know for that. Usually the answer is rules, structure and samples. The real data stays in the HR system, and you run the result yourself there. How to mask data properly, including why replacing names with codes does not yet make data anonymous, is in the masking data lesson.

A CV is a special case because a CV-reading feature does need the CV's contents. Here the question is no longer shape or contents but where the data goes. Many models process data on servers outside Indonesia, and sending a CV there is a cross-border data transfer. Article 56 of the PDP Law sets the conditions, and when the other conditions are not met, the candidate's consent becomes the basis. Before a model reads a CV, make sure your organisation has answered: where the data is processed, what the basis for the transfer is, whether candidates are told and asked to consent, and whether candidates who refuse have a way forward without being disadvantaged.

A note on work accounts. An organisation that has contracted an AI service for HR usually has an agreement on data storage, model training and server location. That makes some work possible, but it does not mean all data may go in. Specific data such as health and disciplinary records still needs a clear reason and is best processed in the HR system itself. Ask your data protection officer what is allowed for your work account, and write the answer in your team's notes so everyone follows the same rule.