What belongs in a data-flow review before a custom AI build?
Format: Article.
A data-flow review should show which information moves, why it moves, who receives it and what remains afterward. Map the exact proposed workflow, not just the products in a diagram. “Hosted here” does not answer where a model request, a log entry or a file copy goes.
Use the review to decide what may move and what must stay put. List any unknown recipient or storage rule as an open question. Name who will answer it before that part of the build uses customer data. A broad promise of privacy does not answer where a copy goes.
Trace one record through the proposed build
Choose a real kind of task, but use a fictional record or remove private details for the review. Follow it from the first read to the final screen. Include steps staff may not see. Does a service read a file, build a prompt, call a model or save an error report? A prompt is the instructions and content sent to the model.
At each step, ask which fields the task needs. A service summary may need the request ID and notes, but not every file on the account. Keep out fields that have no purpose in the task. Then test that rule. A smaller set of data can still contain private facts.
Check where data is stored and where it is used. Those may be different places. Files can stay on your server while a cloud model reads the text sent in a prompt. Name the provider and check its service and account settings before saying that all the work stays local.
Use a per-step worksheet
Complete one row for every recipient, including internal tools and external services. Add the actual provider name when selected. “Cloud” is not a recipient.
| Step | Data and purpose | Recipient or location | Decision and evidence needed |
|---|---|---|---|
| Source read | Approved request ID and notes for review | Source system and application | Permitted fields, role and account scope |
| File extraction | Selected attachment text if required | Named parser or processing service | Whether originals leave the source and how copies are handled |
| Prompt | Instructions plus approved excerpts | Named model service and endpoint | Minimum content, settings and provider terms |
| Result | Draft summary and source references | Application storage and authorized reviewer | Retention, correction and access rules |
| Logs | Errors and operational references | Named logging service | Whether prompts or files are captured, and who can inspect them |
| Backup | Agreed stored records and configuration | Backup service and region | Retention, restore access and deletion exceptions |
| Deletion | Identified records and copies | Each relevant store or processor | Request owner, permitted method and verification evidence |
For every row, record what is known, the source of that knowledge and who must resolve the remainder. A vendor's general terms and an account's actual settings are different kinds of evidence.
A hypothetical service-summary design
An established company wants a custom tool to prepare internal service summaries. In the proposed design, the source system holds account notes and attachments. The reviewer needs a short draft with references, not a new customer message.
The first diagram sends the full account file to a cloud model. During the review, the operations owner notices that unrelated commercial documents are included. The team narrows the input to the selected request and approved notes. Attachments remain excluded until a specific need and handling rule are agreed.
Next, the technical reviewer finds that an error report could save the full prompt. Cutting data from the model request has not dealt with that copy. The team asks for logs that keep only the references and details needed to investigate faults. They then plan a test to see what the logs really store.
The hypothetical design remains held for customer data until the selected provider's terms and account controls are checked. No service is claimed to be connected, and no privacy result has been measured.
Ask about retention by feature
OpenAI's API docs list abuse monitoring logs and application state as different ways data may be stored.[9] The first helps the provider check for misuse. The second is data some features save to do their job. Ask how long each kind of copy stays, rather than asking only whether the provider stores data.
“Not used for training” does not mean “not stored.” Check the exact API feature, files, tools and logs in the proposed build. Some data controls may be offered only to eligible accounts. Confirm the project's real settings. If the build uses another provider, check its rules too; one vendor's answer does not cover both.
If a tool calls another service, add that service to the worksheet. A processor diagram should not stop at the first provider merely because the application team does not see the next hop in its interface.
Turn the map into acceptance checks
Put a made-up marker in a fictional test request. In an approved test setup, check where it appears in the prompt, result and logs. Also test a field that should be kept out. Record what you could inspect and what you could not. This test is evidence for the checked path, not proof about every provider copy.
Have the business owner approve the needed data use. Ask a qualified reviewer to check material contract or legal issues. Keep each customer's data within its agreed access rules. Keep approval for sending, spending and other high-impact actions separate from reading data. A finished diagram does not certify that the system is secure.
Bring one proposed flow to Core Agentic, using sample records with private details removed. Book a Demo to discuss what a custom AI build would need to read, send and keep. Start with those details rather than a blanket privacy promise.
Sources
- OpenAI: Data controls in the OpenAI platform.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.