A supplier emails: “We can review this faster if we put your CAD into our AI tool. Is that OK?” Before answering, turn that sentence into a specific proposal. Which files, which task, which account, which feature, and which companies will receive the information? A useful answer may be approval for a limited packet, a request for a different workflow, or a hold while missing facts are checked.
This guide is for an inventor or small product team handling ordinary confidential design work. It is a preparation aid, not a legal opinion or a security audit. If your customer has its own restrictions, involve the person who can authorize disclosure. Regulated or export-controlled projects need the appropriate specialist review before using this checklist as an approval route.
Start with the task, not the software brand
Ask the supplier to describe the intended result in one sentence. “Find inconsistent hole callouts on drawing revision C” is reviewable. “Help us with the design” leaves the permitted use open. The task determines what the tool needs to see and what a useful output should contain.
Computer-aided design, or CAD, files can be accompanied by drawings, assembly references, material lists and engineering notes. Ask for the proposed input package, including screenshots and pasted text. A supplier might keep the original model on its computer while sending a rendered view or extracted dimensions to another service. Review that proposed disclosure too.
For general file access and version control, use our prototype CAD and test-file access guide. The additional question here is whether the supplier may introduce a new AI service into an already agreed exchange. Treat approval as specific to a workflow and revision, rather than permission for every future design task.
Separate five questions that often get mixed together
| Question | Evidence to request | What it does not establish |
|---|---|---|
| May the supplier send this information? | Your agreement, applicable customer rules and written approval from the authorized person. | A paid software subscription does not grant the supplier permission over your design. |
| May anyone use it for model improvement? | The terms for the exact product, feature and account; any opt-in settings or negotiated exceptions. | A no-training provision does not mean nothing is stored. |
| What is retained, and for how long? | Separate schedules for files, conversations, outputs, logs and backups; deletion procedure and exceptions. | Removing a chat from the interface does not document deletion from every system. |
| Who can receive or access it? | The application operator, hosting services, model providers, routing services, authorized staff and sharing controls. | Encryption alone does not describe authorized access. |
| How will the result be checked? | A named engineer, source revision and acceptance criteria for the supplier's deliverable. | Permission to process a file does not establish that an AI-generated change is correct. |
Write unanswered items as “unknown,” with an owner and a next action. Do not turn an attractive security page into a completed review. Your decision record should connect each answer to a dated document, an applicable agreement, or a confirmed account configuration.
Read the policy for the actual route
Current provider documentation shows why the details matter. The examples below were checked on October 22, 2026. They illustrate different stated practices; they are not endorsements or independent verification of a vendor's systems. Recheck the linked policies before approving a real upload.
- OpenAI's API data-controls documentation says API content is not used for model training unless the customer opts in. It separately describes abuse-monitoring logs and application state. Its endpoint table lists 30-day abuse-monitoring retention for several endpoints, while some stored objects persist until deleted. Zero Data Retention has eligibility and feature limitations. An API claim therefore needs the actual endpoint and configuration, not just the model name.
- PrintPal's CAD Modeler privacy policy says it reserves training and improvement rights over submitted content and currently offers no opt-out for that use. It also describes routing inputs to third-party model services and separate retention periods. Public sharing is off by default, but that is a different control from training permission. Under those published terms, a requirement that confidential inputs never be used for training would remain unresolved.
- Faber's security explanation states that files and prompts are not used to train its models unless a project-specific agreement permits it. It also describes limited staff access, storage in the workspace and deletion on request. Ask for the applicable agreement and deletion details; the no-training statement alone is only one part of the review.
- Autodesk's explanation of trusted AI describes feature-dependent use of aggregated, de-identified customer content for some training datasets, while stating that customer data is not shared with third parties for their own training. It points to feature-level transparency cards. A general statement about the company cannot replace checking the particular feature the supplier intends to use.
If a CAD application calls another company's model, inspect both layers. The application may save a project or conversation even when the underlying model provider does not use requests for training. Ask whether the app changes providers when a model is unavailable. An answer naming only the usual provider leaves the fallback route unreviewed.
Draw a small data-flow map
Use one row for each handoff. Start with your released packet, then the supplier's account, the CAD or AI application, any intermediary, and the model service. Add the return path: an output report may be stored or shared separately from its input. A plain table is enough; you do not need an architecture drawing to notice a missing recipient.
| Handoff | Record | Useful verification question |
|---|---|---|
| You to supplier | Packet ID, revision, file list, permitted task and recipient. | Does the package contain only the material needed for this task? |
| Supplier to application | Product, plan, workspace owner, feature and settings. | Is this the approved company account or a personal account? |
| Application to other services | Named providers, data fields transmitted, regions and fallback routing. | Are previews, extracted text or tool results transmitted as well? |
| Result back to the team | Output location, sharing permissions, reviewer and retention instruction. | Could a public link or reused conversation expose the result? |
Keep the map attached to the decision. If the supplier cannot identify the route, hold the proposed upload and ask for a smaller task that can be completed with an already approved method. That keeps the manufacturing discussion moving without treating an unanswered question as consent.
Worked example: review one drawing without releasing an assembly
Hypothetical example: You are developing a folding fixture. The supplier wants an AI assistant to check the wording and consistency of manufacturing notes. Its first request asks for a native assembly, all drawings and the complete email history. The assembly contains a mechanism unrelated to the note check, and the emails include another supplier's pricing.
Define the job more narrowly: identify inconsistent note wording and produce a list of questions for the engineer. No redesign, machining instructions or automatic changes are authorized. The supplier confirms that the task can start with a single selected drawing, but must still identify its tool, account and full processing route.
You create packet R1 for review. It contains one drawing export, its revision and a short statement of the task. You exclude the mechanism assembly and price discussion. Inspect the exported document itself: page thumbnails, comments, attachments and text should match what you intend to release. A visible cover rectangle is not your evidence that information has been removed.
There is an engineering tradeoff. Removing a dimension or a material note can make the review less useful. The supplier should identify which removed information prevents it from answering a specific question. You can then decide whether to authorize an additional item or ask the engineer to handle that part locally. Do not quietly weaken the drawing and then mistake an incomplete AI review for a full manufacturing check.
Suppose the supplier provides a no-training commitment for the model service but cannot explain the CAD application's conversation storage. The decision remains hold. The unresolved item is application retention, not proof that a leak has occurred. If the supplier supplies acceptable terms and settings, the authorized owner can approve that limited packet and task. If it cannot, the supplier can complete the note review through the previously approved process.
At completion, the engineer receives a question list, checks it against the released drawing and records any accepted change through the normal revision process. The supplier closes the AI project according to the agreed deletion procedure and reports any remaining retention exception. This example demonstrates a decision process; it does not establish a universal safe configuration.
Copy this request into your supplier review
The following is an operational request template. Adapt it with the person responsible for your agreement; it is not a substitute for a negotiated contract clause.
Before uploading packet [ID and revision] to an AI service, please identify the exact product, feature, account plan and company workspace you propose to use. The intended task is [task], and the requested output is [deliverable].
Please list the files and other information that leave your systems, each application or provider receiving them, any fallback providers, processing locations, and who can access the inputs and outputs. Include screenshots, extracted text, metadata and conversation history where relevant.
Provide links or applicable agreement sections covering training and improvement use, retention of files and logs, deletion and backup exceptions, and public-sharing controls. Identify the settings that apply to this workspace and the person who verified them.
Do not upload the packet until [authorized approver] has recorded a decision for this task. Changes to the files, service, account, routing or permitted use require another review. If this route cannot meet the requirements, propose an alternative using the existing approved process.
Keep the response concise enough that both sides can use it. A long questionnaire with unanswered boxes is less useful than a short complete record covering the actual transfer. Include a contact for questions during the work so the supplier does not improvise when the original packet proves insufficient.
Record approve, hold or use another method
Approval should name the packet, task, account, route, conditions, reviewer and date. A hold should name the missing evidence. A decision to use another method should identify that method and the revised deliverable. Avoid an unexplained “AI approved” status, because another employee could apply it to a different tool or a later design revision.
Keep permission separate from legal conclusions about your invention. WIPO's trade-secret guidance explains that protection generally depends on secrecy, commercial value from secrecy and reasonable protective steps. Confidentiality agreements and access controls are examples, not automatic guarantees. Whether a particular disclosure affects your rights depends on the facts and applicable law. Use qualified counsel for that assessment and for unclear recipient or use clauses in an NDA.
If the supplier says it already uploaded the files, stop further transfers while you establish what happened. Ask for the file revisions, time, account, feature, recipients and any sharing links. Preserve the relevant records, involve your responsible security or legal contact, and request containment or deletion through the provider's documented process. Do not circulate the confidential files again merely to explain the incident. A deletion request is useful evidence of action, but it is not proof that every copy has disappeared.
The practical finish line is a usable record: what was sent, why, under which conditions, who approved it, what came back and how the job was closed. Use that record when the same supplier proposes the next tool, and recheck whenever its terms, settings or data route change.