AI is being added to enterprise SaaS platforms at speed. Many organizations have accepted this as a product improvement. Few have deeply assessed what it means for their data and subsequently their compliance posture.
SaaS companies are shipping new AI-enabled features at speed. Often these are turned on by default. And, in several documented cases, AI capabilities have been introduced into platforms handling regulated data before anyone confirmed those features were compliant with the frameworks organizations are required to meet.
This is not an accusation of bad intent, it is however reflective of how modern enterprise software development now works. AI is central to most enterprise software growth strategies. Your data, often without opting in, is used to inform these features and train the models. Similarly, often without opting in, these features are released as "enabled", and, in turn, represent security and compliance risk.
Several major SaaS vendors have established rights in their terms of service to use customer data for AI model training. In some cases, these rights are enabled by default, with opt-out mechanisms available but not prominently surfaced and in some cases not available at time of launch.
Default opt-ins are vendor-specific and, within a single vendor often "tier" specific. The pattern is that the privilege of choice comes with a price tag. You may need to delve deep into settings, documentation, and agreements to get to the truth of what is collected, whether you agreed to it explicitly and if you can change these settings.
Salesforce is the most discussed recent example. A setting surfaced in Salesforce's Spring '26 release revealed that customer data may be used by default to train global predictive AI models. The practice is not new. It has been part of Salesforce's Main Services Agreement since at least 2018. Spring '26 added a self-service toggle in Setup to make the setting visible and disableable without requiring a support case.
Atlassian follows the same pattern at a larger scale. Starting August 17, 2026, Jira and Confluence cloud customers will have their metadata and in the case of the Free and Standard tier, their in-app data used to train Atlassian's AI models by default.
For Free, Standard and Premium tier customers, metadata collection cannot be opted out of at all. Enterprise customers have both data types off by default. The policy applies to cloud deployments only. Self-hosted Data Center customers are not affected.
In-app and metadata are different. In-app data represents the information that in many cases is highly sensitive. In the case of Atlassian, that could be content created by users, such as Jira task titles, descriptions and comments, or content within Confluence pages. Metadata is data about data. It generally describes how your organization and users utilize the platform. It can include things like feature usage, navigation patterns, and workspace structure. It reveals how you work and can represent valuable business intelligence.
Worth Noting: The data center on-premise option is getting the flick, much like other vendors on-premise offerings.
Atlassian's Data Contribution Settings
| Plan | Metadata | In-App data | Can you change it? |
| Free/ Standard |
Always on | On by default | Metadata: No. In-app data: Yes, can turn off |
| Premium | Always on | Off by default | Metadata: No. In-app data: Yes, can turn on |
| Enterprise | Always on | Off by default | Metadata: Yes, can turn off. In-app data: Yes, can turn on |
Source: Atlassian Support — Data Contribution Settings
This is where it gets interesting. Your data can inform the creation, improvement, and expansion of these features, depending on your settings. Whether you actively use their AI features is another consideration.
This is an issue to consider from a few angles. The data accessed or provided in the use of the feature, and the ongoing access to your data to improve that feature and its collective outputs.
Much like the default opt-in to AI training, the default opt-in to AI features being "on" represents another risk.
NetSuite recently illustrated a common issue. Often, AI features are not assessed for compliance; this becomes an even bigger issue when you are automatically opted in for those features.
In the case of NetSuite it was in relation to their customers who are required to be HIPAA compliant. NetSuite released a notice to their customers.
Oracle NetSuite has recently updated certain AI features and functionality in its product offerings. The AI features that are part of the functionality, modules, and services listed on the Oracle NetSuite HIPAA product webpage have not been assessed for HIPAA compliance.
The guidance NetSuite provided with this was that the features should not be used in connection with workflows involving protected health information (PHI) or other data subject to HIPAA requirements.
This represents a clear example of not just the risk of AI to data security and compliance, but the issue with default opt-in for AI features.
Read more: AI risks for HIPAA compliance
AI features embedded in SaaS platforms do more than consume your data for training. They create new access paths to sensitive information that did not exist before the feature was enabled. And create complexity when trying to manage your data security and compliance boundary. It is fundamentally about the exposure of certain types of data and where that data ultimately surfaces.
This holds true for whether it is PHI and HIPAA compliance, CUI and CMMC compliance or export controlled data and ITAR compliance. If that data is exposed in a way that is not compliant, then there is a non-compliance issue, and all that that entails for an organization. Given the pervasiveness of model training outputs, it's not clear how an organization would remedy a breach of this nature, or even if it's possible to regain control over the AI model induced regulated data.
As the NetSuite example illustrates, AI features are being shipped into platforms handling regulated data before compliance assessments are complete. Organizations are often opted in by default. The feature is active before anyone has confirmed it meets the frameworks the organization is required to satisfy.
SaaS vendors ship updates continuously. Default settings change. New AI features are enabled. Opt-in and opt-out configurations that were accurate last quarter may not reflect what is active today. The pace of change is itself a risk. A compliance posture built on a point-in-time review of vendor settings is not a durable one.
As the Salesforce and Atlassian examples show, both AI training and AI feature access are frequently enabled by default. Opting out requires deliberate action, an understanding of where the settings live, and in some cases a support request or email to the vendor. Most organizations have not completed this review across their full SaaS stack.
Many SaaS vendors are not running their own AI models. They are calling third-party models via API. Your data may be sent to an upstream provider whose terms, data handling practices, and compliance posture you have not assessed and may not be aware of.
AI agents act autonomously across multiple systems to complete a goal. Each system boundary they cross is a potential compliance gap. Each data flow they generate may constitute a new business associate relationship under frameworks like HIPAA, occurring at machine speed without human oversight at each step.
The common thread is that AI expands the surface area of who and what can access your sensitive data, often faster than governance can keep up. The changeability of vendor agreements and default opt-in practices increases the risk.
The most durable defense is one that does not depend on vendor settings or release cycles. If sensitive data never reaches the vendor in readable form, their AI cannot train on it, expose it, or pass it to an upstream model provider.
StratoKey's Cloud Data Protection Gateway sits between your organization and your SaaS environment. Before data is transmitted to any SaaS platform, sensitive fields are tokenized or encrypted. Tokenization replaces sensitive values with non-sensitive tokens. Encryption renders data unreadable. Either way, the vendor receives only protected values. The sensitive data stays in your environment and under your control. For AI agents and workflows that move data across system boundaries, StratoKey's API Gateway enforces policy on machine-to-machine data flows, tokenizing or encrypting payloads before they are transmitted.
The SaaS platform and its AI features continue to function. Your users get the productivity benefits. The difference is that the AI operates on tokens or ciphertext rather than your sensitive regulated data. It cannot train on what it cannot read. It cannot expose what it never received. And it cannot pass regulated data in plain text to an upstream model provider.
This also reduces your compliance scope. When sensitive data never enters a vendor environment in readable form, that environment's footprint within your compliance boundary shrinks. Audits become more contained. Controls are easier to demonstrate.
AI features will continue to ship. Defaults will continue to change. StratoKey gives you a position that does not need to be rechecked with every release cycle.