How to Write a PRD for AI Features (With Template)

Your traditional PRD assumes deterministic behavior. Input X always produces output Y. The system either works or it doesn't.

AI features don't work that way. The same prompt can produce different outputs on consecutive runs. "Correct" isn't binary. A feature that works 94% of the time might still ruin your users' trust because the 6% failure rate happens to cluster on your most important use case.

According to Product School's 2026 research, 94% of product professionals now use AI frequently in their workflows, yet most teams still write requirements for AI features the same way they write requirements for a settings page. The result: engineering builds what you specified, QA can't figure out how to test it, and users encounter failure modes nobody anticipated.

This post covers the six sections that separate a functional AI PRD from a wishful-thinking document. If you're building AI features in 2026, your PRD needs to account for probabilistic behavior, define failure modes explicitly, and set acceptance thresholds your team can actually measure.

For general PRD guidance, see our PRD guide and how to write a PRD that engineers actually read. This post focuses specifically on the sections that AI features demand.

Why Traditional PRDs Fail for AI Features

A standard product requirements document assumes three things that AI features violate:

1. Deterministic outputs. Traditional software returns the same result for the same input. AI doesn't. Ask an LLM to summarize the same document twice and you'll get two different summaries.

1. Binary pass/fail testing. You can write a unit test that asserts calculateTax(100) === 7. You can't write a test that asserts "the AI-generated email sounds professional." Quality is a distribution, not a boolean.

1. Failure means broken. In traditional software, a bug is a clear deviation from expected behavior. In AI, "failure" is a spectrum: the output might be slightly off, confidently wrong, or subtly biased. Each requires a different response.

Miqdad Jaffer, Product Lead at OpenAI, frames this shift well: an AI PRD isn't a feature spec, it's a behavioral contract. You're not specifying what the system builds. You're specifying how it should behave, how it should fail, and what happens at the boundaries.

This is why teams that copy their standard PRD template and add "uses AI" to the description end up in trouble. The hardest parts of an AI feature aren't the happy path. They're the failure modes, edge cases, and confidence boundaries that traditional PRDs never address.

The 6 Sections Every AI PRD Needs

Beyond the standard PRD sections (problem statement, user stories, success metrics, scope), AI features require six additional sections. Skip any of them and you'll discover the gap in production.

Section 1: Model Behavior Specification

This is where you define what the AI should do, not as a feature description but as a behavioral contract with measurable criteria.

Instead of: "The AI generates a summary of the uploaded document."

Write: "The AI generates a 3-5 sentence summary of the uploaded document that:

• Captures the document's primary conclusion
• Mentions at least 2 of the top 3 supporting arguments
• Contains no information not present in the source document
• Reads at a Flesch-Kincaid grade level between 8 and 12"

The behavioral spec gives your team something testable. Engineers know what to optimize for. QA knows what to evaluate. Designers know what "good" looks like.

Key elements to include:

• Output format and structure
• Quality rubric with specific dimensions
• Tone, style, or voice requirements
• Input constraints (max length, supported formats, languages)
• Response time expectations (latency budgets)

Section 2: Acceptance Thresholds

Adaline Labs puts it bluntly: if your AI PRD lacks an acceptance threshold section, it's not an AI PRD yet. This is the section that makes quality measurable.

An acceptance threshold defines the minimum performance level across a representative set of inputs. It replaces the binary "works/doesn't work" with a quantified performance target.

Example thresholds for a document summarizer:

How to set thresholds:

Start with your users' existing workaround. If they currently spend 8 minutes reading a document to extract the key points, your AI summary needs to save meaningful time while maintaining accuracy. A 90% accuracy rate that saves 6 minutes is better than 99% accuracy that takes 5 minutes to verify.

Build your test set early. Collect 100-200 representative inputs that cover your expected distribution: short documents, long documents, technical content, ambiguous content, poorly formatted content. Run your model against this set and measure against your rubric before writing a single line of product code.

Section 3: Failure Mode Catalog

Every AI feature fails. The question is whether you've decided in advance what happens when it does.

The failure mode catalog is where you list every way the AI can go wrong and define the system's response. This is the section most teams skip, and it's the section that determines whether your feature builds or destroys user trust.

Common AI failure modes to address:

Hallucination. The model generates plausible but factually incorrect information. This is the most dangerous failure mode because users may not notice it.

