Responsible AI Needs Architects, Not Just Advocates

A friend of mine works on AI policy at a company you've heard of. Last year her team produced a 47-page Responsible AI framework, complete with values, commitments, a maturity model with five tiers, and a RACI chart. By any measure of policy craft it is a serious document, and none of it compiles.

Nothing in those 47 pages is wired to a system call. No code reads that PDF at runtime, no CI job fails when a model violates tier three, and no trace gets dropped because the framework said so. The document and the production stack sit in different buildings and are written in different languages, and most of the harm happens in the gap between them.

That is where Responsible AI stands right now, and it can't last. The principles are written and the frameworks are stacked five deep. What the field is missing is people who can turn any of it into running code.

The advocacy era is over because the agents shipped

For roughly a decade the dominant mode of Responsible AI work was advocacy: write the principle, publish the framework, convene the working group, get the executive sign-off. That made sense when AI systems were narrow classifiers and the governance question was mostly whether to build them at all. A list of principles fit the moment, because the risk was small and the deployment cycle was slow.

What runs in production now is an agent, a loop that reads, decides, acts, observes, and decides again, often while calling tools, writing to systems, sending messages, and executing transactions. The governance question has moved from whether to build it to what it does at 3 a.m., when a user asks it something its principal didn't anticipate, and how anyone would find out.

A framework can't answer that question. Code can, and specifically middleware: the guards, filters, evals, and traces that sit between the model and the world and decide what is allowed to happen. If the framework is the spec, the middleware is the implementation, and right now we have an enormous oversupply of specs and a desperate shortage of implementations.

What governance at the runtime layer looks like

Let me make this concrete, because abstraction is part of how the advocacy era avoided accountability.

Consider trace filtering. Every serious agent system produces a trace, a structured log of model inputs, tool calls, intermediate reasoning, and outputs. Traces are the audit trail. They are also a privacy disaster waiting to happen, because they hold whatever the user said, and that often includes PII, PHI, credentials, or proprietary content the user never meant to persist. A responsible agent stack runs a redaction pass on every trace before it lands in storage. That pass is a piece of code with a regex library, a named-entity recognizer, a confidence threshold, a fallback policy for low-confidence spans, and a manual review queue for edge cases. Someone writes and tests it, and someone owns the on-call when it misses an SSN. That person is doing Responsible AI work, whatever their title says.

Consider eval gates in CI. The question worth asking about a model update is whether the new version regressed on the things you care about, safety and policy included, and a benchmark gain doesn't answer it. The mature pattern is to run a curated eval suite as a required check on every model deployment, the same way unit tests run on every code commit. The suite covers capability, bias, jailbreak resistance, instruction-hierarchy adherence, and domain-specific harm cases. A model that regresses on the safety subset doesn't ship, because the build system blocks the PR before anyone schedules a meeting about it.

Consider the model card as configuration. A model card used to be a PDF. At the runtime layer it becomes a YAML file the orchestrator reads at boot to decide which capabilities are enabled, which tools the model may call, what the rate limits are, which content categories trigger refusal, and where to escalate when a refusal is unclear. Two models with different cards behave differently at the syscall level because the loader parsed different files, with no speech required. The policy and the runtime are the same artifact.

None of these three will get you a TED talk, and all three are where the safety of an agent system gets decided.

The advocate-architect gap is now the bottleneck

Almost every organization I see above a certain size has a Responsible AI team. It produces frameworks, runs trainings, issues guidance, and sits on review boards. Its people are smart, often credentialed in ethics or policy or law, and they want the systems to be safe. The same organization has an engineering org that ships agents, builds tool integrations, manages model deployments, and owns the runtime. Those people are just as smart, usually credentialed in ML or systems, and they want the systems to work.

The two groups talk past each other. The RAI team produces artifacts engineering cannot consume, and engineering makes decisions the RAI team cannot see. When something goes wrong, both sides are surprised, and the postmortem shows that the principle the framework asserted was never expressible in the system that violated it.

