B2B SAAS
Responsible AI Governance for B2B SaaS
Ship an AI feature and you inherit obligations: the EU AI Act if your AI is high-risk in a customer use, GDPR as a processor, and a security review to pass before the deal closes. We engineer the governance that lets you govern the AI you ship and turn it into a sales asset.
For founders, CTOs, Heads of Product and Heads of Trust at B2B SaaS companies. Govern the AI you ship, pass the customer security and trust review, and where you are building the feature, build it right from the start.
THE EXPOSURE
The AI You Ship Comes With Obligations
A SaaS firm that ships AI features inherits duties on two sides at once: rulebooks it must meet as the provider of that AI, and a trust bar its customers now set before they buy. Ignore either and the exposure is regulatory and commercial, not just reputational.
Provider
The role most SaaS firms inherit under the EU AI Act
Ship an AI system under your own name and Article 3 makes you the provider. If the feature falls in Annex III for your customer use, you own the risk management, technical documentation, logging and conformity work. Your customer is usually the deployer.
EU AI Act, Article 3; Annex III (artificialintelligenceact.eu)
Article 28
GDPR processor duties you carry for customer data
Feed a customer end-user data into your AI and you are the processor. Article 28 requires a data processing agreement, action only on documented instructions, Article 32 security, and prior authorisation for any AI sub-processor, with you fully liable for them.
GDPR, Article 28 (gdpr-info.eu)
Article 50
Transparency duties even when the AI is not high-risk
Chatbots must tell users they are dealing with AI. Synthetic audio, image, video or text must be marked as artificially generated. These transparency duties apply to your feature regardless of whether it sits in Annex III.
EU AI Act, Article 50 (artificialintelligenceact.eu)
SOC 2 / 42001
The trust bar enterprise buyers now set
SOC 2 is the market-standard security report enterprise buyers expect before signing. ISO/IEC 42001, the first international AI management system standard, published December 2023, is the way to prove you govern the AI you ship, not just your infrastructure.
AICPA SOC 2; ISO/IEC 42001:2023 (iso.org)
THE POSITION
Govern the AI Well and It Wins Deals
Governance is not a tax on your roadmap. Done properly, it shortens enterprise sales cycles and becomes a reason a buyer picks you over a rival who cannot answer the AI questions.
Governance shortens the sales cycle
Enterprise deals now stall in the AI section of the security review. Firms with the answers already written down, model list, data flows, sub-processors, oversight, clear procurement in days instead of weeks.
The EU AI Act timeline is a head start
Most SaaS firms have not classified which AI features are high-risk or whether they are the provider. The ones that map and remediate now will be ready while competitors are still working out who owns the risk.
Your trust posture is a differentiator
A public AI governance statement and a clean trust centre tell a buyer you take the AI you ship seriously. That signal is what enterprise procurement, and increasingly AI search engines, both reward.
AEO without dark patterns protects the brand
The wider AEO industry is being penalised for manipulative tactics. Done to a Responsible AI standard, your AI visibility is engineered cleanly, so the content that ranks is also the content that survives a buyer diligence check.
OUR APPROACH
Systems. Strategy. Execution.
The same three-level framework, recast for a SaaS company that ships AI to its customers and needs to govern it, sell past the security review, and build it right.
SYSTEMS
Govern the AI You Ship
We architect an AI management system your founder, CTO and Head of Trust can stand behind. Every AI feature classified for its role, its risk tier and its obligations, so responsibility is clear before a customer, a regulator or an incident asks.
- -AI feature inventory with provider or deployer classification
- -Annex III high-risk and Article 50 transparency mapping
- -AI management system aligned to ISO 42001 alongside your SOC 2
- -Data-flow map, DPA and sub-processor register under GDPR Art 28
STRATEGY
Turn Governance Into a Sales Asset
We build the AI risk register and the trust evidence pack that shortens enterprise sales cycles. Governance stops being a blocker in the security review and becomes a reason a buyer picks you over a rival who cannot answer the AI questions.
- -AI risk register scored by likelihood and customer exposure
- -Security-review evidence pack: model list, data flows, controls
- -Public AI governance statement and trust-centre content
- -Remediation roadmap sequenced to the EU AI Act timeline
EXECUTION
Build It Right and Prove It
When execution is needed, we engineer the evidence and, where you are building the feature, help you build it to a Responsible AI standard from the start. Audits, oversight controls, disclosure, and AEO content built to compliance standard rather than gamed.
- -AI feature audits: bias, data leakage, prompt injection, oversight
- -Human-oversight, disclosure and logging controls for shipped AI
- -Responsible AI build support with our engineering services
- -AEO and content engineering without dark patterns
WHERE WE CREATE VALUE
Typical B2B SaaS Engagements
Illustrative scenarios reflecting the types of firms we work with. Specific scope depends on the AI you ship, your customer base and your risk appetite.
ROLE AND SCOPE
SaaS Shipping an AI Feature Into an HR Product
Your platform now scores or ranks candidates for customers. That use sits in Annex III, so the feature can be high-risk and you are likely its provider. The risk management, technical documentation and logging evidence is not yet in place.
Systems-level engagement: classify the feature and your role, build the provider obligations for a high-risk system, and stand up the human-oversight and record-keeping evidence before a customer or auditor asks.
SECURITY REVIEW
Scale-Up Stuck in Enterprise Security Reviews
Deals stall in procurement because the security questionnaire now asks AI-specific questions: model provenance, data handling, sub-processors, training use. Answers are scattered across engineering and legal, so each review takes weeks.
Strategy-level engagement: an AI trust evidence pack, a data-flow map and a sub-processor register mapped to SOC 2 and GDPR Article 28, so the review becomes form-filling and governance shortens the sales cycle.
DATA AND PROCESSOR
Platform Routing Customer Data Through a Model Vendor
Your AI feature sends customer end-user data to a third-party model API. Under GDPR you are the processor and that vendor is a sub-processor, but the DPA, the documented instructions and the sub-processor authorisation do not reflect it.
Data-flow and processor programme: map every AI data path, align your DPA and sub-processor list to Article 28, and close the gap between what your contracts say and what your product actually does.
SHIP AND DISCLOSE
Product Adding a Customer-Facing Chatbot
You are building a chatbot into the product. Article 50 requires users be told they are dealing with AI, and Moffatt v. Air Canada shows you own its answers to your customers. Disclosure, oversight and logging are afterthoughts, not design.
Ship-it-right engagement with our engineering services: disclosure and oversight built into the feature, logging so outputs can be reconstructed, and honest limits on what it claims, so a wrong answer never becomes a liability.
WHY US
We Govern AI and We Build It
Sotiris has 27 years across regulated markets and product engineering, and is the author of AI Moats, Ethical AI and TRANSFORM. VerityAI is a Responsible AI advisory that also builds, not a software platform we are trying to sell you. We govern the AI you ship and, where you need it, help you build the feature to the same standard: designed so it holds up under a customer security review and a regulator's question.
Governance a buyer and a regulator both accept
We architect an AI management system mapped to the EU AI Act, GDPR Article 28 and ISO 42001, with ownership and evidence a security reviewer can follow. Not a policy PDF. A working operating model that closes deals.
We build to a Responsible AI standard
Where you are shipping the feature, our engineering and AI transformation services build oversight, disclosure and logging in from the start, so governance is part of the product, not a retrofit after an incident.
Product and board language, not jargon
We speak to founders, CTOs and Heads of Trust. Reporting connects the AI you ship to regulatory exposure, security-review outcomes and sales velocity, not vanity metrics.
FROM THE PUBLIC RECORD
What Ungoverned SaaS AI Actually Costs
Named cases here are drawn from the public record, with sources. The composite is built from several engagements and flagged as such. No client is identified.
PUBLIC RECORD
Air Canada: liable for its own chatbot
In February 2024 the British Columbia Civil Resolution Tribunal held Air Canada liable for wrong information its website chatbot gave a customer about bereavement fares, awarding CAD 812.02. The tribunal rejected the argument that the chatbot was a separate legal entity, ruling it was part of the company website and the company was responsible for everything on it.
Takeaway: an AI feature you ship is part of your product, and its output is your responsibility to your customer, whatever the terms of service say. Human oversight, disclosure and logging are what keep a wrong answer from becoming a liability.
PUBLIC RECORD
Samsung: confidential data pasted into an AI tool
In April 2023 Samsung engineers pasted confidential source code and internal meeting notes into ChatGPT to get help with their work. The data left the company perimeter onto a third-party AI provider server. Samsung banned generative AI tools across its networks and started assessing the exposure, as reported by Forbes in May 2023.
Takeaway: when your product routes customer data into an AI feature, you inherit the same exposure your customers fear here. A data-flow map, a clear sub-processor list, and controls on what data reaches which model are what a security review is checking for.
COMPOSITE
The feature nobody classified
Composite, built from several engagements. A SaaS firm ships three AI features across two product lines: a chatbot, a scoring model bought from a vendor, and a summariser. No one has written down which are high-risk, who is the provider, or where customer data flows. Then a large enterprise prospect sends a 40-question AI security review, and the deal stalls for a month while engineering and legal reconstruct the answers.
Takeaway: the first control is not a policy. It is an inventory of every AI feature with its role, its risk tier, its data flow and a named owner, so the answers exist before a buyer, an auditor or a regulator asks for them.
Composite lesson, no client identified
ASSESS YOUR READINESS
Start with a Self-Assessment
Free resources built for SaaS product and trust teams. No signup required. Use them to scope the AI you ship before we talk.
EU AI Act Readiness Assessment
Work out whether the AI you ship is high-risk, limited-risk or out of scope, and whether you are the provider or the deployer, in a few minutes. Built for SaaS product and trust teams.
Open →Free AI Risk Register Template
A starting AI risk register for SaaS teams. Map each AI feature to EU AI Act, GDPR and security-review exposure, with a likelihood and impact scoring method.
Open →AI Compliance Audit: Complete Guide
How an AI compliance audit works, what evidence it produces, and how that evidence maps straight onto the AI questions in a customer security review.
Open →START HERE
Wherever You Are in the Decision
Three routes in, depending on where you've got to. Learn the rules, compare the approaches, or move to a decision.
LEARN THE RULES
Getting oriented
New to how AI regulation lands on a SaaS product? Start with what disclosure the EU AI Act requires when you ship AI, and how an AI compliance audit produces the evidence a customer will ask for.
COMPARE YOUR OPTIONS
Weighing approaches
Already scoping the problem? Look at how to assess the AI you build and buy, and what governance a development pipeline needs before an AI feature ships to customers.
READY TO ACT
Moving to a decision
Ready to govern it properly? Test your feature against the EU AI Act, start the risk register, then book a conversation about the AI you ship and where governance reduces the most risk.
GO DEEPER
Responsible AI Knowledge Base
Briefings and guides on governing the AI you ship, from EU AI Act disclosure to AI agent risk and passing an AI compliance audit.
BY JURISDICTION
UK, US and EU: The Rules Are Not the Same
The same AI feature sits under different rulebooks depending on where your customers are. We advise UK-first, and serve US and EU clients in English.
UK
Lead market. We advise UK-first.
- -UK GDPR and the ICO: processor duties, lawful basis and automated-decision rights for the AI you ship
- -DSIT pro-innovation approach: AI governed through existing regulators rather than a single AI Act, for now
- -Customer trust reviews built on ISO 27001 and SOC 2, increasingly with AI-specific questions
US
Served in English.
- -SOC 2 as the market-standard trust report enterprise buyers expect before signing
- -State privacy laws layered on top of sector rules, plus FTC action on unfair or deceptive AI claims
- -NIST AI Risk Management Framework as the voluntary baseline for governing AI
EU
Served in English.
- -EU AI Act: provider or deployer role per feature, high-risk only where Annex III applies, Article 50 transparency
- -GDPR Article 28: processor duties, data processing agreement and sub-processor authorisation
- -ISO/IEC 42001 as the AI management system standard buyers increasingly ask about
FAQ
B2B SaaS AI Compliance: Questions Founders Ask
Straight answers on the duties you inherit when you ship AI, from EU AI Act provider and deployer roles to GDPR Article 28, ISO 42001 and passing a customer security review.
Is our SaaS AI feature high-risk under the EU AI Act?
Usually not by default, but check the use, not the technology. General business software is not automatically high-risk. An AI feature becomes high-risk only when its use falls inside one of the areas listed in Annex III of the EU AI Act, which include recruitment and worker management, credit scoring and insurance pricing, education and exam scoring, biometrics, essential public services, and a few others. So a SaaS recruitment or scoring tool your customer uses to filter candidates can be high-risk, while a generic analytics dashboard is not. There is also a separate transparency layer under Article 50: if your feature is a chatbot or generates synthetic audio, image, video or text, you have marking and disclosure duties even when the system is not high-risk. We map each AI feature you ship against Annex III and Article 50 so you know exactly what applies, and we do not overclaim.
Are we the provider or the deployer under the EU AI Act?
If you build an AI system, or have one built, and put it on the market or into service under your own name or trademark, you are the provider (Article 3). Most SaaS firms that ship an AI feature are providers of that feature. Your customer, who uses the system under their own authority, is usually the deployer. The roles matter because they carry different obligations: providers own the risk management, technical documentation, logging and conformity work for a high-risk system, while deployers own human oversight and use-side duties. It gets subtle when a customer materially changes what your AI does, which can shift them into a provider role too. We classify each party per feature so responsibility, and the contract, are clear before a customer asks.
Do we need ISO 42001 or SOC 2 for AI?
Neither is legally mandatory, but both are becoming the price of entry in enterprise SaaS sales. SOC 2 is the market-standard trust report for security, availability and confidentiality, and most enterprise buyers ask for it before they will sign. ISO/IEC 42001, published in December 2023, is the first international standard for an AI management system, and it is the natural way to show a buyer you govern the AI you ship across its lifecycle, not just your general infrastructure. ISO 42001 shares the same management-system structure as ISO 27001, so it slots alongside controls you may already run. Our view: if AI is core to what you sell, an AI management system aligned to ISO 42001 is the governance layer that lets you answer the AI-specific questions in a security review without scrambling. We help you decide which certifications earn their cost and build the governance underneath them.
How do we pass a customer security review when our product uses AI?
Customer security and trust reviews now include AI-specific questions on top of the usual SOC 2 and ISO 27001 checks: what models you use, where customer data goes, whether it trains third-party models, how you handle prompt injection and data leakage, and what your sub-processors are. Under GDPR you are typically a processor, so Article 28 requires a data processing agreement, that you act only on the customer documented instructions, and that you disclose and get authorisation for sub-processors, which now includes any AI vendor in your stack. The firms that pass fast are the ones with the answers already written down: an AI feature inventory, a data-flow map, a sub-processor list, and a short AI governance statement. We build that evidence pack so the review becomes a form-filling exercise, not a fire drill, and so governance turns into a sales asset rather than a blocker.
What are our GDPR duties for AI when we process our customers customer data?
When your customer feeds their end-user data into your AI feature, you are almost always the processor and your customer is the controller. Article 28 GDPR then requires a written contract, the data processing agreement, that binds you to process only on the customer documented instructions, keep staff under confidentiality, apply Article 32 security measures, help the customer answer data-subject requests, and delete or return data at the end. Sub-processors, including any third-party AI or model vendor you route data through, need the customer prior authorisation and the same contractual duties passed down, and you stay fully liable for them. If your AI makes solely automated decisions with legal or similar significant effect on individuals, Article 22 rights apply on top. We map your AI data flows to these duties so your DPA and your sub-processor list actually match what your product does.
Who is liable when our AI feature gets something wrong in a customer workflow?
You are, in most cases, and courts are already treating it that way. In Moffatt v. Air Canada (2024) the British Columbia Civil Resolution Tribunal held the company liable for wrong information its own website chatbot gave a customer, rejecting the argument that the chatbot was a separate entity. The lesson for SaaS is direct: an AI feature you ship is part of your product, and its output is your responsibility to your customer, whatever your terms of service say. That is why governance is commercial, not just legal. Human oversight on high-stakes outputs, clear disclosure that a user is dealing with AI, logging so you can reconstruct what happened, and honest limits on what the feature claims to do are the controls that keep a bad answer from becoming a liability or a lost renewal. We build those controls into how you ship AI, not bolt them on after an incident.
START HERE
Let's Discuss Responsible AI for Your SaaS
A conversation about the AI you ship, your customer base, and where governance will reduce the most risk and win the most deals. No pitch decks. No proposals on the first call.
Request a Consultation