Privacy, consent, and personal data in Nepal · Working with Data

The moment your dataset contains a name, a phone number, a citizenship number, a face, or a precise location, you are no longer just working with data — you are working with information about real people, and the decisions you make have real consequences for them. This section is not a complete legal guide; the law in Nepal is evolving, and you should consult a real lawyer for anything that touches commercial deployment. But there is a baseline of judgment, hygiene, and ethics that every builder should carry, and that baseline is the subject of this section.

What counts as personal data

A useful working definition: personal data is any information that could be used, directly or in combination with other data, to identify a specific person.

The obvious cases:

Full name, citizenship number, passport number, license number
Phone number, email address, physical address
Date of birth, place of birth
Biometric data: face photo, fingerprint, voice recording
Financial account numbers
Health records, diagnoses, prescriptions

The less obvious cases that catch builders off-guard:

Combinations that uniquely identify even without a name. (Gender + date of birth + district can identify a small number of people; in a small enough community, just date of birth and district can.)
Precise GPS coordinates over time (commuting patterns reveal home and workplace).
Browsing history, search queries.
Photographs that include faces in the background, even if those are not the subjects.
Voice recordings — modern systems can identify speakers from a few seconds.

The principle that helps in edge cases: if removing the dataset would prevent a real person from being identified or targeted, the dataset contains personal data. Treat it accordingly.

The four principles to internalise

A working ethical baseline. None of these is sufficient on its own; together they are a starting position.

A person should know that their data is being collected, what it will be used for, and have the meaningful ability to refuse. Meaningful means real, informed, and revocable — not a hidden checkbox in a 4,000-word terms of service.

For datasets you receive from someone else, ask: did the people in this dataset consent to it being used in the way you are about to use it? If a bank gave you customer transaction data, did the customers consent to AI experimentation on it? Often the legal answer is “yes, in the small print”, and the ethical answer is “they had no idea”. Both answers matter.

Minimisation

Collect only the data you actually need. If your model only needs age_bucket (under 30, 30-50, over 50), do not collect date_of_birth. If your model only needs province, do not collect street_address. Extra data is extra liability — for you to store, for you to leak, for someone to misuse.

When you receive data containing more than you need, drop the unnecessary columns at the earliest possible step in your pipeline. Document what was dropped.

Purpose limitation

Data collected for one purpose should not be used for another without renewed consent. Loan-default data collected to help microfinance institutions assess risk should not be used to train a marketing model, even if the data is technically available. Purpose limitation is what protects people from data they shared in good faith being used against them later.

Security

Personal data should be protected. Encrypted at rest, transmitted over secure channels, stored only where access is controlled. A CSV of customer data on your desktop is a leak waiting to happen. Even small datasets deserve basic hygiene:

Never commit personal data to git, even private repos.
Never email personal data as attachments.
Never store personal data unencrypted on shared drives.
When the work is done, delete the data unless there is a documented reason to keep it.

Nepal-specific considerations

The legal landscape in Nepal is shifting. The Privacy Act 2018 and the Individual Privacy Regulations 2020 establish baseline protections. The forthcoming Data Protection Act (in draft as of 2026) is expected to be stronger and more explicit. Specifics worth knowing today:

Citizenship and passport scans are highly sensitive. A leak of even a few thousand creates real harm — fraud, impersonation, harassment. Treat any project that touches these with extreme care.
Health data is regulated separately and stringently. Working with patient records, prescriptions, or diagnoses requires explicit ethical review, even in research contexts.
Children’s data is treated with extra protection in most jurisdictions, and Nepal is moving in this direction. School datasets that contain identifiable students require consent from guardians.
Caste and ethnicity are sensitive categories that can be (and have been) used to discriminate. Models that use these as features risk codifying discrimination. Often the right move is not to collect or use them — and to actively audit for their proxies.
Cross-border data flows are increasingly scrutinised. Storing Nepali personal data on US-hosted cloud services is often fine today but may not be in two years; build with portability in mind.

Practical hygiene patterns

Concrete habits that protect both you and the people in your data.

Pseudonymise as early as possible. Replace identifying columns with random IDs. Keep the mapping in a separate, secured file.

import hashlib

def pseudonymise(citizenship_number: str, salt: str) -> str:
    return hashlib.sha256((salt + citizenship_number).encode()).hexdigest()[:12]

df["borrower_id"] = df["citizenship_number"].apply(lambda c: pseudonymise(c, "your_salt"))
df = df.drop(columns=["citizenship_number", "full_name", "phone"])

After this, the dataset’s borrower_id cannot be reversed without the salt — and the original identifying columns are gone. Keep the salt in .env, never in git.

Aggregate to the smallest acceptable group. Instead of precise addresses, use municipality or district. Instead of exact ages, use buckets. Instead of timestamps, use day-of-week.

Audit access. If your team shares the dataset, log who accessed it and when. A simple folder permissions check is better than nothing.

Have a deletion plan. Before you start the project, decide: when this is over, what happens to the data? The default should be “delete unless we have a documented reason to keep it”.

Be cautious about combining datasets. Two datasets that are individually low-risk can be jointly identifying. A list of “students by school” is fine. A list of “students by school and birth date” is much more identifying — and combining the two re-creates the identification.

When to refuse

A sometimes-uncomfortable principle: not every project should be built. Some projects, even legal ones, are bad ideas. A model that predicts which children in a school are likely to drop out and shares the prediction with teachers may help; the same model that shares it with employers causes harm. A facial recognition system for a private secure facility may be appropriate; the same system in a public square is something else.

A useful test: if the people in the data could see how their data was being used, would they be glad about it? If the answer is no, or “they would not understand”, or “they would be furious”, reconsider the project.

A builder’s most important professional skill, in the end, is the ability to say “I won’t build that”. It is rare. It is worth practising.

Check your understanding

Quick check

—

A team has been handed a CSV of microfinance applications containing full names, citizenship numbers, phone numbers, addresses, loan amounts, occupations, and default flags. The goal is to build a default prediction model. Which of the following is the most appropriate first move?

Start training the model immediately on all available columns.
Audit which columns the model actually needs (probably loan amount, occupation, and district — not name, full citizenship number, or phone). Drop the unnecessary identifying columns at the earliest step in the pipeline, pseudonymise any identifier the team still needs to keep, and document what was dropped and why. Personal data minimisation is both ethically right and reduces the consequences of a leak.
Email the CSV to all team members so everyone can see it.
Upload it to a public GitHub repo for transparency.