AI governance across the full SaaS stack: one register, many systems

AI did not arrive in your company as a single system you could evaluate, approve, and govern. It arrived as a feature toggle inside Salesforce. It arrived as Copilot inside Microsoft 365, already licensed for your entire organisation. It arrived as Gemini inside Google Workspace. It arrived inside your HR platform, your support ticketing system, your recruiting tool, and whatever your product team shipped last sprint without an approval process in place. Governing AI now means governing the stack you already run — and that is a fundamentally different challenge than evaluating a single new vendor.

The compliance leads and security officers we work with are not struggling with a lack of policy. They have policies. What they lack is an enumerable, current inventory of where AI is operating and evidence that the controls they wrote for those systems actually hold. The gap between the policy document and the running system is where audit findings live, where enterprise sales deals stall, and where the risk accumulates quietly until it doesn't.

This is not an abstract technology problem. It is a governance problem with a defined shape, and it is solvable — but only if you start with an honest picture of what you are actually governing.

01 / The inventory problem

You cannot govern what you have not enumerated. That principle predates AI by decades — it is why asset inventories are a baseline control in SOC 2, ISO 27001, and every serious security framework. But AI features inside SaaS platforms break the inventory assumption in a way that a new server or a new application does not.

When your Salesforce administrator enables Einstein or Agentforce features, no procurement process fires. When Microsoft rolls Copilot capabilities to your tenant, no change ticket is created. The feature appears inside a system you already approved, already pay for, and already trust with your most sensitive customer data. Your vendor inventory lists Salesforce. It does not list the AI features Salesforce shipped in the last three quarterly releases.

The consequence is an inventory that is structurally out of date the moment you finish it. AI governance cannot be a point-in-time project. It requires a continuous process that watches the systems you already have — their configurations, their enabled features, their data-access scopes — and keeps your register current as vendors push updates on their own schedule.

The first move in any serious AI governance programme is therefore not writing an AI policy. It is building the mechanism to know, at any given moment, what AI capabilities are active across your stack and what data each one can reach.

02 / Shadow AI through your vendors' own roadmaps

Shadow AI is the term most organisations use to describe employees using personal ChatGPT accounts or unapproved consumer tools. That problem is real. But there is a more structurally significant version of the same problem: the AI capabilities your approved vendors are shipping into systems you have already trusted with sensitive data.

Salesforce's roadmap is public. Microsoft publishes Copilot release notes on a monthly cadence. Google announces Gemini expansions across Workspace products with its own release cycle. The AI is not hiding. But few mid-market organisations have a process that translates a vendor's release note into a control assessment, a data-flow update, and a register entry before the feature lands in production.

This is the governance gap that matters most at scale. An employee using a personal AI tool is a policy and training problem. A vendor AI feature operating on your customer data, your financial records, or your HR files — inside a system you already granted broad access — is a structural risk that requires a structural response. Your vendor management process needs to extend its scope to cover not just the vendor relationship, but the specific AI capabilities the vendor is deploying into your environment and the data those capabilities can access.

The AI governance problem is not about the tools your employees might be hiding. It is about the capabilities your approved vendors are deploying into systems you already trust.

03 / Mapping obligations onto controls you already have

The EU AI Act, NIST's AI Risk Management Framework, and the AI-specific addenda that enterprise customers are now inserting into contracts all share a common structure: they ask you to demonstrate that the AI systems you operate or use are understood, controlled, and subject to human oversight. The frameworks differ in scope and enforceability. They converge on the same underlying requirement.

For most mid-market organisations, the right approach is not to build a parallel AI governance programme from scratch. It is to extend the controls you already operate. Access governance in Okta already covers who can reach which systems — extend it to cover who can enable or interact with AI features within those systems. Your vendor management process already covers data processing agreements — extend it to explicitly address AI processing, training data use, and model output retention. Your change management process already covers new capabilities in production — extend its scope to include AI feature enablement from existing vendors.

