Employee data and confidentiality

The categories — calibrate the tool to the data

Not every piece of HR data carries the same weight, and the single most useful first move is to sort what you handle into bands.

Highest sensitivity. Full payroll with names and individual salaries, performance ratings tied to named employees, disciplinary records, medical information including leave certificates, citizenship and national identity numbers, family details collected for insurance or PF nomination. If any of this leaks, you have a labour-law problem, a privacy problem, and a trust problem with your own staff that takes years to repair. This data does not go into any tool whose terms permit training on inputs, whose access controls you cannot describe, or whose vendor you cannot name in a sentence. In practice that means enterprise tiers with no-training clauses, or no AI at all.

Moderate sensitivity. Role-level data with identifiers stripped — “Officer, Credit Department, three years tenure, performance band B” — without the name. Anonymised exit-interview themes. Aggregated training-completion records. This data is safer in mainstream tools provided the de-identification is real, not cosmetic. A spreadsheet where you have hidden the name column but left the employee ID is not de-identified; the ID maps straight back. Real de-identification removes the name, the ID, the citizenship number, and any other column that uniquely identifies one person in a small organisation. In a 60-person firm in Hetauda, “the only female engineer over 40” is an identifier even when no name is attached.

Lower sensitivity. Aggregated statistics with no individual reconstruction possible — “47 percent of our hires in 2025 were women,” “average tenure in the finance team is 3.4 years,” “we conducted 28 interviews last quarter.” These numbers are publishable. The model can chew on them freely and you can use mainstream consumer tools without anxiety. Most HR analytics work, done properly, ends up here — the sensitive data was processed on a controlled tool and only the summary numbers travelled onward.

The error to avoid is treating all HR data as one undifferentiated block — either locking everything down and getting no productivity benefit, or treating everything as drafts-of-emails and uploading the payroll. The professional move is the sort, every time, before any tool is opened.

The three stacked defaults

For any AI-assisted HR workflow that touches anything above the lowest band, three defaults stack on top of each other. None of them is sufficient alone; together they are usually enough.

Default one — minimise. Before the data hits the tool, redact what the task does not strictly need. If the question is “what is our gender pay gap,” the tool needs gender and salary. It does not need names, citizenship numbers, addresses, or the disciplinary tab. Strip the columns down to what the task requires. This is fifteen minutes of preparation that converts a high-risk upload into a moderate-risk one. The senior who skips this step is the one whose name will be on the incident report.

Default two — use enterprise tools with no-training-on-inputs clauses. The free tier of a consumer chatbot may, depending on the date and the vendor’s current terms, retain your inputs and use them for model improvement. The enterprise tier of the same product, with a signed business contract, typically does not — the contractual default flips. For HR data above the lowest band, the firm pays for the enterprise tier and routes through it. The annual cost is small compared with the cost of one breach. This default is what makes minimisation hold up: even the redacted file should travel through a tool that contractually does not learn from it.

Default three — limit internal access. Even inside the firm, not every manager needs to see the full payroll table. The HR system should already implement need-to-know controls; the AI workflow inherits them. If the original spreadsheet was visible only to two people, the AI-processed output cannot quietly become visible to twenty because somebody dropped it in a shared drive. The simplest rule is that the AI-touched file inherits the access permissions of its most sensitive input — if the payroll was restricted, the gap analysis derived from it is restricted too.

Nepal-specific concerns

Three concerns are particular enough to Nepal that imported privacy advice misses them.

The draft Personal Privacy Act. Nepal has had a Privacy Act since 2075 BS, and a working draft of a more comprehensive Personal Data Protection framework has been circulating in parliamentary committees for several years. The direction of travel is clear: explicit consent for sensitive personal data, restrictions on cross-border data transfer, mandatory breach notification, and individual rights of access and correction. The exact text is not yet law, but the firms that build their HR-AI practice around the direction — minimise, document, get consent for non-obvious uses — will not have to rebuild it when the Act is gazetted.

