When Your Vendor's AI Ambitions Become Your Governance Problem

Yesterday I argued that most AI governance tools were built for the wrong problem— that agentic AI requires a different governance architecture than the one the category has shipped for generative AI. Here’s what that structural mismatch looks like when a live industry pattern hits every regulated enterprise at once.

A shift is underway across enterprise SaaS, and it deserves more attention than it is getting.

Over the past 18 months, a growing number of major SaaS platforms have updated their data policies to include customer content in AI model training — in many cases, enabled by default. The opt-out mechanisms vary. The notification timelines vary. The exemptions vary by subscription tier. But the direction is consistent: customer operational data is becoming AI training data, and the governance burden is shifting to the customer.

For most enterprises, this is an inconvenience. For regulated financial institutions, it is a compliance event.

The FINOS AI Governance Framework, the EU AI Act, and DORA all have specific requirements around third-party AI data controls, model provenance, and training data lineage. The industry-wide shift toward default AI data collection is testing whether those requirements have teeth — and whether enterprises have the infrastructure to enforce them.

The Industry Pattern

This is not about any single vendor. It is a structural shift in how SaaS platforms monetize customer data in the AI era. The pattern has been documented across the technology press throughout Q1 and Q2 2026 — notably by The Register and ghacks — and it follows a recognizable sequence.

A platform announces an AI capability enhancement. The terms of service or data contribution policy is updated to enable data collection for model training. The default setting is opt-in for AI training — meaning customers must take affirmative action to opt out. Enterprise or premium tiers receive more granular controls or automatic exemptions. And the announcement is made with lead times that often exceed most compliance review cycles, so administrators do not see the change before it takes effect.

Variations of this pattern have emerged from platforms across productivity, collaboration, developer tools, CRM, and communications over the past 18 months. Each instance has been positioned as necessary to deliver “richer, more diverse” AI capabilities. Each instance has placed the governance burden on the customer.

Customer operational data is becoming AI training data, and the governance burden is shifting to the customer.

The cumulative effect is significant. A regulated financial institution running a typical enterprise SaaS stack — project management, documentation, communication, CRM, code repositories, cloud infrastructure — now has potentially dozens of vendors who have modified their AI data practices in the past year. Most procurement and compliance teams have not audited the full scope of these changes.

What the FINOS AI Governance Framework Says

The FINOS AIGF was built for exactly this scenario. Several of its risk categories apply directly to the pattern of vendor-default AI data collection.

Third-party AI model provenance. The AIGF is explicit that organizations consuming third-party AI services must understand and verify the provenance of the models being applied to their data. When a SaaS vendor trains models on customer content, the resulting model is a derivative of that content. The question is not whether the vendor de-identifies the data — it is whether the consuming institution can verify the provenance of the models that are subsequently applied across the platform, including to other customers’ workflows.

Training data lineage. Data lineage tracking is a foundational AIGF requirement. Institutions must maintain information that tracks which source data contributed to AI-generated outputs. When a vendor uses customer content for model training, the institution’s data becomes part of a model’s training lineage — often without the institution’s ability to audit or reverse the contribution.

Cross-tenant signal leakage. This is the most technically subtle concern. When a platform computes semantic similarity scores or embeddings across customer tenants — even using “de-identified and aggregated” data — the shape of one organization’s operations can influence the model behavior experienced by another. An institution’s internal workflows, incident patterns, or project structures become part of the embedding space that informs another customer’s AI-generated recommendations. For regulated enterprises, this is a data boundary question with regulatory implications under both DORA’s third-party risk management requirements and the EU AI Act’s transparency obligations.

CC4AI and control inheritance. FINOS has been building the answer to this problem through CC4AI — Common Controls for AI Services. CC4AI establishes a common evidence artifact format so that cloud providers and AI vendors can attest once to their AI data practices, and every consuming financial institution can inherit that assurance. The initiative includes BMO, Citi, Microsoft, Morgan Stanley, RBC, Bank of America, Google Cloud, Red Hat, and AWS. The gap between CC4AI’s vision and current reality — where vendors can unilaterally change AI data policies with advance notice most compliance teams cannot operationalize — is the governance problem this article is about.

The Regulatory Framework

The EU AI Act and DORA both establish specific obligations that are directly relevant to vendor AI data practices.

EU AI Act — third-party obligations. Under the EU AI Act, organizations deploying third-party AI systems face compliance obligations that extend to how those systems were trained. Article 16 places requirements on providers. Article 26 places requirements on deployers. Commercial and cloud agreements are expected to cover training data provenance, audit and cooperation clauses, exit and interoperability terms, and allocation of regulatory responsibilities. General-purpose AI model providers must publish a summary of training datasets, maintain records of training data origins, and comply with the Copyright Directive. For financial institutions using SaaS platforms that train on customer data, the question becomes: can you demonstrate to a regulator that you understood, consented to, and maintained oversight of how your operational data was used in your vendor’s AI training pipeline?

DORA — third-party risk management. DORA, enforceable since January 17, 2025, requires financial institutions to maintain comprehensive third-party ICT risk management programs. This includes ongoing monitoring of service providers’ data practices, documented risk assessments of material changes to vendor policies, and the ability to produce evidence that third-party risks are being actively managed. A unilateral change to a vendor’s AI data practices is, by definition, a material change to the ICT service relationship. Under DORA, this should trigger a documented risk assessment, an evaluation of the change against the institution’s risk appetite, and a governance decision — not passive acceptance through inattention.

