About
I lead the data function of an analytics platform serving enterprise operators in a regulated industry, and I have spent seven years building systems where data quality and access control carry real consequences.
Evidence the system generates about itself, not a policy binder
My work sits at the point where AI governance stops being a policy question and becomes an engineering one. The thing a regulator, an auditor or an enterprise buyer actually asks for is not a document describing your controls. It is evidence the system generates about itself: what the model was told, what it did, who approved the change, and how you know the answer was sound.
Append-only logs, RLS isolation, versioned baselines: in production
I have built that evidence layer. Append-only audit logs enforced at the database. Row-level-security tenant isolation. Evaluation harnesses with versioned baselines so quality claims survive being questioned. Transparency obligations written into shipped product code rather than into a policy binder.
1,391 commits / 14 repos, under controls I wrote
I also govern the AI that writes my own code. Around 1,391 production commits across fourteen repositories were delivered under AI-assisted development, running under controls I wrote: credential reads blocked at the tool level, least-privilege tool allow-lists, pinned model versions, and backups taken outside model control. That exposure, staff and agents operating with unbounded permissions, is the one most organisations have not addressed at all.
No bench. No handoff. No slide-deck deliverables
I work solo. The person who scopes an engagement is the person who writes the code, and the controls are handed to your team to run.
Engagements start with a scoping call. You work with the person who does the work.