NRB-supervised financial-sector data residency. Banks, BFIs, and remittance companies operate under Nepal Rastra Bank directives that increasingly emphasise data residency — customer and employee data should not leave Nepal without specific approval. Most major AI vendors process inputs on overseas infrastructure. For an NRB-supervised institution, an HR officer uploading payroll to a US-hosted chatbot is potentially a directive breach as well as a privacy issue. The mitigations are either an enterprise contract with explicit data-residency commitments, an on-premise or regional deployment, or — most often, given current vendor offerings — keeping the highest-sensitivity HR data out of the tools entirely and using AI only on the lower bands.

The ICAN/ICAI dual-membership issue for HR data at audit-firm clients. A surprising amount of HR work in Nepal happens inside audit and advisory firms whose partners hold both ICAN and ICAI memberships and whose clients include large corporates. Client employee data — even something as routine as a payroll under audit — falls under professional confidentiality obligations from both institutes. An AI workflow that processes client HR data on a tool the client has not approved is a confidentiality breach with two institutes’ codes engaged simultaneously. The conservative path for audit-firm HR consultants is explicit client sign-off for any AI tool that will touch their employee data, in writing, in the engagement letter.

The “if it leaks tomorrow” test

For any AI workflow you are about to set up, run a single question through your head before the first upload: if the data I am about to put into this tool leaked tomorrow — on a blog, in a news report, to a competitor — would I lose the job, the firm’s reputation, or this candidate’s trust? The question is blunt on purpose. It cuts through the fog of “the vendor says it’s secure” and the optimism of “nobody is really watching.”

If the answer is no — the data is aggregated stats, anonymised survey results, public job descriptions — proceed. If the answer is yes, the workflow needs more containment: more minimisation, an enterprise tool, tighter access, possibly the conclusion that this particular task does not get AI assistance at all and gets done by hand. The point of the test is not to make you paranoid; it is to make the cost-of-leak visible in the same moment you are weighing the productivity benefit. Most HR professionals, asked the question honestly, calibrate well.

Written firm AI policy

The single artefact that turns these habits into something a firm can defend is a written internal AI policy for HR. Two pages, signed off by the partner or HR director, reviewed every six months. It says, in plain language: what tools are allowed for HR work and which tiers; what categories of data may be uploaded to which tools; what gets logged — every use of AI on data above the lowest band recorded in a simple register with date, user, tool, purpose, and data category; who to call when something goes wrong; the consequences for staff who upload sensitive data to disallowed tools. The policy does not need to be elegant. It needs to exist, to be circulated, and to be the document the firm points to when somebody asks how its HR function handles AI.

The firms that have this policy in 2026 will look like the serious ones in 2028. The firms that do not — that have a chatbot habit but no written stance — will look like the firms that found out about AI governance from a labour-court summons.

Check your understanding

Quick check

—

You need to summarise quarterly performance ratings across the firm to prepare a board paper on talent risk. The data includes named employees, individual ratings, and notes from each manager. Which workflow is safest?

1. APaste the full performance table into a free consumer chatbot and ask for a narrative summary in under a minute.
2. BEmail the file to a colleague who is faster with the chatbot and let them handle it.
3. CStrip the names and any unique identifiers, retain only role-level data and ratings, route through an enterprise tool with a no-training-on-inputs clause, and restrict the output to the people preparing the board paper.
4. DPrint the table, summarise by hand, and refuse to use any AI tool on HR data ever.

Check answer→

Quick check

—

What is the strongest argument for putting a written AI policy in place for the HR function, even at a small Nepali firm?

1. AIt is required under the Labour Act 2074.
2. BIt impresses clients in marketing materials.
3. CIt turns individual judgement about what tools and data are acceptable into a documented firm-level stance — which is the artefact the firm can point to when staff have questions, when an incident happens, when a regulator asks, and when the Personal Data Protection regime is finalised.
4. DInsurance companies require it.

Check answer→

What comes next

Internal confidentiality is one half of the privacy question. The other half points outward, at candidates — the people whose CVs, interview notes, and assessment scores are flowing through your AI workflows without any direct conversation with them about it. The next section is about disclosure: what you tell candidates about AI use in your hiring process, why the direction of regulation is plainly toward more disclosure rather than less, and the candor-over-evasion posture that ages well even before any law forces it.