AI Discovery, Governance Design & Retainer

You can't govern the AI you haven't found.

Some of it you built. Most of it arrived — in a SaaS release nobody reviewed. So the way in is small: two days on one product or one department, and you get the list of AI systems in use, the data flows behind them, and where the gaps are. Discovery reads systems, not people — and where a channel touches employee data, the works council is in the room before the scan runs, not after. Then you decide how far up the ladder to go.

Find
it

AI Discovery & Readiness Assessment

Know what AI you're running, what data reaches it, and where the gaps are — against the EU AI Act and ISO/IEC 42001.

discovery across eight channels — code, configuration, network egress, OAuth grants, SaaS spend, browser and IDE, proxy logs, agent connections · a no-blame survey alongside it · reconciled inventory with owners and data inputs · findings mapped to EU AI Act and ISO/IEC 42001 · prioritised remediation roadmap · and if a date is already in your diary — a certification attempt, a client security questionnaire — the evidence pack and a dry run before it.

★ Flagship

Design
it

Context Architecture & Governance Design

Not a list of what's wrong — a design for how context is governed, and who decides.

approved-source registry · what may feed which class of system · filtering and classification boundaries · retention · where evidence attaches · owners, decision rights, review cadence, escalation · then anchored where the work already happens — intake gates in the pipeline, or procurement, tenant provisioning and approval paths, so a new AI system reaches the inventory without anyone having to remember it.

Keep
it

Governance Retainer

The inventory stays current and the evidence chain stays legible — because both decay by default.

recurring re-discovery · intake for new systems · quarterly review · a standing line for the question that can't wait for the next one.

Not all of it needs engineering. Where the answer is policy, procurement, tenant settings and training, that is the project — and it's the same work seen from the other end.

One specialism: if your team already ships with agents, the governance problem is code nobody typed. Standards, review workflow, and a record of what an agent actually touched.

Your context, your logs, your jurisdiction. For regulated buyers, where the evidence lives matters as much as what it says.

Engineering depth, governance judgement.

Eight-plus years building production software, much of it in regulated environments where reliability and compliance aren't optional extras.

Over the last few years my focus moved to applied AI: integrating LLMs into real products, building assistants and agents, and — the part most teams get wrong — governing what data feeds them and being able to prove it later. I led a development team's move to AI-assisted development, setting the context standards and review workflow that held quality while delivery accelerated.

Regulated teams get two answers about their own AI: what are we running, and what data goes into it. I work the whole path — discovery, inventory, data-flow controls, evidence — and then implement it in the actual stack. I prepare the evidence and I build the controls; the certificate is issued by a body I'm not part of.