A policy states a position. An operating model names an owner for every AI in your firm, puts the control at the point in the lifecycle where it can still change the outcome, keeps a register somebody maintains, and produces an attestation your board signs. This is the build: thirteen stages over four to six weeks, grafted onto the three lines of defence you already run rather than standing beside them. The funding case sits inside it, with the cost to build, the cost to run and the cost to govern kept apart. Written for fund managers first, and it carries to regulated fintechs, fund delegates and wealth managers.
Ask your firm for a list of every AI running inside it, who approved each one, what each can reach, and what happens when one is wrong. Almost nobody can produce it. That list is the first thing a regulator asks for, the first thing an investor asks for in operational due diligence, and the first thing your auditor will ask for once the question reaches their programme. Not having it is not a documentation problem. It means nobody is deciding, which means the decisions are being made by whoever configured the tool.
Most firms in this market wrote an AI policy in the last eighteen months. It was the right first move and it changes very little, because a policy tells people what the firm will not accept and says nothing about what is running. It has no owner per system, no control at the moment a use case goes live, no register to go stale, and no date on which somebody has to stand behind it. The gap between a policy and a governance model is the gap between a statement and a working arrangement, and that gap is where the accountability under the Senior Managers regime actually sits.
AI governance fails when it is centralised, because the centre does not know how the work is done, and it fails when it is devolved, because nobody can see across the firm. The model I build is a hub with spokes. The spokes are the functions: the compliance officer building a rule-checking assistant, the operations team automating a reconciliation, the research function putting a model into a screening process. They hold the subject matter expertise and they own the outcome, which is right, because the person who understands the process is the person who should own what it becomes.
The hub does four things, and only four. It holds the register, so there is one place the firm looks. It approves use cases against a consistent test, so that what passes in operations would also pass in research. It decides data access, because the question of what an AI may see is the control that matters most and the one most often skipped. And it governs the gateway that models and agents are reached through, so that permissions are a technical fact rather than a paragraph in a policy. Everything else stays with the spokes. A hub that tries to do more becomes a bottleneck and gets routed around, which is worse than having no hub at all.
Thirteen stages. The order matters, because every stage after the second depends on knowing what you actually have, and most firms are tempted to start at stage seven with a policy rewrite.
Principles the firm will be held to, written in its own language and agreed at executive level, not imported from a vendor deck. Then the frameworks: which external references the firm wants to be measured against, whether that is the NIST AI Risk Management Framework, ISO 42001, or nothing beyond the regulation it already answers to. Deciding this first stops the later stages being redone when somebody asks what standard you are working to.
A control diagnostic across the governance you already run, because almost everything AI needs already exists somewhere in your firm under another name: change control, outsourcing oversight, model validation, data protection, incident management, three lines of defence. Then the regulatory map: which obligations bite on which activity, under the EU AI Act as deployer, DORA, the Central Bank’s fund management company and outsourcing guidance, FCA senior manager accountability, and your data protection duties. The output is a short list of what has to be built, which is always smaller than the firm expects and never the list the vendor sold them.
Inventory and classification of every AI in the firm, vendor-delivered and built in-house, with a declared purpose, a scope of authority, a named owner and a risk class against each. Each is also classified by what kind of AI it is: generative, predictive, agentic, language, vision, or rule-based automation with judgement added. The risk class says how much control a system needs. Its kind says which controls. Then impact analysis, which starts from what AI actually does. It makes a prediction cheaper; the judgement about that prediction and the action that follows stay with your firm. So the analysis asks where each prediction lands, who exercises judgement over it and what action it can trigger, as well as who it affects, what a wrong answer costs, whether anyone would notice, and what it means for privacy, for your ability to explain a decision, and for bias. Where a Vendor AI Oversight Review has already run, its inventory seeds this phase and the build starts a fortnight ahead.
The policy stack, which is the policy you have plus the standards and procedures underneath it that make it operable. Lifecycle controls placed where they can still change the outcome: at intake, at approval, before go-live, at change, and at retirement, rather than all of them at an annual review. The kind of AI sets the default controls at each point. Generative systems need output review and a rule on what data may go into a prompt. Predictive models need validation and a watch for drift. Agents need a scope of authority, a stop, and controls where they reach other systems. Language and vision tools need sample checks on what they extract. Rule-based automation needs its control at the exceptions, because that is where the judgement sits. And third-party AI, which is the hardest part in a fund business, because the AI arriving through your administrator, your transfer agent and your data providers is contractually theirs and legally yours.
How the firm knows this is still true. The assurance routine, who tests what and on what frequency, written for a second line that has no AI specialists. Each system is measured against the job it was approved to do: accuracy, the errors someone had to correct, and drift since approval. A model nobody reviews degrades quietly, and bias usually arrives that way rather than on the day it went live. Agents, which need their own treatment because they act rather than answer: a declared purpose, a scope of authority, a stop, a named owner, and a record of what they called. And incidents, which means deciding now what an AI incident is in your firm, who is told, how fast, and what the threshold for reporting it is, because that decision is impossible to make calmly on the day.
The cadence. What goes to the risk committee monthly, what goes to the board quarterly, what the attestation says and who signs it, and what evidence has to exist behind each line before they do. This is the stage that turns the build into something that survives the consultant leaving, and it is the only stage whose output a board actually sees.
Twelve registers, in one workbook with a dashboard over it, because a governance model that lives in a document is a governance model nobody updates. Use cases. Models. Third-party AI. Data. Agents. Decision records. Obligations. Assessments. Incidents. Assurance activity. AI risks. And onboarding, so the next vendor or the next internal build enters the stack by the front door rather than appearing in it later. Every register has a named owner, a review frequency and a defined trigger for a new line, and every line in the use case and model registers records what kind of AI it is, so the controls and tests that apply follow from the register rather than from someone’s memory. The dashboard is what the hub actually looks at.
The registers are deliberately the firm’s, not mine. They are handed over as an owned asset with the method for maintaining them, which is the difference between a governance model and a consultancy report about governance.
A board does not fund a register stack because it is good practice. It funds it because somebody put a number and a sequence in front of it. So the funding case is built inside the engagement rather than sold as a separate piece of work: what this costs to build, what it costs to run once built, and what it costs to govern on an ongoing basis, kept apart rather than summed into one figure that hides the recurring half. Against that, the exposure the firm carries today, stated plainly, and the cost of waiting another two quarters. Funding is released in tranches against named milestones, with the criteria for stopping agreed before the first pound moves.
Keeping the three costs apart is the part firms most often get wrong, and it is why AI budgets overrun in year two. Building is a project. Running and governing are permanent, and they land on a cost line somebody has to defend every year after the enthusiasm has gone.
An approved AI governance operating model, written in your firm’s language and sitting inside your existing three lines of defence. The twelve registers populated with what you actually run, each with an owner. The policy stack, with the standards and procedures that make the policy operable. The lifecycle control set, mapped to the point in the process where each control fires. The third-party AI position, including what to ask your administrator and your data providers for. The agent treatment, the assurance routine and the incident definition. The funding case, with build, run and governance costs separated and release gates set. The quarterly attestation and the evidence that has to exist behind it. And a mapping onto the NIST AI Risk Management Framework or ISO 42001 where you want one.
It is not legal advice, though it is written knowing your lawyers and your regulator will read the output. It does not validate or test your models or your vendors’ models for bias or accuracy; it establishes who is accountable for doing that and whether the firm can evidence it was done. It is not a technology build and it does not install anything, though it tells you where a control has to be technical rather than procedural to be worth anything. It is not a certification and I do not issue one. And it does not run itself: the cadence in Phase F needs an owner in your firm, and if that owner does not exist yet, that is a finding rather than something to paper over.
Most firms come in through the Vendor AI Oversight Review, because three weeks on a fixed scope is a decision a chief operating officer can take without a board paper, and it produces the inventory the build would otherwise spend its first fortnight assembling. Firms that already know what they are running start here. Where the engagement warrants it I hold the governance lead seat on a fractional basis for an agreed minimum term, running the hub, the gates and the board reporting until the firm can own them. The intention is always that it can.
A policy tells people what the firm will not accept. It does not tell you what is running, who approved it, what it can reach, or what happens when it is wrong. Most firms that have written a policy cannot produce the list of AI inside the firm, and that list is the first thing anyone asks for. The build turns the policy into controls, registers and a cadence with a signature at the end of it.
No, but it is the cheapest way in, and it does the inventory work the build needs. Firms that already know what they are running can start here.
Yes, and in a fund business the in-house half is usually the harder one. The models your data team has tuned, the agents built on a vendor’s foundation model, and the assistants your staff set up for themselves all sit in the same register stack as vendor AI. One model rather than two parallel ones, because AI that crosses functions cannot be governed by a function.
Yes. The stages are written against the obligations your firm already carries, and the control set maps onto the NIST functions and onto ISO 42001 clauses where you want to show an external standard. It is a stated output rather than a rebuild, because your own three lines of defence stay the governing structure.
Yes. The risk class decides how much control a system needs; the kind of AI decides which. Generative, predictive, agentic, language, vision and rule-based systems fail in different ways, so each starts from its own default controls and tests. Where one system combines several, the agentic part governs, because it acts.
By what the agent is allowed to call and what it is allowed to reach, rather than by inspecting the model behind it. An agent is a program that pauses to ask a model, and the pause is where your firm gets to decide. Every agent gets a declared purpose, a scope of authority, a named owner, a stop, and a record of what it called, with the controls placed at the integration layer it has to pass through to do anything at all.
The first attestation is designed to be signable at the end of the build. It will be narrower than the one signed a year later, which is correct: an attestation that claims more than the evidence supports is worse than a modest one.
Twenty-five years inside the governance this is grafted onto, and the AI credential on top of it.
I have held the seats that carry this accountability: Chief Operating Officer, Chief Information Officer and Chief Technology Officer, as well as Chief Revenue Officer, at HSBC Alternative Investments, ONYX Capital Group, Backstop Solutions and an FCA-regulated RegTech platform. At HSBC Alternative Investments I built the oversight methodology for every third party across the alternatives business and was accountable for the administrator and transfer agency relationships behind it, over eighteen years in which assets grew from $200 million to $31.6 billion with zero FCA breaches. That is where the three lines of defence, the outsourcing oversight and the control model on this page were learned, from the inside, under the regulator. The AI is the edge on that record rather than a substitute for it. I wrote Disruptive Innovation in Financial Services, published in 2026, and I am a chapter lead on an industry guide to AI in fund management. The method is my own, built from that record and from what I have studied since, and it is written down: the thirteen stages and the register stack are handed over, which is the test of whether a method exists at all.
Use the contact form, or message me on LinkedIn.