Check Where an AI Feature Sends Business Data

A button labeled “summarize” tells you what a feature offers, not where the submitted text goes. The application you buy, the model provider, a logging service and an optional connector may have different roles. Evaluating only the visible interface leaves a material part of the proposed workflow unexplained.

Before enabling an AI feature for business data, map the specific processing route you intend to use. You are not trying to reconstruct the vendor's entire infrastructure. You need enough verified information to decide whether this feature, under these settings, is suitable for the data and purpose you have approved.

Ask about one action and one data class

Start with a sentence such as: “An authorized researcher submits an internal account note to produce a draft summary, with no external messages sent.” Identify what the note may contain and what it must not contain. A synthetic demonstration and a live customer note have different evaluation consequences even when the same button is involved.

Then distinguish payload from surrounding information. Ask about prompt text, uploaded files, generated output, identifiers and operational logs. Do not assume that a setting described as “not used for training” also means no storage, no human access, no logging or no onward processing. Obtain the actual scope of each assurance.

NIST AI RMF 1.0, GOVERN 6 addresses risks arising from third-party software, data and other supply-chain relationships. The following question map is an original purchasing aid, not proof of anyone's compliance.

The fictional feature's data-flow question map

Assume a fictional product, NoteHarbor, offers optional account-note summarization. On 8 November 2026, an evaluator assembles the following map from fictional documents and written vendor answers. It illustrates a review, not an observed network test.

1. Browser to NoteHarbor application: Payload is the selected note and workspace ID. Purpose is to accept the request and display its result. Evidence NH-12, a feature specification dated 2 November, says only the selected note is submitted. Retention question remains open for abandoned requests. Owner: product support. Decision: synthetic notes only until answered.

2. Application to CedarModel, an invented inference provider: Payload is note text plus the summarization instruction. Purpose is generation. A fictional signed service schedule identifies CedarModel for this feature, while the public supplier list merely identifies it as a possible supplier. Training use is excluded in the fictional schedule; provider-side retention duration is unspecified. Owner: privacy reviewer. Decision: do not infer zero retention.

3. Application to diagnostic logging: Purpose is troubleshooting. Fictional engineering response ENG-14 says request identifiers and error codes are recorded, but does not confirm whether failed requests can include note excerpts. Provider identity and payload exclusions remain open. Owner: engineering lead. Decision: request a feature-specific answer rather than accept a generic “metadata only” description.

4. Application to the connected CRM: Proposed output is a draft summary. The evaluator intends manual review before any write. Fictional configuration guide CFG-6 shows an optional automatic-write setting, currently disabled in the proposed configuration. Owner: workspace administrator. Decision: independently confirm that setting in an authorized test environment before any live connection.

The resulting decision is not “approved because the model is reputable.” It is “continue a synthetic demonstration; do not submit internal notes while retention and diagnostic payload questions remain unresolved.” The map assigns each gap to a person and connects it to a usable restriction.

Use the right evidence for the route

A supplier list can identify organizations the vendor may use without establishing which receives data for your feature. A diagram can describe a design without showing your enabled settings. A support response can clarify a detail without changing contractual terms. Record which kind of evidence supports each statement and refer contractual questions to the appropriate reviewer.

If a vendor says processing is local, ask what “local” covers. The model calculation might occur on a device while licensing, telemetry or error reporting still communicates elsewhere. This is a question to resolve, not a claim that all local features behave that way. Likewise, a connected account does not prove that every action writes to it.

Reopen the map when the route changes

A new model option, connector, region, logging setting or service tier may change the relevant answer. Assign a review trigger rather than treating the first map as permanent approval. Keep the actual configuration and date with the decision.

When downstream information cannot be established, reducing the input to genuinely synthetic material may permit a limited demonstration. It does not resolve suitability for real business information. The useful outcome is a bounded decision with visible unknowns, not a diagram whose tidy arrows hide unanswered questions.

Continue with Prepare a Sales Demo Around One Confirmed Workflow or Build a Small Reference Library for Evidence-Based Selling.