Tech & Sourcing @ Morgan Lewis

A company licenses an artificial intelligence–enabled service after evaluating its functionality, security, performance, and compliance characteristics. Six months later, the provider upgrades the underlying model or replaces it altogether. The product may look the same, but the technology beneath it may have changed in ways that affect performance, data processing, regulatory compliance, or the customer’s downstream obligations.

Model changes are increasingly part of the artificial intelligence (AI) lifecycle. Developers release new models and retire older ones, and providers that rely on those models may need to migrate. For both sides of an AI transaction, this raises a practical question: What happens when the model evaluated at signing is not the model in use during the term?

Technology agreements have traditionally given providers broad flexibility to update and improve their services, and providers have legitimate reasons to preserve such mutability. Customers, meanwhile, may care about the specific model where it is a material component of the solution.

Routine patches, security updates, and improvements that do not materially affect the service may remain within the provider’s discretion. Other changes may warrant a different process, such as replacing a foundation model, changing the third-party model provider, adding new capabilities, or materially altering performance or the handling of customer data. The parties may wish to define where that line falls.

For material changes, the parties may consider an advance-notice mechanism. Customers may value time to evaluate a change before it reaches production, while providers will want a process that is workable at scale and consistent with their release cycles.

Notice might address:

• The model being introduced or retired and expected timing
• Material changes to functionality, performance, security, or data handling
• Any new third-party AI provider or subprocessor
• Any customer action required before migration

For higher-risk or business-critical uses, the parties might also consider testing against agreed criteria or implementing a customer review step or limited period of continued access to the existing model. Providers may weigh these measures against the operational complexity and cost of supporting multiple model versions.

These commitments should also account for upstream dependencies. Because a provider relying on a third-party foundation model may not control when that model is modified or retired, the parties should consider whether downstream notice, testing, and availability commitments can be supported by the provider’s own vendor arrangements.

Model changes should also be considered against the parties’ existing contractual commitments. Where an agreement addresses accuracy, security, data use, intellectual property, regulatory compliance, or service levels, the parties may consider how those obligations apply following an update or substitution.

This may be particularly important where the customer relied upon a particular model in its own risk or compliance assessment. Providers, in turn, may seek flexibility to evolve the service so long as agreed commitments continue to be met.

One approach is to provide that model changes will not materially reduce agreed functionality, security, or compliance protections, while allocating responsibility for any additional testing, documentation, or risk assessments required by the change.

Model retirement presents a related issue. A provider may have limited control over the timing of a model’s retirement where it relies on a third-party model developer, while a customer may need sufficient time to evaluate and migrate to a replacement.

The parties may therefore consider addressing notice of discontinuation, whether a substantially equivalent replacement will be offered, and the consequences if the replacement does not meet agreed requirements.

Where a change materially and adversely affects the service and cannot reasonably be remediated, the parties may also consider transition assistance, termination rights, or other remedies calibrated to the circumstances and what the provider can reasonably mitigate.

As AI-enabled services continue to transform, model changes may become an increasingly key part of contract governance. The appropriate approach will depend on the role of the model, the customer’s use case, and the provider’s control over its underlying technology and third-party dependencies.

Rather than attempting to prevent the technology from changing, parties should consider establishing a workable framework for identifying and managing changes that materially affect their respective rights, obligations, and expectations.