ConceptIntermediateResponsible AI & Advanced Practice / Responsible AI as a product requirement / #6

What is a content policy and who should own it in a product organization?

SPARK the product is Bramblecourt Reviews, and its AI tool that summarizes reviews into a short blurb

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.

The direct answer
A content policy is a named, versioned rule set about what AI-touched content is allowed to say, with one accountable owner, not a legal document nobody outside legal reads. At Bramblecourt, that owner sits in product, since they can make a fast, testable call, but legal and trust and safety co-author it and hold a hard veto on specific categories, like anything that could repeat an unverified serious accusation.
Do this, in order
  1. Name one product owner for the policy, not a committee.Why: a decision three teams can each veto is a decision nobody actually owns.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Stage 1
Scope it to one real feature
Say it like this
"I'll answer this for Bramblecourt's AI review-summarizer, since that's where an undefined content policy actually caused a problem."
Why this works
Keeps an abstract governance question tied to a feature that could really fail.
Stage 2
Name your structure
Say it like this
"I'll use SPARK: the situation today, the payoff we want, the one anchor decision, the risk it has to survive, and what we'd deliberately leave for later."
Why this works
Signals a real design decision is coming, not a definition off a slide.
Stage 3
Say the situation today
Say it like this
"Right now, when the summarizer produces something borderline, product, legal, and trust and safety each think it's someone else's call, so it just doesn't get made until something forces it."
Why this works
Grounds the anchor decision in a real, painful gap instead of an abstract governance debate.
Stage 4
Give the anchor decision
Say it like this
"One named product owner decides the policy day to day. Legal and trust and safety co-author it and hold a hard veto only on named high-risk categories, like anything defamation-adjacent."
Why this works
This is the actual answer to "who should own it," stated as a decision, not a definition.
Stage 5
Prove it survives being wrong
Say it like this
"When the owner approves a rule that's too permissive and a bad summary ships, the rollback and fast-appeal channel are already built in, so one wrong call doesn't become a lasting harm."
Why this works
Answers the follow-up before it's asked: what happens when the named owner gets it wrong.
Stage 6
Say what's deliberately out of scope
Say it like this
"This policy covers the summarizer and the flagging feature that exist today. It doesn't try to pre-write rules for every AI content feature we might ship next year."
Why this works
Shows judgment about scope instead of a wish list that never ships.
Stage 7
Close on the definition
Say it like this
"So: a content policy is a named, versioned rule about what AI-touched output can say, owned by one person in product, with legal holding veto on the categories that actually need it."
Why this works
Closes on the exact definition the question asked for, now backed by a real decision.

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.

Knowledge spark: what's a hard veto category? A specific, named list of content types where a reviewer's "no" always wins, no matter what the product owner thinks. Everything outside that list is the owner's call. Narrow on purpose, so the veto stays fast instead of becoming a bottleneck on every decision.

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.

Time to decide a policy question, before and after a named owner
0 11 days Before, three teams guessing 1.5 days After, one named owner
Nearly eight times faster once one person, not three departments, was actually responsible for the answer.

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.

The decision I would take back We merged "write the legal compliance policy" and "decide what the AI feature is actually allowed to output" into one document that nobody ever operationalized day to day. That made sense back when Bramblecourt shipped one AI feature a year and legal could reasonably weigh in on each one personally. It stopped making sense once several AI features were shipping in parallel and legal review became a queue nobody wanted to join uninvited.

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 summarizer didn't break a rule. There had never been a rule, only three teams, each quietly assuming someone else had written one.

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.

Hand sketched metaphor scene titled A policy nobody opens. Left panel, a document icon labeled Unowned, caption a document nobody opens. Right panel, a person icon labeled Named, caption one owner, a real sign-off.
Same words on the page, either way. Only one of these two actually gets enforced.

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.

Hand sketched comparison diagram titled Before and after. Left panel, a box icon labeled Before, caption three teams guessing, 11 days to decide. Right panel, a person icon labeled After, caption one named owner, two reviewers, 1.5 days.
The gap wasn't a lack of good judgment anywhere in the building. It was that judgment had nowhere assigned to land.

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.

Hand sketched icon list titled Signs nobody owns your policy. Five items: a document icon labeled no version number anywhere, a gauge icon labeled decisions take over a week, a scale icon labeled legal hears about it after launch, a person icon labeled no single name attached, a funnel icon labeled no appeal path exists.
Bramblecourt's actual content policy, before that week, had all five of these signs at once.

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.

Hand sketched labeled parts diagram titled What's in a content policy. Center document icon labeled Content Policy, with five callouts: named categories, a named owner, reviewers with veto, version number, rollback path.
Five parts. Before that week, Bramblecourt's policy had exactly one of them, written down somewhere legal kept it.

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.

Hand sketched decision tree titled The day the owner is wrong. Root: policy owner sets a rule. Two branches: too permissive leads to rollback plus fast appeal, too strict leads to owner adjusts next cycle.
The anchor doesn't require the owner to be right every time. It requires being wrong to be fast and cheap to fix.
Hand sketched flow diagram titled How a policy question gets decided now. Five boxes: question raised, owner reviews highlighted, veto categories checked, decision versioned, appeal path opens.
Five steps, and the whole thing now runs in about a day and a half instead of eleven.

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.

