Using AI to write HR scripts in Singapore: what PDPC says

Suppose an HR operations manager has interview feedback in a spreadsheet and asks an AI assistant to write a script that copies each score and set of notes into the right candidate record in an applicant tracking system (ATS). The prompt describes the spreadsheet columns and ATS fields, but contains no real candidate records.

Once the finished script connects to the live ATS, it can read candidate information and change application records. If the matching logic is wrong, one candidate's interview feedback could be written to another candidate's record.

The AI assistant never receives the candidate data. The script it helped create later accesses and changes it.

Singapore's Personal Data Protection Commission (PDPC) addresses this kind of risk in a 30 September 2026 advisory on employees using unauthorised AI tools to develop software or scripts.

If AI-written code can touch real candidate or employee data, treat it like a live system, not an experiment.

What does PDPC's AI coding advisory mean for HR?

The advisory does not ban AI-assisted coding. It recommends controls for organisations that let employees use AI to create software that may later handle personal data.

For an HR team, the questions are practical: Which AI tool was used? What information was given to it? Who checked the code? Was the finished script tested? What real data could the script reach or change?

The legal duty is not new. Section 24 of the Personal Data Protection Act already requires organisations to make reasonable security arrangements to protect personal data in their possession or under their control. The advisory gives additional guidance for the newer situation of employees using AI to write software.

The advisory focuses on three risk areas. For the interview-feedback import, they translate into three straightforward checks.

Start with the result, not the code

A script can finish without errors and still change the wrong candidate record. Before you write or approve the code, define what a correct result looks like.

For the interview-feedback import, do not begin with:

Write a Python script to import this spreadsheet into the ATS.

Write down what a correct result looks like first:

For each row, write the interview score and notes to the candidate record with the matching application ID. Only update candidates for this job. If the application ID is missing, duplicated or does not match a candidate, stop that row for review. Do not change any other candidate fields or stages.

Now the recruiter and the person reviewing the code are working from the same expected result. A better prompt may improve the code, but this written result gives you something independent to test it against.

Before you build anything, check whether you need custom code at all. Your ATS, interview platform or existing integration may already import or sync the information with built-in permissions, audit history and support.

If an existing feature already does the job safely, custom code may only give your team another piece of software to maintain.

The same habit is useful before you automate anything with AI: start with the job, then decide how much machinery it actually needs. Onboard Your AI is our free AI course for talent and people teams, built around everyday work and taking learners from better prompts toward a first AI agent. It is useful for that design step. Once code can touch candidate or employee data, the review, testing and access controls in this article still apply.

If you still need the script, use that expected result to review it before it reaches real candidate data.

Five checks before the script touches candidate data

The five checks below are Screened's practical synthesis, not PDPC's wording. They cover the advisory's three risk areas, then add two questions that matter once code connects to live systems: what the script can reach or change, and how far a mistake could spread.

1. Was the AI tool approved, and what did you give it?

Start with the AI service and account used to create or change the code. Then record what information you gave the AI.

For example:

"Write a script that reads application_id, interview_score and interview_notes columns."

That prompt names three spreadsheet columns but contains no candidate records. Uploading a real applicant list, code containing a password or API key, or a screenshot with employee information is different: now real data or account secrets are going into the AI service.

An approved enterprise AI account does not automatically make every input or every use acceptable. Follow your organisation's rules for personal data, passwords, API keys and confidential material.

Keep two decisions separate. First, is the AI tool approved for this kind of work? Second, is this particular script safe to use with your real systems and data?

2. What data can the code access, and what can it do?

Do not review only the code. Check what the account or connection lets the script reach in the real system.

For this import, the script needs to identify the intended application and write the interview score and notes. That does not mean it should also be able to delete applications, move candidates to another stage or change unrelated records.

For any script, list both the data it can reach and the actions it can take:

read, change, send, upload, download, move, delete

The more it can reach or change, the more damage a mistake can cause. Give the script only the access it needs.

3. Who can review the code properly?

A recruiting manager can decide what the script should achieve. Managing the recruiting process does not necessarily mean they can verify how the code works.

Someone reviewing the code should be able to answer questions such as:

• How does the script choose which candidate record to update?
• Can one candidate's interview feedback be written to another candidate's record?
• What happens when an input is blank or invalid?
• Which systems and accounts can the script reach, and can it affect records outside the intended job?
• What happens if the script fails or is run again? Does it leave candidate data in logs or temporary files?

PDPC's advisory recommends that people with the necessary technical competence review and validate AI-generated code before it goes live.

If nobody on the team can review the code properly, reduce what the script is allowed to do, use an existing product feature or get help from someone who can review it.

