Client Data and AI: Check the Path Before You Upload

By 9,6Hz Agency

Published 2026-10-10T00:29:48.381808+00:00

Before using client files with AI, check training use, retention, access and local options. A practical review for briefs, interviews and unreleased media.

Before sending client material to an AI tool, identify the actual data path. What leaves the computer, which service receives it, who can access it and how long it may remain are different questions. A feature being useful does not answer them, and “not used for training” does not mean “not retained.”

This article offers a review method for creative teams. It does not describe an audited security system at 9,6Hz Agency or make promises about the agency's account settings. The agency's confirmed position is to use AI as support while keeping real filming central. The interview and launch examples below are fictional.

AI-generated editorial concept about data choices. It does not depict or certify an agency security system.

What counts as client material in a creative workflow?

It can include more than the finished video. A brief may contain an unreleased positioning idea, an interview may include personal information, and a call sheet may reveal names, phone numbers and location details. A reference folder can also include material the client licensed only for a particular use.

Look inside the file, not just at its extension. A harmless-looking planning document may contain comments, hidden slides or embedded images. An audio recording may include conversation before the formal interview starts. Decide which content the AI task actually needs before uploading the full source.

For a fictional launch film, AI may only need a redacted description of the required deliverables to help organize questions. It may not need the product name, launch date, budget or unreleased design. Removing those details can keep the task useful while narrowing the information shared.

Which policy questions should you separate?

Read the policy for the exact service, account type and feature. OpenAI's data-use documentation distinguishes individual services from business products and notes a separate Codex setting for full environments. That is an example of why one general privacy statement may not cover every setting. It does not establish which choices are active in the agency's account.

For API processing, the OpenAI data-controls documentation discusses retention and endpoint-specific controls. Treat that as service documentation to review, not evidence that your organization has a particular retention arrangement. Check the relevant product and configuration before making a statement to a client.

How do you map the path before a pilot?

Write the task in one sentence, then list its inputs and outputs. Follow the input from the source folder through the application, any connected services and the returned result. Note whether a connector or shared workspace adds another recipient.

Check what the tool can read. A coding assistant with access to a directory may receive more context than a single selected document. A media tool may create analysis files beside the original. A collaboration feature may expose an output to workspace members. The visible prompt is not always the complete boundary.

Keep the first test on public, synthetic or properly authorized material. A fictional interview can reveal whether a transcript is editable; a generic brief can test question organization. Only expand to real sensitive inputs when the task requires them and the chosen path has been reviewed.

What can you remove without breaking the task?

Replace names with role labels when identity is unnecessary. Remove contact details, account numbers, confidential dates and internal budget information from a working copy. For a planning comparison, retain only the production constraints that change the answer.

Check the copy after redaction. Search for names in comments and file names, review images and read the remaining context. Removing a name may not make a person unidentifiable if the rest of the document describes a unique situation. Use a genuinely fictional example when identification would still be possible.

Keep the original intact in its appropriate location. A redacted working copy should not overwrite the source or become the only project record. Label it so a colleague knows that omissions are intentional and can return to the authorized original when needed.

When is local processing worth considering?

Local processing can reduce the need to upload source media for a particular task. The official Whisper repository provides a locally runnable transcription option. Adobe documents local analysis and search for Media Intelligence. These are examples to evaluate, not a confirmed agency workflow.

Test quality and practical requirements. The local tool still needs suitable hardware, installed models and enough storage. An inaccurate transcript is not useful simply because it stayed on the machine. Review names, technical terms and the actual passages that will be quoted.

Local does not mean no data risk. Cloud sync may copy the folder, logs may contain material, and another feature in the same application may use a remote service. Check storage, access and sharing around the processing step. A local choice narrows part of the path; it does not certify the whole environment.

How should permissions be discussed?

Identify who can authorize the proposed use of the material. A person sending you an interview does not automatically give permission for every new processing purpose. Explain what you want the tool to do and what it would receive. Keep the authorization connected to that task.

Review existing project agreements and the client's instructions before expanding use. If the conditions are unclear, develop independent parts with fictional or redacted material while the responsible people resolve the question. Do not treat a tool's subscription terms as the client's permission.

Separate consent for appearing in a filmed interview from permission to generate a new likeness or voice. Those are different actions with different consequences. This article does not interpret any particular contract; it recommends making the intended use visible and seeking the appropriate review when necessary.

Who needs access to the output?

Give access according to the actual handoff. An editor may need a transcript and source timecodes; a designer may need a disclosed concept image; a producer may need a comparison of requirements. They may not all need the original confidential brief.

Check shared links and workspace membership before handing off. A result that appears private in a personal view may be visible in a team space. Avoid copying sensitive extracts into a new tool simply to make the handoff convenient.

Record where the working result is kept and who is responsible for removing it when it is no longer needed, within the applicable project requirements. Do not promise deletion behavior you have not verified. “Deleted from our visible folder” and “removed from every provider record” are different statements.

What should a practical review record contain?

1. The task and why the material is needed.
2. The actual service, account type and feature.
3. The input scope and any redaction.
4. The relevant policy pages and date checked.
5. The authorization and permitted recipients.
6. The output review and storage location.
7. Any unresolved limit and the alternative method.

Keep credentials out of that record. Record the configuration's meaningful effect without copying API keys or passwords into notes. Do not turn a privacy review into another repository of sensitive information.

Use plain, bounded statements. “This test used a fictional transcript and local processing” is verifiable. “All client data is always secure” is far broader than the evidence. The review should help a colleague choose the next step, not create an assurance the team cannot support.

What if the task cannot fit the permitted path?

Choose a different method. You can transcribe manually, use an approved local process, remove unnecessary inputs or keep that part outside the AI task. A tool does not have to touch every document to be useful in the project.

Explain the tradeoff in production terms. If a local transcript needs more correction, schedule the review. If an unapproved cloud feature is excluded, use the existing search or logging method. The goal is a workable result under the project's conditions, not maximum AI use.

Recheck when a service, feature, account or integration changes. A review of one configuration should not silently approve a later one. Keep the decision linked to the actual path and the kind of material involved.

Common questions

Does “no training” mean no storage?

No. Review retention separately, including any relevant logs or application state.

Can you use a desktop tool without checking policy?

No. A desktop interface does not establish where a specific feature processes content.

Can public reference material always be uploaded?

No. Public visibility does not establish the rights or permission for every new use. Check the material and intended task.

Sources checked on 10 October 2026. This is a practical review method, not a legal interpretation or a claim of certified agency infrastructure. Read the tool-selection guide, explore the portfolio, or discuss project constraints with 9,6Hz Agency.