Skip to main content

About

·3 mins

AI has collapsed the cost of producing code. It has done nothing to the cost of safely absorbing it.

The hard problem was never generating code inside one service. It is governing change across the interdependencies between teams, contracts, and release cycles, the part no model holds. In regulated settings that gap meets auditability, data residency, and clearance authority. My work lands there: making governance an architecture that runs in the flow of delivery, rather than oversight added afterwards.

Most organisations still treat AI in the SDLC as a tooling decision. Give the engineers a code assistant, keep the process, watch the velocity numbers improve. Every other function, finance, customer service, risk, redesigned itself around the capability. Software engineering is the exception, and it is the one place where the cost of getting it wrong stays hidden until an audit or an incident traces a failure back to it.

That gap is what I am hired to close.

What I do #

I work as a fractional or interim leader for the part of the AI problem that does not look like delivery work: the governance, architecture, and operating-model changes that decide whether AI-assisted delivery is something you can stand behind in front of a regulator.

Concretely, that means:

  • Designing where AI governance actually lives. Not in a policy document that two teams interpret two ways, but in the execution layer, as evaluable contracts, evidence-sufficiency gates, and runtime attestation.
  • Making accountability hold under autonomy. As agentic systems combine autonomy with human feedback loops, single-person accountability stops being sufficient. I help organisations move to deployment invariants they can attest to.
  • Treating legacy as a context problem, not a code-age problem. The thing you maintain was never the code. It was the knowledge the code is derived from. I help teams externalise that knowledge so AI-assisted modernisation is governed rather than hopeful.
  • Lifting engineering effectiveness and developer productivity without loosening regulatory constraint. Speed and assurance stop being a trade-off once governance runs in the flow of delivery instead of being added as oversight afterwards.

How I work #

I am not a tool evangelist and I do not sell inevitability. The work is structural: name the boundary, name the invariant, name the failure mode, and make governance executable rather than aspirational. I bias toward the smallest move that changes a design decision, and I am direct about what breaks first and where the leverage is.

I work best embedded, with enough authority to change the operating model, not just advise on it. Regulated finance and other high-assurance environments are the home ground: DORA, the EU AI Act, model-risk regimes, three-lines-of-defence. The constraints are the point, not an obstacle.

The thinking #

The articles and posts on this site are the working record of how I think about this problem. If the framing resonates, the engagement will too.

Track record #

Twenty-five years in enterprise architecture and technology strategy, across global banks, insurers, and public institutions. Leading professional-services firms and regulated institutions engage me as an independent advisor on architecture and AI.

Available for independent advisory engagements across the EU. The fuller record, including roles and recommendations, is on my LinkedIn profile.

Work with me #

I take a small number of fractional and interim engagements at a time.

Get in touch to talk through where your AI-in-engineering programme is exposed and what the next structural move is.

M.F.Borman