Use of third party AI model services poses significant risk to your alpha. Without sovereign control over how your data is processed by those services (either the AI Labs or the Hyperscalers, collectively referred to as “Hosted Model Providers”), Hosted Model Providers may extract your alpha (your unique institutional knowledge and tradecraft embodied in data exposed to and generated from your use of AI models) and resell it to the broader market in the form of weights or services. Storage of your data by Hosted Model Providers also increases the attack surface against your alpha in an increasingly cyber-insecure world, and risks your most valuable assets being swept up in the ongoing existential legal battles that many Hosted Model Providers are facing. It is essential to maintain sovereign control of your data so this does not occur.
While additional sovereign control might involve making use of neoclouds (providers of which might be more open to more data-protective terms than Hosted Model Providers) to host and improve open-source models you deploy and control, you may still be inclined to make use of the walled-garden frontier models offered by Hosted Model Providers. But even for wary legal teams, Hosted Model Providers’ labyrinthine legal terms hide traps that can jeopardize AI sovereignty. This document helps identify some of those common traps and proposes best practices to mitigate the associated risks. It walks you through guidance on securing terms that protect your data, tracking and permitting only services that are covered by those protections, restricting the ability of the Hosted Model Providers to unilaterally change the terms of your agreement, and mitigating the risk of operational disruption when things go wrong.
Note: this document is not intended as and does not contain legal advice, nor does it establish any attorney-client relationship. Please consult an attorney for any legal advice.
1. Contractually Protect Your Alpha
1.1 Secure robust Zero Data Retention (ZDR)
One critical way of mitigating these risks is by securing contractual guarantees for Zero Data Retention (ZDR). Different Hosted Model Providers will use different conceptions of ZDR.
Robust ZDR means the Hosted Model Provider will not (1) store or otherwise log your prompts or responses to disk (which would be more permanent than ephemerally keeping it in memory), (2) expose your prompts or responses to human review, (3) use your prompts or responses to train their models or improve their services, and (4) will only persist prompts and responses in memory for the time required to return a request.
Some Hosted Model Providers offer a version of ZDR protection that is diluted by exceptions that hide in their contracts, technical documents, and product architecture, exposing your alpha to their control. Some of the most common exceptions are addressed in section 2 of this document — track them carefully and permit only services that are actually covered by your protections.
1.2 Restrict use of your alpha
Your alpha should compound to your benefit only, not to a Hosted Model Provider’s. Some Hosted Model Providers will provide assurances that models will not be trained on your data. However, there may be omissions from this protection — e.g. a hyperscaler acting as a Hosted Model Provider may assure you that the AI lab that created the model you are using will not train on your data, but the hyperscaler may not bind themselves in the same way. They may hide terms in their legal agreements or product documentation enabling them to use metadata about your patterns of use, or your prompts and responses themselves, to improve ancillary services and tools. E.g., they may use your prompts that trigger safety classifiers to improve their safety classifiers, or your usage patterns to improve their model harnesses.
Best practice:
- Ensure that the terms limit the Hosted Model Provider’s and (if the Hosted Model Provider is a hyperscaler) any AI lab involved in the processing’s use of your data to providing you the service — it’s better to positively recite this one permitted use, rather than to try and create a laundry list of various restrictions, which risks missing something. Additionally, be sure that the restrictions on how your data is used extend to both the Hosted Model Provider’s platform you are using and any relevant AI lab.
- If you can’t land the above, at minimum do not permit your data to be used to improve the product or service you are using, including but not limited to model training. Be sure to bind both the Hosted Model Provider and any AI lab involved in the processing.
1.3 Ensure liability caps are high enough to make contractual protections bite
Hosted Model Providers may set a nominal liability cap for violations of ZDR, data processing obligations, or other contractual obligations protective of AI Sovereignty, giving them a weak incentive to abide by those obligations. This is especially common for beta services, but is not limited to those.
Best practice:
- In addition to negotiating robust ZDR, ensure the Hosted Model Provider is exposed to high enough liability for ZDR and data protection violations to incentivize their compliance with those obligations.
- Follow the mitigation strategies in Section 3.1 to protect against unilateral modifications to liability caps by Hosted Model Providers.
2. Track and Permit Only Services Covered by Your Contractual Alpha Protections
2.1 Beta or other ZDR-ineligible services
Many Hosted Model Providers do not apply ZDR to services in beta (also called “preview” or “pre-GA”). Some services, tools, and API endpoints might also be ZDR-ineligible by default. These exceptions can sneak their way into your legal terms in a variety of ways — they may appear in hyperlinked service-specific terms, in a special section of the terms for beta services, or even via a note in the terms that says that beta services are excluded from the definition of model services to which ZDR obligations apply. ZDR-ineligible and beta statuses can apply not just to models, but to specific configurations of the API calls to the models. E.g. model A may not be beta, but model A called with a specific beta tool, feature, or API may be excepted from ZDR. As an additional complexity, the Hosted Model Provider’s default legal terms will almost never spell out what services, features, and tools are beta — they will usually be buried either in ever-changing online product documentation, or the Hosted Model Provider’s console or portal (which, for good reason, IT departments rarely give legal teams access to by default).
Best practice:
- Contractually obtain a broad scope of services (e.g. covering any use of any of the Hosted Model Provider’s APIs, including to access beta services) that fall within your data protections, and ensure that there are no terms subject to unilateral change by the Model Provider (e.g. no hyper-linked online terms).
- If you cannot obtain the above, work with your IT department to establish a living allow-list of models, tools, and features, and API endpoints that fall within the scope of the data protections you did obtain, which will often need to exclude beta services. Regularly update that list based on routine checks of the Hosted Model Provider’s applicable documentation, and set up operational processes for your IT department to connect with legal to vet new models, tools and features prior to allowing them for your organization.
- Some Hosted Model Providers make use of a “beta” header that must be proactively added to API calls to a beta service for the call to go through. This can be a helpful technical gate to block disallowed services — collaborate with IT to automatically block calls that include beta headers as a fail-safe.
2.2 Data is stored when a safety classifier is triggered
Many Hosted Model Providers will store prompts and outputs, and implement human review, when a safety classifier fires. These safety classifiers can and have incorrectly triggered on perfectly legitimate prompts (false positives), meaning legitimate prompts get stored and reviewed.
Best practice: some Hosted Model Providers offer a technical option to disable this ZDR exception, often referred to as disabling abuse monitoring or safety classifiers. If you cannot obtain broad contractual ZDR protections that render this issue moot, ensure operationally that you have configured your account to disable abuse monitoring (or its equivalent) where possible.
2.3 Prompts with images or files introduce ZDR exceptions
Many Hosted Model Providers do not apply ZDR to prompts that include images or files. Some other Hosted Model Providers might claim that use of image inputs or outputs (or interaction with image API endpoints) is subject to their (less robust) conception of ZDR, while buried in their documentation there may be disclosures that in the event of positive safety classifier hits for certain classifiers, all the context of your prompts or responses are retained by the Hosted Model Provider to disk and potentially subject to human review. This may be true for certain high priority safety classifiers even if abuse monitoring is disabled.
Best practice: seek custom terms that apply ZDR to image inputs and outputs by requiring that none of your prompts or responses may be stored to disk or subjected to human review under any circumstances.
2.4 Some prompt caching configurations may store your data for longer than needed
Some Hosted Model Providers offer features (sometimes required for use of certain models or API endpoints) involving extended or enhanced prompt caching. While some form of prompt caching may be helpful for reduced latency and cost, and may be unavoidable, ideally prompt caching will have a reasonable TTL (“Time-to-Live”, indicating how long data is persisted) and will persist the cached prompts only in memory for as long as needed to complete your session, after which the cache is purged. This can be consistent with robust ZDR. Undesirable prompt caching configurations may involve storing your prompts and responses to disk for unreasonably long periods of time.
Best practice: If you cannot secure robust contractual ZDR protections that prohibit caching to disk, add a check for acceptable prompt-caching configurations to your allow-list vetting process.
2.5 Carefully determine which terms apply
Terms and conditions for models can vary based on which Hosted Model Provider platform you are using and which model you are using. In many cases, Hyperscalers flow down certain terms from the model creator and add their own terms on top.
Best practice: Be sure to thoroughly vet the relevant terms for the specific Hosted Model Provider platform you are using. Note that if you have secured favorable custom terms from the model creator (e.g. disabling abuse monitoring), you should ensure that the Hosted Model Provider platform you are using is aware of these custom terms and is implementing any special data handling such as ZDR. For example, if you are using a model created by AI Lab A (with whom you have custom terms and protections), but are accessing the model via Hyperscaler B, you may need to connect AI Lab A with Hyperscaler B so that the AI Lab can confirm to the Hyperscaler that special data handling should apply.
2.6 Disclaimer of data processing terms
Hosted Model Providers sometimes disclaim DPAs or BAAs, or simply all “data processing terms”, for certain services. This typically appears in online hyperlinked terms. This has historically surfaced for beta features and for specialty features such as websearch, though it could in theory be applied to any service.
Best practice: Ideally you should have master terms that override any online terms that disclaim data processing protections. If that can’t be obtained, carefully vet new services before adding them to your allow-list. These data processing disclaimers could be applied directly to the service or could be applied via a status of the service (e.g. via the service being labeled “beta”, thereby attaching beta conditions), so be sure to check (i) the service’s specific documentation, (ii) any service-specific terms that the model provider has (often its own webpage, presented as a long list of services and special conditions that apply to them), and (iii) the terms that apply to the status of the service of interest.
2.7 Surprise service enablement
Some Hosted Model Providers may auto-enable or auto-upgrade services or models to new services or models that are not covered by ZDR or other AI Sovereignty protections described in this document, and you will not be provided express notice of such term change (though the change may be disclosed in unilaterally updated technical or contractual documentation).
Best practice: In addition to the mitigations described in Sections 2.1 and 3.1, secure contractual guarantees that any new model or service that does not satisfy ZDR or your other AI Sovereignty requirements will not be enabled for your tenant without provision of prior notice and your express written consent.
2.8 Ensuring appropriate accreditation compliance boundaries
Not all Hosted Model Providers, and not all of their services, meet the compliance requirements your organization may require for specific workflows — while many may have a SOC2, many may not have FedRAMP certification, or IL2, 4, or 5 accreditation, for example.
Best practice: If you need heightened technical compliance or accreditation for specific workflows, articulate contractually in your terms with the Hosted Model Provider which compliance or accreditation requirements you require (and to which services they need to apply). Work with your engineering teams to fail-safe requests from environments requiring a heightened accreditation or compliance certification from going to lower-accredited or certified Hosted Model Provider endpoints or services.
3. Clamp Down on the Hosted Model Provider’s Ability to Unilaterally Change Terms
3.1 Unilateral changes to hyperlinked online terms
Terms and conditions with Hosted Model Providers often incorporate online terms that are subject to unilateral change by the Hosted Model Providers. Often this is a consequence of Hosted Model Provider terms layering in hyperlinked terms that can be unilaterally updated and effective without notice. Even if you have successfully negotiated master terms, those terms may incorporate hyperlinked terms (e.g., to acceptable use policies, service specific terms, data processing terms, ZDR terms, etc.) that may be unilaterally updated by the Hosted Model Provider without notice. Hosted Model Providers often do update these hyperlinked terms in ways corrosive to ZDR and other AI Sovereignty considerations discussed in this document.
Best practice:
- Seek custom contractual terms that do not incorporate online terms by reference; or if you need to incorporate links, specify that those linked terms are only effective as-written on the effective date of your contract.
- If you’re able to achieve the above for some but not all hyperlinked terms (i.e., some hyperlinked terms can be unilaterally changed by the Hosted Model Provider), specify a rigorous order of precedence in the event of inconsistencies or conflicts between the negotiated and hyperlinked terms such that unilateral changes to the hyperlinked terms may not erode negotiated contractual guarantees like ZDR.
- If you need to agree to hyperlinked terms that the Hosted Model Provider may unilaterally alter, establish regular checks (ideally automated alerts) to monitor for any changes to the relevant online terms. Viewing older versions of the terms and conditions (e.g. via https://web.archive.org/) can be helpful in figuring out what changed.
3.2 Click-through terms surfaced to your non-legal employees
Model Providers may surface click-through terms in their console or platform that notify users that ZDR or other protections will not apply to a service they are trying to enable. An engineer attempting to enable that service may inadvertently accept these terms.
Best practice: Include contractual terms that make click-through agreements ineffective. If that cannot be obtained, educate console or platform users about this risk and have them check with legal before accepting any click-through agreements.
4. Mitigate Risk of Operational Disruption
4.1 Business disruption if safety classifiers triggered
Terms and conditions may allow Hosted Model Providers to suspend or terminate service immediately under certain conditions, including if they believe that you are violating any of their acceptable use policies (AUPs), which often include a broad set of restrictions that are subject to frequent unilateral changes by the Hosted Model Provider. Even in a robust ZDR setup Hosted Model Providers may rely on safety classifiers (that store only metadata indicating if the classifier fired, not the prompt that caused it to fire) to determine whether you are complying with their AUP, and those classifiers are often overly-sensitive and can incorrectly trigger on benign prompts. This means even a compliant use of their service can trigger suspension or termination, threatening disruption of your business.
Best practice:
- Require contractually that prior to initiating any termination or suspension of the service, the Hosted Model Provider provide (a) notice in the event a safety classifier fires, (b) an “investigation and cure” period for your security and IT teams to evaluate what triggered the classifier and collaborate with the Hosted Model Provider to establish that the trigger was the result of a false positive, or align on remediation in the event of a true positive, © that such “investigation and cure” period does not give the Hosted Model Provider rights to obtain or review your alpha, and (d) a reasonable buffer period for any suspension or termination of the service, sufficient to allow you to migrate to a different model.
- Ensure that your technical organization has implemented appropriate observability infrastructure to be able to track down prompts that caused a positive safety classifier hit, to help de-escalate any Hosted Model Provider outreach about a flag. Most Hosted Model Providers implement prompt IDs, and in the event of an incident can provide you the offending IDs to help you in your audit.
4.2 Blocking legitimate model requests
Hosted Model Providers’ safety classifiers can block legitimate use. Even if you have secured contractual exemptions to certain prohibited use cases, the Hosted Model Provider’s safety classifiers may still fail your requests to enforce those use case restrictions, disrupting your business.
Best practice: Add affirmative contractual language permitting your specific use cases, and if possible, language guaranteeing that the Hosted Model Provider will disable relevant safety classifiers. Don’t just remove blocking use case restrictions in your contract.
4.3 Global inference standards that route your traffic to prohibited regions
Many Hosted Model Providers offer model services, tools, and features by default under global inference standards that load balance your traffic across infrastructure in all the regions in which they have capacity. Some of those regions could be prohibited by your business operations due to legal or contractual requirements, and result in incidents and/or attendant business disruptions. Hosted Model Providers are not always upfront in their contracts or documentation about precisely what regions are in scope for global inference standards, and when they are, those lists are often subject to unilateral change by the Hosted Model Provider.
Best practice:
- Contractually require that the Hosted Model Provider not route your traffic to regions that would be prohibited by your organization.
- If you cannot obtain the above, some Hosted Model Providers offer inference capacity dedicated to specific regions, which you can contractually specify upon purchase. Note that these region-restricted options often involve additional cost.
- If you cannot obtain any of the above, contractually require that the Hosted Model Provider notify you if and when they add new regions to their global inference services, with sufficient lead-time to either procure region-restricted capacity or migrate to a different model service.
Key Takeaways
Sovereign control of your alpha requires granular control over how your data is processed by Hosted Model Providers. The protections offered by Hosted Model Providers, even if they call them “ZDR”, and even if you have negotiated robust ZDR, are full of pitfalls and traps for the unwary. Seek broad protective contractual terms, establish a vetting process and allow-list for new services to avoid going outside the scope of your protections, clamp down on unilateral changes to your agreement, and mitigate the risk of operational disruption by limiting what Hosted Model Providers can do if they believe things have gone wrong. The Hosted Model Providers have put a lot of thought into what their terms allow them to do with your alpha — you should too.
AI Sovereignty is Your Alpha: How to Avoid Transferring Your Alpha to a Hosted Model Provider was originally published in Palantir Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.