
The Pipeline That Changed How I Think About Governance
Before I built BuildMoat, I worked with the product team responsible for migrating critical systems from on-premises infrastructure to the cloud. This was before my Policy role at the Bank of England. HSBC was introducing public cloud to all of its businesses globally through a long-term deal with Amazon Web Services. My responsibility was specific: developing the Policy as Code framework embedded in our CI/CD pipeline. My team worked with AWS CloudFormation and Terraform to ensure every piece of infrastructure we provisioned met the bank's security, compliance, and governance requirements before it ever touched production.
That experience shaped everything I believe about governance today.
What Policy as Code Actually Was
Before Policy as Code, governance was manual. An engineer requested infrastructure. A change advisory board reviewed it. Someone checked a spreadsheet. Days passed. By the time approval came through, requirements had often changed.
Infrastructure as Code changed the first part. Engineers declared infrastructure in code using Terraform or CloudFormation. Version-controlled, repeatable, auditable.
But that created a new problem: if any engineer could provision infrastructure through code, how do you ensure every deployment meets the bank's regulatory standards?
That's where my team came in.
Using HashiCorp Sentinel and native AWS controls, we codified governance requirements as executable logic. Sentinel policies sat between the plan and apply stages of the Terraform workflow. If a deployment violated a policy, it was blocked. Not flagged. Not logged for later review. Blocked.
We wrote policies covering encryption requirements, network segmentation, tagging standards, data residency restrictions, access controls. Each policy was version-controlled in Git, peer-reviewed, and tested before deployment to the pipeline.
The result was elegant. Engineers moved fast. Infrastructure was provisioned in minutes, not weeks. And every deployment was automatically checked against governance requirements before it existed in the real world. The audit trail was inherent. Git history showed who wrote the code and when. Pipeline logs showed which policies passed or failed.
If a regulator asked "how do you ensure your cloud infrastructure meets security standards?", we pointed to code, tests, and logs. Not a spreadsheet. Living, continuous, automated proof.
Tech moves fast, but you're still playing catch-up?
That's exactly why 200K+ engineers working at Google, Meta, and Apple read The Code twice a week.
Here's what you get:
Curated tech news that shapes your career - Filtered from thousands of sources so you know what's coming 6 months early.
Practical resources you can use immediately - Real tutorials and tools that solve actual engineering problems.
Research papers and insights decoded - We break down complex tech so you understand what matters.
All delivered twice a week in just 2 short emails.
The Philosophy: Shift Left
The cloud engineering community called it Shift Left. Move governance as close to the point of creation as possible. Don't wait for a post-deployment audit. Catch violations at the moment of creation.
The principles were clear:
Policies are code. Version-controlled, peer-reviewed, testable.
Enforcement is automated. No human bottleneck, no inconsistency.
Gates are binary. Pass or fail. No ambiguity.
Audit trails are inherent. Git history plus pipeline logs equals complete evidence.
Humans decide policy. Machines enforce it.
That last principle is the one I keep coming back to. It contains both the genius of the approach and the seed of a problem the cloud world never had to confront, but that financial services compliance faces every day.
Why the Cloud Pattern Worked: Deterministic Decisions
Policy as Code worked beautifully because the decisions were deterministic. An S3 bucket is either encrypted or it isn't. A security group either allows unrestricted access or it doesn't. Binary. A machine can evaluate these perfectly, every time, at scale.
There was no need for a human at the gate. The judgement had already been exercised upstream when the policy was written. The machine simply enforced a decision already made.
That's the key insight. We separated deciding from enforcing. Humans decided once. Machines enforced continuously. Governance at scale.
The AI Era: When Decisions Stop Being Deterministic
Now fast-forward to 2026. AI agents are being deployed across financial services at extraordinary pace. The industry is spending over $35 billion on AI this year. Unlike earlier tools that handled isolated tasks, agentic AI acts as a semi-autonomous orchestrator, planning, acting, and coordinating complex compliance workflows.
Here's where the pattern breaks.
In a KYC onboarding workflow, an AI agent screens a client, pulls adverse media, checks sanctions lists, and presents a risk profile. But the determination of whether this particular client, with ambiguous PEP connections and an unusual source-of-wealth explanation, should be onboarded? That's not binary. That requires context, experience, and judgement no codified policy can fully capture.
In a suitability review, an AI agent compiles portfolio data and flags inconsistencies. But the decision about whether a recommendation is genuinely suitable for a specific client with declining health? That's not a pass/fail check.
In transaction monitoring, an AI agent scores alerts by risk. But the adjudication of whether a flagged pattern is genuinely suspicious? When an AI agent retrieves and acts on client data, who is accountable?
You cannot write a Sentinel policy that captures every permutation of human judgement required in financial services compliance. The decisions are probabilistic, contextual, and consequential. Under SMCR, a named individual is personally accountable for getting them right.
The cloud world solved governance for deterministic decisions. Financial services needs governance for non-deterministic decisions. That requires a different kind of gate.
From Codified Policies to Human Gates
Here's the connection I keep drawing.
In the cloud pipeline: Code flows through automated policy gates producing auditable outcomes.
In a compliance workflow: AI Agent flows through human decision gates producing auditable outcomes.
The structural pattern is identical. Define the work. Embed the gates. Log everything. Enforce before harm occurs.
Cloud Pipeline (2017) | Compliance Pipeline (2026) |
|---|---|
Infrastructure as Code | AI Agent workflow orchestration |
Policy as Code (Sentinel, OPA) | Governance rules in agent orchestration |
Automated gates (binary pass/fail) | Human gates (contextual judgement) |
Git audit trail | Decision capture with SMCR attribution |
Continuous compliance | Continuous monitoring and drift detection |
The cloud engineers removed humans from enforcement because the decisions were deterministic. BuildMoat moves humans to the gates because the decisions aren't. Both share the same philosophy: separate the groundwork from the governance, embed checkpoints in the flow, make every outcome traceable.
Most adults with ADHD don't realize how deeply it affects their daily life—from emotional regulation to working memory. This free personalized quiz reveals your ADHD trait score across 5 key areas and shows you exactly where to focus first. Takes 10 minutes, changes everything.
What This Means in Practice
When I was writing Sentinel policies at HSBC, I didn't automate governance to eliminate oversight. I automated the mechanical checks so security and compliance teams could focus on hard problems: architecture reviews, threat modelling, regulatory interpretation. Policies handled repeatable logic. Humans handled judgement.
That's exactly what AI agents should do for compliance teams today. The agent handles data gathering, screening, document aggregation, initial risk scoring. The human sits at the gate where the determination must be made. Actively applying expertise at the point where it matters most.
The compliance analyst spending three hours copying data between systems? She now reviews a structured, AI-prepared case file and applies fifteen years of experience to the question that actually matters: is this client relationship genuinely suspicious? Her judgement is logged, attributed under SMCR, and forms part of an evidence trail that satisfies any regulatory inquiry.
That's not a revolution. It's a proven architectural pattern adapted for a domain where the stakes are higher and the decisions require human cognition.
An Invitation
We're running pilots with wealth managers, fintechs, and mid-tier firms to apply this architecture to their highest-risk compliance workflows. If you're a Senior Manager who feels the weight of accountability without the infrastructure to support it, I'd like to talk.
The cloud engineering community solved governance at scale by codifying policy and embedding it in the pipeline. Financial services can solve AI governance by positioning human judgement at the gates and letting agents handle the rest.
The pattern works. It's time to apply it.
Visit buildmoat.co.uk for the full framework, or reach out to discuss a pilot.
Thanks for Reading
BuildMoat builds AI Agents and the human infrastructure to deploy them responsibly. Agents handle the groundwork. Humans sit at the gates for judgement and decisions. Every action is traceable, accountable, and audit-ready.
That's how firms increase AI adoption, stay compliant, and build a moat.
We're currently piloting with financial services firms. If you want to see what this looks like for your workflows, book a call.
Did someone forward this to you? Subscribe here for weekly insights on AI adoption that actually works in regulated environments.
Keep building,
BuildMoat
AI Agents. Human Gates. Your Moat.



