AI Adoption · Written and maintained by Haink’s AI adoption team · Updated July 2026 · 9 min read
Non-Functional Requirements for AI: The Quality Bar That Decides Trust
Functional requirements say what an AI solution does. Non-functional requirements (NFRs) say how well it must do it — its accuracy, latency, cost, reliability, safety, security, fairness, explainability, compliance and resistance to drift. In classic software the NFRs are the fine print. In AI they are where most of the risk lives, and skipping them is a leading reason a convincing demo never becomes a system anyone trusts.
Why NFRs carry the risk in AI
Classic software is deterministic: it either meets the spec or it has a bug you can reproduce and fix. An AI system doesn’t work that way. It is right most of the time, not always — it has a quality distribution, not a pass/fail state. That single fact rewrites the requirements:
- “Correct” stops being a guarantee and becomes a measured threshold over a representative test set.
- The interesting requirements are no longer “what does it do on a good input” but “what does it do when it’s unsure, wrong, or attacked” — and who catches the misses.
Which is why teams that specify only the happy path ship demos, and teams that specify the NFRs ship products. The NFRs are the bar that separates the two, and they belong in the quality section of the solution blueprint, agreed before the build — not discovered when the pilot meets real data.
The NFR reference for AI solutions
A complete AI spec sets requirements across all of these. Not every use case needs every row at full strength, but every row should be a deliberate decision rather than an omission.
| NFR | The question | How to measure it |
|---|---|---|
| Quality / accuracy | How often is the output good enough? | Task-success rate, precision/recall or an LLM-judged score over a held-out test set. |
| Latency | Fast enough for the workflow? | p50 and p95 response time under expected load. |
| Cost | Economical at real volume? | Cost per request × projected volume; watched for scale, not the demo. |
| Reliability | Available and graceful under failure? | Uptime target; defined fallback when the model or a dependency is down. |
| Safety / guardrails | What must it never produce or do? | Red-line tests; harmful-output and prompt-injection resistance rates. |
| Security | Is data and access protected? | PII-leak tests, access controls, prompt/response handling and retention. |
| Fairness | Does it perform evenly across groups? | Accuracy and error rates measured across relevant segments. |
| Explainability | Can a decision be understood and audited? | Traceability of inputs/outputs; a human-readable rationale where required. |
| Compliance | Does it meet the applicable rules? | Mapped obligations (human oversight, record-keeping) as testable checks. |
| Drift / maintainability | Will it stay good over time? | Monitoring for quality decay; defined retraining and rollback triggers. |
Two kinds of NFR: targets and red lines
Treating every requirement the same way is a common error. NFRs split into two categories that are managed completely differently.
Targets
Thresholds you optimize toward and can trade off against each other — “92% task success,” “p95 latency under 2s,” “cost per request under $0.03.” Graded, tunable, and balanced against one another.
Red lines
Hard constraints the system must never cross — never expose personal data, never give unsafe instructions, never act autonomously in defined cases. Pass/fail, non-negotiable, and no amount of accuracy buys them back.
Confusing the two is dangerous in both directions: treating a red line as a target (“we leak PII only 0.5% of the time”) is a breach waiting to happen, while treating a target as a red line (“must be 100% accurate”) sets an impossible bar for a probabilistic system and stalls the project.
Writing acceptance criteria for a system that’s right “most of the time”
Acceptance is the moment the NFRs become a contract. Because a single output proves nothing, acceptance is measured statistically over a representative, held-out test set the model hasn’t seen — plus behavior rules for the uncertain cases. A workable pattern has three parts: threshold targets, a confidence-based fallback, and red lines.
Worked example — a support-triage AI
- Accuracy: correctly routes
≥92%of tickets on a 500-ticket held-out set, versus a~78%human baseline. - Latency:
p95 < 2sat 3× current peak volume. - Cost:
≤ $0.02per ticket at projected annual volume. - Fallback: below
0.7confidence, route to a human rather than guess. - Red lines: never expose customer PII in a response; never auto-close a ticket flagged as a complaint.
- Drift: alert if weekly accuracy drops below
90%; retrain trigger at<88%.
Notice what this does: it accepts that the model will be wrong ~8% of the time and designs for it (a human catches the low-confidence cases), while making the truly unacceptable outcomes hard constraints. That is the shape of a defensible AI acceptance spec — and it’s exactly the discipline missing from the pilots that fail for lack of a success metric.
A real pattern: advisory first-pass, human sign-off
The support example isn’t hypothetical — the same NFR shape appears in delivered systems. In Haink’s computer-vision control for aviation MRO documentation, the AI classifies maintenance document pages and flags missing signatures, stamps and empty checklist cells — but it is scoped as an advisory first-pass: the specialist gives the final sign-off. That scoping is a non-functional requirement. In a domain where a false negative is safety-critical, the acceptance spec deliberately sets the AI’s role below full autonomy and keeps a human in the loop as a red line, rather than chasing an accuracy number high enough to remove them. The right NFRs sometimes decide the product’s shape, not just its grades.
Common mistakes
- No NFRs at all. The spec covers what it does and nothing about how well — so demo quality ships to production.
- Accuracy-only. A model that’s accurate but too slow, too expensive at scale, or unsafe still fails; NFRs are a set, not a single number.
- Unmeasurable requirements. “Must be reliable” isn’t testable; “99.5% uptime with a defined fallback” is.
- A 100% bar on a probabilistic system. Demanding perfection where a threshold plus a human fallback is the honest design.
- NFRs written after the build. Then they’re a report card, not a target — the value is in agreeing them up front.
NFRs, governance and the law
For higher-risk use cases, some NFRs aren’t optional — they’re mandated. Risk and regulatory frameworks translate directly into testable requirements for safety, transparency, human oversight and record-keeping. Two references worth mapping your obligations against: the NIST AI Risk Management Framework, a voluntary standard for building trustworthy AI, and the EU AI Act, which imposes graduated obligations by risk tier. The practical point for a blueprint: compliance is not a separate binder — it becomes specific NFRs and acceptance tests, and it connects to your wider AI governance.
Where NFRs sit in the design
NFRs are the quality layer of the solution blueprint, alongside the functional and technical design. They set the acceptance criteria the build is tested against, and they carry forward into rollout and operation — the monitoring, the drift triggers, the fallback — which is where the handover to implementation begins; see from blueprint to implementation. Several NFRs also trace back upstream: latency and cost depend on the architecture, and quality depends on data readiness. The measurable targets, in turn, become the inputs to measuring ROI.
The through-line is simple: for AI, the non-functional requirements are much of the product. A system that does the right thing 80% of the time, slowly, at a cost that doesn’t scale, with no plan for the 20% it gets wrong, has met its functional spec and failed completely. Set the bar — targets, fallbacks and red lines — before you build, and the build has something real to be measured against.
The quality bar, built in. The AI Solution Blueprint specifies non-functional requirements, success metrics, acceptance criteria and test scenarios alongside the functional, AI and technical design — so the solution is testable against an agreed bar, not a hope. For the security and compliance depth behind several of these NFRs, see security & compliance.
Frequently asked questions
What are non-functional requirements for AI?
They define how well an AI solution must perform — accuracy, latency, cost, reliability, safety, security, fairness, explainability, compliance and drift resistance — rather than what it does. For AI they carry more risk, because output is non-deterministic and “correct” becomes a measured threshold.
How do you write AI acceptance criteria?
Set statistical thresholds over a representative held-out test set, add confidence-based human fallback, and define red lines the system must never cross. Acceptance is measured over the set, not on a single output.
Target vs red line?
A target is graded and tunable (92% accuracy, sub-2s latency); a red line is pass/fail and non-negotiable (never leak PII, never act without a human in defined cases).
Why do AI NFRs matter more?
Because AI is right most of the time, not always — it has a quality distribution, so the NFRs are what separate a demo from a trustworthy production system.
Do NFRs include compliance?
Yes — obligations from the NIST AI RMF and EU AI Act become testable NFRs for safety, transparency, human oversight and record-keeping, especially for higher-risk use cases.
Set the bar before you build
The AI Solution Blueprint writes the non-functional requirements, success metrics and acceptance criteria into the design — targets, fallbacks and red lines — so the build has something real to pass.
Explore the AI Solution Blueprint Functional vs technical design →