What is a content policy and who should own it in a product organization?
Bramblecourt Reviews lets people rate and review local businesses. An AI feature summarizes a business's reviews into a short "what people are saying" blurb, and separately flags reviews for policy violations. Osric Vantry leads the reviews-integrity team, and tracks open policy questions on a whiteboard he photographs at the end of most shifts.
- Name one product owner for the policy, not a committee.Why: a decision three teams can each veto is a decision nobody actually owns.
- Give legal and trust and safety a hard veto on named high-risk categories only.Why: full veto power over everything slows every decision to the pace of the slowest reviewer.
- Version every policy decision, so any rule can be traced to who set it and when.Why: an unversioned policy can't be audited after something goes wrong.
- Build a fast-appeal channel for a business affected by a bad AI-generated summary.Why: even a good policy owner will sometimes call it wrong, and someone has to be able to say so quickly.
- Keep the policy's scope narrow to the features that exist today.Why: trying to pre-write rules for every future AI content feature slows down the one that's shipping now.
How to answer this, stage by stage
The interviewer already suspects "a committee decides" is the wrong answer. What they want to hear is who specifically, and why that person, not a department.
Let's learn
Say a reviews platform builds an AI tool that reads a business's customer reviews and writes a short summary blurb. Underneath it, a separate model flags individual reviews that might break the platform's rules.
For most of its life, "content policy" at Bramblecourt existed only as a legal compliance document, written by the legal team, reviewed once a year, and read by almost nobody outside that team. The product teams shipping AI features had their own informal sense of what was fine, built from habit rather than any written rule.
The summarizer had shipped fourteen months earlier with no documented policy for what it should do when the underlying reviews contained a serious, unverified accusation about a business. Nobody had written a rule, because nobody had been assigned to write one.
At its worst: the summarizer, drafting a blurb for a small restaurant, folded in a single reviewer's serious, unverified claim as if it were an established fact, phrasing it in a way that read like a settled complaint rather than one person's account. The business owner threatened legal action before anyone at Bramblecourt had even agreed on whose job it was to respond.
What I would leave alone: a summary blurb that's simply a little dry or generic doesn't need this same governance weight. The policy exists for named categories of real harm, not every stylistic complaint about how a blurb reads.
The lesson: a policy with no name on it isn't being followed loosely. It isn't being followed at all, because nobody who could actually enforce it thought it was theirs to enforce.
Now here is the same thing as a story
The short version above is what you'd say defending this ownership model cold. Read this one for how the gap actually got found.
Callum has led Bramblecourt's reviews-integrity team for three years. He's the closest thing the company has to a policy owner, but nobody had ever formally given him that title, and he'd never asked for it either.
Whenever a borderline case came up, from the summarizer or the flagging model, Callum's habit was to raise it in whichever meeting felt closest, and wait. Sometimes legal answered within a day. Sometimes it sat for two weeks. He'd developed a quiet tolerance for the wait, since escalating felt like overstepping into someone else's territory.
Then came the restaurant's blurb. A single reviewer had posted a serious, unverified accusation about the owner, and the summarizer's draft folded it into the "what people are saying" summary in language that read like settled fact rather than one person's claim. It went live for six hours before anyone caught it.
The restaurant's owner called, furious, threatening to involve a lawyer. Callum pulled together product, legal, and trust and safety on an emergency call within the hour, and watched all three, in real time, each wait a beat too long before answering "whose call is this," because genuinely, on paper, it wasn't clearly anyone's.
We did not almost ship one bad summary. We almost let a business's reputation ride on an accusation nobody at Bramblecourt had actually decided was safe to repeat, because nobody had ever been handed the job of deciding.
Within that same week, Callum was formally named the policy owner for anything the summarizer or flagging model touched, with legal and trust and safety co-authoring the written rules and holding a hard veto on a short, specific list: anything that could repeat an unverified serious accusation, anything touching a protected characteristic, and anything a court order had already restricted.
The first real test came a month later, when Callum approved a rule that turned out to be slightly too permissive, letting a summarizer draft repeat a claim it shouldn't have. Because the decision was versioned and dated, the team traced it back to the exact rule within minutes, rolled the summarizer back to its safer prior behavior the same day, and the affected business had a direct appeal channel instead of a generic support ticket.
I want to say the summarizer was broken. It wasn't. It did exactly what an unconstrained language model does with an accusatory sentence: it smoothed it into confident, readable prose. Nobody had told it, or the humans reviewing its output, where that particular line was supposed to be drawn.
We wrote "content policy" as a legal compliance document because that's whose job policy documents had always been. It took one restaurant owner's furious phone call, and three capable people each waiting a beat too long to answer "whose call is this," to see that a policy nobody's actually accountable for enforcing isn't a policy. It's a legal team's private notes.
SPARK, the anchor that actually shippedNot a review board. SPARK is what forces one name onto the decision before the next borderline case shows up.
The recap, one line per letter: situation is three teams each waiting on the others, payoff is a day-and-a-half decision instead of eleven, anchor is the single named owner with a narrow legal veto, risk is the versioned rollback that survived a wrong call, and keep out is the deliberately narrow scope.
And if you want to be sure it really works, try it somewhere elseSame five letters, a podcast hosting platform instead of a reviews site. This time the harm concentrates differently, and the owner sits somewhere else.
Farrowdale Podcasts hosts independent shows and runs an AI tool that generates transcript-based tags for ad placement, occasionally misattributing a controversial statement to the wrong speaker when an episode has overlapping voices. Petra Vantoor, who owns that feature, ran the same SPARK anchor and landed somewhere different. Situation: a misattributed statement risks a real, named person being publicly linked to something they never said. Payoff: hosts stop worrying that a transcription error could put words in their mouth in a way that spreads before anyone corrects it. Anchor: here the policy owner sits in trust and safety, not product, since the core harm is about factual misattribution between named individuals, a legal-adjacent risk from the start, not a product-experience judgment call. Risk: a misattribution ships anyway; the recovery path is a same-day correction pinned to the episode plus a direct outreach to the host, not just a quiet backend fix. Keep out: the policy doesn't yet cover fully AI-generated show notes, only the transcript-tagging feature that's actually shipped.
Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "one named owner, a narrow legal veto, and a versioned decision you can trace," and stop.
Cost: there's no headcount to formally staff a policy-owner role this quarter. Say so honestly, and start by naming an existing PM as the interim owner in writing, rather than leaving the gap open.
The model gets better, for real: if the summarizer's overall accuracy improves, the ownership question still matters just as much, since a better model is still capable of confidently repeating the one accusation nobody wrote a rule about.
Where people run it wrong.
They build a review committee instead of naming one accountable person, which slows every decision to the pace of the slowest member.
They give legal a veto over everything, not just named high-risk categories, which turns every decision into a queue.
They write the policy as a legal document instead of a versioned, testable product spec anyone can actually check a decision against.
How to use it live. When someone asks who should own a content policy, ask yourself first: if a borderline case showed up right now, whose name would actually be on the decision. If you can't answer in one word, that's the real gap to fix.
Flashcards (tap any card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"What happens when a new AI feature touches a category the policy never anticipated?" Response: the narrow, versioned scope means a gap gets noticed and added quickly, since the policy is a living, dated document, not a static one nobody revisits.
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on Responsible AI as a product requirement
- #1 How do you turn a responsible AI principle into a testable product requirement?
- #2 What safety requirements belong in every AI PRD regardless of feature?
- #3 Describe how you would assess a feature for potential harm before building it.
- #4 Explain the difference between a safety issue and a quality issue.
- #5 How would you handle a feature that works well overall but poorly for one demographic?
- #7 Design the guardrails for an AI feature aimed at teenagers.