Why Subscription-Tier Privacy Is a Governance Failure

The most concerning element of the current industry pattern is the tiering of privacy controls by subscription level.

When full opt-out rights or default-off data collection is available only to enterprise-tier customers, the implication is clear: data governance is being treated as a premium feature rather than a baseline right. Customers with the most regulatory muscle — large banks, government agencies, HIPAA-covered entities — receive exemptions. Everyone else is opted in by default.

This creates a two-tier governance landscape. The institutions with the most sophisticated compliance programs are protected. The institutions that most need protection — mid-tier banks, regional financial firms, healthcare organizations on standard plans, fintechs subject to the same regulations but operating on smaller budgets — are the ones whose data enters the training pipeline.

The existence of the opt-out does not satisfy the governance requirement.

From an AIGF perspective, this is a control failure regardless of subscription tier. What satisfies the governance requirement is evidence that the institution assessed the risk, made a documented decision, and can demonstrate ongoing compliance with its third-party AI data controls.

What Regulated Enterprises Should Do Now

This is not a moment for outrage. It is a moment for governance.

Audit your SaaS AI data exposure. Every regulated institution should conduct an immediate audit of AI data policies across its SaaS stack. Which vendors have updated their terms to include AI training in the past 12 months? What are the default settings? What opt-out mechanisms exist? Are they tier-dependent? Document the findings and map them to your AIGF risk categories.

Treat vendor policy changes as material ICT risk events. Under DORA, a change to how a vendor uses your data for AI training is a material change to the service relationship. It should trigger the same documented risk assessment process as any other significant vendor policy modification. If your third-party risk management program does not currently include AI data practices, it has a gap.

Assess whether subscription tiers satisfy your governance requirements. If your current tier does not provide full opt-out control over AI data collection, evaluate whether an upgrade is necessary to meet your regulatory obligations — and document the rationale either way. The governance question is not “can we opt out?” but “do we have evidence that our data controls are enforced?”

Demand CC4AI-style evidence from your vendors. The FINOS CC4AI initiative exists because policy documents are not sufficient evidence of AI data governance. Vendors should be able to provide machine-readable, standardized attestations of their AI data practices — including training data provenance, retention periods, cross-tenant isolation, and opt-out enforcement. If your vendor cannot provide this today, that is a finding in your third-party risk assessment.

Evaluate sovereign alternatives for critical workflows. For workflow infrastructure where data sovereignty is non-negotiable — case management, regulatory reporting, compliance automation, incident management — evaluate whether SaaS platforms subject to unilateral AI data policy changes are appropriate. Open-source, managed alternatives exist for many of these workloads. The FINOS ecosystem, including Fluxnova for workflow orchestration, was built specifically to give financial institutions sovereign control over critical infrastructure.

The Structural Question

The current wave of vendor AI data collection is not going to reverse. AI is too valuable, and customer data is the most efficient training resource available. Every enterprise SaaS vendor is facing the same incentive: use customer data to improve AI capabilities, or fall behind competitors who do.

The question is not whether vendors will train on customer data. The question is whether regulated institutions have the governance infrastructure to manage the risk.

That means continuous monitoring of vendor AI data practices — not annual policy reviews. It means automated evidence collection that proves your third-party AI controls are enforced — not manual audit responses assembled after the fact. It means an evidence architecture that maps vendor practices to specific AIGF controls and regulatory requirements — so that when a regulator asks, the answer is ready.

This is the infrastructure problem that sits underneath every vendor AI data controversy. The policy debate is important. The governance infrastructure is what determines whether you are actually compliant or merely intending to be.

At iTmethods, this is the problem we built the Fortress Family to solve. Reign’s Evidence Engine automates AIGF compliance evidence across the AI stack, including third-party AI vendor governance. Forge provides managed infrastructure for sovereign workloads that cannot be subject to a vendor’s unilateral AI ambitions. And we have been aligning the platform to the FINOS ecosystem — AIGF, CC4AI, Fluxnova — because the governance standards being built by the industry’s largest institutions are the standards that will define compliance for the next decade.

The vendor AI data question is going to get louder. The institutions that treated it as a governance infrastructure problem — rather than a contract negotiation problem — are the ones that will be ready.

Paul Goldman is CEO of iTmethods and creator of the Fortress Family — Reign, Forge, and BioCompute. He has been building managed infrastructure for regulated enterprises for 21 years. He writes about AI governance, enterprise infrastructure, and what financial institutions need to build safely in the agentic era.

Reign maps to all 25 FINOS AIGF risk categories, including third-party AI model provenance, training data lineage, and the six new agentic AI risks in v2.0. Learn more at itmethods.com/reign.

Sources

• FINOS AI Governance Framework — air-governance-framework.finos.org
• FINOS AIGF v2.0 — finos.org v2.0 blog
• FINOS CC4AI announcement — finos.org CC4AI press
• EU AI Act high-level summary — artificialintelligenceact.eu
• DORA enforcement — advisori.de regulatory-year-review-2026
• Industry pattern reporting — The Register (theregister.com), ghacks (ghacks.net), Q1–Q2 2026

Previously in this series: Day 1 — Why the AI Governance Stack Was Built for the Wrong Problem · 114 Days · The Camunda 7 Fork