Erik Buckman

My background is unusual for this space: 20-plus years in SEO and digital strategy, 6-plus years focused on GEO, AEO, and AI search optimization, formal training in UX research and design thinking, and a practice built around the belief that human intent is the most important input in any AI system. Before I write a system prompt, I map the workflow. Before I recommend a model, I ask whether AI belongs in the conversation at all. That same instinct extends to a second discipline I've built alongside enablement work: adversarial testing and AI governance. A system that people trust and a system that survives someone actively trying to break it are the same design problem, viewed from opposite directions. I've built the data-boundary architecture and threat model for a public-facing RAG chatbot from real jailbreak attempts in production logs, and I hold my own AI agents to the same adversarial standard I'd apply to anyone else's. Search experience optimization (SXO) sits at the intersection of how search engines rank content and how real people actually use it. You cannot separate the two anymore. The same principle applies to AI enablement and AI safety alike: a system built without understanding the human on the other end, whether that human is a trusting first-time user or an adversary probing for a weakness, becomes technically impressive and practically unreliable. Design thinking, intent mapping, and jobs-to-be-done are the core methodology here, not soft skills layered on top of it.

I listen before I configure. I map the human workflow before I write a system prompt. I ask who uses this, what they're trying to accomplish, where the real friction lives, and whether AI is actually the right answer before anyone touches a tool. That process comes directly from UX research practice: empathize, define, ideate, prototype, test. Applied to AI enablement, it becomes: listen to pain points, validate the fit, design for the user, build with governance, iterate on feedback. Applied to AI safety, it becomes: understand the system's real boundary, model how an adversary would probe it, build the evaluation battery that proves the boundary holds, and re-test on a cadence, because a system that passes on launch day doesn't stay safe as attackers adapt. Every agent I build has a name, a character, and a reason someone would want to open it again tomorrow. Every agent I deploy publicly gets tested against the same adversarial pressure I'd expect a real attacker to apply. Adoption is a design problem. Trust is a security problem. I treat both like one.

Open to AI enablement, AI governance, and AI safety roles in Denver, CO and remote. I'm looking for organizations that want to build AI capability thoughtfully, with governance, with human judgment at the center, and without the graveyard of tools nobody uses or the blind spots nobody tested. If that sounds like your team, let's talk.