How Grab uses an LLM to find the personal data in its data lake
You cannot protect personal data you cannot find. Grab handed the finding to a large language model, kept data owners as the final check, and stopped treating half its data as top secret. Here is how it works, and why Indonesian companies should pay attention before January 2027.
Every growing company ends up with the same mess: thousands of tables, nobody quite sure which columns hold a customer's phone number or ID number, and an access policy that is either too loose to be safe or so strict that nobody can get work done. Grab, the Southeast Asian super-app for rides, food delivery and payments, has this problem at petabyte scale. In October 2023 its engineers described how they use a large language model to tag every column with the kind of data it holds, while the data's owner keeps the final say. It is one of the most practical uses of an LLM inside a company we know of, and with the implementing regulation for Indonesia's personal data protection law taking effect in January 2027, it is about to matter to a lot more businesses.
The problem: when half of everything is top secret
Grab sorts data into sensitivity tiers, from Tier 1 (highly sensitive) to Tier 4 (nothing sensitive), and the tiers decide who can access what. The tagging used to be manual: campaigns asked data producers to label their own schemas. The result, in Grab's words: "half of all schemas were marked as Tier 1, enforcing the strictest access control measures." A single sensitive table made its whole schema Tier 1, so a lot of harmless data sat behind the strictest controls. Moving access control down to the table level would fix that, but not safely without knowing what each table actually contained.
Manual campaigns could not keep up with the volume of data, and developers read the internal policies and external regulations differently, so the same kind of column got different labels. A first attempt at automation, an internal service called Gemini (named, Grab notes, before Google announced its Gemini model), paired a third-party classifier with regex rules. The vendor's classifiers could not be customised and the regex produced too many false positives.
How they built it
The appeal of an LLM was that governance rules could be written as plain-language instructions and customised "effortlessly without code or model training". The system has three parts.
An orchestrator that respects limits. Data platforms send classification requests to Gemini, which batches them through a message queue for workers running GPT-3.5, alongside the third-party classifier while Grab compared the two. A rate limiter keeps the calls under the provider's limits, which in 2023 meant a 4,000-token context and a single shared quota of 240,000 tokens per minute. Results flow back through Kafka, as the diagram at the top of this article shows.
A prompt written like a policy. The prompt tells the model it is "a database column tag classifier" for a company that provides ride-hailing, delivery and financial services, then gives it a library of tags with definitions: Personal.ID for government ID numbers, Personal.Name, Personal.Contact_Info, Geo.Geohash and so on. The definitions also say what a tag is not: Personal.ID "should absolutely not be assigned" to internal identifiers such as a passenger or driver ID. Grab lists four techniques: state the requirements clearly, give a few examples, enforce the output schema (JSON with a column name and an assigned tag), and "allow for confusion" with a default None tag, so the model can admit it cannot decide instead of guessing.
A human who confirms. Predictions are not final. The data platforms ask owners every week to verify the tags, and a notice in the platform flags datasets that may contain personal data.
The confirmed tags, combined with rules from Grab's data privacy office, set each table's sensitivity tier, which in turn drives attribute-based access control and dynamic data masking.
What it delivered
Grab reports that within a month of rollout the system had scanned more than 20,000 data entities, around 300 to 400 a day. For tables whose owners acknowledged the predictions, users changed on average less than one tag. In an internal survey of data owners in September 2023, 80 percent said the new process helped them. Assuming a person needs about two minutes per entity, Grab estimates savings of around 360 man-days a year, at a cost it calls "extremely affordable contrary to common intuition", without giving a figure.
Note what is missing: Grab published no accuracy percentage. "Less than one tag changed per acknowledged table" says owners found the tags useful. It does not say how often the model was wrong on the tables nobody checked, and that gap is exactly what the next version worked on.
What has changed since
Version 2 learned where personal data hides. In November 2024 Grab described Metasense V2, the production version. Owner feedback showed where the model struggled: personal data in unexpected places, such as a "business email" column holding someone's personal address, names and phone numbers buried in nested JSON, and passenger messages. Grab's diagnosis was model capacity, since 13 of the original 21 tags only told kinds of non-personal data apart. So it split the job: one pass for personal-data tags, cut from 21 to 8, and one for everything else. It also trimmed the prompt from 1,254 to 737 words, split tables wider than 150 columns, and moved prompts into LangChain and LangSmith, where each version is evaluated against a dataset before deployment. Grab now calls its misclassification rates "exceptionally low", again without a number, and alerts on them if they cross a threshold.
A regulator took a close look. The work went through the Privacy Enhancing Technology Sandbox of Singapore's IMDA, which concluded in March 2024, and IMDA's case study adds useful detail. Users without access to restricted data can still query it, with the personal-data columns hashed using SHA-256. In the proof of concept, the share of data available without extra access approvals rose from about 50 percent to about 85 to 90 percent. Singapore's Personal Data Protection Commission named the main risk: the model missing personal data and downgrading it from restricted to unrestricted. Grab's safeguards include rule-based cross-checks, sampling by its data governance office, and a policy that the LLM may not learn from owners' tag revisions, because an edit that wrongly removes a personal-data tag could teach it to stop spotting that kind of data.
Classification became AI infrastructure. In a July 2026 post on its agent platform, Grab notes that its LLM tooling resolves the model endpoint "per environment, and per data tier". The tiers that began as an access-control project now also help decide which model endpoint a request goes to.
Why it matters for your business
Indonesia's Personal Data Protection Law (UU PDP, Law No. 27 of 2022) has been fully binding since its two-year transition ended in October 2024. Its implementing regulation, Government Regulation No. 33 of 2026, was signed in July 2026 and takes effect on 16 January 2027. Among much else, it spells out the record of processing activities controllers must keep: what personal data you process, about whom, why, where it flows, how long you keep it and how you protect it. In Nusantara DFDL's reading of the regulation, that record is "the foundation document and typically the first document a regulator will ask for".
That is Grab's problem in legal form. You cannot list the personal data in each system if you do not know which columns hold it, and the law singles out "specific" personal data, such as health, biometric, financial and children's data, for extra care. Administrative fines can reach 2 percent of annual revenue. They are imposed by a supervisory agency that, as of September 2026, had not yet been established, but DFDL's view is that obligations not tied to the agency apply from January 2027 regardless. We are engineers, not lawyers, so check the details with your counsel.
In most Indonesian companies, personal data does not sit in one tidy data lake. It sits in a production database, a CRM, marketplace exports and dozens of spreadsheets someone made for a campaign two years ago. Column names mix Indonesian and English (nama_lengkap, no_hp, tgl_lahir), and plenty of personal data hides in free-text notes. That is exactly where hand-written rules break down and a language model does well.
How we would build it today
- Crawl everything. Pull table and column names, types and a few sample values from every database, CRM and shared drive, spreadsheets included.
- Rules for the obvious, a model for the ambiguous. Deterministic checks catch anything with a fixed shape, such as a 16-digit NIK, a +62 phone number or an email address, cheaply and exactly. The LLM handles what rules cannot: a "keterangan" column full of names and addresses, a JSON blob, a mixed-language column name. As in Grab's second version, personal-data tags get their own short pass with a None option and a strict JSON output. Samples are masked before they reach a hosted model, because raw samples sent to a model overseas are personal data leaving the country. When the content itself has to be read, an open-weight model runs on your own server instead.
- Owners confirm, and the model never learns from removals. A weekly digest in the tool the team already uses, whether email, Slack or a WhatsApp group, asks owners to confirm. We track how often they override the model, keep a rules engine scanning for anything it missed, and never let an owner's edit silently retrain it.
- Make the tags do work. Tags set tiers, tiers drive masking and access, and the inventory exports straight into your record of processing activities. Re-run on every schema change.
Grab's numbers are big, but the pattern fits a company of fifty people. The hard part is not the model. It is agreeing on your tags, keeping a human on the final say, and wiring the result into the controls you already have.