Insights & Resources

Practical thinking for AI governance and investment decisions

Long-form articles, frameworks and checklists drawn from advisory engagements with financial services firms, private equity investors and regulated enterprises.

In depth

Regulation · 12 min read

EU AI Act Readiness: A Practical Roadmap for Regulated Enterprises

The EU AI Act is the world's first comprehensive, horizontal AI regulation. Compliance is not a policy exercise — it is a system-level programme spanning inventory, classification, technical documentation, human oversight, post-market monitoring and evidence.

Why readiness is harder than firms expect

Most enterprises underestimate the Act because they read it as a compliance checklist rather than an operating-model change. The Act introduces obligations that cut across data science, engineering, procurement, legal, risk and product. Provisions on high-risk systems require conformity assessments, quality management systems, logging, human oversight and post-market monitoring — each of which touches multiple functions. Firms that treat readiness as a legal deliverable rather than a cross-functional programme routinely discover, six months in, that they do not have the evidence pipeline, control library or ownership model needed to demonstrate compliance to a regulator.

The five workstreams that actually matter

A defensible readiness programme organises around five workstreams: (1) applicability and inventory — identifying every in-scope AI system, including embedded third-party components and general-purpose AI models fine-tuned or deployed by the firm; (2) risk classification — mapping systems to prohibited, high-risk, limited-risk or minimal-risk categories with a documented rationale; (3) obligation mapping — translating Article-level requirements into concrete controls, artefacts and owners; (4) technical documentation — producing the Annex IV file, data governance evidence, and conformity assessment records; and (5) post-market surveillance — standing up monitoring, incident reporting and serious-incident notification workflows.

General-purpose AI and the deployer trap

Firms using foundation models via API often assume the provider carries the compliance burden. In practice, the moment a firm fine-tunes, prompts or substantially modifies a general-purpose AI model, or deploys it into a high-risk use case, obligations shift onto the deployer. This is the single most common gap we see in readiness assessments: procurement contracts that assume vendor responsibility, without the contractual, technical or governance mechanisms to actually receive and act on the information the deployer needs.

What good evidence looks like

Regulators will not accept assertions. They will ask for logs, sign-offs, test results, model cards, data sheets, human-oversight procedures and change history. The single strongest indicator of readiness maturity is whether a firm can produce, on demand, a coherent evidence pack for any in-scope AI system — showing who approved it, on what basis, against what risk assessment, with what controls, and with what monitoring in place. Firms that can do this are ready. Firms that cannot are exposed, regardless of how sophisticated their policies read on paper.

Discuss this with an advisor

Framework · 11 min read

AI Risk Assessment Frameworks: Choosing and Adapting the Right Model

NIST AI RMF, ISO/IEC 42001, the EU AI Act's risk tiers, and internal model risk management standards each solve a different problem. Choosing one and adapting it to your risk appetite is the actual work.

Why generic frameworks fail without adaptation

Enterprises frequently adopt NIST AI RMF or ISO 42001 wholesale and then find that neither maps cleanly to their existing risk taxonomy, three-lines-of-defence model or regulatory obligations. Frameworks are scaffolding — they define categories, functions and lifecycle stages, but they do not tell you what a specific level of AI risk means for your business, what controls are proportionate, or how to weigh trade-offs between model performance and safety. Without adaptation, framework adoption becomes a documentation exercise that produces artefacts nobody uses.

The four dimensions of AI risk that boards should track

A workable AI risk taxonomy tracks four dimensions: (1) model risk — accuracy, drift, bias, robustness and explainability; (2) operational risk — data quality, integration failure, third-party dependency and resilience; (3) conduct and customer risk — fairness, vulnerability, transparency and Consumer Duty exposure; and (4) regulatory and reputational risk — AI Act, sector-specific rules, and public accountability. Every AI system in the inventory should be scored against each dimension, and material risks should be reported to the risk committee with the same rigour as credit or operational risk.

Risk tiering that actually drives control effort

The purpose of tiering is not classification for its own sake — it is to make control effort proportionate. A three-tier model (elevated, standard, low) is usually sufficient, provided the criteria are explicit: criticality of the decision, reversibility of harm, population affected, regulatory exposure and autonomy of the system. Firms that skip explicit criteria end up either over-controlling low-risk systems (slowing adoption) or under-controlling high-risk ones (creating regulatory and reputational exposure). The tiering criteria should be approved by the risk committee and re-tested annually.

From framework to control library

The bridge from framework to daily operations is a control library — a reusable set of technical and process controls (bias testing, red-teaming, human-in-the-loop review, monitoring thresholds, incident triggers, model change control) mapped to risk tiers. This turns the framework from a document into an operating capability. It also makes audit and assurance dramatically easier: assurance teams test controls, not paragraphs.

Discuss this with an advisor

Governance · 10 min read

Board-Level AI Oversight: What Directors Should Actually Ask

Boards are accountable for AI outcomes but rarely have the vocabulary, cadence or reporting to discharge that duty. Effective oversight requires structural changes, not just briefings.

The oversight gap

In most enterprises, AI reporting reaches the board as a status update: use cases in flight, models deployed, spend to date. This is not oversight. It tells the board what is happening but not whether risk is being managed, whether controls are working, or whether the firm's AI exposure is within appetite. Effective oversight requires a shift from activity reporting to risk and control reporting — the same shift boards made decades ago on credit, market and operational risk.

Six questions every director should be able to answer

Directors should be able to answer, at any point: (1) what AI systems does the firm operate, and which are material? (2) who owns AI risk and how is it escalated? (3) what is our AI risk appetite and how is it evidenced against actual exposure? (4) what independent assurance has been performed on high-risk systems? (5) what regulatory obligations apply, and are we compliant? and (6) what would we do if an AI system caused customer, financial or reputational harm tomorrow? If any answer is uncertain, the oversight architecture is incomplete.

