Every production prompt should have one accountable owner, usually the team that owns the feature it powers, plus a named reviewer outside that team for high risk prompts. Record both in a register so that when behavior changes, somebody is clearly responsible for finding out why.
Why ownership goes missing
Prompts are easy to write and easy to edit. A support lead adds a sentence, an engineer adjusts a format, a product manager pastes in a new tone guide. Six months later, nobody can say who last changed the customer facing assistant's instructions or who should be told when it behaves badly.
Without an owner, nobody retires old prompts, nobody checks the origin of copied text, and nobody answers the auditor.
The three roles
| Role | Responsibility |
|---|---|
| Owner | Accountable for behavior, keeps the register entry current, approves changes |
| Reviewer | Independent check on changes that widen access or alter constraints |
| Escalation contact | Reachable when the owner is away, decides during an incident |
Keep the owner a team or a role rather than a single person, so a departure does not leave the entry empty.
What the owner is accountable for
- Inventory. The prompt is listed with purpose, location and version.
- Origin. The register says whether the text was written in house or adapted from outside.
- Inputs. The owner knows which slots take untrusted text and what the model can do with it.
- Change control. Edits go through review, as set out in how to version and review prompt templates in Git.
- Testing. A regression set exists and runs on change.
- Retirement. Unused prompts are removed, not left to be rediscovered.
A register entry
name: ticket-summarizer
owner: support-platform team
reviewer: appsec
location: prompts/ticket_summarizer.txt
origin: written in house, tone section adapted from vendor sample
untrusted inputs: ticket_body
model can call tools: no
last reviewed: 2026-10-19
Eight lines is enough. Keep it in the repository next to the prompt.
Risk tiers keep the process light
Not every prompt needs the same scrutiny. Use two tiers.
- Higher risk. The prompt controls tools, touches personal or regulated data, or produces customer facing claims. Needs a reviewer from security or compliance, a regression set and a change record.
- Lower risk. An internal summarizer with no tools and no sensitive data. The owner can approve changes, with the register entry kept current.
Decide the tier when the entry is created, and move it up whenever the prompt gains a tool or a new data source.
When ownership is shared
Prompts used by several products are the hardest case. Name one owner for the shared text and make each consuming team a listed user who is told about changes. Avoid copying the prompt into each product, since the copies drift apart and each needs an owner of its own.
Warning signs
- Edits made in a vendor dashboard that nobody reviews.
- A register entry whose owner left the company.
- Two services with slightly different copies of the same prompt.
- A prompt gaining a tool without a change in tier.
Quick check
Can the person who writes a prompt also approve it?
For low risk prompts, yes. For prompts that control tools or sensitive data, have someone else review.
Where should the register live?
In the same repository as the prompts, so entries change in the same pull request as the text.
Last reviewed: 19 October 2026.
