Skip to content
Enterprise Tech Logic

Independent analysis for technology leaders

Data & AI

Enterprise AI data controls: approve the feature, not just the provider

Training restrictions, retention and customer logging answer different questions. Check the actual AI service, enabled features and configuration before approval.

By Enterprise Tech Logic

Enterprise technology, security and IT leadership

· 5 min read

Orange robot hand with open fingers

At a glance

  • Separate training use, retention, access and processing location.
  • Match each commitment to the product, feature and configuration being deployed.
  • Reopen the decision when new grounding, logging or integration features change the data flow.

A supplier can promise not to train on your business data and still retain some of it to provide a feature. Those statements address different uses. An enterprise AI lead who treats the first as a complete privacy answer can approve a service without understanding where the information goes or how long it remains available.

The unit of approval should be the proposed data flow: a named product, model or service, account arrangement, enabled features and configuration. A provider’s reputation and a broad enterprise privacy statement help frame the review, but neither describes every deployment.

Separate the promises before comparing them

Training use concerns whether submitted information can improve or customise models. Retention concerns what persists and for how long. Access concerns who or what can reach it. Location concerns where storage and processing occur. Deletion concerns how retained information is removed, including any exceptions or separate customer-controlled copies.

A good answer to one does not settle the others. Encryption does not identify every authorised recipient. A selected storage region does not, by itself, establish the location of every processing operation or connected service. A deletion control for uploaded files may not govern application logs containing the same text.

Google Cloud’s Service Specific Terms, for example, state that Google will not use Customer Data to train or fine-tune AI/ML models without the customer’s prior permission or instruction. Read that as a commitment about training use, then examine the relevant service documentation for retention and feature behaviour.

Keep the evidence types distinct. Contractual terms establish commitments within their scope. Technical documentation describes controls and behaviour. A setting shows how your particular deployment is configured. If approval depends on a setting, someone must demonstrate that it is enabled in the environment that will handle the data.

A useful feature can change the retention answer

Google’s Gemini Enterprise Agent Platform retention documentation provides a concrete example. It says Grounding with Google Search stores derived queries and supplied contextual information in logs for up to three days, and that this storage cannot be disabled when using the feature. Grounding with Google Maps has a different arrangement: prompts, contextual information and generated output are stored for thirty days. The same page says optional request-response logging writes specified model requests and responses to a designated BigQuery table.

Those differences change a deployment decision. A team may accept one feature for public product information while excluding it from a workflow involving confidential negotiations. Another may need the feature enough to design a narrower input and obtain approval for that documented flow. The question is whether the capability and its data handling fit the use case.

Consider a hypothetical procurement assistant approved to summarise internal supplier proposals. Its team later enables web grounding to make answers more current. Before using the existing approval, trace what the new feature receives: does the request include supplier names, bid details or retrieved passages? An interface toggle can change the relevant data path without changing the provider logo.

Customer logging deserves equal attention. Engineers may enable detailed logs to diagnose an answer-quality problem, then leave them accessible to a wider support group. Decide what must be logged, whether sensitive content can be omitted, who needs access and how long the record is useful. A provider retention control cannot clean up a separate copy the application team deliberately stores.

Follow the whole request

Walk through a representative transaction from the employee’s input to the final answer. Include retrieved documents, attached files, tool calls, evaluation traces, support exports and connected applications. For each stage, identify the service receiving the information and the relevant control boundary.

Check the actual purchasing route. Direct API use, an enterprise application that embeds a model and a consumer account can have different contractual and technical arrangements. A model name shared across them does not establish identical data handling. Match the evidence to the service you will contract for and the features you will enable.

Ask about the exceptions that matter to the workflow, such as abuse monitoring, troubleshooting access, optional feedback or third-party processing. Resolve whether an exception applies to your account and whether any approval or configuration is required to change it. An available option is not evidence that it has already been granted.

Test what you control. Inspect the deployed logging configuration, permissions and selected location. Exercise file deletion and observe the customer-visible state. Retain the applicable commitments for behaviour you cannot independently observe inside the provider. A successful application test should not be described as proof of an internal deletion process the customer cannot see.

Make approval survive product change

Write the decision around permitted data and features. For example, approval might cover internal policy summaries with a defined retrieval collection and limited logging, while excluding particular grounding or external-tool paths until they are assessed. That gives the delivery team a usable boundary rather than an undifferentiated yes or no to “AI”.

Reassess when the team changes products, introduces a new model route, enables a feature with different handling, adds a connector or expands the data class. Assign ownership for following relevant service changes and keeping the deployed configuration aligned with the approved one.

Carry those requirements into an enterprise AI platform evaluation built around the workflow. The useful provider is the one whose documented capabilities and controls support the task you intend to run, at an operating cost your team can sustain.

Your next step

Enterprise AI platforms: make the shortlist prove the workflow

Take the approved data flow into a practical enterprise AI platform evaluation.

Read the guide

Keep reading

Related insights

Data & AI · Decision guide

AI inference costs: compare the cost of a useful answer

A lower token price can still produce a higher cost per accepted task. This worked example compares model charges, retries and human review on the same basis.

Enterprise Tech Logic ·

Data & AI · Analysis

When an AI agent is the wrong architecture

Choose between deterministic automation, model-assisted workflows and agents by examining where discretion creates value and where it adds avoidable cost.

Enterprise Tech Logic ·