A second AI model can help spot mistakes, but it is not a substitute for someone who can understand the code and its access.

Code review tells you what the script appears capable of doing. Testing shows what it does in practice.

4. Did you check the actual output?

Before the script touches real candidates, test it with invented candidates in a test job or account you control.

PDPC recommends synthetic or dummy data for testing rather than the real personal data used in live systems.

For a small recruiting script, start with a few normal cases and a few cases that should fail.

Do not stop at:

Import completed successfully.

Open the affected ATS records and inspect what changed. Check the candidate, job, interview score, notes and any other fields the script could alter.

5. How will you limit the damage if something goes wrong?

Review and testing will not catch every mistake. Add controls that keep one error from spreading.

Controls can include:

• limiting the script to the test or live job it is meant to update;
• allowing it to change the interview fields it needs, but not unrelated stages or fields;
• starting with a small batch before a full import;
• making sure a retry does not repeat updates that already succeeded; and
• monitoring the import and having a clear way to stop it.

The aim is to make a mistake small, visible and recoverable.

Scale the review to what the script can do

Use the same five checks, but go deeper as the consequences grow.

• Invented data with no live connection: keep the experiment isolated.
• Reads live data but cannot change it: check what it can read, store and expose.
• Changes records or sends messages: add code review, end-to-end testing, narrow permissions and a recovery plan.
• Can act across several systems: design its permissions and approvals before giving it access.

The interview-feedback import belongs in the third group because it changes ATS records. A short script with that access can deserve more scrutiny than a much larger tool that only reads test data.

Worked test: importing interview feedback into the ATS

Turn the expected result into cases that should pass and cases that should stop for review. Use invented candidates and a test job.

After the import, inspect the ATS itself. A successful script log is not enough evidence that the right records were changed.

Keep one short approval record

Once the test passes, keep one short record before the script is used with real candidate or employee data. It should show what was tested, what access was approved and who approved the use.

If the code, input format, destination, permissions or an important connected service changes, decide which checks need to be repeated.

The record should be easy to scan later: who owns the script, what was approved, what was tested and how to stop or repair it. That matters most if something later goes wrong.

If the script exposes or mishandles personal data

Stop the script or unsafe action first. Keep the evidence needed to understand what happened, such as the relevant version of the code, settings, logs, test records and affected outputs.

Then assess whether the breach must be reported. Under section 26C of the PDPA, an organisation that has reason to believe a personal-data breach occurred must assess, reasonably and promptly, whether it is notifiable. PDPC's breach guide says organisations should aim to complete that assessment within 30 calendar days.

A breach is notifiable if it is likely to cause significant harm, or if it is or is likely to be of significant scale. The current regulations set the significant-scale threshold at 500 affected individuals. A smaller breach can still be notifiable if the significant-harm test is met. Section 26B; Data Breach Regulations

If the breach is notifiable, section 26D requires notification to PDPC as soon as practicable and no later than three calendar days after the day the organisation makes that assessment. Breaches involving significant harm generally also require notification to affected individuals, subject to the Act's exceptions.

Fixing the code is only one part of the response. The organisation still needs to assess the breach and understand how the script was able to reach the affected data.

Common questions

Can HR use ChatGPT, Claude, Copilot or another AI assistant to write scripts?

PDPC's advisory does not impose a general ban on using AI assistants to write scripts. But tool approval is only the first step. Separately check what the generated code can access or change, who can review it, how you will test it and how errors will be contained.

Can we use real candidate data in a test environment?

PDPC recommends synthetic or dummy data for testing rather than the real personal data used in live systems. For this kind of recruiting script, use invented or synthetic test records and accounts you control.

Does this apply to Excel macros, Apps Script, no-code automations or vibe coding?

Yes. If AI-generated logic in a macro, Apps Script or automation can access, send or change personal data, the same review and testing questions are relevant.

Before you let the script run

Before you let the script use real candidate or employee data, make sure you can answer five questions:

What should happen? What data can the script reach, and what can it do? Who reviewed the code? What did you test? How would you stop it if something went wrong?

If you cannot answer those questions, the script is not ready for real candidate or employee data.

The prompt is only where the code started. Before you use the script, look at the finished result: what it can access, what it can do and what the testing showed.

If the AI itself is screening or interviewing candidates, the risk is broader than AI-written code. See AI hiring in Singapore: current rules and practical safeguards. For the separate question of how long to keep candidate records, see How long should you keep candidate data in Singapore?.

If your team is evaluating AI screening rather than building an internal script, discuss the workflow with Screened.

Guidance and source material checked 23 October 2026. This article provides general information, not legal advice or certification that a workflow complies with the PDPA. Appropriate controls depend on the organisation, data, systems and use case.