NIST's AI RMF is useful here not as a compliance obligation for most US mid-market companies, but as a vocabulary and a structure. It maps cleanly onto controls that ISO 27001 and SOC 2 organisations already operate. Using it as scaffolding allows you to demonstrate AI governance through your existing audit programme rather than creating a separate one that auditors must learn to evaluate.

The EU AI Act matters most to companies that sell AI systems or operate high-risk AI use cases as defined in the regulation. For most mid-market SaaS users, the more immediate obligations come from customer contracts and from the representations your own privacy and security documentation already makes about how you handle sensitive data.

04 / Human oversight as a checkable control

Every AI governance framework requires human oversight. NIST's AI RMF calls for it. The EU AI Act makes it a legal requirement for high-risk systems. Enterprise customer contracts are increasingly specific about it. The challenge is that "human oversight" as written in a policy document is not a control. It is a statement of intent.

A control is something you can check. Human oversight over an AI feature in Salesforce means a defined process: which decisions the AI makes autonomously, which decisions require human review before action, who performs that review, how it is recorded, and how exceptions are handled. Those are auditable. The policy sentence is not.

Mid-market organisations that are ahead of this problem have translated oversight requirements into specific configurations and process controls at the system level. In Salesforce, that means reviewing which Agentforce actions are permitted to execute without confirmation. In Microsoft 365, it means configuring Copilot data access scope and reviewing what it can surface to which users. In Google Workspace, that means understanding which Gemini features can access and summarise restricted content.

The documentation of those configurations — the current state, the date it was verified, the data it was drawn from — is what makes oversight a control rather than a claim. That documentation has to be maintained continuously, because the configurations can change when the vendor ships an update, when an administrator adjusts a setting, or when a new feature is enabled by default.

05 / Why continuous evidence is the only honest answer

Point-in-time assessments made sense when systems changed slowly. A SOC 2 Type II audit covers a twelve-month period because the systems under audit were, for most of that period, roughly stable. The controls tested in January were still the controls in December, with documented exceptions for changes in between.

AI features in SaaS platforms do not change on that cadence. Microsoft ships Copilot updates monthly. Salesforce operates on quarterly release cycles that routinely include new AI capabilities. Google Workspace features change on a rolling basis. The system you assessed in January may be meaningfully different by April — not because your team changed anything, but because the vendor did.

This means the evidence you produce needs to be continuous, not periodic. The question is not whether you were compliant at audit time. The question is whether you can demonstrate the current state of your controls and the history of that state over the period under review. A register of AI capabilities that was accurate in January and is now eight months out of date is not evidence. It is a liability — because it represents what you thought you knew, not what is actually running.

Continuous evidence collection is not a new concept in security. It is how mature vulnerability management programmes work. It is how cloud security posture management works. The same logic applies to AI governance: automated, continuous observation of the systems under governance, with a timestamped, independently-held record of what each system's controls show.

06 / The evidence posture matters double for AI

AI systems — whether embedded in Salesforce, Microsoft 365, or your own product — process content. They process email, customer records, support tickets, financial data, personal information, and the most sensitive operational content your organisation handles. That makes AI governance an extension of your data protection programme, not a separate exercise.

The evidence posture that matters for SOC 2, ISO 27001, HIPAA, and GDPR compliance matters for AI governance for exactly the same reasons: the systems being governed handle sensitive data, and the proof that you are governing them well must not itself become a new risk surface. A compliance tool that copies your Salesforce data, your Microsoft 365 content, or your HR records to prove that you protect those records is not solving the problem. It is replicating it.

The right model observes the control at its source — in Salesforce, in Microsoft 365, in Okta, in AWS — and records that it was met. Timestamped, independently held, covering the full population of the relevant control, holding zero copies of the underlying sensitive records. That is the evidence posture that survives scrutiny from an auditor, from a customer's security team, and from a regulator reviewing your AI obligations.

Governing the full SaaS stack for AI is not a problem that yields to a one-time project or a policy update. It requires a continuous evidence record maintained by a process designed for the speed at which your vendors are moving. The organisations that establish that infrastructure now will be in a materially different position when their next enterprise customer asks whether they can prove it.