AI Governance for SaaS: The Buyer Asks First

Something I keep running into, and it took me a while to name.

A deal is in its last stretch. Security review cleared weeks ago. Then a questionnaire arrives with a section that was not in last year's version, and every question in it is about an AI feature that shipped in spring.

Who is accountable for what it outputs. What data it was trained or grounded on. What it can reach inside the system. Whether a person reviews what it decides. Whether any of that can be shown, rather than asserted.

Nobody involved is a regulator. It is a procurement analyst at a company that wants to buy, asking because the moment they sign, their obligations run through the vendor.

That is the part I think most SaaS teams have filed in the wrong drawer. Governance gets treated as a legal project with a deadline attached. In SaaS I have come to think it behaves like a revenue function, arriving on a customer's schedule rather than a legislature's.

The deadline moved. The question didn't.

The calendar has shifted under anyone tracking the EU AI Act. The Digital Omnibus came into force in July 2026, and on the Commission's own implementation timeline the high-risk tier now applies from 2 December 2027 under Annex III, and 2 August 2028 for AI embedded in regulated products. Obligations for general-purpose AI providers have applied since August 2025, and the Article 50 transparency rules since August 2026.

Read as a countdown, that is real breathing room, and I have watched it get read exactly that way.

Read as anything else, it says something less comfortable to me. The obligations did not change. Only the date they are enforced did. And enforcement was never the first thing to reach a software company anyway — a customer was, holding a purchase order and a list of questions.

Deadlines move. Deals do not wait.

A customer's obligations become the vendor's requirements

The transmission mechanism here is not the statute. It is the contract.

A regulated buyer cannot outsource its accountability by buying software. Whatever it owes its own regulators about oversight, data provenance and recordkeeping, it has to satisfy on top of the product it licenses — so it needs those answers from the vendor, in writing, before approving the purchase.

That question is being standardised right now. The Cloud Security Alliance's AI Controls Matrix v1.1 publishes 24/7 control objectives across 18 domains, with a companion questionnaire built explicitly so organisations can perform "an evaluation of third-party vendors" — mapped to ISO 42001, NIST's AI Risk Management Framework and the EU AI Act. That is not a think piece. It is a spreadsheet that lands in an inbox.

And the standards it maps to are the ones buyers have started naming. Stanford HAI's 2026 AI Index records ISO/IEC 42001 cited by 36% of organisations as a regulation shaping their approach, and the NIST AI RMF by 33% — both new entries, alongside GDPR, which slipped from 65% to 60%.

Here is the structural bit that makes this sharper for SaaS than for almost anyone else.

A regulated enterprise can usually carve out a compliant corner — a separate process, system or team for the part that gets inspected. A multi-tenant SaaS product has no corners. One codebase serves the customer in Frankfurt and the one in Ohio, the hospital and the marketing agency. There is no governed version for the buyer who asks and an ungoverned one for everybody else.

So the most regulated customer on the roster sets the bar for the whole product — whether or not anyone decided that on purpose.

Evidence is the part that cannot be backdated

A policy is a document. It can be written this quarter and be perfectly true.

What a policy cannot do is produce last quarter's logs.

That asymmetry is the whole argument for doing this early. Almost every governance question that gets asked resolves to something recorded at runtime: what the system reached, who approved it, what a human changed. If nothing wrote that down while it happened, there is no honest way to produce it later. Writing it down from today is a promise about the future, and buyers are asking about the past.

So the decisions underneath governance are not legal decisions at all. They are architecture:

What a system is permitted to reach. Where a person stays inside the decision. What gets written down while it runs, in a shape someone outside the team can read.

Each is nearly free to decide while the code is being written, and steadily more expensive once features stack on top.

The failure modes bear that out. IBM's 2026 Cost of a Data Breach Report — 602 breached organisations, March 2025 to February 2026 — found more than 20% reported a breach targeting their AI models or applications, most commonly through compromised APIs, applications and plug-ins (27%) and cloud misconfigurations (27%).

Those are not model failures. Nothing there is about a bad answer. They are boundary failures — a system reaching something nobody decided it should reach. A governance question in a security incident's clothes.

The policy is the easy half

There is a number in the AI Index that looks like good news until I sit with it.

The share of businesses with no responsible AI policy fell from 24% to 11% in a single year, which reads like a problem closing fast.

Then: AI-specific governance roles grew 17% over the same period, and the obstacles organisations name are knowledge gaps (59%), budget (48%) and regulatory uncertainty (41%). The AI Incident Database logged 362 incidents in 2025, up from 233.

My read is that policies got adopted far faster than the capacity to implement them. Which is understandable — a policy is the one part that can be finished by deciding to. It is also the part a questionnaire is least interested in, because a policy is a claim, and what is being asked for is the evidence behind it.

That gap — between having a governance policy and being able to demonstrate it — is exactly where the questionnaire lands.

The questions I want answered before someone asks them

When I want to know whether governance actually exists at a company rather than existing as a PDF, these are the five I look for in writing:

• Which rules genuinely reach this product? Scoped to real markets, customers and use cases — not every framework in existence.
• Who is the named owner of each AI system? A person, decided before anything goes wrong rather than in the meeting afterwards.
• What is each system allowed to reach? Scoped to the work it actually does — and where several agents hand work between them, each inside its own boundary, so authority does not quietly widen in transit.
• Where does a person stay in the decision? Named in advance for the decisions that carry consequence, not added afterwards where something went badly.
• What is recorded while it runs, and could it be handed over? The difference between believing it worked and showing it.

Every one of those is answerable. What decides whether answering is cheap or expensive is when it gets asked.

The advantage nobody puts on the roadmap

The version of this I find most persuasive is not the defensive one.

When one vendor can answer the AI section of a security questionnaire and a competitor cannot, the first has not merely avoided a problem. It has shortened a sales cycle in a way that is hard to copy quickly — because what it is producing is a record, and a record takes time to accumulate no matter how badly anyone wants one now.

So the SaaS teams I expect to clear enterprise procurement fastest over the next couple of years are not the ones that read the regulation earliest. They are the ones that treated "what is this allowed to do, and who says so" as an architecture question, while the architecture was still soft enough to answer it cheaply.