Module 1 · Start safe
Decisions about citizens stay with officials, and must be fair
In short
AI may tidy verification material, but eligibility, permits and sanctions are decided by an official whose name is recorded. Check every criterion against protected traits and their stand-ins.
After this lesson you can
- Explain why AI must not determine citizens' rights, assistance, permits or sanctions
- Recognise protected traits and their stand-ins in service and priority criteria
- Write decision notes that name the responsible official and the basis checked
Terms in this lesson
Understand
The hardest part of public service work is deciding: who goes on the assistance list, which application is approved, which citizen gets a warning. Such decisions have a direct effect on people's lives. This is where the temptation to use AI is greatest, because the files are many and time is short, and it is also where the risk is highest.
The AI Ethics Circular you met in the first lesson asks that AI is not run as the maker of decisions concerning humanity. Article 10(1) of the PDP Law gives data subjects the right to object to automated decisions, that is, decision-making based solely on automated processing, including profiling, that has legal effects or significantly affects them. Article 15(1) excludes this right in some cases, including the public interest in running the state, so whether it applies to your service is something to check with your data protection officer. Even so, both point the same way: decisions about people are made by people who can be asked for their reasons.
In practice, this means AI stops at the material layer. It may tidy verification files, flag incomplete documents or summarise each applicant from masked data. It does not produce an eligibility score that is used directly, does not draw up the final recipient list and does not choose who is struck off. The deciding official reads the material, records the basis of the decision, and their name is recorded. That is real human in the loop, not just a signature. That note, plus the audit log in the agency's system, is what lets the decision be re-examined if a citizen objects.
Fairness is the second risk. A model repeats patterns in its material, including unfairness. If priority criteria contain protected traits, the model applies them diligently to every file. Across InfraLoka Academy we keep protected traits in one list: age, sex, religion, ethnicity or race, marital status, pregnancy, disability, place of residence or origin, photo or appearance, and health conditions not relevant to the service. Sometimes a trait is the lawful basis of a programme, for example a service for people with disabilities or assistance for pregnant women. That basis must be written in the programme rules, not inferred by a model.
Harder to see are stand-ins: data that does not name the trait but carries it. A school name can imply religion. A village can imply ethnicity or economic class. A photo of a house can imply appearance and origin. A model also has model bias from the text it learned, so per-applicant summaries can sound more positive for some groups. So every criterion in use must be asked: does this really measure the service requirement?
Before
The prompt
Here are files for 25 business assistance applicants. Score each from 1 to 10 for eligibility and rank them from most eligible, so I only need to sign.
What came back
Bad example output: the model invented these figures and references, do not use them: a ranked list of 25 names with scores, including reasons such as still young so the business can grow, and lives in a less developed area.
After
The prompt
Goal: I am preparing verification material for the official deciding business assistance. I am not asking for scores or a ranking. Reader: the verification team. Material: programme requirements from the technical guidelines: (1) business running for at least one year, (2) a business certificate, (3) residence in the target district, (4) no similar assistance this year; and applicant files coded P01 to P25 with no names, ages, photos or addresses. Limits: check only completeness against written requirements; do not score, rank or conclude eligibility. Shape: a table of code, requirements met, missing documents. Check: flag any requirement you think could imply a protected trait.
What came back
Draft verification material. P01: requirements 1, 3 and 4 met; requirement 2, the business certificate, missing. P02: complete. Note for the team: requirement 3 concerns place of residence, a protected trait; it is valid only because the technical guidelines state it, so confirm that basis still applies.
What changed
- The first request hands the decision to a machine; the official only signs.
- The first output uses age and residence as reasons. Both are protected traits.
- The second request only checks completeness, removes identities and asks for flags on risky requirements.
Common mistake
- Mistake
- Signing a recipient list drawn up by AI without reading the files or recording the basis of the decision.
- Why it hurts
- If a citizen objects or an auditor asks why someone was struck off, the only answer is that a machine chose. A decision without a reason you can show is hard to defend, and the mistake still carries the signing official's name.
- Do this instead
- Use AI to prepare material per file, then decide yourself, write a short basis for every rejected file and keep that note in the agency's system.
Try
Each criterion below sounds neutral. Open it to see the trait it may carry.
It screens on age. Ask what is really being measured, such as business readiness, and measure that directly.
It carries appearance and an economic impression. If housing condition is truly a requirement, a survey team assesses it with written guidance.
It concerns origin. Allowed only if the programme rules set it and the basis is written.
Marital status is a protected trait and does not measure need.
Your supervisor refuses a permit application after reading material you prepared with AI. Which note is best to keep?
Take home
Before a decision about citizens is taken
- AI only prepared material; no score or ranking is used directly
- Identities and protected traits were removed from the material for AI
- Every criterion was checked for stand-ins of protected traits
- The deciding official read the files themselves
- The basis and the official's name are recorded in the agency's system
What went wrong for us
Each unit sees only its own data
- Context
- A client's app we build is used by many service units, and by a few admins who oversee them all.
- What tends to go wrong
- We do not rely on the screen to hide other units' data. The restriction sits in per-row database rules.
- What it costs if ignored
- One mistake in a view or report does not automatically expose another unit's data.
- Root cause
- Restrictions that live only in the view are easy to miss when a new feature or report is built.
- How we do it
- Per-row rules are enforced so each service unit sees only its own data, while admins see everything.
- The rule we keep
- New access to data starts as a database row rule. Where a rule alone is too broad, the server adds its own check with a test; the screen is never the only barrier.
The lessonWho sees what is decided in the data rules, not in the view.
What it means for your workWhen preparing material for AI or reports, start from your own unit's data, and ask clearly for permission to use another unit's.
Sources
- Surat Edaran Menteri Komunikasi dan Informatika Nomor 9 Tahun 2023 tentang Etika Kecerdasan Artifisial (JDIH Kemkomdigi) (accessed 26 October 2026)
- UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (JDIH BPK) (accessed 26 October 2026)