Who owns the prompt in production?
Something breaks. The AI is giving weird responses. Customers are complaining. You gather the team and somebody asks what the current system prompt actually says.
Then three people pull out three different documents.
Nobody knows which one is live.
This happens more than people admit. The prompt starts as a product decision, gets cleaned up by engineering, tweaked by the AI team, then quietly edited by whoever raised the last incident ticket. Six months later it's a mess and nobody's the author.
The real problem isn't the prompt itself. It's that nobody owns it.
Prompts are software. We're not treating them that way.
Think about how your team handles an API contract. Versioned. Reviewed. With a named owner and a rollback plan.
Now think about how your team handles the system prompt.
For most organisations, honestly, it lives in a config dashboard. Or a Notion doc. Or someone's head. Changes get made in-place when something goes wrong and never revisited. What started as 200 tokens becomes 800 tokens, with sections that contradict each other, and nobody can tell you why.
The prompt is a contract with the model. It defines how your AI behaves for every user, every request, every second it's running. When that contract is ambiguous, the model doesn't throw an error. It just quietly drifts.
What ownership actually looks like
It's not about who writes the prompt. It's about who's accountable when it changes.
Before anything goes to production, you need one named person who signs off on changes. Not "product and engineering together." One person. Somebody who can be woken up at 2am and knows exactly what changed and when.
The prompt should live in your repo, not in a dashboard. Every change needs a commit message. Rollback should take less than five minutes.
And somebody needs to be watching what the model's actually doing in production. Not uptime. Not latency. Actual behaviour. Tone drift. Refusal rates. Edge cases you didn't think to test.
What a functioning setup looks like
A really simple way to think about it: author, review, deploy, monitor. The same loop you already use for code. The only difference is that most teams haven't applied it here yet.
Author it together. Product and engineering in the same room, agreeing on what the model should and shouldn't do. Not a ticket passed back and forth.
Version it properly. The prompt lives in Git. Every change has context. You can see the full history and roll back without drama.
Name an approver. One person who owns the decision to deploy a change. Not a committee, not a shared inbox. One person.
Watch the outputs. Not just "is it up" but "is it behaving the way we intended." Tone, refusals, edge cases. Set up evals before you need them, not after.
None of this is technically hard. The tooling already exists. It's a cultural problem, not an engineering one. Teams have just never been asked to apply the same rigour to prompts that they apply to code.
Before you ship your next feature
Ask yourself: if your prompt changed in production right now, would you know? Not eventually. Right now.
Would you know what it changed from, who changed it, and whether it's safe to roll back?
If the answer isn't a clear yes, you've got a gap worth closing before the next incident report lands on your desk.
What does prompt ownership look like in your organisation right now?
#AI #EnterpriseArchitecture #AIEngineering
