PRD Template for AI Products in Regulated Industries

This is a fill-in-the-blank PRD template built specifically for AI/ML products in regulated industries - Life Sciences & Healthcare, financial services, government. Standard PRD templates ignore model behavior, data dependencies, and regulatory approval cycles. This one doesn't.

Instructions: replace everything in [brackets] with your actual content. Guidance notes appear in italics below each field. Delete guidance notes before sharing externally.

PRD: [Product/Feature Name]

Author: [Name, role]\

Version: [e.g., 0.3 - Draft / 1.0 - Approved]\

Last Updated: [Date]\

Status: [Draft / In Review / Approved / Deprecated]\

Stakeholders: [Engineering Lead, Clinical Lead, Compliance, Data Science, Product]

1. Problem Statement

Current State: [Describe the workflow, pain, or gap that exists today. Be specific about what happens manually or fails.]

Guidance: One paragraph maximum. If you need more than a paragraph to describe the problem, you don't understand it well enough yet.

Desired State: [Describe what success looks like for the user and the business when this product exists.]

Why Now: [What changed that makes this the right time to build? Regulatory change, new data availability, competitive pressure, clinical evidence?]

Scope:

  • In scope: [explicit list]
  • Out of scope: [explicit list - this is often more important than in-scope]

2. User Personas

Guidance: AI products in regulated industries often have 3-4 distinct personas with different risk tolerances and success definitions. Don't collapse them into one.

Primary User

Role/Title: [e.g., Oncology Nurse Practitioner]\

Context: [Where are they when they use this? Under what time pressure?]\

Goal: [What outcome matters to them?]\

Current workaround: [What do they do today without your product?]\

Success signal: [How would they describe "this product is working" in their own words?]

Secondary User

Role/Title: [e.g., Clinical Informaticist]\

Context: [...]\

Goal: [...]\

Success signal: [...]

Compliance/Oversight Persona

Role/Title: [e.g., IRB, Compliance Officer, QA]\

What they need from this product: [audit trail, explainability, override log, etc.]

3. Model Requirements

Guidance: This section is the core of an AI PRD. Vague accuracy targets ("should be highly accurate") are not requirements. They are wishes. Make them measurable.

3a. Performance Targets

| Metric | Minimum Acceptable | Target | Measurement Method | | --- | --- | --- | --- | | Accuracy (overall) | [e.g., 85%] | [e.g., 92%] | [held-out test set, n=[x]] | | Sensitivity / Recall | [e.g., 90%] | [e.g., 95%] | [clinical validation cohort] | | Specificity | [e.g., 80%] | [e.g., 88%] | [same cohort] | | AUROC | [e.g., 0.88] | [e.g., 0.93] | [prospective validation] | | Latency (p50) | [e.g., 800ms] | [e.g., 400ms] | [production load test] | | Latency (p95) | [e.g., 2s] | [e.g., 1.2s] | [production load test] | | Throughput | [e.g., 100 req/min] | [e.g., 500 req/min] | [stress test] | | Uptime SLA | [e.g., 99.5%] | [e.g., 99.9%] | [monitoring dashboard] |

3b. Failure Modes

Acceptable failure mode: [e.g., "Model returns low-confidence flag and defers to human, rather than returning incorrect high-confidence output"]

Unacceptable failure mode: [e.g., "Model confidently predicts normal when patient is deteriorating"]

Failure budget: [How many false negatives/positives are acceptable per 1,000 predictions before the product is pulled?]

3c. Explainability Requirements

Required: [Yes/No and why]\

Format: [e.g., SHAP feature importance, attention weights, plain-language rationale]\

Audience: [clinician at point of care vs. QA review vs. regulatory submission]

4. Data Dependencies

Guidance: AI products fail at data more often than at model architecture. Be specific about what data you need, where it lives, and what needs to be true about it.

4a. Training Data

| Data Source | Volume | Owner | Access Status | PHI/PII? | | --- | --- | --- | --- | --- | | [e.g., EHR discharge summaries] | [e.g., 500K records] | [Data Engineering] | [DUA signed / pending / not started] | [Yes - de-identified] | | [e.g., Claims data] | [...] | [...] | [...] | [...] |

4b. Inference-Time Data

Required inputs: [List every field the model needs at inference time. Flag anything that may be missing or delayed in real workflows.]

Data freshness requirement: [e.g., "Patient vitals must be within last 4 hours"]

Missing data handling: [What happens if a required field is null? Imputation, error, degrade gracefully?]

4c. Labeling

Labeling method: [Clinical expert annotation, rule-based, proxy label]\

Annotator qualifications: [e.g., Board-certified [specialty] physician]\