System response options: Show confidence indicators. Ground outputs in source documents with citations. Add a "verify this" prompt for high-stakes outputs. Implement RAG (retrieval-augmented generation) to constrain the model's knowledge base.

Confidence collapse. The model can't produce a reliable answer but generates one anyway. Models don't naturally say "I don't know."

System response options: Set a confidence threshold below which the system shows a disclaimer, offers alternatives, or escalates to a human. Define what "low confidence" means for your specific use case.

Prompt injection. Users (intentionally or accidentally) provide inputs that cause the model to ignore its instructions. A user writes "ignore all previous instructions and..." in a form field.

System response options: Input sanitization. Output validation against behavioral constraints. Rate limiting. Separate system prompts from user inputs architecturally.

Bias amplification. The model produces outputs that reflect or amplify biases from its training data. A resume screening feature favors certain demographics.

System response options: Test with diverse input sets. Monitor output distributions. Implement fairness metrics. Add human review for high-stakes decisions.

Format degradation. The model returns outputs in unexpected formats. A feature expecting JSON gets markdown. A summary comes back as bullet points when you need prose.

System response options: Output validation and parsing. Retry logic with format-specific prompts. Fallback to a structured template.

For each failure mode, document three things: how the system detects it, what the user sees, and how the system recovers.

Section 4: Behavioral Constraints

Behavioral constraints define what the AI must never do, regardless of the input. This is different from the behavior spec, which defines what the AI should do.

Think of constraints as guardrails. They protect users when the model is technically responsive but wrong in ways that cause harm.

Examples:

• "Never provide medical, legal, or financial advice without a disclaimer"
• "Never generate content that could be used to impersonate a real person"
• "Never store or repeat personal information from user inputs in other users' outputs"
• "Never make claims about competitor products that aren't verifiable"
• "Never generate outputs longer than 2x the specified length"

Constraints are especially important for features where users have creative control over inputs. Chat interfaces, free-text generators, and any feature with an open prompt surface need explicit behavioral boundaries.

Use Forge to quickly generate an initial PRD with these constraint sections, then refine with your team.

Section 5: Evaluation Plan

Traditional QA tests whether the feature matches the spec. AI evaluation tests whether the feature performs within acceptable bounds across a distribution of inputs. Your evaluation plan needs to cover three types of testing.

Pre-launch evaluation:

• Benchmark testing. Run the model against your test set. Measure against acceptance thresholds. This happens before every model update, prompt change, or parameter tweak.
• Red-team testing. Have team members actively try to break the feature. Attempt prompt injection, submit adversarial inputs, test boundary conditions. Document what you find and add it to the failure mode catalog.
• A/B comparison. If you're replacing an existing workflow, compare the AI output against the human-produced equivalent. Measure accuracy, speed, and user preference.

Post-launch monitoring:

