Handle API keys, personal data and logs in an AI app in line with the PDPA.
An AI app needs extra care with three things: the keys that pay for it, the personal data flowing through it, and the logs that record both. If you handle each one deliberately, you can answer the questions a data protection team will ask before your app is used more widely.
Priya built an app that summarises customer complaints. Her manager suggested rolling it out to the whole customer service department. Before that happened, someone from the company's data protection team asked to see it first, with a short list of questions. They wanted to know whose personal data goes to the model provider, where prompts and replies are stored, who can read them, when they are deleted, and what happens if a key is stolen. Priya could answer the first question roughly and none of the others.
In Singapore, the Personal Data Protection Act (PDPA) sets the rules organisations must follow for personal data. The Personal Data Protection Commission (PDPC) publishes guidance on how the PDPA applies, including advisory guidelines covering AI systems.
You already keep your API key on the server as a secret, from Lesson 1.2, "Keep your API key on the server, never in the browser". Three more habits limit the damage a leaked or misused key can do.
Use separate keys for testing and production. Your laptop, your test deployment and your live app each get their own key. A key leaked from a test script then cannot touch production, and the provider console shows which environment is spending what. Many providers offer projects or workspaces with separate keys and spending limits, which makes this separation easy to set up.
Rotate keys on a schedule: every few months, and immediately whenever someone with access leaves the team. Rotation has four steps. Create a new key, update the secret on your hosting service, confirm the app works, then revoke the old key. Write these steps down for your own setup so that rotating a key is a ten-minute routine when you need it.
Give each key the least power it needs. If your provider allows it, restrict a key to certain models or features, and set a spending limit per key or per project.
Every prompt goes to the model provider's servers, which may be outside Singapore. Treat sending a prompt as disclosing data to another organisation, because it is one. Send only the minimum the task needs. This is data minimisation: sending only what a task needs. It also saves tokens.
Priya's summaries need the complaint content but not the customer's name, phone number or email. Her server now strips those three details before the model call, sends only the complaint content, and reattaches the customer ID to the result afterwards. Each summary still comes back linked to the right customer record.
Read your provider's API terms and check four things: how long it keeps prompts and outputs, whether it uses API data to train models, where it processes data, and whether you can request shorter retention. Terms vary between providers and change over time, so read the current versions on the provider's own website. Second-hand summaries and old copies may be out of date.
The PDPA places several obligations on organisations that apply directly to an AI app:
use personal data only for purposes individuals have been told about and would consider reasonable protect personal data with reasonable security arrangements do not keep personal data longer than needed make sure data sent overseas is protected to a comparable standard
How these obligations apply depends on your organisation and the data involved. Read the PDPC's guidance and involve your data protection officer before real customer data flows through anything you build.
In module 5 you used logs to debug, run evals on real traffic and trace mistakes. Logs are also a copy of every piece of personal data your app has touched, and they are often stored with less care than the main database.
Start by deciding what to log. You may not need full prompts. For monitoring, token counts, timing, the case type and whether validation passed are often enough. Where you do need full text, for debugging or building test cases, mask personal details before writing them to the log.
Limit log access to the people who need it, usually a small number of people. Having access to the hosting dashboard should not on its own let someone read the logs. A log nobody deletes grows into the riskiest data store you own, so set a retention period, such as 30 days for full prompt logs, and make deletion automatic.
Rate limits protect your money as much as your security. In Lesson 6.5, "Ship a small working app", you added rate limits per IP address. Once your app has real logins, also limit each user account: requests per minute, requests per day, and a maximum input size.
Per-user limits stop an enthusiastic user from running up the bill by accident. If someone steals a login, the limits cap them at one person's allowance, and the unusual pattern shows up quickly in your logs.
The activity below asks you to write the answers Priya could not give: a one-page data note for your app.
Write a one-page data note for your app. Say what personal data it sends, where that data is logged, who can see it, and when it is deleted.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).