By KYN AI Advisory Team — AI implementation specialists, Singapore
An AI agent stores data in at least six places: the database, file storage, logs, the model provider's servers, backups and the vendor's support tools. Most buyers ask only about the first. Ask your vendor to name the location, the owner and the retention period of all six, in writing, before you connect a single customer record. If the answer is "it depends", the data is not under your control.
Why does the storage location matter?
Three reasons, in order of cost.
- Law. Personal data of customers and staff has rules attached to where it goes and how long it stays. Singapore's PDPC enforces the PDPA, and the same logic applies in Hong Kong, Indonesia and Malaysia. We cover the Singapore rules in PDPA and AI agents in Singapore.
- Exit. Data you cannot extract is data you rent. If the vendor closes, raises prices or changes terms, you need your records and your configuration in a form you can move.
- Breach scope. A vendor that holds data from many clients in one shared database has one failure that touches all of them. A system in your own cloud account has a failure that touches you only.
The question is not "is it secure". Every vendor says yes. The question is "whose account is it in, and who holds the keys".
What are the six places an agent keeps data?
| Location | What it holds | Question to ask | |---|---|---| | Primary database | Contacts, deals, ledgers, tasks, agent outputs | Which cloud account, which region, who is the account owner? | | File storage | Uploaded PDFs, receipts, contracts, images | Same account as the database? Encrypted at rest? | | Logs and traces | Prompts, replies, tool calls, the actor on each action | Do logs contain full customer text? How long are they kept? | | Model provider | The text sent for each model call | Is it used for training? Is it retained, and for how long? | | Backups | Copies of all of the above | Where do they sit, and how do you delete a record from them? | | Vendor support tools | Screenshots, tickets, debug exports | Can vendor staff read customer data? Is each access logged? |
Logs deserve extra attention. Teams secure the database and then write every prompt, with the customer's name and phone number inside it, to a log service. The log becomes the largest copy of your data.
What should the vendor say about the model provider?
Every agent that writes or reads text calls a language model, usually hosted by a third party. Your data crosses that boundary on each call. You need four facts:
- Which provider and which model family handle your text.
- Whether the provider trains on your inputs. Major providers publish terms for their business and API products. Read the vendor's actual contract with the provider, not the consumer app's terms.
- Retention at the provider. Some providers keep API inputs for a short period for abuse monitoring unless a zero-retention arrangement is in place. Ask which applies.
- Region. A model call from a Singapore system may be processed in another country. Ask where.
If the vendor cannot answer from a document, treat the answer as unknown. We list further vendor questions in what questions a company should ask an AI vendor about security.
Whose cloud account holds the data?
This is the single question that settles most of the others.
- Vendor's account (multi-tenant). Your data sits beside other clients' data. Separation depends on the vendor's code. You see only what the vendor shows you. Exit depends on an export feature.
- Your account (single-tenant, in your name). The vendor deploys into an account you own. You can see the resources, read the access logs and revoke the vendor's role. The system keeps running when the vendor leaves.
The second model costs more to set up and less to leave. It is the only model where "we do not have access to your data" can be a technical fact rather than a promise. For the trade-off in more depth, see multi-tenant database security: what to ask your web developer.
If the vendor does run a shared database, ask how separation is enforced. Row-level security in the database itself is a stronger answer than "our application filters by customer ID". A bug in application code removes the filter. A database policy does not depend on the application remembering to apply it.
Who at the vendor can read your data?
Ask for the list by role, not the policy.
- Do engineers have standing access to production data, or do they request time-limited access?
- Is each access logged with the person's name and a reason?
- Can you see that log?
- Are support staff able to open a customer's records, and under what approval?
Shared logins are a red flag. If three engineers use one admin account, the log says "admin" and nothing else. Named accounts through the cloud provider's identity service give you a log that names a person.
How is data deleted?
Deletion has three parts, and vendors often cover one.
- The record. Deleting a contact removes the row. Does it also remove the copies in search indexes, caches and exports?
- The backups. Backups age out on a schedule. Ask how many days, and whether a deleted record can reappear on restore.
- The model provider. If text was sent to a model, does the provider hold it, and for how long?
For a request from a customer to delete their data, you need a procedure that touches all three. Ask the vendor to walk through one real deletion, end to end, and show the log entry.
Also ask what happens when the contract ends. A sound answer names a date by which all data is returned and then destroyed, and says what proof you receive.
What proof should you ask for?
Words cost nothing. Ask for artefacts.
- A data flow diagram showing every system your data touches, including the model provider.
- The list of sub-processors with their countries.
- Your cloud account's resource list, if the system runs in your account.
- A sample of the access log showing actor, action and time.
- The contract clause on training, retention and deletion.
- A recent summary of any independent security assessment, with the scope stated. A report that covers the vendor's office network does not cover the product.
A vendor that works inside your cloud account can show most of this from your own console. One that works in its own account has to produce it for you, and the quality of that effort tells you something.
Where KYN fits
KYN builds systems that run in a cloud account in the client's name. The database, file storage and logs sit in that account, so the client can see every resource and read the access log. Row-level security is enforced in the database. Each user works through one restricted account per session, and agents have their own restricted accounts. Every action is logged with the actor. Outbound messages, money, filings and deletions wait for a named person. If the client revokes KYN's role, the system keeps running.
The first 14 days are a review of your stack and interviews with your team, including a map of where your data lives today. A full build ships in under 90 days. See security and infrastructure.
Frequently asked questions
Is a Singapore data centre enough?
No. The region of the database is one fact out of six. Check the model provider's processing location, the backup location and the support tooling too. Data can leave a region through a model call even when the database never moves.
Should logs contain full customer messages?
Only if you need them, and then with a short retention period and restricted access. Many teams log an identifier and the action, and keep the full text in the primary database where access rules already apply. Decide this before launch, because changing it later means purging old logs.
What if the vendor refuses to name its sub-processors?
Treat it as a no. You cannot assess a data flow you cannot see, and several privacy laws expect you to know who processes personal data on your behalf. Ask again in writing, and consider a vendor that can show the flow from inside your own account.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
