No training, zero retention, and no external transfer: enterprise AI data protection explained
Separate model training restrictions, data retention, and transfer boundaries when choosing enterprise AI. Map documents, prompts, responses, and logs to practical SaaS and on-premises requirements.
No training describes how data may be used. Zero retention describes how it may be stored. No external transfer describes the boundary it may cross. These commitments are not interchangeable. A cloud AI service that does not train on your data may still receive document content to generate an answer. A model service may retain no request history while the business application stores the conversation.
If company information must stay inside your organization, asking whether a product trains on it is only the beginning. First define which information may be processed where, and what may remain afterward. This guide turns three common phrases in enterprise AI proposals into specific questions about configuration and operations.
Compare the three commitments
| Term | What it addresses | What it does not establish on its own | Follow-up question |
|---|---|---|---|
| No training | Whether customer data is used to train or improve models | External transfers, conversation history, or log retention | Does the restriction cover documents, prompts, responses, and derived data? |
| Zero Data Retention | Which data a specified service retains, and for how long | Original files stored by the application, logs elsewhere in the workflow, or feature exceptions | Which service, model, feature, and data types does it cover? |
| No external transfer | Whether data leaves the boundary defined by the organization | Internal access permissions, internal retention periods, or model quality | Does the boundary include the provider's cloud and logs sent for support? |
Use this distinction when evaluating claims that a product is secure because it is an enterprise offering. Comparing proposals requires knowing the covered data, enabled features, configuration, and operating procedures, not just the product tier.
Search may require storage and processing without model training
An internal document search system may extract text, split it into searchable passages, and build an index. When someone asks a question, it retrieves relevant passages and sends them to a model to generate an answer. Building that search index is different from updating model weights through training.
Storing a document for search therefore does not, by itself, mean that the document is being used for training. A no-training policy also does not remove the need to manage stored documents and indexes. You still need to check what happens to search results and earlier conversations when a file is deleted.
Wissly does not use customer documents, questions, or answers to train, retrain, or fine-tune AI models, or to improve its own AI models. Document indexing supports search. That policy is separate from the deployment environment, so the next step is to examine the actual processing path.
Read the scope and exceptions of zero retention
When a provider says it does not retain data, identify which provider and processing stage it means. The business application, model service, and monitoring service may each retain different information. A commitment at the model processing layer does not necessarily delete original files uploaded to the application or conversations saved by users.
For example, Amazon Bedrock's model invocation logging documentation explains that invocation logging is disabled by default. When enabled, it can collect inputs, outputs, and metadata for supported calls in CloudWatch Logs or S3. Logging configuration needs its own review even when the underlying model service remains the same.
Google Cloud's generative AI data retention documentation also addresses training restrictions and zero-retention conditions separately. Request and response logging, caching, and some additional features have different retention conditions. Review the current documentation against the features you will actually use. The availability of a provider's zero-retention option does not establish that every application using that provider has enabled the same settings.
Ask the vendor for these three items together:
- The models and features you will use, with retention conditions for each processing stage.
- The logging, caching, and history settings applied to the production environment, and who owns those settings.
- A notification and review process for changes to models or features that affect those conditions.
Removing every record is not always the operational goal. You may need access records for incident investigation while excluding document bodies from logs. Define the purpose and contents of each record, then compare your requirements with the settings the service actually supports.
Put the transfer boundary into words
Organizations mean different things by “external.” Does the policy prohibit traffic across the public internet? Does it prohibit data leaving a company-controlled cloud account? Or must all processing stay on physical servers inside the organization? Establish that boundary before comparing deployments.
For example, AWS PrivateLink connectivity for Bedrock provides a private connection between a VPC and Bedrock. It is not the same deployment arrangement as running a local model on an internal server. A private communication path and a requirement to process AI requests only on your own servers are separate conditions.
Write the requirement using both the data and its boundary. The following is an example for an organization to consider, not a statement of any product's default behavior:
Original documents, extracted text, questions, and answers must be processed only within the designated internal network. Model inference and embedding generation must not call external APIs. Logs needed for external support must be reviewed for document content and approved separately.
Apply that statement to OCR, embeddings, model inference, external search, and error reporting. It will expose the connections you need to inspect. An interface can be hosted internally while some processing calls external APIs, so check where each stage runs rather than relying on where the screen is hosted.
Separate originals, derived data, and support logs
If a proposal promises data deletion, specify what is deleted. The table below is a review worksheet to complete with the vendor, rather than a list of product features.
| Data | Storage locations to check | Retention decision | Deletion scope to confirm |
|---|---|---|---|
| Original documents | Upload storage and connected source systems | Whether copies are made and who manages them | Distinction between the AI service's copy and the original system |
| Extracted text and document chunks | Processing storage and search indexes | When changes to the source are reflected | When a deleted source disappears from search |
| Embeddings and search metadata | Vector and search stores | Links to document permissions and source records | Treatment of data derived from the deleted document |
| Questions, answers, and attachments | Application history and model services | Separation of user history from service logs | Difference between removal from the interface and deletion from storage |
| Operational and error logs | Monitoring and support systems | Whether content is included and who can access it | Retention and disposal procedures for logs and backups |
The same information may remain in more than one location. If a document deleted from its source survives as a quotation in an earlier conversation, index deletion and conversation retention need separate treatment. See the RAG document updates and deletion guide for a more detailed review sequence.
Record the answer and its evidence together
A yes-or-no response to each requirement leaves room for different interpretations during operation. For external transfers, retain the architecture diagram and allowed destination list. For retention, record the settings and their owner. For deletion, document the procedure and timing for each data type.
You can test with recognizable sample documents instead of sensitive originals. A deployment review might follow this sequence:
- Connect a test document and complete search, question, and answer workflows.
- Compare each processing and logging location with the architecture diagram.
- Delete the test document or change its permissions, then inspect search results.
- Check conversation history, source quotations, operational logs, and backups against their respective retention policies.
- Distinguish unverified items from items accepted under specific conditions.
An item disappearing from the screen does not prove that every stored copy has been deleted. Equally, the presence of an audit record does not automatically mean the requirement has been violated. Define the permitted data and retention period first, then test against those conditions. If the review also covers document access by individual users, use the enterprise AI security checklist.
Review Wissly's deployment and processing conditions together
Wissly SaaS uses Amazon Bedrock or Google Cloud Vertex AI for AI processing, depending on the feature and selected model. On-premises deployments use local AI within the internal network. Both deployment options are covered by Wissly's no-training policy, but they do not process data in the same location.
If your organization permits cloud processing, define the features and data scope before reviewing processing and retention conditions. If documents cannot be sent to external AI services, evaluate on-premises deployment around the internal processing path and operating requirements. Confirm access control, logging, and integration scope in the deployment configuration and agreement.
Use the cloud and on-premises deployment comparison to narrow your options. Then bring the restricted data categories and acceptable retention conditions to a Wissly Enterprise discussion.
Frequently asked questions
Does a no-training policy mean company documents never leave the organization?
No. It restricts how data may be used. You must separately check whether a cloud model receives relevant document passages to generate its answer.
Does on-premises deployment automatically provide zero retention?
No. An on-premises system can store original copies, search indexes, conversation history, and logs. Internal storage and no storage are different requirements. Decide what to retain and when to delete it.
Can encrypted data be treated as if it has not been transferred externally?
Encryption protects data. Where the encrypted data moves and where it is processed remain separate questions. Evaluate whether that movement is permitted under your organization's data boundary.
What should we prepare for a deployment discussion?
Bring the document types, restricted data categories, permitted processing locations, required history and logs, and retention periods. These specifics make it easier to discuss a suitable deployment and remaining review work than a general request for strong security.
