An AI tool can change without the product changing at all.
The interface can look exactly the same. Employees can use it exactly the same way. There may be no major product announcement or new feature for security teams to notice.
But underneath the product, something important may have changed.
A privacy policy gets rewritten. A restriction on how customer content can be used disappears. Retention commitments become less specific. A new arbitration clause appears. Or a vendor introduces clearer protections that actually reduce risk.
These changes can materially affect an organization's risk exposure, even when nothing about the employee experience changes.
That's why we continuously maintain the risk analysis behind the Verax AI Tool Risk Center.
Here's what changed in September.
September 2026 at a Glance
Our September review identified changes across a number of AI tools, including 10Web, Copysmith, DeepSeek, Gamma, Gling, Hemingway, Jenni AI, Leonardo.AI, Meta AI, OpenAI, Pictory, Respeecher, Riverside.fm, Synthesia, and Wordvice AI.
Not every update resulted in a score change. In some cases, vendors moved their Terms of Service or Privacy Policy to new URLs without materially changing the risk dimensions we track.
In others, the underlying terms changed enough to affect our assessment of training use, data retention, or legal risk.
Some scores increased. Others improved.
The important part isn't simply which direction a number moved. It's what changed underneath it.
Training Practices Continue to Change
Several of the most significant changes this month involved how AI providers describe their ability to use customer content.
Jenni AI: Training Use 2 → 5
Jenni AI saw one of the more notable changes in our September review.
Its previous policy contained an explicit prohibition around training use. In the rewritten policy, that language was removed and replaced with disclosures showing content sharing with a third-party analytics provider.
That doesn't automatically mean every piece of customer content is being used to train an AI model.
But from a risk-assessment perspective, removing an explicit restriction matters.
When evaluating an AI service, clear contractual limitations around how data can be used are materially different from policies that leave broader possibilities open.
As those commitments become less explicit, uncertainty increases, and so does the corresponding risk.
Riverside.fm: Training Use 4 → 5
Riverside provides another example.
Its June 2026 Privacy Policy explicitly describes Riverside as an independent controller of Content Data for AI training, with an opt-out available to business customers through written agreement.
The previous policy described AI processing differently and did not make the same distinction around standard-tier content.
The important detail here is that the same AI service can have a different risk profile depending on the contractual relationship under which it's being used.Enterprise agreements, business plans, and consumer accounts aren't necessarily interchangeable from a security or data-governance perspective.
10Web and Pictory
We also increased the training-use risk scores for 10Web and Pictory from 5 to 6.
For 10Web, rewritten terms introduced broader operational licensing language and explicit sharing with third-party AI service providers while removing some of the clearer delineations present previously.
For Pictory, a rewritten Privacy Policy broadened language around aggregated data, including commercial uses, compared with the more limited language in the previous version.
Again, the interesting pattern isn't any single vendor.
It's how frequently the language governing AI data use is still changing.
Data Retention Can Change Too
Training gets much of the attention in AI security, but it's only one part of the data lifecycle.
How long an AI provider keeps information matters too.
Jenni AI: Data Retention 4 → 5
Alongside its training-use change, Jenni AI's rewritten policy introduced explicit long-term retention categories.
These include support logs retained for 24 months and some abuse, legal, and tax records that may be retained indefinitely.
While the policy also describes faster deletion from active systems in some circumstances, the expanded long-term retention categories increased the overall retention risk in our assessment.
Pictory: Data Retention 5 → 6
Pictory also moved higher on retention risk.
Previous findings referenced a defined 12-month period following account termination. That commitment isn't present in the current policy.
Instead, the current language describes keeping information for as long as necessary and includes exceptions for backups, archiving, fraud prevention, and related purposes without defining a specific deletion window.
The difference may sound subtle.
From a risk perspective, it isn't.
A defined retention period gives an organization something concrete to evaluate. "As long as needed" leaves substantially more discretion with the provider.
Leonardo.AI: Data Retention 5 → 4
Not every retention change increased risk.
Leonardo.AI moved in the opposite direction after introducing a clearer account-deletion provision.
Its current terms specify deletion after 12 months of account inactivity, providing a more concrete retention boundary than the previous language.
That's an improvement, and the risk score moved accordingly.
Continuous assessment should capture positive changes just as readily as negative ones.
Legal Terms Are Moving in Both Directions
Some of the largest changes this month weren't about models or data at all.
They were in the legal terms governing what happens when something goes wrong.
Copysmith: Legal Terms 4 → 7
Copysmith's rewritten Terms of Service introduced binding arbitration and a class-action waiver that weren't present in the version previously assessed.
Those provisions materially changed our legal-risk assessment, moving the score from 4 to 7.
Wordvice AI: Legal Terms 4 → 7
Wordvice AI saw a similar increase.
Its updated terms introduced mandatory arbitration through the Korean Commercial Arbitration Board, along with class-action and jury-trial waivers and Korean governing law.
The additional clarity resolved some previous ambiguity, but the terms themselves increased the restrictions placed on users in a dispute.
As a result, its legal-risk score increased from 4 to 7.
Gamma: Legal Terms 5 → 6
Gamma's updated terms also include mandatory arbitration and a class-action waiver.
However, they provide a 30-day opt-out window.
That distinction matters.
Our risk model doesn't treat the presence of arbitration as a binary checkbox. A meaningful opt-out provides users with a protection that isn't present in more restrictive agreements, and the resulting score reflects that difference.
Legal Risk Can Improve Too
Two vendors moved in the other direction.
Respeecher: Legal Terms 5 → 3
Respeecher's current Terms of Service specify Washington state law and don't contain a mandatory arbitration provision.
Compared with the assumptions underlying the previous assessment, that represents a materially more favorable legal position for users.
Its legal-risk score therefore decreased from 5 to 3.
10Web: Legal Terms 6 → 5
10Web's rewritten terms also no longer include the explicit mandatory arbitration structure visible in the previous version we reviewed.
Its legal-risk score decreased from 6 to 5, even while its training-use score increased.
That's a useful reminder that a vendor's risk profile rarely moves in only one direction.
One dimension can improve while another gets worse.
Sometimes the Change Is Simply Where the Policy Lives
DeepSeek, Gling, Hemingway, and OpenAI all had policy URL changes identified during this review.
DeepSeek moved its Terms of Use and Privacy Policy to new hosted policy URLs. Gling moved its Terms of Use. Hemingway's previous terms and privacy URLs no longer resolve and have been replaced by new legal pages. OpenAI also changed the location of its Privacy Policy.
A changed URL by itself isn't evidence of increased or decreased risk.
But it's operationally important.
Automated assessments, vendor inventories, procurement records, and compliance processes can easily continue pointing to documents that have moved or no longer exist.
Continuous monitoring therefore isn't only about identifying score changes. It's also about making sure the underlying evidence remains current.
The Product Didn't Change. Should Your Policy?
This month's changes illustrate something security teams increasingly need to account for.
When an employee opens one of these tools tomorrow, it may look exactly like it did yesterday.
The buttons haven't moved. The workflow hasn't changed. The employee may have no reason to know that anything happened.
But the conditions under which their organization's data is being processed may have changed.
And that raises a more interesting question than whether a risk score moved from 4 to 5:
Should a change in an AI tool's risk automatically affect how the organization allows that tool to be used?
If a tool's training practices become less favorable, perhaps employees should no longer be allowed to send certain categories of sensitive data to it.
If retention commitments weaken, perhaps usage should be restricted for particular teams.
If the enterprise version offers stronger protections than the consumer version, perhaps access should depend on which account an employee is using.
Discovery tells you that the tool exists.
Continuous risk assessment tells you whether the conditions around that tool have changed.
Policy enforcement is what allows you to do something about it.
From Risk Monitoring to Risk-Based Enforcement
This is ultimately why we don't think AI tool risk should live only in a vendor-assessment spreadsheet.
Organizations increasingly need to connect what they know about an AI tool with how employees are allowed to use it.
At Verax, we continuously maintain risk profiles across the AI tools in our registry. Those risk signals can then become part of the policy decisions organizations make around which tools are allowed, which users or groups can access them, and
what information can be shared.
The goal isn't to block every tool whose score changes.
It's to make sure that when the conditions behind an approved tool change, the organization's security posture can change with them.
Because the tool your security team approved six months ago may still have the same name, the same interface, and the same users.
It doesn't necessarily have the same risk.