Inter-annotator agreement target: [e.g., Cohen's kappa > 0.75]\

Label volume needed: [x labeled examples for training, y for validation]

4d. Data Pipeline

Batch vs. real-time: [Batch nightly / streaming / on-demand]\

Pipeline owner: [Team/person]\

Known gaps or risks: [e.g., "Claims data lags 30 days - not suitable for real-time inference"]

5. Regulatory Constraints

Guidance: This section should be written with your Regulatory/Compliance team, not by you alone. If you're in Life Sciences & Healthcare, this section may be longer than Section 3.

5a. Classification

Is this a medical device (SaMD)? [Yes/No/TBD]\

FDA classification (if applicable): [Class I / II / III | 510(k) / De Novo / PMA | exempt]\

Intended use statement: [Exact language for regulatory submission, if applicable]

5b. Applicable Regulations

  • HIPAA: [PHI present? BAA in place with all vendors?]
  • FDA SaMD guidance: [Total Product Lifecycle framework considerations?]
  • SOC 2 Type II: [Required by enterprise customers? Timeline?]
  • Other: [GDPR if EU data, 21 CFR Part 11 if e-records, state laws]

5c. Approval Timeline

Regulatory pathway: [...]\

Estimated clearance timeline: [e.g., 12-18 months for De Novo]\

Pre-submission meeting planned? [Yes/No - date]\

Impact on product launch: [Will regulatory gating delay MVP? What can ship as non-SaMD decision support?]

6. Feature Requirements

Guidance: Write requirements in the format "The system MUST/SHOULD/MAY [do X] so that [user/stakeholder Y] can [achieve Z]."

Must Have (P0)

  • The system MUST [requirement] so that [user] can [outcome].
  • The system MUST [requirement] so that [user] can [outcome].

Should Have (P1)

  • The system SHOULD [requirement] so that [user] can [outcome].

Nice to Have (P2)

  • The system MAY [requirement].

Audit and Logging Requirements

  • The system MUST log every prediction with: input hash, model version, output, confidence score, timestamp, user ID.
  • The system MUST log every user override of a model recommendation.
  • Logs MUST be immutable and retained for [x] years per [regulation].

7. Acceptance Criteria and Clinical Validation Plan

Guidance: "Works in testing" is not acceptance. For clinical AI, define the prospective validation study before you build the feature.

7a. Technical Acceptance

  • [ ] Model achieves [metric] >= [target] on held-out validation set of [n] examples
  • [ ] p95 latency <= [x]ms under [y] concurrent users
  • [ ] Zero critical bugs in staging environment after [x] days
  • [ ] All PHI access logged and auditable
  • [ ] Rollback procedure tested and documented

7b. Clinical Validation Plan

Study design: [Prospective shadow-mode / retrospective / RCT / pre-post]\

Site(s): [Which health systems, sites, or units]\

Sample size: [n, and how you calculated it]\

Primary endpoint: [Specific measurable clinical outcome]\

Secondary endpoints: [...]\

Duration: [Weeks/months of observation]\

Success threshold: [The number that lets you declare validation passed]\

IRB required? [Yes/No - if yes, submission date]

8. Rollback Criteria

Guidance: Define the tripwires before you deploy, not after something goes wrong. Rollback criteria are non-negotiable and owned by the clinical or safety lead, not the PM.

Automatic rollback triggers:

  • Error rate exceeds [x]% over any [y]-hour window
  • Model drift detected: accuracy drops below [z]% on weekly evaluation
  • Any report of patient harm directly attributed to model output
  • Latency p95 exceeds [x]ms for more than [y] minutes

Rollback owner: [Name and backup]\

Rollback time target: [e.g., full rollback within 30 minutes of trigger]\

Communication plan on rollback: [Who gets notified, via what channel, within what timeframe]

9. Success Metrics

Guidance: Pick 1-2 primary metrics. Everything else is secondary. If you have 10 primary metrics, you have zero.

Primary Metrics

| Metric | Baseline | Target at 30 days | Target at 90 days | | --- | --- | --- | --- | | [e.g., Time-to-diagnosis for [condition]] | [x hrs] | [y hrs] | [z hrs] | | [e.g., Workflow adoption rate] | [0%] | [30%] | [65%] |

Secondary Metrics

  • [User satisfaction NPS: target >= 7.0]
  • [Override rate: target < 20% - high overrides signal low trust]
  • [Time-to-first-value: target < 5 mins for new users]

10. Model Card

Guidance: Model cards are non-negotiable for regulated industries. Write one before clinical deployment. This section becomes a living document maintained by the ML team.

Model name and version: [...]\

Model type: [e.g., Transformer-based NLP classifier, gradient boosting, multimodal CNN]\

Training data summary: [Date range, institution sources, demographic breakdown if known]\

Known limitations: [Performance disparities by subgroup, known edge cases, out-of-distribution behavior]\

Subgroup performance: [Table of accuracy by age, gender, race/ethnicity if evaluated]\

Intended use: [Exact intended use, in regulatory language]\

Out-of-scope uses: [Explicitly list uses that are NOT validated]\

Training compute: [GPU hours, carbon estimate if tracked]\

Model card author: [ML lead name, date last updated]

This template is updated as I learn what breaks in regulated AI deployments. Last update: March 2026.

Related posts

Further Reading