More frameworks and more trainings won't close that gap. People who work in both worlds will: people who can read a principle and write the eval that enforces it, read a trace and tell you which policy commitment it violates, and sit in a model review asking the architecture questions that decide whether a commitment is even physically possible. I call them architects, because they design the structure of a system so that the desired properties hold.

The advocate-architect ratio in most organizations is something like 20 to 1. It needs to invert.

What I've been building, and why

I run the AI Leadership Think Tank at the Marketing + Media Alliance. On paper it is a forum for senior marketers to discuss AI strategy. In practice it is where I test whether the architect framing holds up against operators who carry P&L responsibility and have no patience for vibes.

The leaders moving fastest have stopped treating Responsible AI as a separate workstream. They treat it as an architectural property of the agent stack they are building, so the questions they ask are about that stack: what does our trace pipeline redact, which evals does a deploy have to pass, what capability constraints sit in our orchestrator config, and who holds the kill switch and how fast does it propagate? Each of those has an answer in code.

I have spent the last year building Claude and ChatGPT skills and agent toolkit components that try to make those answers cheaper to write. They include a redaction skill that runs before traces hit storage, an eval harness that plugs into CI and fails the build on regression, capability-constraint middleware that reads a policy file and refuses tool calls outside its scope, and a trace viewer that flags the moments where a model's reasoning diverged from its instructions. None of it is exotic. All of it should exist as default infrastructure, and mostly doesn't, because the people writing about Responsible AI are rarely the people who write infrastructure.

I mention this because the bar is low, and that should make you angry. A person with a humanities-heavy background and a recent AI Ethics degree can ship middleware that improves the governance posture of real production systems, and the reason is that almost nobody else is doing the work. The field has produced one generation fluent in the vocabulary of harm and a separate generation fluent in the vocabulary of systems. The overlap is small enough that anyone willing to work in it has an enormous amount of useful work to do.

The objections, briefly

Two objections come up every time I make this argument.

The first is that not everyone needs to code, which is true. Advocacy, policy, and external pressure on companies and governments all still matter, and I am not arguing that everyone in Responsible AI should become an engineer. My claim is that the field as a whole is dramatically over-indexed on the non-technical side of the work. The marginal value of one more framework is now roughly zero, while the marginal value of one more person who can ship a working eval suite is enormous. The right mix has far more architects than the current one, though it isn't all architects.

The second objection is that this framing privileges technical work over ethical reasoning and risks collapsing normative questions into engineering ones. I take this one more seriously. Some ethical questions about AI can't be reduced to system design, and I don't want to suggest otherwise. Even so, the most carefully reasoned normative claim has no purchase on a production system until someone translates it into a property the system can be measured against. The ethicist who produces the argument and the architect who produces the eval work in sequence. Right now the second step almost never happens, people cite the first as if it were sufficient, and a principle nobody enforces stays a wish.

What the next five years look like

The Responsible AI field is going to split. One branch will keep producing frameworks, principles, and high-level guidance, and will matter less each year to what happens in production systems. The other will build middleware, evals, traces, guards, kill switches, audit pipelines, and capability constraints, along with the operating practices around them. The credible leaders of the next decade will come from the second branch, because they will be the only people who can point to a system and show you the line of code that enforces a given commitment.

If you are early in your career and want this work to matter, learn to ship. Pick a model, a runtime, and an agent framework, and build something that constrains its behavior in a way you can defend. Write the eval, read the trace, push the PR. Five years from now, the systems you architected will count for more than the documents you authored.

If you are already senior in a Responsible AI role and have been working in advocacy mode, your job is to get close enough to the runtime that your interventions land. Sit with the engineers and read the orchestrator config. Ask which evals run on which deploys, then find the trace pipeline and learn what it captures. You don't have to write the code yourself, but you do have to understand it well enough that the principles you propose can be expressed in the system you are proposing them for.

The advocates wrote the principles, and that work mattered and is largely done. The architects will write the runtime, and that work has barely started. Over the next five years, the Responsible AI work that changes how systems behave will arrive as diffs.