S
Situation. Today, without an owner.
Product, legal, and trust and safety each assumed a borderline case was someone else's call, so it often didn't get made at all until forced.
Grounds the whole design in a real, painful gap, not an abstract governance debate.
P
Payoff. The habit we want.
Teams stop shipping content-touching AI features hoping nobody asks a hard question, and start getting a real answer within a day and a half.
Names the behavior change the whole design exists to cause.
A
Anchor. The one concrete decision.
A single named product owner decides day to day. Legal and trust and safety co-author it and hold a hard veto only on a short, named list of high-risk categories.
The hardest step, and the actual answer to "who should own it."
R
Risk. What breaks when the owner is wrong.
A too-permissive call shipped once. Versioning let the team trace it in minutes, roll it back the same day, and gave the affected business a direct appeal.
The anchor survives being wrong, which is what makes it a real design instead of a wish.
K
Keep out. What's not built day one.
No attempt yet to pre-write rules for every future AI content feature Bramblecourt might ship, only the summarizer and the flagging model that exist today.
A deliberately narrow scope, not a wish list that never ships.
Flagged outputs touching an undocumented category, over 14 months
60/mo 30/mo 0 Month 1 Month 14: 60/mo
By month 14, most of the summarizer's flagged output touched a category with no written rule behind it at all.

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.

Hand sketched decision tree titled The day the owner is wrong. Root: policy owner sets a rule. Two branches: too permissive leads to rollback plus fast appeal, too strict leads to owner adjusts next cycle.
Same shape as Bramblecourt's tree, but at Farrowdale the person holding the pen sits in a different department entirely.

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)

1 · THE FRAMEWORK
What framework fits "what is a content policy and who should own it"?
Tap to flip
ANSWER
SPARK: the situation today, the payoff wanted, the one anchor decision, the risk it must survive, and what's deliberately kept out.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Osric Vantry, who leads Bramblecourt's reviews-integrity team and tracks open policy questions on a whiteboard he photographs each shift.
3 · THE OLD HABIT
What did Callum used to do with a borderline policy question?
Tap to flip
ANSWER
Raise it in whichever meeting felt closest and wait, sometimes up to two weeks, since escalating felt like overstepping into another team's territory.
4 · THE ANCHOR
What's the one concrete design decision this answer settles on?
Tap to flip
ANSWER
A single named product owner decides day to day, while legal and trust and safety co-author the policy and hold a hard veto only on a short list of named high-risk categories.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Merging "write the legal compliance document" and "decide what the AI feature can actually say" into one policy nobody outside legal operationalized.
6 · THE NUMBER
Fill in the blank: naming a single policy owner cut the average decision time from 11 days to ___ days.
Tap to flip
ANSWER
1.5 days. Nearly eight times faster once one person was actually accountable for the call.
7 · THE REPLAY
Same too-permissive rule, redesigned ownership. What changes?
Tap to flip
ANSWER
The versioned decision gets traced in minutes, the summarizer rolls back the same day, and the affected business gets a direct appeal channel instead of a generic ticket.
8 · CROSS PRODUCT TRANSFER
Section 4 answers this again for a different product. Which product, and where does the owner sit differently?
Tap to flip
ANSWER
Farrowdale Podcasts' transcript-tagging feature. There, the owner sits in trust and safety instead of product, since the core harm is factual misattribution between named people.

Check yourself Score: 0 / 0

True or false
1. True or false: this answer recommends giving legal a full veto over every content policy decision, not just a named list of categories.
  • True
  • False
Show hint
Look at SPARK's anchor step.
Show answer
False. Legal's veto is deliberately narrow, a short list of named high-risk categories, so most decisions still move at the product owner's pace.
Multiple choice
2. Why did Bramblecourt's original content policy fail to prevent the restaurant incident, even though it existed on paper?
  • A. The policy document was too long for anyone to read.
  • B. It had no named accountable owner, so a borderline case had nobody clearly responsible for deciding it.
  • C. The summarizer model was outdated.
  • D. The restaurant owner never filed an official complaint.
Show hint
Look at "the decision I would take back."
Show answer
B. A policy nobody is accountable for enforcing isn't being followed loosely, it isn't being followed at all.
Fill in the blank
3. Fill in the blank: by month 14, flagged summarizer outputs touching an undocumented category had climbed to ___ a month.
Show hint
Look at the line chart in the SPARK recap section.
Show answer
60 a month. Up from 5 a month at launch, all with no written rule behind any of them.
Short answer, name the reversal
4. What old decision does this answer take back, and why did it make sense when it was made?
Show hint
Look at "the decision I would take back."
Show answer
Model answer: Merging the legal compliance document with the actual product rule into one unowned document. It made sense while only one AI feature shipped a year and legal could review each personally.
Short answer, where it wouldn't matter
5. Name a kind of AI-generated content issue at Bramblecourt that would NOT need to go through the full policy-owner process.
Show hint
Look at "what I would leave alone."
Show answer
Model answer: A summary blurb that just reads a bit dry or generic. The policy exists for named categories of real harm, not stylistic complaints about tone.
Short answer, apply it yourself
6. Pick an app you use with user-generated or AI-generated content. If something on it crossed a line, do you know whose job it would be to decide what happens next? What would you guess?
Show hint
Think about whether that decision would live with one named team, or bounce between several.
Show answer
Model answer: Most people guess "trust and safety" for a major platform, but can't name an actual person, which is exactly the gap this answer's anchor decision closes.
Before you close the answer
Why this works
Tests whether you can turn "who owns this" into a real, accountable design decision instead of naming a department, and whether you've thought through what happens the day that named owner gets it wrong.
Follow-up traps
"Isn't putting the owner in product a conflict of interest, since they're incentivized to ship fast?" Response: that's exactly why legal and trust and safety hold a hard veto on the specific categories where speed shouldn't win, not a general override.

"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.
If pressed
The versioning system logs not just the rule and its date, but which specific eval case prompted the change, so a future reviewer can see exactly what real example the policy owner was responding to.
From U2xAI Academy

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
Know more