• Output sampling. Review a random sample of real outputs on a regular cadence. Start with daily reviews (100 outputs), then weekly as confidence builds.
• User feedback loops. Add thumbs up/down, "report an issue," or inline editing to every AI output. Track override rates (how often users modify the AI's output).
• Drift detection. Model performance degrades over time as the distribution of real inputs diverges from your test set. Define triggers for re-evaluation. Monitor accuracy metrics weekly.

Regression testing:

• Prompt change protocol. Every prompt modification runs against the full benchmark set. Define a maximum regression threshold (e.g., "no more than 2% drop on any dimension").
• Model upgrade protocol. When the underlying model updates (GPT-4 to GPT-4.5, Claude 3.5 to Claude 4), run the full evaluation suite. Don't assume a newer model is better for your specific use case.

If you're evaluating whether AI features are right for your product, our AI Readiness Assessment can help you gauge your team's preparation. For calculating the business case, use the AI ROI Calculator.

Section 6: Data and Privacy Requirements

AI features often process, store, or learn from user data in ways traditional features don't. This section needs to be explicit about data flows.

What to document:

• Training data. Is user data used to fine-tune or improve the model? If so, how is consent obtained? Can users opt out? What data retention policies apply?
• Input logging. Are user inputs logged for quality monitoring? For how long? Who has access? How are they anonymized?
• Output storage. Are AI outputs stored? Can they be linked back to specific users?
• Third-party data flows. If using an external API (OpenAI, Anthropic, Google), what data leaves your infrastructure? Review the provider's data usage policy.
• PII handling. How does the system handle personally identifiable information in inputs? Does the model strip, redact, or ignore PII before processing?
• Regulatory compliance. GDPR right to erasure, CCPA data deletion requests, HIPAA for health data, SOC 2 for enterprise customers. AI features often create new compliance requirements that traditional features don't trigger.

Putting It Together: AI PRD Template

Here's a condensed template you can adapt for your next AI feature. You can generate a full PRD using Forge and then add these AI-specific sections.

1. Problem & Context (standard PRD)

• User problem, business case, success metrics

2. Model Behavior Specification

• Behavioral contract with measurable criteria
• Output format, quality rubric, tone, latency budget

3. Acceptance Thresholds

• Performance targets per dimension
• Test set description and measurement method
• Minimum viable threshold vs. target threshold

4. Failure Mode Catalog

• Failure type, detection method, user experience, recovery
• Minimum: hallucination, confidence collapse, format degradation

5. Behavioral Constraints

• Hard boundaries the AI must never cross
• Input/output guardrails

6. Evaluation Plan

• Pre-launch benchmarks and red-team protocol
• Post-launch monitoring cadence and metrics
• Regression testing for prompt/model changes

7. Data & Privacy

• Data flows, retention, consent, third-party usage
• Compliance requirements

8. User Stories (adapted for AI)

• "As a user, I want to see a confidence indicator so I know when to double-check the AI's output"
• "As a user, I want the AI to explain its reasoning so I can catch errors"

Common Mistakes in AI PRDs

After reviewing dozens of AI feature specs from teams of all sizes, these mistakes show up repeatedly:

Specifying the model instead of the behavior. "Use GPT-4 to generate summaries" is an implementation detail, not a requirement. Specify the behavior you need and let engineering choose the best model. Models change frequently. Your requirements shouldn't have to change with them.

Treating accuracy as a single number. "95% accurate" is meaningless without defining accurate against what rubric, measured on what test set, and evaluated by whom. Break accuracy into dimensions (factual correctness, completeness, relevance, format compliance) and set thresholds for each.

Ignoring the latency budget. AI features that take 15 seconds to respond change the UX fundamentally. Specify latency requirements up front and design the interaction pattern accordingly (streaming, progress indicators, async delivery). Your RICE prioritization should factor in the UX cost of slow AI responses.

No fallback for when AI is unavailable. Model APIs go down. Rate limits get hit. What does the user see? A spinner forever? An error? A degraded non-AI version? Define it.

Writing requirements only for the happy path. The AI summarizer works perfectly on well-structured documents. What about scanned PDFs with OCR errors? Tables and charts? Documents in mixed languages? A slide deck with mostly images? Edge cases determine whether your feature is useful or frustrating.

Real Examples From Production AI Features

GitHub Copilot's approach to failure modes. Copilot doesn't just generate code suggestions. It signals confidence through suggestion length and timing. Single-line completions appear inline (high confidence). Multi-line suggestions require explicit acceptance (lower confidence). And the system degrades gracefully: when the model isn't confident enough, it simply doesn't suggest anything. No suggestion is better than a wrong suggestion.

Notion AI's behavioral constraints. Notion's AI writing assistant explicitly refuses certain categories of requests. It won't generate content that impersonates specific people. It won't produce legal or medical advice without caveats. These aren't bugs or limitations. They're deliberate behavioral constraints documented in the product spec.

Stripe's Radar fraud detection evaluation. Stripe publishes precision and recall metrics for their AI fraud detection. They define explicit thresholds: a false positive rate that's too high means legitimate transactions get blocked (bad for merchants). A false negative rate that's too high means fraud gets through (bad for everyone). The PRD for this feature had to balance these competing thresholds with measurable targets.

When to Use This Approach

Not every AI feature needs a 15-page PRD. Match the depth of your specification to the risk level:

Full AI PRD (all 6 sections): Features that generate user-facing content, make decisions that affect users, or handle sensitive data. Examples: AI-generated reports, automated customer responses, content moderation, recommendation engines.

Lightweight AI PRD (behavior spec + thresholds + key failure modes): Internal tools, developer-facing features, or features where a human always reviews the output before it reaches the end user. Examples: draft generators, internal search, code suggestions with mandatory review.

Standard PRD with AI notes: Features where AI is an implementation detail rather than a user-facing capability. Examples: backend optimization, A/B test allocation, internal data classification.

The AI Feature Triage Tool can help you assess whether a feature warrants a full AI PRD or a lighter-weight approach.