Treat the Release Note as a Third-Party Risk Event

A vendor can add an AI capability to software you already licensed, and nothing in the contract requires notice.

Corporate Compliance Insights published an edited version of this article on October 12, 2026.

In a wellness supplement plant, the SaaS quality management system holds the deviation record. An ingredient weight is high, a blend runs under the minimum time, or a contaminant turns up on a line check. Each one is documented in the system, routed to a reviewer, and tracked through the investigation behind the decision to release the batch.

The vendor updates the quality management system to version 12.4 and adds a line to the release notes: “AI-assisted deviation triage, enabled by default.” Nothing goes to legal because the agreement already permits it, and no purchase order is initiated because nothing is purchased. A change approver clears the release as routine, since it involves no infrastructure change and no new integration. The assessment on file describes a rules engine that passed every deviation to a human reviewer. In the version now in production, the model scores each one and closes the minor ones without a human reviewer. No one assessed that version.

Diligence generally reopens upon an additional purchase or a contract event, and a vendor adding a capability is neither. The control question is the same whether the product is a quality management system, an HR system or a procurement application.

The change clause already permits it

The vendor has done nothing wrong here, since the contract allowed the change. Review the unilateral modification clause in the vendor contract. Under it, the vendor may add or alter features at its discretion, and notice is usually required only for a change that reduces functionality. An added AI capability reduces nothing, so no notice is required. Then check the services agreement for language about improving or developing the services, since that is where a vendor takes the right to train on customer data.

At the next contract renewal, negotiate a notice obligation. “Material change” is not sufficient, because the vendor judges materiality. Name the capability instead: written notice before the vendor turns a feature on for customers, for any release in which it adds or modifies automated decision-making, generative output or model-based scoring applied to customer data. Pair that with the right to switch the capability off for your whole organization rather than by user, and with a documentation obligation covering the model and version, the hosting region, how long the vendor retains inputs and outputs, and whether it trains on customer data.

Nothing happens until someone notices the release

SaaS updates are made on the vendor’s schedule rather than yours. One instance of the platform runs for every customer, so there is no version to approve and no upgrade to decline. That leaves detection.

The system owner, whether that sits in quality or in IT, receives the vendor’s release communications and raises a change ticket for any software update. That ticket is where compliance can ask for more information, namely whether the release adds or modifies automated decision-making, generative output or model-based scoring against company data.

A change ticket carrying that information goes to the third-party risk owner, who decides whether the release needs a reassessment. That reassessment is narrower than the onboarding review. It covers one capability rather than the whole platform. The assessment determines whether anyone relies on the output without a human step, and whether the record the capability produces would satisfy a regulator.

Rank vendors by the sensitivity of the data they hold and the regulated decisions they touch, take the top tier, and assign each vendor to a person by name in the vendor record. For that tier, schedule a quarterly review with the assigned reviewer.

The same questions work at onboarding

These questions cover any AI capability in a vendor’s product, whether it arrived in a release or came with the original contract. Most of them can be answered by the account team, provided someone technical joins the call.

Which model, on whose infrastructure, and in which region it runs.

Whether the vendor sends company data to the model provider, and whether that provider appears as a sub-processor under the current terms.

Whether the vendor uses customer data for training or fine-tuning, what the default is, and how a change is confirmed in writing.

Whether the capability can be switched off for your organization alone, and whether that is supported configuration or a workaround the vendor may remove later.

What can be retrieved from the logs: inputs, outputs, confidence or ranking, who accepted or overrode the result, and how long each is kept.

What accuracy evidence the vendor holds for the decision this capability touches, and what it tested against.

How the vendor notifies customers of a model version change, and whether it will put that commitment in writing.

How the vendor classifies itself under the EU AI Act for this capability, and what it treats you as.

From the answers, decide whether the reassessment is paperwork or a finding, and whether the capability stays on while the question is open.

In addition, decide on ownership for shutting down or overriding the capability. When asked as part of ISACA’s 2026 AI Pulse Poll of more than 3,400 digital trust professionals, 39% did not know whether their organization has a documented process for shutting down or overriding an AI system, and 56% did not know how long halting one would take after a security incident. Whether an off switch exists at all is the vendor’s decision. Who may use it is yours.

The co-manufacturer’s release notes never reach you

None of that is available one step outside the company. A co-manufacturer runs its own quality management system, licensed from its own vendor, and the brand owner has no contract with that vendor, no access to the release notes and no standing to ask it anything. The assessment on file covers the co-manufacturer rather than what it runs, so all of it has to be written into the co-manufacturing agreement instead, as flow-down obligations: notice when the capability of a system touching your product changes, and the same documentation the platform vendor provides its own customers. If a co-manufacturer’s AI quality management system releases a batch that should have been held, it is the brand owner’s name on the recall notice.

This quarter, take the ten vendors holding your most sensitive data. Compare the date of the last assessment with the software version now in production, and read the vendor’s release notes for the interim. Ask each co-manufacturer the same question about the system running on its floor. You will finish with a clean answer or with a list of AI capabilities already running, in need of an assessment.

Sources

The source below is published by ISACA. It was read on October 12, 2026.

ISACA, “AI Use Accelerates, While Governance and ROI Lag, Says New ISACA Research,” press release, May 5, 2026. Respondent count of more than 3,400 digital trust professionals, the 39 percent who did not know whether a documented shutdown or override process exists, and the 56 percent who did not know how long halting an AI system would take after a security incident.

https://www.isaca.org/about-us/newsroom/press-releases/2026/ai-use-accelerates-while-governance-and-roi-lag-says-new-isaca-research

Next
Next

Where Your AI Policy Stops Being True