AI system requirements and specification

“AI system requirements and specification” sounds like paperwork until you have to explain a model’s behavior to an auditor, a customer, or your own incident review team. ISO/IEC 42001’s expectation is simple: define what you are building, what “good” looks like, and what boundaries you will not cross, before engineering starts. That single move prevents most downstream governance failures: unclear scope, missing controls, untestable “accuracy” claims, privacy surprises, and last-minute ethical review.

For a Compliance Officer, CCO, or GRC lead, the operational goal is to create a repeatable requirements workflow that works for internal AI builds and third-party AI systems you configure or deploy. The output is not a slide deck. It is a version-controlled requirements specification with measurable acceptance criteria, clear ownership, and traceability into testing and monitoring. If you can’t point to “the requirements we approved” and “the tests that prove we met them,” you will struggle to show control effectiveness.

This page provides requirement-level implementation guidance you can implement quickly: who it applies to, what to do step-by-step, what artifacts to retain, and how audits usually fail.

Regulatory text

Requirement (excerpt): “The organization shall define and document requirements for AI systems before design and development.” ¹

Operator interpretation

You need a documented AI system requirements specification created before design and development begins, approved by accountable stakeholders, and managed under change control. The requirements must be detailed enough that engineering can build to them and assurance teams can test them. ¹

Plain-English interpretation (what this means in practice)

Before anyone trains a model, fine-tunes a foundation model, writes prompt chains, or integrates an AI API, you must answer and document:

• What is the AI system supposed to do (and not do)?
• Under what conditions will it be used, by whom, with what permissions?
• What performance and quality bar must it meet to launch?
• What harms are unacceptable, and what guardrails prevent them?
• What data is allowed, what is prohibited, and what legal/contract constraints apply?
• How will you verify it meets the requirements, and how will you monitor drift after release?

This is not limited to “functional requirements.” ISO expects “comprehensive requirements,” commonly including functional, performance, and ethical requirements, written early enough to shape design choices. ¹

Who it applies to

Entities

• AI providers building AI systems.
• AI users/deployers configuring, integrating, or operating AI systems (including third-party tools).
• Organizations using AI for internal operations where model outputs can affect decisions, customers, employees, or regulated activities. ¹

Operational contexts that count as “before design and development”

Treat this control as triggered when any of the following begins:

• You start solution design for an AI feature (requirements “discovery” is fine; building is not).
• You procure or select a third-party AI model/tool and plan configuration for production use.
• You begin data preparation specifically intended for training, fine-tuning, evaluation, or prompt/policy optimization.
• You begin building integrations, prompt flows, agent logic, or decision automation around AI outputs.

What you actually need to do (step-by-step)

Step 1: Create a standard AI Requirements Specification template

Make a single template used across teams. Keep it short enough that product teams will complete it, but strict enough that it is testable.

Minimum sections to include:

1. System overview and scope
   • Business purpose, in-scope workflows, out-of-scope workflows.
   • Users, user roles, and deployment environment(s).
2. Intended use and prohibited use
   • What decisions the AI may influence.
   • Explicit non-goals (e.g., “not used to make final credit decisions”).
3. Functional requirements
   • Inputs, outputs, integrations, human-in-the-loop steps.
4. Performance and quality requirements
   • Measurable acceptance criteria defined for your use case (e.g., evaluation criteria, thresholds, confidence handling).
5. Safety and ethical requirements
   • Harm categories relevant to the use case (bias, toxicity, unsafe advice, over-reliance, etc.).
   • Required mitigations (guardrails, escalation paths, refusals, disclosures).
6. Security requirements
   • Authentication/authorization, secrets handling, logging, threat assumptions.
7. Privacy and data requirements
   • Allowed/prohibited data elements, retention, access constraints, data provenance constraints.
8. Explainability/traceability requirements (as applicable)
   • What must be explainable, to whom, and what evidence is required.
9. Operational requirements
   • Monitoring, incident response hooks, fallback modes, model/prompt change control.
10. Verification plan

• What tests prove each requirement is met (link requirements to test cases).

This template is your operationalization of “define and document requirements … before design and development.” ¹

Step 2: Assign ownership and approval gates

Define RACI so the spec is not “owned by everyone and no one.”

A common workable approval set:

• Product owner: scope, intended use, user workflow.
• Engineering lead: feasibility, integration constraints, testability.
• Risk/Compliance: ethical requirements, governance constraints, launch criteria.
• Security: security requirements, logging, access control.
• Privacy/Legal (as applicable): data constraints, contractual limitations.

Add a release gate: no build work starts until the spec is approved and versioned.

Step 3: Translate risk assessment results into explicit requirements

If your AI risk assessment identifies risks, they must become requirements, not “notes.” Examples:

• If you identify risk of hallucinated instructions, add a requirement for refusal patterns and mandatory citations or escalation.
• If you identify discriminatory outcomes, add fairness evaluation requirements and constraints on feature inputs.
• If you identify privacy leakage risk, add prohibited training data requirements and redaction rules.

The value here is auditability: risks map to requirements, and requirements map to tests.

Step 4: Make requirements testable and traceable

For each requirement, include:

