You will be able to handle API keys, personal data and logs in an AI app in line with the PDPA.
When Priya's manager suggested rolling the summariser out to the whole customer service department, someone from the company's data protection team asked to see it first, with a short list of questions. Whose personal data goes to the model provider? Where are the prompts and replies stored? Who can read them? When are they deleted? What happens if a key is stolen? Priya could answer the first question roughly and none of the others.
An AI app handles three things that need care beyond what you have built so far: the keys that pay for it, the personal data that flows through it, and the logs that record both. In Singapore, the Personal Data Protection Act, the PDPA, sets the rules organisations must follow for personal data, and the Personal Data Protection Commission publishes guidance on how they apply, with a set of advisory guidelines that cover AI systems.
You already keep your 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 make a leak less likely and less damaging.
Use separate keys for testing and production. Your laptop, your test deployment and your live app each get their own. Then a key leaked from a test script cannot touch production, and you can see in the provider console which environment is spending what. Many providers let you create projects or workspaces with separate keys and spending limits, which makes this easy.
Rotate keys on a schedule. Create a new key, update the secret on your hosting service, confirm the app works, then revoke the old key. Do it every few months, and immediately whenever someone with access leaves the team. Write the steps down, 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 lets you restrict a key to certain models or features, or set a spending limit per key or project, do so.
Every prompt you send goes to the model provider's servers, which may be outside Singapore. Treat that as disclosing data to another organisation, because it is one.
So send the minimum. Priya's summaries need the content of the complaint. They do not need the customer's name, phone number or email address, so her server now strips those before the call and reattaches the customer ID to the result afterwards. Sending only what a task needs is called data minimisation, and it saves tokens as a side effect.
Then read the provider's terms for its API. Check how long it keeps your prompts and outputs, whether it uses API data to train models, where it processes data, and whether you can request shorter retention. These terms vary between providers and change over time, so read the current versions on the provider's website rather than relying on what someone told you last year.
Under the PDPA, organisations must use personal data only for purposes individuals have been told about and would consider reasonable, protect it with reasonable security arrangements, not keep it longer than needed, and make sure data sent overseas is protected to a comparable standard. How these obligations apply to your app 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.
Logs are how you debug, run evals on real traffic and trace mistakes, as module 5 showed. They are also a copy of every piece of personal data your app has touched, often stored with less care than the main database.
Decide what you log. You may not need full prompts. Token counts, timing, the case type and whether validation passed are often enough for monitoring. Where you do need full text, for debugging or building test cases, mask personal details before writing them.
Limit who can read the logs. The people who need them, usually a small number, get access. Not everyone with access to the hosting dashboard.
Delete on a schedule. Set a retention period, such as 30 days for full prompt logs, and make deletion automatic. A log that nobody deletes grows into the riskiest data store you own.
The last protection is about money as much as security. In lesson 6.5, Ship a small working app, you added limits per IP address. Once your app has real logins, limit each user account too: requests per minute and per day, and a maximum input size.
Two things are protected. An enthusiastic user cannot run up your bill by accident. And if a login is stolen, the thief's use is capped at one person's allowance, and the unusual pattern shows up in your logs quickly.
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: what personal data it sends, where it 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).