Map the real data flow before negotiating ownership
Start with the deployed architecture, not the vendor's contract template. Identify every data object the service will receive or create: prompts, uploaded documents, model responses, conversation history, embeddings, indexes, user feedback, telemetry, support tickets, caches, and backups. For an assistant connected to LINE, an ERP, or a CRM, include tool-call arguments and returned records. Those integration payloads can contain more sensitive information than the original prompt.
Put the inventory in a contract schedule with each data type's source, purpose, processing location, retention period, and permitted recipients. This exposes gaps that broad statements such as no prompt storage often conceal. A provider may avoid retaining the main conversation while its monitoring platform or upstream model API keeps request fragments. The definition of customer data should therefore cover operational and intermediate data produced while delivering the service, not only files intentionally uploaded by the customer.
- Locations: Where are data transmitted, processed, stored, and backed up, including cloud regions and cross-border transfers?
- Recipients: What can the primary vendor, model provider, cloud host, observability service, and support team access?
- Retention: Do prompts, application logs, security logs, caches, and backups follow different deletion schedules?
- Sensitive fields: Are personal data, credentials, source code, and trade secrets blocked or redacted before inference?
Separate service delivery from training and product improvement
A provider needs limited permission to process data in order to run inference, retrieve documents, and support the service. That does not require an open-ended right to improve products, train foundation models, build evaluation sets, or benefit other customers. State these purposes separately. Unless the company gives specific written approval, the restriction should cover prompts, documents, outputs, feedback, embeddings, fine-tuning examples, and derived datasets.
Do not rely solely on an opt-out switch in an administration console. Behavior may vary by account type, workspace, API plan, or downstream model provider, and settings can change over time. The contract should establish no training by default, identify every approved exception, and explain its scope, duration, withdrawal process, and effect on previously created artifacts. If a vendor reserves broad rights over de-identified data, define the de-identification standard, prohibit re-identification, and exclude data that can still be linked to a particular company, document, or user.
Review output rights with similar precision. The customer usually needs broad rights to use, modify, retain, and integrate responses, but generative output may not be unique and may implicate third-party material. Exclusive ownership promises can therefore be less useful than clear operational protections: the provider should not assert additional rights over customer outputs, applicable usage restrictions should be disclosed, and the parties should assign responsibility for infringement notices, disabling disputed content, and providing a workable replacement.
Control model substitution and behavioral change
AI services can change even when the API name remains stable. A provider may update model weights, system instructions, safety policies, retrieval ranking, content filters, or routing between models. Any of these changes can alter response structure, citation quality, language behavior, latency, refusal patterns, and tool selection. The technical schedule should record the model family, available version identifier, hosting arrangement, retention configuration, and whether requests may be routed to another provider.
For a system that writes to an ERP, creates tickets, or sends LINE messages, model replacement is not routine maintenance. Require advance notice for material changes, access to a test environment, a compatibility window, and a rollback or fallback path. The customer should be able to pause an upgrade when security, regulatory, or acceptance requirements are not met. Acceptance should use representative company scenarios and test structured output, grounding, citation behavior, permission boundaries, and safe failure modes rather than relying only on the vendor's general benchmarks.
- Change threshold: Define which version updates, routing changes, and policy revisions count as material.
- Notice: Allow enough time for regression testing, business-owner review, and security approval.
- Recovery: Specify whether the service can revert, switch to an approved alternative, or disable risky tools.
- License continuity: Confirm that open-source weights, fine-tuned models, and adapters remain licensed for the intended commercial use.
Make security, incident response, and deletion verifiable
A promise to use reasonable security is difficult to operate. The agreement should address encryption in transit and at rest, tenant isolation, least-privilege access, multifactor authentication for administrators, access logging, key management, vulnerability handling, and subprocessor governance. When an agent can take actions, define tool permissions, human approval gates, transaction limits, and audit trails. These controls contain the impact of prompt injection, excessive permissions, and confident but incorrect model decisions.
Incident terms should state what triggers notification, when initial notice is due, what information it must contain, how updates will be delivered, and how evidence will be preserved. The customer needs the affected data types, accounts, model endpoints, and time window, not merely a message that an investigation is underway. Verification rights should also be practical. Depending on risk, this may mean access to an independent assurance report, a penetration-test summary, remediation evidence, or a narrowly scoped audit mechanism.
Deletion obligations must extend beyond the primary database. List prompts, responses, vector indexes, logs, caches, fine-tuning data, backups, and copies held by subprocessors. Require confirmation when deletion is complete. If backups cannot be purged immediately, restrict access and restoration to disaster recovery, prevent renewed production use, and set a defined rotation period after which the copies are permanently removed.
Use risk tiers to focus the negotiation
A proof of concept using synthetic or properly de-identified data may justify lighter terms. A production assistant handling customer records, internal knowledge, or write access to business systems requires stronger controls for data use, model change, incidents, and exit. Rank the deployment by data sensitivity, agent autonomy, potential impact of an error, cross-border processing, and difficulty of replacing the provider. This keeps the team from spending equal effort on clauses that carry very different operational consequences.
Before signature, convert the negotiated promises into tests. Verify that logging can actually be disabled, deletion covers vector data, model versions are observable, provider failure has a tested fallback, and exports are sufficient to reconstruct the service elsewhere. The strongest agreement is not necessarily the longest one; it is the agreement whose commercial terms match configuration, architecture, and day-to-day operations. Where several models, clouds, and enterprise systems are involved, an integration team can help translate those obligations into technical controls and release gates.