• Unique identifier (REQ-###).
• Acceptance criteria (what must be true to pass).
• Verification method (test type, dataset, reviewer, tooling).
• Evidence pointer (where results are stored).

A practical traceability matrix can be a table with columns: Requirement ID → Design element (model/prompt/policy) → Test case → Test result → Monitoring signal → Owner.

Step 5: Control changes (requirements baseline + change control)

Once approved, treat the requirements as a controlled baseline:

• Store in a version-controlled system.
• Require a change request for updates.
• Re-run impacted tests when requirements change.
• Record approvals for material changes.

This avoids the common failure mode where requirements drift informally and controls no longer match the shipped system.

Step 6: Extend to third-party AI systems (procured models/tools)

If you deploy a third-party AI system, you still “define and document requirements” for your use. Your requirements should include:

• Vendor-provided model limitations and your compensating controls.
• Data sharing constraints (what is sent to the provider, how it is retained).
• Required contractual terms (audit rights where possible, incident notification, subprocessor controls).
• Configuration requirements (guardrails, content filters, routing, logging).

Day-to-day, this becomes a procurement and onboarding gate: no production deployment without an approved requirements spec and verification plan.

Step 7: Operationalize with workflow tooling (so it survives reality)

Teams fail this control when it’s a document-only exercise. Put it into your intake workflow:

• Require the spec as part of the AI project intake ticket.
• Auto-route for approvals.
• Require the traceability matrix link before launch.

If you need a practical way to run this across many AI projects and third parties, Daydream can act as the system of record for requirements, approvals, and evidence collection, so you can answer audits without reconstructing decisions from Slack and Jira later.

Required evidence and artifacts to retain

Retain artifacts that prove “before design and development” happened, and that the requirements drove build and testing:

• AI Requirements Specification (versioned, dated, approved)
• Approval records (sign-offs, decision log, meeting minutes if used)
• Traceability matrix (requirements-to-tests-to-monitoring mapping)
• Verification plan and test cases tied to requirements
• Test results (evaluation reports, red-team results, QA outcomes)
• Data requirements evidence (allowed/prohibited data definitions; dataset summaries where appropriate)
• Change control records (change requests, impact assessments, re-approvals)
• Deployment readiness checklist that references requirement completion

Common exam/audit questions and hangups

Auditors and internal assurance teams usually probe these areas:

1. Timing: Show evidence the requirements existed before build started. They will look at timestamps, version history, and approvals.
2. Completeness: Do requirements include more than functionality (performance, ethical constraints, safety, data constraints)? ¹
3. Testability: Are requirements measurable, and is there a verification method for each?
4. Traceability: Can you trace a launched behavior back to a requirement and the test evidence?
5. Change management: What happens when the model, prompts, or training data changes?
6. Third-party scope: Do you define requirements even when the AI model is purchased?

Hangup to expect: teams present a product requirements doc that lacks AI-specific constraints, acceptance criteria, and verification mapping.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Requirements are aspirational (“high accuracy,” “fair outcomes”).
   Fix: Write acceptance criteria and a verification method. If you can’t test it, rewrite it.

2. Mistake: Requirements created after a prototype is already in motion.
   Fix: Put a gate in the intake workflow. “Prototype” still counts as development if it influences production direction.

3. Mistake: Ethics and safety handled as a separate memo.
   Fix: Embed ethical and safety constraints directly into the requirements spec and trace them to tests.

4. Mistake: No requirements for operational monitoring and fallback.
   Fix: Add operational requirements (monitor drift indicators, incident triggers, rollback/fallback mode).

5. Mistake: Third-party AI treated as exempt.
   Fix: Define requirements for your deployment context, plus compensating controls for vendor limitations.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat this as a best-practice control expectation under ISO/IEC 42001 rather than a cited enforcement-driven mandate. The practical risk is still material: unclear requirements lead to untestable AI deployments, inconsistent approvals, and weak incident response because nobody can point to the intended behavior versus observed behavior. ¹

Practical 30/60/90-day execution plan

First 30 days: Stand up the minimum viable requirements gate

• Publish the AI Requirements Specification template and a short completion guide.
• Define RACI and approval workflow.
• Add an intake gate: no AI build or third-party deployment begins without an approved spec.
• Pilot on one active AI initiative and one third-party AI tool.

By 60 days: Make it auditable and repeatable

• Add traceability matrix requirements (REQ → test → evidence).
• Standardize verification artifacts (evaluation report format, red-team checklist).
• Implement change control for model/prompt/data updates tied to requirement impacts.
• Train product and engineering on writing testable requirements.

By 90 days: Scale across the portfolio

• Inventory active AI systems and bring high-risk ones onto the template retroactively (document current state, gaps, remediation plan).
• Integrate the requirements gate with SDLC and procurement workflows.
• Centralize evidence storage and retrieval for audits (Daydream can serve as the evidence hub if you need workflow plus documentation control).

Frequently Asked Questions

What counts as “before design and development” for an LLM feature that starts as a prototype?

If the prototype will influence production design choices, treat it as development and require the requirements spec first. You can keep early requirements lightweight, but they must be documented and approved before building begins. ¹

Do we need separate requirements for the model and the overall AI system?

Often yes. The “AI system” includes the model plus prompts, policies, integrations, human review steps, logging, and monitoring. Write system-level requirements, then add model/prompt-level requirements where they carry distinct risks or test methods. ¹

We buy an AI tool from a third party. How can we define requirements if we don’t control the model?

Define requirements for your deployment context: allowed uses, data constraints, required logging, access control, and acceptance testing of vendor behavior in your workflows. Add compensating controls for vendor limitations and document them in the spec. ¹

What’s the minimum set of requirements categories auditors expect to see?

Expect scrutiny if your spec only lists features. Include functional requirements, performance/quality acceptance criteria, and ethical constraints at a minimum, then add security, privacy/data, and operational monitoring requirements based on the use case. ¹

How do we keep requirements “alive” after launch?

Put the requirements baseline under change control and tie changes to re-testing and re-approval. Treat model/prompt/data changes as changes that may invalidate prior verification evidence. ¹

Can we store the requirements in Jira/Confluence, or does it need to be a formal controlled document?

Either can work if you can prove version history, approvals, and linkage to testing evidence. The audit failure is not the tool; it’s missing traceability and weak change control.

Footnotes

1. ISO/IEC 42001:2023 Artificial intelligence — Management system