AI Governance & Responsible AI · Technical Program Manager
Clear AI policies and a review process your team can actually run. Launching an AI feature, or getting asked how you use AI? I help growing companies and nonprofits answer with confidence. Trained at Brown and Oxford, and I've built a governance program from scratch.
Services: AI Governance Setup, AI Usage and Vendor Review, and Program and Operations Support.
For organizations that have launched an AI feature or plan to launch one soon.
You getFor teams leveraging AI tools or bringing in a new vendor.
You getFor teams that need structure to deliver.
You getI'm not a lawyer. Policy drafts are written for review by your legal counsel.
Oxford faculty member Peter Ptashko talks with two alumni of Oxford's online AI programmes about strategic innovation and AI.
I talk about what the AI Ethics, Regulation and Compliance Programme gave me: a working understanding of international AI regulation such as GDPR, ethical decision-making, and the societal impact of AI systems.
A conversation with host Chris Parisi about the ethics of AI, diversity in tech, and how to build an effective governance task force.
A civic recreation startup had no data governance function. It collected personal data (names, emails, dates of birth) and was about to launch its first AI feature.
Nothing retained or shared beyond the 7-day window.
Most small teams don't need a heavy compliance program. They need a clear record of what their AI does, the risks it creates, and controls sized to those risks.
At a metaverse research company, I worked hands-on with engineers building hardware systems that captured human data for avatar research.
I asked how the systems performed for people with disabilities, different skin tones, tattoos, and piercings. No one had concrete answers. The operators who ran sessions with participants knew some appearances weren't captured correctly. That data was effectively excluded from the foundational models. It was a known issue, but undocumented.
The capture suite wasn't reliably capturing darker skin tones, so the data wasn't usable for avatars. We traced it to lighting: at certain brightness levels, darker skin reflected light back as a sheen. We ran lighting experiments with the research team and validated the fix with participants who had darker skin tones. The pipeline then produced accurate avatars for them.
The checklist became a standing gate. Every capture system had to pass testing across a wider range of appearances before sign-off.
Bias often lives in undocumented gaps that the people closest to the work already know about. Asking them, and writing it down, is where fairness work starts.
I led evaluation for a desktop security product at an early-stage startup. It flagged phishing and unsafe links in real time, and flagged personal data being copied into applications.
Sites known to be safe should never be flagged. If more than 10% of a known-safe benchmark set gets flagged, the release is blocked until the cause is found.
Above 10%: fix, retrain, and run the loop again. Older known FPs are re-checked periodically.
On the 1.0 release, a major UX update shipped with a model update and false positives spiked above 10%. We traced the cause. Most flags were subdomains on known-safe hosting platforms like GitHub and Substack, so we allowlisted those hosting patterns. That resolved most flagged cases and brought the rate back under the threshold.
A control only matters if it can stop a release. Set a measurable threshold, track it continuously, and re-check whenever the model or product changes.
At an autonomous vehicle company, I was the program manager on the Product team delivering technical requirements for autonomous vehicle behavior.
Requirements moved through a spreadsheet in sequence: Product drafted, Engineering signed off, then Safety and Legal reviewed. That took weeks. Safety or Legal often flagged issues after Engineering had started building, so the cycle restarted. The churn was expensive and demoralizing.
Issue flagged: the cycle restarts after build has begun.
After: parallel sign-off in JiraNot every requirement carried the same risk. Pedestrian interaction requirements were the highest tier and got more review time and scrutiny by default.
One example covered vehicle behavior around pedestrians with disabilities in crosswalks. Product and Engineering wanted to move forward. Safety and Legal needed more time for edge cases. We worked it through in a biweekly working session.
Signed off with additional safety controls, which could be revisited once the technology had proven itself.
Controls shouldn't be static. Match their intensity to current risk and demonstrated maturity, and define what would trigger a review.
Product and program manager with 10+ years delivering software, hardware, and AI/ML programs at tech companies, from Fortune 500 to startups. I build governance where none exists: risk review, model evaluation, and the cross-team process that makes it stick. Formally trained in AI ethics through Brown and Oxford, with hands-on experience in AI evaluation and deployment.
Joined through the Technology Development Program as Application Systems Analyst
Tools