About

I help teams govern the AI they are already shipping, without turning delivery into paperwork.

What I do now

I work with engineering teams on AI governance: model inventories, risk classification, review processes, and readiness against the EU AI Act, NIST AI RMF and ISO 42001. Most of that work is less about writing policy than about finding the version of a control that a team will still be following in six months.

How I got here

I have spent a decade building production systems, and the last stretch of it building and shipping AI and ML features rather than reading about them. I run engineering for a cross-border payments platform today — team, sprint cadence, code review, release — so the governance advice I give is advice I have to live with on my own roadmap.

I did governance work inside a company first, which is where I learned that the gap is rarely knowledge of the framework. It is that nobody has translated the framework into something that fits how the team actually works.

Sectors I have built in

I have not worked in every industry, and the ones I have worked in shape what I am useful for. Most of them were regulated before anyone was talking about AI regulation, which is the part that transfers.

The through-line is that in every one of those, somebody was going to audit the thing eventually. Financial crime controls, transaction integrity, security clearance for government deployments — I have written the evidence and I have sat in the review. AI governance is a new vocabulary over a problem shape I already know.

The AI systems I have shipped

I think you should be suspicious of AI governance advice from people who have not built the systems they want to govern. Three I have put into production:

• An agentic operations platform that investigates incidents and executes remediation, sitting behind a policy engine that requires human approval for anything consequential — durable workflows, event-sourced audit trail, decisions scored by an LLM judge. That is human-in-the-loop design as a working system rather than a slide.
• A customer-facing retrieval agent that scores its own confidence per response and escalates to a human when it is low, with an ops console for reviewing sessions and watching the escalation rate.
• A Model Context Protocol server exposing a logistics platform to external developers and AI agents, which is a question about what you are willing to let an agent do to your production systems.

Every governance control I recommend, I have had to implement against a delivery deadline. That is the whole basis on which I would ask you to trust the estimate.

What I think governance is for

Governance has a bad reputation with engineers because most of what they have seen of it was designed to produce evidence, not to reduce risk. A review process that nobody can complete in a sprint does not make a system safer; it makes people route around it.

The version I care about is boring and small: you know what models you run, you know which ones can hurt someone, those ones get looked at by a human before they ship, and you can show your work afterwards. Almost everything else is decoration.

How I work

I read your code and your process before I recommend anything. I would rather tell you that you have no real gap than sell you a programme you do not need — it is a smaller invoice and a better reference. If I am not the right person for the problem, I will say so on the first call.

Where to check my thinking

I write at TechTalkByte and post shorter breakdowns elsewhere. The writing is the work sample — read a few pieces and you will know quickly whether how I think is useful to you.

Read the writing

Follow along

If you would rather see the work before you talk to me, pick whichever of these you already read:

• LinkedIn — governance notes and what I am learning on the delivery side.
• Instagram — short breakdowns of the same ideas, in reel form.
• GitHub — the code behind the systems I describe here.