How a PE-owned SaaS company built a governance model that lets a software business ship AI without exposing itself to regulatory or reputational risk

Without slowing down the product team, without a compliance-only mindset, and without building a governance structure that existed on paper but not in practice.

3-tier governance framework delivered · Replicable across a large SaaS portfolio · Internal and customer-facing AI deployed · Board-level reporting established

The bridge. The client had a clear mandate to deploy AI across its product and operations, and no structured way to decide which initiatives to pursue, how to assess their risk before committing resources, or who was accountable when something needed to change. A year later, the business had a governance model with defined accountability at every stage, a track record of approved and deployed AI initiatives, and a framework the PE owner could use across its broader portfolio. That shift is the work.

The client is a PE-owned SaaS company operating in the property technology sector, providing housing and residential experience management software to universities and residential operators across multiple countries. Its private equity owner manages a large portfolio of SaaS companies in which AI adoption is a strategic priority. The commercial rationale for AI deployment across that portfolio is clear. The governance challenge is equally clear: deploying AI in customer-facing products and internal operations without coherent oversight creates real exposure, legal, reputational, and commercial, at a scale that affects the whole portfolio.

As the PE owner began its AI transformation program, the client was positioned as one of the first portfolio companies to build a structured governance model for AI deployment.

Justin Hancock of SeidrLab led the design and implementation of that model. The objective was not a compliance document. It was a working governance system that enabled the business to deploy AI quickly, responsibly, and with clear accountability at every stage.

---

How we designed three layers that each do a different job

AI transformation programs in SaaS businesses tend to stall or create problems for the same reasons. Use cases are prioritised on enthusiasm rather than commercial logic. Responsibility for assessing risk is unclear, so it either gets skipped or becomes a veto. Execution happens in silos, disconnected from the strategy decisions made further up. And when something goes wrong, the accountability for fixing it is ambiguous.

The three-tier framework we designed addressed each of these failure modes with a distinct structural layer.

The AI Oversight Committee sat at the top. Chaired by the Product function and composed of VP, SVP, and relevant C-suite leaders from Product, Technology, Cybersecurity, Platform, Go-to-Market, Customer Operations, and Legal, this group was responsible for one job: evaluating proposed AI use cases against commercial and strategic value and deciding which ones to advance. Proposals came to the committee as one-to-three page briefs covering commercial benefit, risk assessment, and implementation effort. The committee provided go, no-go, or seek-more-information decisions. It met quarterly, and it built the discipline of practising the full lifecycle of AI strategy execution on lower-complexity initiatives before moving to more ambitious ones.

The Cyber Risks Board handled the scrutiny that the Oversight Committee could not do at the depth required. Staffed by VP Cyber Security, VP Legal, the CPTO, a Data Protection SME, and VP Platform, this group met monthly and assessed approved initiatives across three categories: data protection and privacy, legal and contractual obligations, and cybersecurity risk. Its role was to identify and mitigate risk before it became a problem, and to provide formal assurance that each project adhered to current regulatory frameworks and data-use permissions.

The AI Working Group was where execution happened. Staffed by mid-to-senior management closer to delivery, meeting monthly, it monitored rollout progress, surfaced obstacles, tracked dependencies across departments, and proposed playbooks for implementing future roadmap items. It also owned change management for initiatives where adoption required active support.

Key takeaway. The value of a three-tier governance model is not that it adds layers: it is that each layer does a different job that the others cannot do well. Strategy, scrutiny, and execution require different compositions, different meeting cadences, and different accountability structures.

---

How we built the use case pipeline

A governance model without a clear process for moving a use case through it is not a governance model: it is a committee. The framework we designed included an explicit pipeline that a proposed AI initiative had to move through before resources were committed.

Proposed use cases came to the Oversight Committee with pre-assessment for regulatory exposure. The submitting team was required to research potential data residency rules, sector-specific regulations, and emerging compliance requirements before presenting. This prevented regulatory surprises later in the development cycle and ensured the committee’s time was spent on genuine strategic decisions rather than catching issues that should have been identified earlier.

The committee’s decisions fed directly to the Cyber Risks Board for the detailed scrutiny that determined whether a project posed material risks across its three assessment categories. The board’s findings fed back into the committee’s ongoing reporting to the company board. The Working Group received approved initiatives with the risk assessment completed, giving execution teams a clear mandate and a documented risk profile to work within.

The early-stage discipline of starting with lower-complexity, lower-risk initiatives allowed the organisation to practise the full cycle before committing to more complex AI deployments. The governance model was built with room to be extended as the organisation’s AI capability and confidence grew.

Key takeaway. The governance process is also a capability-building process. Each initiative that moves through the framework trains the teams involved in how to assess, approve, and execute AI work. That institutional knowledge compounds.

---

How we designed for replication across the portfolio

The client was not the only company in the PE owner’s portfolio that needed this model. The framework was designed from the start with portability in mind: a structure that could be adapted to different company sizes, regulatory environments, and AI maturity levels, rather than something built specifically for one company’s circumstances.

For companies over 150 people, the full three-layer model was recommended. For smaller organisations, a scaled-down version of the same principles applied: the core requirement was that strategy, scrutiny, and execution be grounded in a shared cross-functional set of outcomes, and that legal, cybersecurity, and operations teams provide structured input before significant resources were committed.

The governance documentation, process templates, and committee charter formats were developed in a form that the PE owner could use across other portfolio companies without rebuilding from scratch. The client’s implementation became the reference model, and the lessons from running the framework in practice, what the committees needed, where the process created friction that needed to be smoothed, and what the board reporting required, were captured for the benefit of the broader portfolio program.

Key takeaway. A governance model that only works in the specific organisation it was built for has limited value. The design choices that make a framework portable, its principle-based structure, its adaptable scaling, and its documented rationale, are what give it leverage across a larger organisation or portfolio.

---

What changed

Before. The business had a clear mandate from its PE owner to pursue AI transformation, but no structured model for deciding which use cases to prioritise, who was accountable for assessing risk before implementation, or how execution would be coordinated across departments. AI initiatives were being evaluated inconsistently, and the path from idea to deployed capability was undefined.

After. A working three-tier governance model was in place, with defined composition, meeting cadences, and accountability at each level. The use case pipeline gave teams a clear process for proposing, evaluating, and advancing AI initiatives. Both internal AI capabilities and customer-facing AI features were deployed with board-level visibility and documented oversight. The framework provided the PE owner with a replicable model for responsible AI governance across its broader SaaS portfolio.

---

Does this fit your situation?

If your business has a mandate to deploy AI but lacks a structured model for deciding what to build, how to assess the risk before committing, and who is accountable when something needs to change: the governance work comes before the roadmap.

Book a discovery call →