Data Privacy When Using AI & Indonesia's PDP Law
The real risks of sending data to AI tools—PII leakage, whether inputs train the model, and vendor terms—plus how to stay aligned with Indonesia's PDP law at a general level.
AI tools are everywhere now: support agents paste customer chats to get a draft reply, marketing pastes a lead list to clean it up, finance pastes bank transactions for a summary. Fast and convenient. But every time data goes into a third-party service, one question tends to get skipped: where does this data go, how long is it kept, and who can see it?
Note: this is general guidance, not legal advice. For your specific situation, consult a qualified professional (legal counsel or a DPO).
Real risks, not scare tactics
Three things cause the most trouble:
- PII leakage. Names, national ID numbers, phone numbers, addresses, health or financial data can slip into a prompt without anyone noticing—often when they weren’t needed for the task at all.
- Inputs used for training. Some services, especially free/consumer tiers, may use your input to improve their models. Business tiers usually offer a non-training option, but that has to be verified, not assumed.
- Vendor terms nobody reads. Data retention, server location, subprocessors, and audit rights all live in documents people rarely open. The “default” settings aren’t necessarily right for sensitive data.
How this connects to the PDP law
Indonesia has a Personal Data Protection Law (UU PDP) that governs how personal data is collected, processed, and protected. At a general level the principles are familiar: you need a lawful basis to process data (such as consent), data is used for its stated purpose, it’s reasonably secured, and individuals have rights over their data.
Sending personal data to an AI tool—especially one hosted abroad—still counts as “processing personal data.” Those obligations don’t disappear just because an AI vendor is the one doing the processing. We deliberately avoid citing specific article numbers, fine amounts, or dates as hard facts, since those technical details should be verified directly. The key point stands: as the data controller, the responsibility remains yours.
Practical safeguards you can apply today
- Minimize and redact PII. Before pasting, strip what isn’t needed. Replace names with “Customer A,” mask ID and account numbers. The model can still help without real identifying data.
- Read the data-use terms and sign a DPA. Look for a non-training option, check retention, and for any serious use, get a Data Processing Agreement from the vendor.
- Prefer regional or self-hosted options for sensitive data. For genuinely sensitive data, a self-hosted open-weight model or a service with data residency is safer than a consumer public API.
- Make sure you have a lawful basis, including consent. If customer data flows through AI, make sure that’s covered by your privacy policy and the consent you collect.
- Keep an audit trail. Log which tool was used, on what data, by whom. When a question or incident comes up, those records help a lot.
A short checklist before pasting data into AI
- Is there any PII you don’t actually need? (if so, redact first)
- Does the tier you’re using train on your input?
- Where is the data stored, and for how long?
- Is there a DPA / data-processing agreement in place?
- Is this use covered by your customer consent?
- Is anyone logging this usage?
Closing
AI doesn’t need to be avoided—just used deliberately. Most of the risk disappears with two cheap habits: minimize what you send, and read the vendor terms before sending anything sensitive. For binding compliance details, still loop in a legal professional. If you’d like help designing an AI workflow that’s safe and aligned with the PDP law—from automatic redaction to self-hosted options—that’s one of the things we do.
