Before Client Material Goes Into a Third-Party Tool, Check the Actual Permission
Before Client Material Goes Into a Third-Party Tool, Check the Actual Permission
Somewhere in a project thread there's a message like this: the tool says it doesn't train on your data, so I'll run the client's product shots through it this afternoon. Nothing in that sentence is dishonest. It's just an answer to a question nobody asked. The question that matters isn't does this service train on my inputs? It's am I allowed to hand this particular file to this particular service, for this particular task, under this particular account?
Those are different questions, with different owners, different evidence, and different ways of going wrong. The no-training statement settles one subquestion inside the provider's half of the problem. It says nothing at all about the client's half.
The short answer: describe the transfer precisely enough that someone could approve or refuse it in one sentence. Get the client-side answer from whoever holds the relationship. Read the provider's conditions yourself, for the feature and account you'd actually use. If either side is unresolved, use an approved substitute or leave the file where it is. None of this requires a law degree. It requires noticing that two permissions are being treated as one.
Describe the proposed transfer precisely
Most of these decisions go wrong at the description stage. "Use a creative tool to help with the deck" cannot be approved or refused by anyone, because it doesn't name the thing being decided.
Convert it into an operation. Which file, from which folder, entering which named feature of which named service, under which account, to produce what — and who else ends up with access as a result of the operation itself. Uploading a product image to a one-shot analysis returns labels and a palette. Uploading it into a shared project workspace also hands viewing access to two collaborators and possibly a link. Same file, same service, different transfer, because the access consequence changed.
Two assumptions are worth naming out loud, because they're the ones people make silently.
The first: permission to see a file inside an existing project does not extend to sending a copy somewhere else. The person who can open the deck is not thereby authorized to disclose it. Access is about who may look at something in a bounded place. Disclosure is about the file leaving that place. These are related, but they aren't the same permission, and the second one doesn't follow from the first.
The second: making a copy is a decision even if you delete it afterwards. Retention is a provider condition to check, not a cleanup step that undoes the transfer.
So the unit of decision is this transfer. When a colleague says "the studio's fine with that tool," the useful reply is not a debate about the tool's reputation. It's the one-sentence version of the operation, so it can be answered.
Separate the owner's permission from the provider's conditions
There are two ledgers, and they don't trade against each other.
The client ledger. Find the relevant instructions or working agreement and read the scope language for what it actually contemplates. Does it cover using client materials in connection with the project? Does it say anything about third-party services, named vendors, or processors? Is there a brand-side vendor-security requirement attached to the engagement? If someone at the client said "sure, test it with a tool" in an email, check whether that email named a service that matches the one you'd actually use, and whether it was written by someone with authority to say it. A verbal or chat-level "sure" is a data point about the relationship, not necessarily the permission you need.
The provider ledger. Read what the service says about processing, storage, sharing, human review, and model training, as applied to your proposed use. Not as a general reputation check. As the handling conditions for this feature on this account.
Then keep them separate. A strong provider answer does not create client permission. A broad client permission does not change how the provider treats the file. A client's shrug does not resolve an unanswered provider question. And when the two point in different directions — the client's requirements stricter than the provider's defaults — the stricter one governs your decision, because you're the one who has to satisfy both.
The failure mode here is substitution: reaching for the answer you have because you can't get the answer you need. "They don't train on it" is a marketing-shaped claim about one processing purpose, from the party with an interest in your reading it favorably. It's worth reading. It isn't a signature, and it doesn't answer a question about disclosure to a third party. When the two ledgers disagree with each other, leave the disagreement visible on paper rather than resolving it by picking the more convenient reading.
Check the account and feature actually involved
Provider policies are not one document. A vendor can run several products under several sets of terms, and the question it answers about one profile type or feature may not answer the same question for another. Statements are scoped, and the scope is the first thing to look at.
Adobe's Content analysis FAQ is a useful illustration of the shape of the problem — not a verdict on anyone's setup. The page, recorded as updated June 4, 2026, and checked for this article on 2026-09-08 and again on 2026-09-18, is organized into separate sections covering generative AI, personal versus business profiles, content held on the company's servers, and human review under limited circumstances. That division is the lesson: the page treats training, content analysis, profile type, and human review as distinct questions, each with its own context and its own exceptions. Expect any serious provider to make similar divisions, and expect that a sentence lifted out of one section will not answer a question that belongs to another.
Two traps follow from that.
A default is not a control, and a control is not your setting. "You can opt out" describes a capability the service offers. An option is not a state. What you need is a fact about an account, and you cannot report that fact from having read the option.
Reading the documentation is not auditing the account. The person who can open the admin console is the person who can say what's switched on. Ask them, and record what they saw and when they saw it. If nobody has looked at the settings for the account you'd use, then the account-specific conditions are unconfirmed, no matter how clear the public page is.
And resist extending. A statement about one profile, one program, or one feature does not describe the provider's whole catalog. Team plans, enterprise agreements, and individual accounts routinely differ, and features inside a single plan differ too.
Keep the limits attached to the evidence. The FAQ is the provider's own current description of its own practices. It is not independent verification of what the systems do, not advice about your account, and not permission from your client. Policy pages get revised. Anything you rely on should be read at the time you rely on it, not remembered from the time you first encountered it.
Choose an authorized route, not a workaround
If both ledgers are resolved — the responsible client-side owner has confirmed this disclosure, and the handling conditions for this account and feature are confirmed — proceed, within that scope. But notice what the scope covers. The confirmation named a file, a use, and an account. A second file, a different feature, or a different team workspace is a new transfer that inherits none of it automatically.
If either side is unresolved, the real options are narrow and unglamorous:
- An approved nonconfidential substitute: material you're free to disclose.
- A method that doesn't transfer the material at all — local processing, a description written by hand, a question answered by a person instead of a service.
- Holding the work, with the specific open question sent to whoever owns the answer.
What does not work is the category of move that looks like a fix and isn't. Redacting the logo. Cropping the label. Renaming the file. Uploading from a personal account so the operation doesn't appear in the team workspace. Using a free tier "just to test." None of these establishes permission, and several make the disclosure harder to see afterwards, which is worse than the disclosure. If the material's confidentiality is the issue, muting the identifying marks doesn't change the status of the thing being sent. If the material genuinely isn't confidential — a licensed stock frame, a public asset, an invented mock — then that isn't a workaround, it's an authorized substitute, and you should be able to say which one it is and why.
The reflex to avoid at the end of all this is the blanket safety verdict. Contractual and security uncertainty has an owner: usually the person who holds the client relationship, sometimes an in-house legal or security contact on the client side. Route it there by name. A confident answer from someone who isn't the owner is not an answer. It's a liability with your name on it.
One image, two open questions
Invented case. No account was audited and no upload is performed in it.
A researcher on the team wants a cloud service's image-analysis feature to read a client's confidential product image — an unreleased shot from a packaging shoot — and return object labels and a palette description for a treatment section. The working agreement permits use of client materials in connection with the project. It says nothing about sending them to a third-party service. The provider publishes a no-training statement covering inputs. Storage, sharing, and review conditions for the studio's specific account have not been confirmed, and nobody has opened the admin settings. Two separate questions are open, and they belong to different people.
The transfer question, written so it can be answered. May the client's unreleased product image, delivered under the referenced agreement for use in the project deck, be uploaded to the named service, to the named feature, under the studio's plan account, and retained in that service's project for the duration of the treatment work?
The account question, written so it can be checked. What are the storage, sharing, and review settings for this feature on the studio's plan account? That is a fact about an account, not about a policy page, and only the person who can open that account's admin console can report it. Nobody has looked, so this one is open too.
The owners. The transfer question belongs to the engagement lead who holds the client relationship — the person who can put it to the client's brand contact and bring back a written answer. Not the provider's support page. Not the teammate who created the account. Not a colleague who has used the same tool on other clients without incident.
The account question belongs to whoever administers the studio's plan account and can read its settings — the person who opens the admin console and reports what it shows, and when they looked. Name that person before the work depends on their answer. Until both have answered, neither ledger is closed, and the confidential image stays where it is.
The substitute. An image the studio already has rights to: a licensed stock frame, or a product shot from a different, nonconfidential project, run through the same feature under the same account.
What the substitute can settle. Mechanics and format. Does the feature accept the file type and size? Does the output arrive in a shape the treatment template can absorb? Is the label quality useful enough to justify the setup time? Does the plan level actually include the feature, or does it push a limit or a watermark? Those are real answers, and none of them requires confidential material.
What the substitute cannot settle. Anything about the client's actual product. If the question is whether the tool's reading of this product is accurate enough to build a visual direction on, a different image answers nothing — the tool may recognize the stand-in and fail on the real item, or the reverse. The substitute validates the pipeline. It does not validate the creative judgment about the client's product, and it certainly does not validate the disclosure.
Recorded outcome. The substitute test proceeds. The confidential image stays out of the service, held until the client's answer and the account check are both recorded. The transfer question above goes, dated, to the engagement lead; the account question goes to the studio's administrator, who reports the settings back in writing. The treatment section advances on the tool's mechanics meanwhile. Three states, all visible: what is permitted, what is pending on each ledger, and who owns each open question.
Notice what nobody did. Nobody declared the tool safe, and nobody declared it unsafe. The provider's training statement was read and recorded; it simply wasn't an answer to the question blocking the work.
That's the whole method. Write the transfer in one sentence. Name the two ledgers. Name the person who closes each one that's still open. Then record which of three outcomes you're in: the transfer is authorized as described, an approved substitute is used, or the material stays out pending named decisions. Anything beyond those three is a guess wearing a policy citation.
Frequently asked questions
Does a provider's no-training promise authorize uploading client material?
No. It may settle a provider subquestion about one processing purpose, but it says nothing about whether the client permits handing that file to that service, for that task, under that account. These are different questions with different owners and evidence.
How should a transfer be described so it can be approved or refused?
Describe it as an operation: which file or folder, entering which named feature of which named service, under which account, to produce what, and who else gains access. The same file in a one-shot analysis versus a shared workspace is a different transfer because the access consequence changed.
What are the two ledgers, and how do they relate?
The client ledger covers scope, third-party services, vendor-security requirements, and the authority of whoever grants permission. The provider ledger covers processing, storage, sharing, human review, and training for the proposed feature and account. A strong answer on one does not create or resolve the other; the stricter requirement governs.
Why isn't reading public provider documentation enough?
Policies are scoped to products, profiles, and features. An option is not an account setting, and reading documentation is not auditing the account. Someone who can open the admin console must report the actual settings and when they were checked, because public pages can be revised.
What can an approved nonconfidential substitute settle, and what can't it settle?
It can settle mechanics and format: file type and size, output shape, label quality, and plan feature limits. It cannot settle accuracy on the client's actual product, creative judgment about it, or permission to disclose confidential material.