How to protect your data when using AI

Confidential credit documents create a demanding test for any AI service. Draft restructuring materials, private-side lender presentations and unannounced financing terms can carry contractual, regulatory and commercial consequences if mishandled. A generic assurance that a platform is “secure” does not tell a risk function what happens to those materials after upload.

The diligence question is therefore not whether the vendor has a security page. It is whether the firm can trace its data through the entire service, identify every party that handles it and match each material risk to an enforceable commitment and a functioning technical control.

“Zero data retention” can be an important part of that answer. It is not the whole answer. Retention, model training, access, processing location and tenant separation are distinct issues. Each needs to be tested separately.

What should zero data retention actually mean?

At its strongest, a zero-data-retention arrangement means customer content exists only for the time required to complete the requested processing and is not persistently stored afterward. The relevant content should include uploaded documents, prompts, extracted text, model inputs, model outputs and files generated from the analysis.

The phrase is not self-defining. A vendor may use “zero retention” to describe only its model provider while retaining documents in its own application database. Another may delete uploaded files but preserve prompts or outputs. A third may exclude support records, security logs or backups from the claim.

Ask the vendor to define:

• The data types covered.
• The systems and entities covered.
• The event that starts the deletion process.
• The maximum time before deletion is complete.
• Any exceptions, including logs, backups, abuse monitoring and support.
• Whether users or administrators can enable storage that changes the default position.

“Deleted after processing” is also incomplete without a definition of processing. A document may pass through malware scanning, text extraction, optical character recognition, chunking, embedding, model inference and output generation. Temporary copies or intermediate artifacts may exist at several stages.

A useful answer maps each stage and states whether the artifact is held in memory, temporary storage or persistent storage. It also states how and when the artifact is removed.

Is “not used for training” the same promise?

No. A provider can retain customer data without using it for training. It can also claim short retention while using eligible data for model improvement during that period. The two promises address different risks.

A training restriction should cover more than training a foundation model. Ask whether customer data may be used for:

• Fine-tuning or adapting any model.
• Human review of model responses.
• Evaluation datasets and benchmark creation.
• Prompt, retrieval or ranking improvements.
• Product analytics that preserve document content.
• Development or testing outside the customer’s environment.

The restriction should apply to inputs, outputs and data derived from them. It should also flow down to sub-processors. A contractual promise from the application vendor is of limited value if the model provider’s terms permit broader use.

Opt-out language deserves close attention. A service that does not train on data by default presents a different governance position from one that requires each user to find and disable a setting. Enterprise administrators should be able to enforce the approved configuration across the tenant.

Which retained artifacts are easy to overlook?

The uploaded PDF is only the most visible object. Systems handling long credit documents often create additional artifacts that may contain equally sensitive information.

Logs require particular scrutiny. “We retain logs for security” does not establish whether those logs contain document content. The vendor should distinguish metadata, such as timestamps and request identifiers, from payload data, such as extracted clauses or model responses.

Intermediate artifacts matter even when they are short-lived. Ask for the maximum lifetime, not merely whether storage is described as temporary. Also ask what happens when a job fails. Error handling can leave files in retry queues, quarantine storage or diagnostic systems after the ordinary deletion path has stopped.

Why does the sub-processor chain matter?

An AI application rarely performs every function itself. Cloud infrastructure, model inference, document parsing, observability, customer support and security services may involve separate providers. Each additional party expands the set of systems, personnel, contractual terms and jurisdictions relevant to the data.

The vendor should provide a current sub-processor list that identifies each entity’s function and processing location. A list of company names without service descriptions is not enough to reconstruct the data flow.

For each material sub-processor, determine:

1. What customer data it receives.
2. Whether it stores that data and for how long.
3. Whether it may use the data for its own purposes.
4. Where its processing and support access occur.
5. What deletion commitments apply.
6. How the primary vendor monitors compliance.
7. How customers are notified of changes.

Pay special attention to the model endpoint. The application vendor’s retention policy does not automatically describe the model provider’s policy, particularly where multiple models or fallback routes are used. Ask whether requests can be routed to a different provider because of capacity, geography, feature selection or service failure.

Sub-processor changes also need a process. Notice after a new provider begins processing may not give the firm a meaningful opportunity to assess the change. The contract should specify notification, objection rights and the consequence if the parties cannot resolve an objection.

What does tenant isolation need to cover?

Tenant isolation is the set of controls preventing one customer from accessing another customer’s data. A vendor saying that each customer has an “account” does not establish how isolation works beneath the interface.

Ask whether tenant identity is enforced at the application, database, object-storage, search-index and cache layers. If the system uses retrieval or embeddings, establish how every query is scoped to the correct tenant and matter. Shared infrastructure can be acceptable, but logical separation must be consistently enforced.

Administrative access is a related issue. Determine which vendor personnel can access production systems, under what circumstances and with what approval, logging and review. Support access should be time-limited and tied to a specific need. The vendor should be able to explain whether administrators can view document content by default or must take an auditable exceptional-access step.

Encryption is necessary but answers a different question. Encryption at rest does not prevent an authorised application process or privileged administrator from reading data. Ask how encryption keys are managed, but do not treat encryption as a substitute for isolation and access control.

Where is the data actually processed?

A statement that data is “hosted” in a chosen region may refer only to the application database. Model inference, logging, backups, support access or security analysis may occur elsewhere.

Request a data-flow diagram showing every location where customer content is transmitted, processed or stored. The answer should distinguish data residency from data access: content stored in one country may still be accessible to personnel in another.

Questions should cover normal operations and exceptions. Does regional routing change during an outage? Can a user select a feature that invokes a model hosted elsewhere? Are telemetry and support systems regionalised? Are encryption keys held in the same jurisdiction? Geography should be addressed for the complete service, not just its primary hosting environment.

Which questions separate evidence from reassurance?

Broad questions invite broad answers. “Is our data secure?” will usually produce policy language. More useful questions require the vendor to identify systems, limits and exceptions.

Take these into diligence:

• Define “zero data retention” in the contract. Which data and systems are excluded?
• What is the longest period any customer content can persist after a request completes?
• Can logs, traces, tickets or abuse-monitoring systems contain document text?
• Are inputs, outputs or derived data used for training, evaluation or product improvement?
• Which sub-processors receive content rather than metadata?
• Does every relevant sub-processor accept the same retention and training restrictions?
• Can requests be routed to an alternative model provider or processing region?
• How are temporary files, queues, caches, embeddings and failed jobs deleted?
• What happens to deleted content in backups, and can it return during restoration?
• How is tenant identity enforced across storage and retrieval systems?
• Which personnel can access content, and is that access approved and logged?
• What customer action is required when a new sub-processor is introduced?
• Which controls are independently assessed, and does the assessment cover this service?
• What happens to customer data at contract termination?

Documents such as security reports, penetration-test summaries and certifications can corroborate a control environment. They rarely answer the full product-specific data-lifecycle question. Read them alongside the contract, architecture description and retention schedule.

How should the approval be documented?

A defensible approval records both the vendor’s commitment and the firm’s operating conditions. It should state which document classifications may be uploaded, which features are permitted, whether storage must remain disabled and what user behaviour could defeat the approved controls.

Map each important representation to evidence:

The distinction matters when facts change. A contract may remain static while a new feature introduces storage. A technical setting may enforce zero retention today but be changeable without breaching the agreement. Approval should therefore include an owner, a review cadence and triggers for reassessment, such as a new model provider, material architecture change or revised retention policy.

The core test is simple: can the firm explain where a confidential document goes, who can touch it, how long each artifact survives and which binding obligation governs each step? If the answer depends on a slogan, the diligence is not finished.