The first thing we do is read the design and the code. AI inventories matter, but they tell you what exists, not whether it is wrong. The questions that decide whether you are exposed are architectural: do your agents have the right tools, and only those tools? Are the identity boundaries between them drawn in the right places? What happens when a model returns something unexpected, or a tool call fails halfway through? Those are code-and-design questions, and they are where we spend our time. An inventory is the start of the conversation, not the end of it.

A design review hands to an engineer with named changes, not to a steering committee with a five-workstream roadmap. Threat models map to specific architectural decisions, so you can see which design choice each risk depends on. Controls look like middleware specifications — things you can build — rather than statements of intent. Policy artefacts exist where they are genuinely needed, but they are downstream of the engineering, not upstream of it. The test we hold ourselves to is simple: could a senior engineer act on this on Monday morning?

We know SR 11-7, SS1/23, the EIOPA guidance, DORA, and the FINOS AI Governance Framework. We have written about all of them. That fluency matters, because it means we can tell you where a design choice will create a problem with a regulator long before it does. But the regulatory work is downstream of the engineering: when the architecture is right, the answer to the regulator's question is short. We are not here to sell you a compliance programme. We are here to make sure you do not need a large one.

We take on a small number of engagements at a time, principal-engineer-led throughout. The person in your design reviews is the person doing the work; there is no layer of juniors between the diagnosis and the delivery. We expand the team as engagement volume warrants rather than ahead of it, which keeps the quality of attention high and the firm honest about what it can take on. Our team is the work, not the org chart.