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. It has values. It has commitments. It has a maturity model with five tiers and a RACI chart. It is, by every measure of policy craft, a serious document.

It does not compile.

By which I mean: nothing in those 47 pages is wired to a system call. No line of code reads that PDF at runtime. No CI job fails when a model violates tier three. No trace gets dropped because the framework said so. The document and the production stack live in different buildings, on different floors, speaking different languages, and the gap between them is where most of the harm actually happens.

This is the situation in Responsible AI right now, and it is not sustainable. The principles are written. The frameworks are stacked five deep. What is missing is the layer of 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. This made sense when AI systems were narrow classifiers and the governance question was mostly “should we build this at all.” A principle list was an appropriate intervention because the risk was small and the deployment cycle was slow.

That world is gone. The thing in production now is not a classifier. It is an agent: a loop that reads, decides, acts, observes, and decides again, often calling tools, writing to systems, sending messages, executing transactions. The governance question is no longer “should we build this.” It is: what does this agent do at 3 a.m. when a user asks it something its principal didn’t anticipate, and how do we know.

That question cannot be answered by a framework. It can only be answered by code. Specifically, by middleware: the layer of guards, filters, evals, and traces that sits between the model and the world and decides what is allowed to happen. 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 actually 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 contain whatever the user said, which often contains 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 redaction pass is a piece of code. It has 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 it. Someone tests it. Someone owns the on-call when it misses a SSN. That person is doing Responsible AI work, whether or not their title says so.

Consider eval gates in CI. The interesting question about a model update is not “is the new version better on benchmarks.” It is: did this version regress on the things we care about, including the things we care about for safety and policy reasons. The mature pattern is to run a curated eval suite as a required check on every model deployment, the same way you run unit tests on every code commit. The suite includes capability evals, bias evals, jailbreak resistance, instruction hierarchy adherence, and domain-specific harm cases. A model that regresses on the safety subset does not ship. The PR is blocked. The governance is enforced by the build system, not by a meeting.

Consider the model card as configuration. A model card in the old paradigm was a PDF. A model card in the runtime paradigm is a YAML file the orchestrator reads at boot to determine which capabilities are enabled, which tools the model is allowed to call, what the rate limits are, which content categories trigger refusal, and what the escalation path is when refusal is unclear. Two models with different cards behave differently at the syscall level, not because anyone gave a speech about it but because the loader parsed the file. The governance is structurally inseparable from the runtime.

Each of these is unglamorous. None of them will get you a TED talk. They are also where the actual safety lives.

The advocate-architect gap is now the bottleneck

Here is what I see in almost every organization above a certain size. There is a Responsible AI team. It produces frameworks, runs trainings, issues guidance, sits on review boards. The people on it are smart, often credentialed in ethics or policy or law, and genuinely want the systems to be safe.

There is also an engineering org. It ships agents, builds tool integrations, manages model deployments, owns the runtime. The people on it are smart, often credentialed in ML or systems, and genuinely want the systems to work.

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

The fix is not more frameworks. The fix is not more trainings. The fix is people who live in both worlds: who can read a principle and write the eval that enforces it, who can read a trace and tell you which policy commitment it violates, who can sit in a model review and ask the architecture questions that determine whether the commitment is even physically possible. I will call these people architects, because that is what they are. They design the structure of the system such 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. It is, on paper, a forum for senior marketers to discuss AI strategy. What it actually is, in practice, is a place where I get to test whether the architect framing holds up under contact with operators who have P&L responsibility and no patience for vibes.

The pattern I keep seeing: the leaders who are moving fastest are the ones who have stopped treating Responsible AI as a separate workstream and started treating it as an architectural property of the agent stack they are building. They are not asking “what is our AI policy.” They are asking: what does our trace pipeline redact, which evals a deploy has to pass, what are the capability constraints in our orchestrator config, who has the kill switch and how fast does it propagate. Those are architecture questions. They have answers 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. A redaction skill that runs before traces hit storage. An eval harness that plugs into CI and fails the build on regression. A capability-constraint middleware that reads a policy file and refuses tool calls outside its scope. A trace viewer that flags the specific moments where a model’s reasoning diverged from its instructions. None of this is exotic. All of it is the kind of thing that should exist as default infrastructure and largely doesn’t, because the people writing about Responsible AI are not, in general, the people who write infrastructure.

I am not saying this to brag. I am saying it because the bar is genuinely low, and that should make you angry rather than reassured. The reason a person with a humanities-heavy background and a recent AI Ethics degree can ship middleware that meaningfully improves the governance posture of real production systems is that almost nobody is doing the work. The field has produced a generation of people fluent in the vocabulary of harm and a separate generation fluent in the vocabulary of systems, and the intersection is small enough that anyone willing to live in it has an enormous amount of useful work to do.

The objections, briefly

Two objections come up every time I make this argument, and they deserve direct answers.

The first is that not everyone needs to code. True. The architect role is not the only role. Advocacy still matters; policy still matters; external pressure on companies and governments still matters. What I am arguing is not that everyone in Responsible AI should become an engineer. I am arguing that the field as a whole is dramatically over-indexed on the non-technical side of the work, and that 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 optimal mix is not all architects. It is also not the current mix.

The second is that this framing privileges technical work over ethical reasoning, and risks collapsing normative questions into engineering ones. This one I take more seriously. There are real ethical questions about AI that are not reducible to system design, and I do not want to suggest otherwise. But here is the thing: even the most carefully reasoned normative claim has no purchase on a production system unless 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 are not in competition. They are in sequence. The problem right now is that the second step almost never happens, and the first step gets cited as if it were sufficient.

A principle that cannot be enforced is not a principle. It is a wish.

What the next five years look like

The Responsible AI field is going to bifurcate. One branch will continue producing frameworks, principles, and high-level guidance, and will become progressively less relevant to what is actually happening in production systems. The other branch will produce middleware, evals, traces, guards, kill switches, audit pipelines, capability constraints, and the operational practices around them. The second branch is where the credible leaders of the next decade will come from, because they will be the only people who can point to a system and say, specifically, here is the line of code where this commitment is enforced.

If you are early in your career and you want this work to matter, learn to ship. Pick a model, pick a runtime, pick 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. The credentials that count five years from now will be the systems you architected, not the documents you authored.

If you are already senior in a Responsible AI role and you have been operating in the advocacy mode, the work in front of you is to get close enough to the runtime that your interventions land. Sit with the engineers. Read the orchestrator config. Ask which evals run on which deploys. Find the trace pipeline and learn what it captures. You do not have to write the code yourself. You do have to understand it well enough that the principles you propose are physically expressible in the system you are proposing them for.

The advocates wrote the principles. That work mattered and is largely done. The architects will write the runtime, and that work is barely started. The interesting frontier of Responsible AI is no longer the document. It is the diff.