Committee structure and cadence

Boards typically discharge AI oversight through a combination of the risk committee (for risk appetite, exposure and incidents), the audit committee (for controls, assurance and evidence) and, where established, a technology or AI committee (for strategy and ethical framing). What matters is not the exact configuration but that AI has a named home, a defined reporting cadence (typically quarterly with an annual deep-dive) and a standing agenda item — not a special report when something goes wrong.

The role of independent assurance

Boards should not rely solely on management assertions or internal audit. Independent assurance — from external advisers, technical auditors or specialist firms — is increasingly expected by regulators and investors, particularly for high-risk systems and for firms making material AI-related public statements. The purpose is not to duplicate internal work but to test the evidence a board is being asked to rely on.

Discuss this with an advisor

Due Diligence · 13 min read

M&A AI Due Diligence: Best Practices for Acquirers and Investors

AI is now material to valuation, deal terms and post-close integration. Traditional technology due diligence rarely surfaces the AI-specific risks that destroy value after close.

Why standard tech due diligence misses AI risk

Conventional technology diligence focuses on architecture, scalability, security and technical debt. AI diligence has to cover different terrain: data provenance and licensing, model performance under distribution shift, dependency on third-party foundation models, governance maturity, regulatory exposure and the sustainability of any AI-based competitive claim. Deal teams that rely on standard tech due diligence for AI-heavy targets routinely discover, post-close, that the AI capability was more fragile, more concentrated on a small number of vendors, or more legally exposed than the CIM suggested.

The five diligence workstreams

A rigorous AI diligence engagement covers five workstreams: (1) capability validation — does the AI actually do what management claims, at the claimed accuracy, on representative data? (2) data diligence — provenance, licensing, consent, quality and defensibility; (3) governance and compliance — inventory, controls, regulatory exposure and readiness for AI Act, sector rules and jurisdictional data regimes; (4) talent and dependency — key-person risk, concentration on external providers and open-source components; and (5) value-creation potential — the credible near-term opportunity to increase margin, reduce cost or defend market position through governed AI.

Red flags that should change the deal

Certain findings should trigger price adjustment, indemnities or walk-away: undisclosed use of scraped or unlicensed training data; models that cannot be reproduced from the target's own code and data; material AI systems with no owner, no monitoring and no incident history; regulatory obligations (particularly EU AI Act high-risk classifications) that have not been assessed; and public AI claims that cannot be substantiated on the evidence available. Each of these has become a recurring finding in the last twelve months.

From diligence to Day 100

Diligence output should not be a report that is filed after close. The best AI diligence engagements produce a Day 100 integration plan: prioritised remediation, governance uplift, control implementation and value-creation initiatives, each with owners and milestones. This is what turns diligence from a defensive exercise into a value-protection and value-creation lever across the hold period.

Discuss this with an advisor

Guide · 9 min read

GenAI in Production: A Governance Baseline for Regulated Firms

Generative AI creates governance problems that classical model risk management was not designed for: non-deterministic outputs, prompt injection, third-party model dependency and rapid capability drift.

What makes GenAI different

Traditional model risk management assumes a model with a defined input space, measurable performance and stable behaviour. Generative AI breaks all three assumptions. Outputs are non-deterministic, the input space is effectively unbounded, and the underlying foundation model can change without notice when the vendor ships an update. Governance frameworks built for credit scoring or fraud models do not transfer directly and need explicit adaptation.

The baseline controls

Every GenAI application deployed to production should have, at minimum: a documented use case with an approved risk classification; input and output guardrails proportionate to risk; a red-team assessment before launch and at material change; retrieval and grounding controls where factuality matters; human review for material or irreversible decisions; monitoring for accuracy, drift, refusal rates and safety events; a documented rollback and incident procedure; and contractual and technical arrangements to receive change notifications from the foundation-model provider.

Agentic AI raises the bar again

Once GenAI systems gain the ability to take actions — call tools, execute code, transact — the governance envelope expands to include tool authorisation, action limits, oversight of chained decisions, and containment of failure modes. Firms deploying agentic AI without explicit authorisation frameworks and action-level oversight are creating operational-risk exposure that most existing control libraries do not cover.

Discuss this with an advisor

Operating Model · 10 min read

Designing an AI Operating Model That Actually Scales

Most AI operating models are drawn on a whiteboard and then quietly ignored. The models that survive contact with reality make three decisions explicit: where AI capability lives, how funding flows, and how risk is escalated.

Centralised, federated, or hybrid — and why it matters

There is no universally correct answer, but there is a wrong answer for a given firm. Centralised models concentrate expertise but starve business units. Federated models accelerate adoption but produce fragmentation, duplicated spend and inconsistent risk posture. Hybrid models — a central capability owning platforms, policy and assurance, with embedded AI leads in each business unit — dominate at scale, but only when the split of authority is explicit and funded.

Funding and prioritisation

AI operating models fail most often on funding, not architecture. If AI investment is bundled into general technology spend, prioritisation becomes political and short-term. Firms that scale AI successfully typically ring-fence AI investment, prioritise through an AI investment committee against explicit value and risk criteria, and rebalance quarterly. Governance sits inside this process — not alongside it.

Governance as an accelerator, not a brake

The best AI operating models make governance the fast path, not the slow one. Approved patterns, pre-cleared foundation models, standard control implementations and reusable evidence templates mean that a compliant deployment is faster than a bespoke one. When governance is engineered this way, adoption accelerates and risk posture improves at the same time — which is the actual point.

Discuss this with an advisor

Frameworks, checklists & templates