“We do not store it” is one of those software sentences that sounds complete until you ask one rude follow-up question:
Who is “we”?
Your app may send a user’s text to an AI provider, copy it into an error log, forward part of it to a tool, save the result in a database, and leave the original in an analytics event. The model provider can retain nothing while your product quietly collects five other copies like a squirrel preparing for winter.
That is why a retention setting is useful, but it is not a privacy architecture.
I did not find a stronger development in the previous 24 hours that supported a sufficiently distinct beginner lesson, so I widened the search window to seven days. On August 19, 2026, OpenAI announced an update to Zero Data Retention and previewed Private Safety Processing. OpenAI says Zero Data Retention gives eligible API customers a promise that prompts and responses are not retained after a request is processed. The new safety-processing design is intended to detect patterns across related interactions without giving OpenAI personnel access to the underlying customer content.
That is a meaningful technical direction. It is also easy for a beginner to misunderstand.
The durable lesson is not “turn on ZDR and stop worrying.” It is this:
Treat every AI request as a data export. Before you code it, write down the minimum data that may cross the boundary, every place a copy can exist, and the proof that each copy expires or is deleted.
I call that a minimum-data contract.
If you are still turning an app idea into a bounded first workflow, my AI App Builder Starter Prompts are free. Use them to define the user, input, result, and success criteria first. Then add the data contract below before the AI feature touches real user information. OpenAI’s announcement concerns eligible API customers, not a magic switch available in every consumer AI product. The company’s current API data-control documentation says API data is not used to train its models by default unless a customer opts in. It also says standard abuse-monitoring logs may retain customer content for up to 30 days, while approved Zero Data Retention or Modified Abuse Monitoring controls change that handling.
The endpoint table is the part I would make every beginner read.
Some API features are eligible for Zero Data Retention. Others keep application state until deletion or have feature-specific storage behavior. The documentation also notes that data sent to remote MCP servers or other third-party services is governed by those services’ own retention policies.
In plain English: the logo on the model call does not tell you the complete data story.
You have to inspect the endpoint, tools, files, caches, logs, database, and every service that receives the information.
AI features are usually pitched from the exciting end:
Then the implementation grabs whatever data is nearby and sends it all because more context feels safer.
It is not safer. It is merely easier to prompt.
OWASP lists sensitive-information disclosure as a major LLM application risk and recommends measures such as sanitization, validation, least-privilege access, restricted data sources, clear retention policies, and tokenization or redaction. It also warns that prompt instructions alone may not reliably prevent disclosure.
My beginner version is simpler: the model should not receive a field merely because your database already has it. Every field has to earn the trip.
Write one sentence:
The AI receives [minimum input] so it can return [specific result] for [specific user].
For an invoice-description helper, the result might be a clearer line-item description. That does not automatically require the customer’s full name, email address, payment history, tax information, internal account ID, and every previous invoice.
If you cannot name the result precisely, you cannot judge which data is necessary.
Proof: remove one field at a time from a test request. If the result remains useful, that field did not earn the trip.
Create three buckets:
A support summarizer may need the message body but not the user’s exact account number. A budgeting assistant may need spending categories and totals but not raw card numbers. A meeting-note tool may need the spoken content but not hidden calendar metadata from unrelated attendees.
Do this classification in application code before the request is assembled. “Do not reveal private data” inside the prompt is not a substitute for withholding the data.
Proof: inspect the final request object in a safe test environment and verify that blocked values never appear.
Most beginner diagrams show this:
App → AI model → Answer
Use this instead:
User input → app server → request log → AI endpoint → optional tool → response log → database → user screen
Add analytics, queues, file storage, crash reporting, caches, and human review if they exist.
This is where OpenAI’s endpoint-specific documentation matters. A Responses API call, a stored conversation, an uploaded file, a batch job, and a remote MCP tool do not necessarily have the same storage behavior. A third-party tool creates another provider boundary even if the model initiated the call.
The AI App Builder Starter Prompts are free and can help you map the workflow. For this step, extend that map with one box for every service that can receive, transform, or preserve the data.
Proof: every arrow names what crosses it, who operates the destination, and whether the transfer is necessary.
Use one row for every copy:
| Location | Data | Why it exists | Retention | Delete action | Proof |
|---|---|---|---|---|---|
| App request log | request ID, timing, status | debugging | 14 days | automatic expiry | expired test record absent |
| AI provider | allowed prompt fields | generate result | provider/endpoint policy | configured control | documented setting plus test |
| Tool provider | minimum tool arguments | complete tool action | tool policy | provider-specific | deletion/expiry evidence |
| App database | user-approved result | product history | until user deletes | delete control | record absent after deletion |
| Error tracker | redacted error metadata | diagnose failures | 30 days | project retention rule | no prompt or response content |
Do not write “temporary” or “as needed.” Use a duration, a user-controlled lifecycle, or an honest statement that the provider keeps it until deletion.
NIST’s Privacy Framework treats privacy requirements as part of the full system development life cycle—plan, design, build, deploy, operate, and decommission—and recommends verifying those requirements before operation. That is the right mental model. Deletion is a product behavior to design and test, not a paragraph to improvise later.
Proof: create a harmless test record, run the documented deletion or expiry path, and verify every system you control.
The model should not decide which customer record belongs to which signed-in user.
Your application must authenticate the user, authorize access, select the permitted records, and only then construct the minimum AI request. If the model can ask broadly for “the relevant customer data,” you have given probabilistic software a job that should belong to deterministic access control.
Test with two accounts. Ask each account to use the AI feature against its own smallest sample record. Then try an identifier from the other account. The second request should fail before any model call happens.
Proof: cross-account access is rejected by application logic and produces no outbound AI request.
Privacy diagrams love the happy path. Leaks prefer the boring paths.
Check what happens when:
A safe normal request can become three retained copies after a retry, an exception dump, and a dead-letter queue. Your model provider may satisfy its retention commitment while your error tracker preserves the full prompt.
Proof: trigger each failure with fake data, then search only the systems you are authorized to inspect for the unique fake marker. The marker should appear only in the locations named by the contract.
Do not hide the AI data boundary behind a generic “powered by AI” sparkle icon.
Tell the user, in plain language:
You do not need a legal novel inside the button. You need a short product explanation that matches the actual system, plus an accessible privacy notice for the details.
Proof: compare the user-facing explanation against the route diagram and retention table. If the copy promises less collection or shorter storage than the system performs, the build fails.
Copy this before you add an AI-powered feature:
| Question | Decision |
|---|---|
| User result | What exact outcome does the AI create? |
| Allowed fields | Which values must cross the boundary unchanged? |
| Transformed fields | Which values are redacted, tokenized, summarized, or aggregated first? |
| Blocked fields | Which values never enter the AI request? |
| Recipients | Which model, endpoint, tools, providers, and app systems receive data? |
| Retention | How long does each copy exist? |
| Deletion | Who or what removes each copy? |
| Failure | What happens during timeout, retry, fallback, or partial completion? |
| User explanation | What does the product tell the user? |
| Proof | What test demonstrates that the contract is true? |
If one row says “I assume,” the feature is not ready for real user data. Minimum-data design can reduce convenience.
Redaction may remove context that improves an answer. Short retention can make debugging harder. Avoiding a stored conversation may require your app to manage state differently. Some useful tools or endpoints may not fit the retention requirements of a sensitive workflow.
The answer is not to pretend the tradeoff disappeared. Decide which matters more for this feature, then make the limitation visible.
For a low-risk recipe-name generator, the contract can be light. For an app involving personal, financial, health, employment, legal, or confidential business information, the review should be much stricter and include qualified security and legal guidance. This checklist is an engineering starting point, not a compliance certificate. Take one AI feature you are building and replace its broad “context” object with an explicit allowlist. Draw the complete route. Add a retention row for the provider, every tool, your logs, and your database. Then run one fake-data deletion test and one failure-path marker test.
For the immediate guided action, use my [AI App Builder Starter Prompts](https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts), which are free. Add the minimum-data contract beside your user, scope, workflow, and QA prompts.
If you want the organized path from idea to publication, [AI App Builder From Zero](https://marcusykim.gumroad.com/l/ai-app-builder-from-zero) is my $19 field manual covering scope, stack, prompting, architecture, QA, deployment, and launch.
A provider retention control can protect one part of the route. Your job as the builder is to make the entire route honest.
Every field has to earn the trip, and every copy needs an exit.
You can also find me here:
Medium: [https://medium.com/@marcusykim](https://medium.com/@marcusykim)
DEV.to: [https://dev.to/marcusykim](https://dev.to/marcusykim)
Website: [https://marcusykim.com/](https://marcusykim.com/)
X: [https://x.com/marcusykim](https://x.com/marcusykim)
LinkedIn: [https://www.linkedin.com/in/marcusykim/](https://www.linkedin.com/in/marcusykim/)